Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 9 Dec 2021 01:41:55 +0000

> 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:[email-masked]]
> Sent: Wednesday, December 08, 2021 3:58 PM
> To: Templin (US), Fred L <[email-masked]>
> Cc: [email-masked]; [email-masked]
> 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 <[email-masked]> 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=

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 8 Dec 2021 19:43:50 -0600

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 <[email-masked]> wrote:
> 
> 
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Dec 2021 08:53:37 +0000

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

> From: Int-area <[email-masked]> On Behalf Of Dino Farinacci
> Sent: jeudi 9 décembre 2021 2:44
> Cc: [email-masked]
> Subject: Re: [Int-area] Side meeting follow-up: What exact features do we
> want from the Internet?
> 
> > 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
> >
> >>> 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.
> >>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 9 Dec 2021 14:36:30 +0000

Pascal, good info. I prefer to call it "adaptation layer" because that is what AAL5 called
it and what is essentially being done is AAL5 over heterogeneous Internetworks. But, the
fragment loss recovery mechanism is between tunnel endpoints in which the tunnel acts
as a link and the principles of RFC3366 apply. It is a best-effort retransmission service - not
a perfect one - and it is not true end-to-end because the tunnel endpoints are often not
co-located with the application endpoints (although they sometimes can be).

Fred

> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Thursday, December 09, 2021 12:54 AM
> To: Dino Farinacci <[email-masked]>; Templin (US), Fred L <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] RE: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?
> 
> 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.
> 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
> 
> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Dec 2021 09:53:23 -0600

> 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.

> 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 wha…

Right, agree.

Dino