Hi, Lucas, On Thu, Nov 12, 2020 at 8:32 AM Lucas Pardue <[email protected]> wrote:
> 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, > Thank you for this. All of it is helpful to me. I'll work on incorporating your feedback in the draft. > 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? > I agree. The first comment I got about this draft was that I was using "flows" and "connections" almost interchangeably, and that wasn't helpful in my world, where so much will be relying on datagrams. So, yes, I need to work on clarity here. > 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. > That confusion sure wasn't intentional! Taking a quick tour through https://tools.ietf.org/html/draft-ietf-quic-transport-32#section-12 makes me think that I should be saying "sending". Does that sound about right? > 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 this is the kind of thing that needs to go in Section 2.3, now to be called Sending Strategies with Multiple Paths, if that's the right term. > 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) > Yes, I agree. The current sending strategies in Section 2.3 are roughly the non-ATSSS-specific strategies from ATSSS, which got me started, but this section will benefit from pushing down a level of detail or two. And your "redundantly sending overlapping ranges, for efficiently striping non-overlapping ranges for bandwidth, or for strict ordering" in the previous comment would be a helpful clarification. Thanks again so much for your thoughts. Much appreciated. Best, Spencer > > Cheers > Lucas >
