Hi Spencer, On Thu, Nov 12, 2020 at 1:22 PM Spencer Dawkins at IETF < [email protected]> wrote:
> I think "we need to establish some common ground on terms and > capabilities" is exactly right. > >> > If I understood David Scinazi's comment to me about this at the virtual > interim, he found the steering/switching/splitting characterization in my > presentation helpful, so I started working on an individual draft in Github > here - https://github.com/SpencerDawkins/draft-dawkins-q > <https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with-multipath> > *draft-dawkins-quic-what-to-do-with-multipath* > uic-what-to-do-with-multipath > <https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with-multipath> > - to begin capturing understandings of ways in which multiple paths might > be used, and different strategies for using them. > > The current version of the draft uses language that's ATSSS-specific, > although I don't think the ideas are closely tied to ATSSS. As I said in > the draft, > > This section uses terminology from 3GPP ATSSS {Access Traffic > Steering, Switch and Splitting, [TS23501]) to describe three > different patterns of packet forwarding that could be used when > multiple disjoint paths are available. Note that these terms > describe concepts that are not ATSSS-specific, and could apply to any > multipath environment. If terminology more accessible to IETF QUIC > working group participants presents itself, I'll change it. > > If people agree that common ground on terms and capabilities would be > useful, they are invited to contribute. > Hi Spencer, Reading the latest Markdown copy as an individual, and someone familiar with the QUIC world, I find that the definition of flow is a little too ambiguous. This is in part because it is not entirely clear to me what you mean by packets. One interpretation of packets would be QUIC packets, a different interpretation is application data. There are two examples of where I find this particularly confusing. First, "a "flow" is "a set of packets that share an ordering constraint"", is this ordering constraint based on QUIC packet numbers or something else? If you're intending to mean something like a stream, then I don't know where QUIC's control plane traffic fits. Secondly, the statement "This would allow "Traffic Splitting" for unordered QUIC datagram packets" is confusing because DATAGRAMS are frames in packets. Are you intending to say a packet that contains only DATAGRAM frames, or something else? Perhaps it's just me but I also find the term forwarding confusing. The only cases where this term is used in the QUIC Transport document are in relation to describing attacks that would copy and forward QUIC packets. For endpoint-managed multipath QUIC, I would assume that QUIC packets are synthesized with particular paths in mind and then sent on those paths. I wonder if a document such as this should talk more in terms of the multiple bytestreams that QUIC provides, which TCP (and MPTCP) does not. Leveraging QUIC streams seemed to be a use case enabler, either for redundantly sending overlapping ranges, for efficiently striping non-overlapping ranges for bandwidth, or for strict ordering. I think there could be more clarity about the control plane and data plane. IIUC an application might want to leverage splitting of stream data but only steering of the corresponding ACKs or retransmissions to a particular path (something like the highly-asynchronous Satellite use case) Cheers Lucas
