Hey Florin, On Mon, 19 Oct 2020, 22:56 Florin Baboescu, <[email protected]> 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:[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 > > > > > > > >
