> On 28. Mar 2023, at 12:03, Ian Swett <[email protected]> > 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 <[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.
