> 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
