Re: [tsvwg] Further thoughts on maturity of multipath

[Lucas Pardue <[e-mail]>]

Hi,

I was not able to attend tsvwg so I might be missing the full context. But
the multipath QUIC draft is PS and I don't see any need to change it to
experimental. Partly because people are intending to use it for production
workflows that serve their needs, rather than some experiment to find
something out to feed into some future work. Yes, there may be certain uses
of multipath QUIC that can be novel. That's completely true for normal v1
QUIC too. But it doesn't mean the base thing needs to be marked that way.

Cheers,
Lucas

On Thu, Mar 30, 2023 at 1:02 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>.
>