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
