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

[Lucas Pardue <[e-mail]>]

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