Hello Dino: It's a bit unfair to generalize like this. There's the classical Internet with mail and streaming, and there are special applications.
In the IoT we do have adaptation layers (shims), one called 6LoWPAN and the other called SCHC (from LPWAN). Both provide fragmentation, because the L2 frames can range from 12 to several hundred bytes. Both provide optional fragment recovery because losing a fragment can be really harmful and lead to congestion collapse and stalled devices. Note that from the IP perspective that's within the subnet, just like 802.11 ARQ is within one IP hop. => I'm not necessarily following Fred on generalizing to end-to-end fragment recovery for any flow, because of the usual interference problem with L4, but use cases such as IoT already require subnet-local protection that operates below IP on a smaller time scale. The related IoT RFCs (see RFC 8724 or RFC 8931) have provision for the timers not to interfere with upper layer ones, though in practice there's no TCP, and it's up to the application to manage what can be lost (e.g., what industrial people call buffered data), what needs protection, and mostly, what application "reply" can be considered an acknowledgment so you do not need a L4 one that's undesirable overhead. Keep safe; Pascal > -----Original Message----- > From: Int-area <int-area-boun...@ietf.org> On Behalf Of Dino Farinacci > Sent: jeudi 9 décembre 2021 2:44 > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > Cc: int-area@ietf.org > Subject: Re: [Int-area] Side meeting follow-up: What exact features do we > want from the Internet? > > 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 > <fred.l.temp...@boeing.com> 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 > > > >> -----Original Message----- > >> From: Dino Farinacci [mailto:farina...@gmail.com] > >> Sent: Wednesday, December 08, 2021 3:58 PM > >> To: Templin (US), Fred L <fred.l.temp...@boeing.com> > >> Cc: to...@strayalpha.com; 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. > >> > >> > >> > >> > >> > >>>> On Dec 8, 2021, at 5:33 PM, Templin (US), Fred L > <fred.l.temp...@boeing.com> 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= > > > > _______________________________________________ > 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
