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:[email protected]] *Sent:* Monday, October 19, 2020 2:31 PM *To:* Florin Baboescu <[email protected]> *Cc:* Spencer Dawkins at IETF <[email protected]>; WG Chairs < [email protected]>; IETF QUIC WG <[email protected]>; Flinck, Hannu (Nokia - FI/Espoo) <[email protected]> *Subject:* Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim On Mon, 19 Oct 2020, 22:25 Florin Baboescu, <[email protected]> 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
smime.p7s
Description: S/MIME Cryptographic Signature
