Re: [tsvwg] Further thoughts on maturity of multipath

[Ian Swett <[e-mail]>]

Apologies, in terms of the implications on simultaneously using multiple
paths at the same time, I agree that they're approximately equivalent.  In
other ways, the 3 protocols have more substantial differences.

On Thu, Mar 30, 2023 at 9:01 AM Anna Brunström <[e-mail]>
wrote:

>
>
>
>
> *From:* tsvwg <[e-mail]> *On Behalf Of *Ian Swett
> *Sent:* den 28 mars 2023 12:04
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [tsvwg] Further thoughts on maturity of multipath
>
>
>
> 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.
>
>
>
> Hi Ian, could you expand on what conceptual differences you see with
> respect to concurrent path usage? Is it related to safety or you are
> thinking of something else?
>
>
>
> The potential safety issues involved in concurrent use of more than one
> path seem conceptually similar to me for all three protocols (ask well as
> for SCTP), even if there are other differences between the protocols.
>
>
>
> The publication of MPTCP as PS suggests that concurrent path usage is
> considered safe. But I can agree with Martin that the use may have been
> mostly for particular use cases so far and perhaps not much general use and
> there is no coupled CC published as PS yet. It is also very easy to get
> wrong. From that perspective, I think it makes sense to leave general use
> of concurrent paths out of scope.
>
>
>
> Unless someone sees other safety issues, I am in favor of PS for both
> MP-DCCP and MP-QUIC. From my understanding, this will make it easier to
> make use of the protocols by other standardization organization. That seems
> desirable from an IETF perspective.
>
>
>
> BR,
>
> Anna
>
>
>
> 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.
>
> När du skickar e-post till Karlstads universitet behandlar vi dina
> personuppgifter <https://www.kau.se/gdpr>.
> When you send an e-mail to Karlstad University, we will process your
> personal data <https://www.kau.se/en/gdpr>.
>