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: Wed, 15 Dec 2021 18:56:21 +0000

Alex,

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

The adaptation layer is that layer below the network layer but above the
data link layer. The group-degroup functions you are referring to would
apply at the adaptation layer send-side entry or receive-side exit. Those
sorts of capabilities are already out in the wild in some systems, but I
have not seen a formal IETF spec yet. This seems like something that
could be mentioned in an adaptation layer spec.

Fred

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Dec 2021 20:09:27 +0100

> could be mentioned in an adaptation layer spec.

It sure is in RFC 4944, although it took until RFC 8930 to mention some of the finer points of this.

Grüße, Carsten

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Dec 2021 10:58:26 +0100

Le 15/12/2021 à 20:09, Carsten Bormann a écrit :
> RFC 8930
It says:
>    VRB overcomes the limitations listed in Section 4.  Nodes do not wait
>    for the last fragment before forwarding,

I did not to fragment, but to re-group.

Fragmentation and reassembly happening at the sender and receiver 
respectively aims at dividing a big IP packet, such that to accomodate a 
particular MTU.

Grouping and de-grouping would happen too at the sender and receiver 
respectively, but its aim would be to create large packets, not small.

This group-degroup could help to reduce overhead on the network, and 
level a burst of packets at extremely high bandwidth into a more gentle 
sequenced flow.

An application generating very small packets sent over a huge bandwidth 
Ethernet makes such problem.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Dec 2021 09:53:03 +0100

Le 15/12/2021 à 19:56, Templin (US), Fred L a écrit :
> Alex,
> 
>> 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.
> 
> The adaptation layer is that layer below the network layer but above
> the data link layer. The group-degroup functions you are referring to
> would apply at the adaptation layer send-side entry or receive-side
> exit.

Yes, from a topology perspective that's where 'group-degroup' could sit.

 From an ISO layer perspective a 'group-degroup' would probably sit in an
adaptation layer, below IP and above data link layer.

A 'group-degroup' function can also be seen in the jumbogram software
mechanism, rather than in the frag-defrag mechanism.  The jumbogram
seems to be in the app layer (ApL?) whereas frag-defrag in the
adaptation layer (AdL?).

This makes wonder whether a group-degroup function would go into ApL or
rather in the AdL?

Whether or not the modern QUIC, rather than the older UDP and TCP,
includes a jumbogram mechanism and potentially group-degroup functions
could be explored.  Because IPv6 jumbograms are specified for TCP and
UDP (RFC2675 "jumbograms"), but not for QUIC.  This could further hint
on which layer is best for a group-degroup function, AdL or ApL.

Alex

  Those
> sorts of capabilities are already out in the wild in some systems,
> but I have not seen a formal IETF spec yet. This seems like something
> that could be mentioned in an adaptation layer spec.
> 
> Fred

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 17 Dec 2021 07:29:38 -0800

Hi, Alex,

> On Dec 17, 2021, at 12:53 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

Every function can and may occur at any layer in a layered protocol system. Aggregation and coalescing (what you’re calling group/degroup) already exists in Ethernet (grouping small packets to avoid the need for padding for min frame size artifacts from shared-access MAC mechanisms), TCP (to reduce per-packet overhead, often buried inside interface drivers), and applications (HTTP).

The idea that layer implies function or that functions uniquely exist at a single layer is one of the great failures of the original OSI model.

The other being that “layer” is ever an absolute, except for the transmission layer (i.e., the one where logical bits become physical symbols).

Joe

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 17 Dec 2021 15:36:56 +0000

Alex, I do not think there is any problem for QUIC. IPv6 Next Header field only takes
a value for UDP; it does not take a value for QUIC. It is QUIC's job to make sure that
everything beyond the UDP header is aligned properly for its own purposes.

Fred

> -----Original Message-----
> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Friday, December 17, 2021 12:53 AM
> To: Templin (US), Fred L <[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.
> 
> 
> 
> 
>