RE: Uploaded "Why Multipath QUIC?" for 2020-10 Interim

[Florin Baboescu <[e-mail]>]

Hi Lucas,

When you say “Is it the intention to map QoS flows to QUIC streams?” In
short I can say yes. If it is available.  I consider though this to be an
orthogonal discussion to the multipath one and I believe it to be dependent
onto the current progress with the QUIC tunneling draft.

-Florin



*From:* Lucas Pardue [mailto:[e-mail]]
*Sent:* Monday, October 19, 2020 3:09 PM
*To:* Florin Baboescu <[e-mail]>
*Cc:* Spencer Dawkins at IETF <[e-mail]>; WG Chairs <
[e-mail]>; IETF QUIC WG <[e-mail]>; Flinck, Hannu (Nokia -
FI/Espoo) <[e-mail]>
*Subject:* Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim



Hey Florin,

On Mon, 19 Oct 2020, 22:56 Florin Baboescu, <[e-mail]>
wrote:

Hi Lucas,



Maybe you may want to rephrase your question as I do not think that we
discuss the use of MPQUIC as a transport for either QUIC or TCP.



The slides that we provided discuss the need of using MP-QUIC as a multi
path transport for both IP and Ethernet traffic. In the context of the 3GPP
ATSSS work the use of multiple accesses is done in the context of a Multi
Access (MA) PDU session. This session may be either of IP type or Ethernet
type. An IP type session may cover all the IP traffic associated with a
specific IP address/prefix at the UE. A PDU session may have multiple QoS
flows. A QoS flow is formed by the set of packets matched by a specific
Traffic Filter template on which a specific QoS profile is applied.

In a 3GPP system it is assumed that all the packets of the same QoS flow
are delivered in order between UPF (a network node, which may be seen by
someone as a “entry point” in the 3GPP core system) and the terminal. This
is done through the GTP tunneling between the core network (represented by
UPF) and access network (represented by gNB) and between the access network
and the terminal (UE) via PDCP layer.



In the ATSSS solution, MPQUIC is proposed as a transport solution between
the UPF and the terminal UE operating over multiple paths that may be
established between the UE and UPF. A multipath QUIC connection is
associated with a QoS flow as described above. In this context the
multipath QUIC connection needs to be able to provide in order delivery of
the packets associated with the same QoS flow.



The slides that we provide are supposed to describe a couple of use cases
in which multipath access is needed. A description of the current ATSSS
architecture is provided from what I’ve seen in Mirja’s presentation.



I hope this clarifies.



Thanks for the elaboration. So to cut to the chase, what are your
requirements here. Is it the intention to map QoS flows to QUIC streams?
That would provide in-order delivery within the stream, and reliability. Or
do you have something else in mind?



Cheers

Lucas



-Florin





*From:* Lucas Pardue [mailto:[e-mail]]
*Sent:* Monday, October 19, 2020 2:31 PM
*To:* Florin Baboescu <[e-mail]>
*Cc:* Spencer Dawkins at IETF <[e-mail]>; WG Chairs <
[e-mail]>; IETF QUIC WG <[e-mail]>; Flinck, Hannu (Nokia -
FI/Espoo) <[e-mail]>
*Subject:* Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim





On Mon, 19 Oct 2020, 22:25 Florin Baboescu, <[e-mail]>
wrote:

Hi Lucas,

Based on how the ATSSS-LL sender is implemented, in-order delivery of the
packets may not be guaranteed at the receiver side once multiple paths are
used.



What packets are you talking about here? Why does in-order delivery matter?
TCP and QUIC are designed to accommodate reordering. But QUIC specifically
offers no ordering guarantees across different streams.



Cheers

Lucas