Re: [tsvwg] Further thoughts on maturity of multipath

[Michael Tuexen <[e-mail]>]

> On 28. Mar 2023, at 12:03, Ian Swett <ianswett=[e-mail]> wrote:
> 
> I don't have a strong opinion on EXP vs PS, but the conceptual structure of MPTCP, MP-QUIC, and MP-DCCP don't seem equivalent to me.
Just for having a more complete list: we worked in the past (15 years ago or so) on
load sharing for SCTP:
https://datatracker.ietf.org/doc/draft-tuexen-tsvwg-sctp-multipath/

Best regards
Michael
> 
> On Tue, Mar 28, 2023 at 2:50 PM <[e-mail]> wrote:
> Dear all,
> 
> Thank you to everyone who participated in today's TSVWG discussion on the proposed section 3.9 for the MP-DCCP draft in the email below. The goal of this section is to provide a clear recommendation to implementers that concurrent path use is not a well-verified feature and therefore not appropriate to be implemented over the Internet. With this statement in the MP-DCCP draft, authors believe PS track can be followed instead of EXP. Certainly, this cannot guarantee that implementers will use MP-DCCP without the concurrent path usage feature over the Internet, but at least the proposed Section 3.9.1. and the existing statement in the draft that packet scheduling is out of scope indicate that this is experimental and therefore at the user's own risk.
> 
> Let me share my conclusion from the meeting and in particular the lack of discussion that I see in this context to reach a generally accepted consensus.
> 
> 
> 1. the voting results on the EXP->PS question during the meeting showed that more people have an opinion than have actually read the document or the suggested section 3.9, which was confirmed in another vote earlier. I would like to encourage these people, especially those who are not in favor, to comment on the mailing list. As the author, I did not receive any feedback from them during the meeting as to why they believe PS is not appropriate.
> 
> 2. I assume that the proposed text reflects a general dilemma of multipath in the IETF. Therefore, any conclusion related to the change of MP-DCCP draft from EXP to PS is part of a general multipath discussion that also affects the ongoing standardization of MP-QUIC, or is also related to the standardized MPTCP. Since the conceptual structure of MPTCP, MP-QUIC and MP-DCCP is pretty much the same, this should motivate those involved with these protocols to share their views here.
> 
> Br
> 
> Markus
> 
> From: tsvwg <[e-mail]> On Behalf Of Amend, Markus
> Sent: Donnerstag, 9. März 2023 19:45
> To: [e-mail]; [e-mail]
> Subject: Re: [tsvwg] Further thoughts on maturity of multipath
> 
> Hi Martin, all,
> 
> With the MP-DCCP draft-07 a version is now available which includes the latest reviews from Simone and IANA. So I now come to the discussion from the last IETF to change to "Proposed Standard". We, the authors, have below attached a text with the new section 3.9 to the "Step 4b" proposed by you for this. I am looking forward to the discussion.
> 
> --------------------------------------------------------------------------
> 
> ### 3.9 Path usage strategies
> 
> MP-DCCP can be configured to realise one of several strategies for path usage, via selecting one DCCP subflow of the multiple DCCP subflows within a MP-DCCP connection for data transmission. This can be a dynamic process further facilitated by the means of DCCP and MP-DCCP defined options such as path preference using MP-PRIO, adding or removing DCCP subflows using MP_REMOVEADDR, MP_ADDADDR or DCCP-Close/DCCP-Reset and also path metrics such as packet-loss-rate, CWND or RTT provided by the Congestion Control Algorithm.
> 
> Selecting an appropriate method can allow MP-DCCP to realise different path utilization strategies that make MP-DCCP suitable for end-to-end implementation over the Internet or in controlled environments such as Hybrid Access or 5G ATSSS.
> 
> #### 3.9.1 Path mobility
> 
> The path mobility strategy provides the use of a single path with a seamless handover function to continue the connection when the currently used path is deemed unsuitable for service delivery.
> 
> Some of the DCCP subflows of a MP-DCCP connection might become inactive due to either the occurrence of certain error conditions (e.g., DCCP timeout, packet loss threshold, RTT threshold, closed/removed) or adjustments from the MP-DCCP user.
> 
> When there is outbound data to send and the primary path becomes inactive (e.g., due to failures) or de-prioritized, the MP-DCCP endpoint SHOULD try to send the data through an alternate path with a different source or destination address (depending on the point of failure), if one exists. This process SHOULD respect the path prio configured by MP_PRIO or if not available pick the most divergent source-destination pair from the original used source-destination pair.
> 
> Note: Rules for picking the most appropriate source-destination pair are an implementation decision and are not specified within this document.
> 
> Path mobility is supported in the current Linux reference implementation [https://multipath-dccp.org/].
> 
> #### 3.9.2 Concurrent path usage
> 
> This method could be used to support a concurrent path utilization strategy, which allows multiple path resources to be aggregated for higher throughput.
> 
> Compared to the path mobility strategy, the selection of DCCP flows is a per-packet decision and part of the multipath scheduling process which is out of scope of this specification.
> 
> Concurrent path usage over the Internet can have implications. The choice of (coupled) congestion control, scheduler, and possible reordering function has performance and fairness consequences. Since this needs further investigation, it is recommended that concurrent path usage over the Internet SHOULD NOT be used.
> 
> Concurrent path usage is also supported in the current Linux reference implementation [https://multipath-dccp.org/].
> 
> --------------------------------------------------------------------------
> 
> 
> Br
> 
> Markus
> 
> From: tsvwg <mailto:[e-mail]> On Behalf Of Amend, Markus
> Sent: Freitag, 11. November 2022 15:22
> To: mailto:[e-mail]; mailto:[e-mail]
> Subject: Re: [tsvwg] Further thoughts on maturity of multipath
> 
> 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 <mailto:[e-mail]> On Behalf Of Martin Duke
> Sent: Donnerstag, 10. November 2022 11:44
> To: tsvwg <mailto:[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.