Re: [tsvwg] Further thoughts on maturity of multipath

[[e-mail]]

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 <[e-mail]> On Behalf Of Amend, Markus
Sent: Freitag, 11. November 2022 15:22
To: [e-mail]; [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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Martin Duke
Sent: Donnerstag, 10. November 2022 11:44
To: tsvwg <[e-mail]<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.