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 > On Dec 1, 2021, at 4:08 PM, Dino Farinacci <farina...@gmail.com> wrote: > > Yes, I agree. > > Dino > >> On Dec 1, 2021, at 3:57 PM, Templin (US), Fred L <fred.l.temp...@boeing.com> >> 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:farina...@gmail.com] >>> Sent: Wednesday, December 01, 2021 3:06 PM >>> To: Templin (US), Fred L <fred.l.temp...@boeing.com> >>> Cc: Dirk Trossen <dirk.trossen=40huawei....@dmarc.ietf.org>; >>> int-area@ietf.org >>> 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 >>>> <fred.l.temp...@boeing.com> 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:int-area-boun...@ietf.org] On Behalf Of Dino >>>>> Farinacci >>>>> Sent: Wednesday, December 01, 2021 2:18 PM >>>>> To: Dirk Trossen <dirk.trossen=40huawei....@dmarc.ietf.org> >>>>> Cc: int-area@ietf.org >>>>> 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=40huawei....@dmarc.ietf.org> 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 >>>>>> Int-area@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/int-area >>>>> >>>>> _______________________________________________ >>>>> Int-area mailing list >>>>> Int-area@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/int-area >> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
