Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 2 Dec 2021 14:41:30 +0000

>Yeah - I often wonder what IP would look like if it were more like Ethernet, i.e., when you add shims (Q-tags or encapsulation), you don’t actually reduce the payload size.

Or even more like ATM.

>It’s somewhat counterintuitive, but it certainly puts the work of dealing with longer packets at the endpoints that made them bigger.

Yes, that is exactly right.

Fred

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, December 01, 2021 5:29 PM
To: Dino Farinacci <[email-masked]>
Cc: Templin (US), Fred L <[email-masked]>; [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]>
Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Yeah - I often wonder what IP would look like if it were more like Ethernet, i.e., when you add shims (Q-tags or encapsulation), you don’t actually reduce the payload size.

It’s somewhat counterintuitive, but it certainly puts the work of dealing with longer packets at the endpoints that made them bigger.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>

On Dec 1, 2021, at 4:08 PM, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

Yes, I agree.

Dino

On Dec 1, 2021, at 3:57 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Dino, we have an opportunity to bring true MTU diversity back to the Internet. We lost
that when the "fragmentation considered harmful" myth hit and gave way to the brittleness
of Path MTU Discovery. This is about righting a wrong that got put into the Internet because
people cut corners back in the 1980s and 1990s to meet scheduling deadlines instead of
working through the details. It doesn't have to be that way anymore.

Support for true MTU diversity in the Internet would yield better network utilization,
better per-flow performance based on lossless adaptive packet size tuning instead of
throwing away good data, elimination of MTU black holes, integrity assurance at the
correct layers and a technicolor variety of sizes instead of the black-and-white "1500
everywhere" we are currently stuck with.

We have also been falsely conditioned into believing that bridging L2 media with
dissimilar MTUs is infeasible, but we can begin to add that option to our capability
portfolio. That would open doors for network equipment vendors to bring out
revolutionary new products, and would allow network operators flexibility to
plug and play diverse equipment in ways that were never before possible.

This message addresses the MTU question only. Your message also indicated that
the different solutions have an equivalence of function for supporting the other
M's, but they are not equivalent.

Fred

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]]
Sent: Wednesday, December 01, 2021 3:06 PM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: Dirk Trossen <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?>

These are not user requirements. They are what a network engineer thinks should be supported. That's fine. But no user gives a damn about
MTU. And they don't care about multicast. They care about user group communication (like group texting on iOS and Android).

And 1, 2, 3 and 5 are covered under my user requirement definition. In other words, just keep the network up all the time no matter how my
physical connections change.

Dino

On Dec 1, 2021, at 2:27 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

My input is that we will want the "6 M's of Modern Internetworking", namely:

1.  Multilink - a Client's ability to coordinate multiple diverse
    underlying data links as a single logical unit (i.e., the OMNI
    interface) to achieve the required communications performance and
    reliability objectives.

2.  Multinet - the ability to span the OMNI link over a segment
    routing topology with multiple diverse administrative domain
    network segments while maintaining seamless end-to-end
    communications between mobile Clients and correspondents such as
    air traffic controllers, fleet administrators, etc.

3.  Mobility - a Client's ability to change network points of
    attachment (e.g., moving between wireless base stations) which
    may result in an underlying interface address change, but without
    disruptions to ongoing communication sessions with peers over the
    OMNI link.

4.  Multicast - the ability to send a single network transmission
    that reaches multiple Clients belonging to the same interest
    group, but without disturbing other Clients not subscribed to the
    interest group.

5.  Multihop - a mobile Client vehicle-to-vehicle relaying capability
    useful when multiple forwarding hops between vehicles may be
    necessary to "reach back" to an infrastructure access point
    connection to the OMNI link.

6.  MTU assurance - the ability to deliver packets of various robust
    sizes between peers without loss due to a link size restriction,
    and to dynamically adjust packets sizes to achieve the optimal
    performance for each independent traffic flow.

Fred Templin

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Wednesday, December 01, 2021 2:18 PM
To: Dirk Trossen <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

EXT email: be mindful of links/attachments.

Here's my single feature request the network layer should provide:

(1) I want to be connected ALL THE TIME, I want my computer to use all its links, either cabled or radio, ALL THE TIME.

(2) I do not want to turn on and off wifi to get my device/computer to connect when it is currently not connected. The network layer
should

do all this for me.

(3) I want it easy for people to find me (my IP address), so I don't want multiple addresses from the user level. I want one device ID, EID,
host address, whatever you want to call it. I want you to "ping <dino's-computer>".

Yes, I want host multi-homing and mobility. And I want it to work seamlessly.

Speaking as a user,
Dino

On Dec 1, 2021, at 12:52 AM, Dirk Trossen <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>> wrote:

Dear all,

Many thanks for those participating in the side meeting on Internet addressing during the IETF 112 week. As suggested during the
meeting, we want to take various points of discussion during the meeting onto the mailing list to continue discussion here on possible
ways

forward.

Specifically, we wanted to come back on the issue that a larger architectural discussion may be needed, a point that we make towards
the

end of the GA draft (https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/), but which was also core to
Dirk

K’s main point that only such architecture discussion may lead to possibly needed changes to addressing. We will be looking into such
possibly larger discussion along different possible avenues.

For our discussion here on the INT area list, we found Dino’s related suggestion particularly useful in that we may need a discussion on
what we (as users) may want from a network. We feel that our current GA draft may contribute to this question by observing that the
many

extensions to Internet addressing that we have gathered so far may be seen as an expression of a desired feature that those proposing
the

extension may want to see from the network. Hence, in addition to positioning those extensions as identified gaps to Internet
addressing,

we may want to formulate those extensions as desired features towards an extended Internet system, not just addressing; this can be
done

through suitably extending the GA draft with another section.

Why is this useful? We think that such view provides an observational input into the question that Dino suggests to answer, which in
turn

links to the larger architectural discussion that Dirk K suggests to have. While the overall architectural discussion may (and likely will)
touch

on more than ‘just’ addressing, we as a community may contribute to the discussion by rationalizing the work that has been done in this
space.

We would like to solicit thoughts on this proposed way forward as concrete steps for the community here on the list. Also, anybody
wanting to provide concrete input and contribution to this proposed revision of the draft is more than welcome.

Best,

Dirk
(on behalf of the co-authors)

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 9 Dec 2021 01:51:23 +0000

> Then you want some lower layer to the app to fragment. That is not a good idea.

I want an adaptation layer - that is a good idea. Again, all details have already
been discussed in previous emails.

Fred

> Sent: Wednesday, December 08, 2021 5:44 PM
> To: Templin (US), Fred L <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Then you want some lower layer to the app to fragment. That is not a good idea.
> 
> Dino
> 
> > On Dec 8, 2021, at 7:42 PM, Templin (US), Fred L <[email-masked]> wrote:
> >
> > 
> >>
> >> Does that mean no app should send more than 576?
> >
> > Dino, I am not sure what to say in response to this other than you must not be reading
> > my messages. I want apps to be able to use whatever packet size gives them the best
> > performance *even if the packet size exceeds the path MTU*. Also, to dynamically tune
> > their packet sizes in case network conditions change and even use jumbos if they want
> > and if the path will support it. If that has not come across to you, please go back and
> > read my messages.
> >
> > Fred
> >
> >> Sent: Wednesday, December 08, 2021 3:58 PM
> >> To: Templin (US), Fred L <[email-masked]>
> >> Cc: [email-masked]; [email-masked]
> >>>> On Dec 8, 2021, at 5:33 PM, Templin (US), Fred L <[email-masked]> wrote:
> >>>
> >>> Dino, my response to your response is "MTU diversity everywhere, with 576 as the
> >>> minimum cell size". I know Joe won't like that, but I can't get him to give a straight
> >>> answer.
> >>
> >> Does that mean no app should send more than 576? That would be a bug, a major performance bug. And you would be way too late to
> the
> >> table. If it was the minimum an app has to send, that is a bug too and tardy as well.
> >>
> >> So let’s move on to requirements again. I bet this list is bored with the topic.
> >>
> >> Dino=
> >

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 9 Dec 2021 18:28:08 +0000

Dino - see below:

> Sent: Thursday, December 09, 2021 9:33 AM
> Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> > Dino, 'iperf3' proves that applications can sometimes get better performance by using
> > packet sizes larger than the path MTU even though IP fragmentation is invoked.
> 
> In loss-less networks.

Not entirely lossless - that is why the adaptation layer has its own fragment retransmission
facility. And if loss becomes excessive, applications are simply asked to reduce the size of the
packets they are sending.

> And what about firewalls, that forward packets they should be filtering because fragment 0 transport info is not
> available?

That would be a spurious fragment. Spurious fragments are filtered through inspection
of the adaptation layer identification field regardless of whether transport info is available.

> > Also, "adaptation layer" is not a new term; it is a very old term introduced by AAL5
> > and possibly earlier than that.
> 
> That wouldn't be a marketing strategy I would use, LOL.

Not a laughing matter - some old networking concepts such as AAL5 and Catenet were
simply ahead of their time and that time has now come.

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 15 Dec 2021 19:29:37 +0000

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Wednesday, December 15, 2021 11:09 AM
> Cc: Alexandre Petrescu <[email-masked]>; [email-masked]
> On 2021-12-15, at 19:56, Templin (US), Fred L <[email-masked]> wrote:
> >
> > The adaptation layer is that layer below the network layer but above the
> > data link layer. The group-degroup functions you are referring to would
> > apply at the adaptation layer send-side entry or receive-side exit. Those
> > sorts of capabilities are already out in the wild in some systems, but I
> > have not seen a formal IETF spec yet. This seems like something that
> > could be mentioned in an adaptation layer spec.
> 
> It sure is in RFC 4944, although it took until RFC 8930 to mention some of the finer points of this.

Thanks for these references, Carsten. The adaptation layer I am thinking of is capable
of handling large packets, so my plan would be to spec the group/degroup function at
the jumbo level also.

Fred

> Grüße, Carsten