Renames datagram mode into encapsulation mode in a separate document

[mpiraux]

• "lightweight mode" is now "tunnel mode"
• "datagram mode" is now "encapsulation mode"

[masputra]

Maxime, I have two high-level comments:

Section 3 begins with the sentence "If the client uses IP, then the concentrator can allocate an IP address to the client at the end of the authentication phase." Given that the draft does not elaborate this aspect of IP address allocation any further, I would suggest removing this sentence, or alternatively, indicate that IP address assignment is out of scope. I.e. it can be defined out-of-band (such as the 3GPP case using PDU session establishment), or even via other means such as DHCP or RA which can be carrier as payloads. I think it's worth making a note that they payload may be non-IP as well (e.g. Ethernet) if both endpoints agree on the inner protocol (such as IP or Ethernet) via out-of-band configuration.

Another comment is related to the QUIC tunnel control TLVs. I think it's good to give a short paragraph describing how these TLVs are exchanged. In the same QUIC connection, or a different one? If in the same QUIC connection, on a different stream, etc? That would help avoid confusion especially for some 3GPP participants who aren't familiar with the background of this draft.

Other than that, I think it looks good. It's simple enough to act as baseline, though we need to be careful of not adding too many things upfront esp. given that we're looking for WG adoption. On the naming, I see that the lightweight is now called tunnel. I think that's a good start, although the previously-called datagram mode (now called encapsulation mode) seems to be overlapping to some extent. I.e. both are tunnels and both have similar constructs. It seems to me, that the biggest difference between the two is the concept of "tunnel session". If so, how do you envision this session to be used for (in lieu of MP-QUIC)? Perhaps that could help us arrive at a proper name for each.

[mpiraux]

Section 3 begins with the sentence "If the client uses IP, then the concentrator can allocate an IP address to the client at the end of the authentication phase." Given that the draft does not elaborate this aspect of IP address allocation any further, I would suggest removing this sentence, or alternatively, indicate that IP address assignment is out of scope. I.e. it can be defined out-of-band (such as the 3GPP case using PDU session establishment), or even via other means such as DHCP or RA which can be carrier as payloads. I think it's worth making a note that they payload may be non-IP as well (e.g. Ethernet) if both endpoints agree on the inner protocol (such as IP or Ethernet) via out-of-band configuration.

Agreed.

Another comment is related to the QUIC tunnel control TLVs. I think it's good to give a short paragraph describing how these TLVs are exchanged. In the same QUIC connection, or a different one? If in the same QUIC connection, on a different stream, etc? That would help avoid confusion especially for some 3GPP participants who aren't familiar with the background of this draft.

Sec 6 is a bit lacking on the practical side indeed. Although it is explained later on in the format section, I will detail it there first.

On the naming, I see that the lightweight is now called tunnel. I think that's a good start, although the previously-called datagram mode (now called encapsulation mode) seems to be overlapping to some extent. I.e. both are tunnels and both have similar constructs.

Yes both tunnels packets effectively. "encapsulation" has a bit more elaborate encapsulation than "tunnel", but both are lying on the same paradigm side.

It seems to me, that the biggest difference between the two is the concept of "tunnel session". If so, how do you envision this session to be used for (in lieu of MP-QUIC)?

Indeed. And this by itself has little to do with the name "encapsulation". We added this mechanism considering that relying on Multipath, although simpler from an implementation perspective, could refrain adoption from a WG. But, adding a session mechanism with the "tunnel" mode has little practical sense without adding some metadata in the encapsulation. The use of the session and "encapsulation" mode we envisioned is to encode the transmission order of packets in the packet tag, either as a timestamp or as a sequence number, and then reorder at the receiver at will.

The session provides a common context for performing the reordering, just as a MPQUIC connection glues different network paths under the same connection context. It is still up to the application, i.e. the QUIC tunnel, to reorder incoming tunneled packets. We could also explore how the packet scheduler could be adapted to account for path characteristics, but that's advanced considerations as far as we are concerned now.

Maybe we could rename further "datagram" as "tunnel session", emphasing the similarity with the "tunnel" mode ? I remember 3GPP found the Protocol Type field not useful for their deployments but also I also have a sense that this would be valuable for more generic deployments that the IETF would care about.

[masputra]

I like "tunnel session"!

Thanks for considering these feedbacks, Maxime.