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 17:22:59 +0000

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:[email-masked]]
> Sent: Thursday, December 09, 2021 7:53 AM
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Templin (US), Fred L <[email-masked]>; [email-masked]
> 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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Dec 2021 11:33:05 -0600

> packet sizes larger than the path MTU even though IP fragmentation is invoked.

In loss-less networks. And what about firewalls, that forward packets they should be filtering because fragment 0 transport info is not available?

> and possibly earlier than that.

That wouldn't be a marketing strategy I would use, LOL.

Dino

---

From: Hesham ElBakoury <[email-masked]>
Date: Thu, 9 Dec 2021 10:14:50 -0800

I am not sure if these discussions are related to IP addressing which 
what we should focus on.

Thanks

Hesham

On 12/9/2021 9:33 AM, Dino Farinacci wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Dec 2021 12:16:47 -0600

Agree and wish we can get back on Dirk/Luigi's topic.

Dino

> On Dec 9, 2021, at 12:14 PM, Hesham ElBakoury <[email-masked]> wrote:
> 
> I am not sure if these discussions are related to IP addressing which what we should focus on.
> 
> Thanks
> 
> Hesham
>

---

From: Hesham ElBakoury <[email-masked]>
Date: Thu, 9 Dec 2021 10:19:16 -0800

Thanks Dino!

Hesham

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Dec 2021 13:48:16 +0100

> That wouldn't be a marketing strategy I would use, LOL.

Marketing strategy would probably accept new features in "Adaptation 
Layers v2."

A new feature in an ALv2 would be that instead of just a frag-reassembly 
from sender to receiver, one would consider group-degroup of packets 
too, to reduce overhead.  If this too is not already there in ALs.

Alex