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

[Florin Baboescu <[e-mail]>]

Also, please note that a MPQUIC based solution for ATSSS may be
complemented with MPTCP for example. In other words for a MA PDU session
one may setup a QoS flow all the TCP traffic. This traffic may be
associated with a MPTCP component. The default QoS flow of the MA PDU
session (associated with match *) may use the MPQUIC tunnel.

-Florin





*From:* Florin Baboescu [mailto:[e-mail]]
*Sent:* Monday, October 19, 2020 2:56 PM
*To:* 'Lucas Pardue' <[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



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.

-Florin





*From:* Lucas Pardue [mailto:[e-mail]
<[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