Re: [tsvwg] Further thoughts on maturity of multipath

[[e-mail]]

Hi Martin,


Thank you for your thoughts on the items we raised during the IETF 115 TSVWG meeting.


We believe that 4b is a feasible step. We are currently working on a draft version -07 that includes the final comments from Simone and IANA. Our plan is then to provide text for a concurrent path usage section on the mailing list.


Br

Markus

From: tsvwg <[e-mail]> On Behalf Of Martin Duke
Sent: Donnerstag, 10. November 2022 11:44
To: tsvwg <[e-mail]>
Subject: [tsvwg] Further thoughts on maturity of multipath

I reflected a bit more on the appropriate maturity level of MP-DCCP and MP-QUIC, and the result is perhaps a bit more nuanced than what I said at the mic.

1. After the presentations at IETF 115, I feel somewhat better about the maturity of MP-DCCP. That said, I have no strong opinion as to whether this has cleared the bar for standards track, and would be interested in the overall consensus of the WG.

2. As I stated at the mic, for all MP protocols I am concerned about a Proposed Standard that includes concurrent bulk delivery when we don't really know how to fairly apply congestion control or schedule data streams across multiple paths. Indeed, one reason I encouraged both the MP-DCCP and MP-QUIC work is to provide a good experimental platform for the research community to explore these questions.

3. However, that statement glosses over an important point. There are a variety of use cases that are *not* concurrent delivery. Failover and "hot standby" are sometimes supported by existing standards, but sometimes not (for example, QUIC supports client address changes but not server).

4. Stepping back from the question of how to spell this in documents, what I would like is for the non-concurrent cases to be standards track (assuming they are otherwise mature enough) while implementers are warned away from the concurrent use case unless they "know what they are doing".

4a. One way to do this would be to have a PS document that does not include concurrency while a smaller experimental extension covers concurrency.

4b. Another would be a PS document with a section concurrency that says, in some way, implementers SHOULD NOT do this unless they know what they are doing, perhaps outlining how this can be dangerous if you don't understand your traffic, etc.

5. I am not the responsible AD for QUIC, but I believe a similar framework is appropriate for MP-QUIC.

I'm happy to hear the community's thoughts on this.