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.
On Tue, Mar 28, 2023 at 2:50 PM <[email protected]> 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 <[email protected]> On Behalf Of Amend, Markus > Sent: Donnerstag, 9. März 2023 19:45 > To: [email protected]; [email protected] > 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:[email protected]> On Behalf Of Amend, Markus > Sent: Freitag, 11. November 2022 15:22 > To: mailto:[email protected]; mailto:[email protected] > 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:[email protected]> On Behalf Of Martin Duke > Sent: Donnerstag, 10. November 2022 11:44 > To: tsvwg <mailto:[email protected]> > 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. >
