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.
Also, "adaptation layer" is not a new term; it is a very old term introduced by AAL5 and possibly earlier than that. Fred > -----Original Message----- > From: Dino Farinacci [mailto:farina...@gmail.com] > Sent: Thursday, December 09, 2021 7:53 AM > To: Pascal Thubert (pthubert) <pthub...@cisco.com> > Cc: Templin (US), Fred L <fred.l.temp...@boeing.com>; int-area@ietf.org > Subject: Re: [Int-area] Side meeting follow-up: What exact features do we > want from the Internet? > > > It's a bit unfair to generalize like this. There's the classical Internet > > with mail and streaming, and there are special applications. > > Well I am really not. The LISP design will fragment packets after it > encapsulates at the ITR so the ETR reassembles and then decapsulates. > So this "abstraction layer" is in, at least, one overlay architecture. > > It just shouldn't be encouraged. So, optimally, I suggest lower MTU > configuration on the source hosts. > > > 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. > > Understand. Fragmentation should not be encouraged though, if you can avoid > it. I realize there are IoT apps (even over LORA links) that > send really small packets that are still fragmented by a lower layer. > > > Note that from the IP perspective that's within the subnet, just like > > 802.11 ARQ is within one IP hop. => I'm not > > Right, and it isn't the average 20 hops from client to server. My > generalization is related to the IP layer and if fragmentation has to be done > by a link-layer between hops 15 and 16, so be it. > > > 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. > > Right, agree. > > Dino _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
