Re: [tsvwg] WG Call for comments on intended document status for draft-ietf-tsvwg-multipath-dccp-08, by June 23rd 2023

[[e-mail]]

Dear Med,

Thank you for bringing in your view on the relationship between MPTCP and MP-DCCP.

At your suggestion to strengthen the paragraph on coupled congestion control, I have created a PR on this topic for further discussion: https://github.com/markusa/ietf-multipath-dccp/pull/195

Br

Markus

From: tsvwg <[e-mail]> On Behalf Of [e-mail]
Sent: Dienstag, 20. Juni 2023 15:58
To: Gorry Fairhurst <[e-mail]>; [e-mail]
Subject: Re: [tsvwg] WG Call for comments on intended document status for draft-ietf-tsvwg-multipath-dccp-08, by June 23rd 2023

Hi Gorry, all,

Targeting PS is consistent with other published effort in this area (RFC8684). This is even appropriate given that the spec leverages many aspects (primitives, for example) defined in RFC8684. For example, the following is mentioned vs. CC:

   Multipath TCP uses the coupled congestion control
   Linked Increases Algorithm (LIA) specified in [RFC6356] to solve this
   problem.  This scheme can be adapted also for Multipath DCCP.

This text echoes these parts from RFC8684:


   *  [RFC6356] (congestion control), which presents a safe congestion

      control algorithm for coupling the behavior of the multiple paths

      in order to "do no harm" to other network users.

and


   One algorithm

   for achieving this is presented in [RFC6356]; the algorithm does not

   achieve perfect resource pooling but is "safe" in that it is readily

   deployable in the current Internet.  By this we mean that it does not

   take up more capacity on any one path than if it was a single path

   flow using only that route, so this ensures fair coexistence with

   single-path TCP at shared bottlenecks.


I would expect a strong language in the following (e.g., s/proposed/used):


    This scheme could also be proposed for

   Multipath DCCP.  The same applies to other coupled congestion control

   schemes that have been proposed for Multipath TCP such as

   Opportunistic Linked Increases Algorithm [OLIA].

Given that we don't have a restriction about concurrent paths in MPTCP, I don't think it is justified to have one here, especially given the commonalties between these extensions with regards to the CC.

Thanks.

Cheers,
Med

De : tsvwg <[e-mail]<mailto:[e-mail]>> De la part de Gorry Fairhurst
Envoyé : mardi 6 juin 2023 12:59
À : [e-mail]<mailto:[e-mail]>
Objet : [tsvwg] WG Call for comments on intended document status for draft-ietf-tsvwg-multipath-dccp-08, by June 23rd 2023

The TSVWG has an active work item to develop a specification for MP-DCCP, and the WG Chairs are considering a request from the editors to publish on the standards track.

This topic was discussed at IETF-115 and IETF-116, and an update was then requested to clarify the position with respect to the use with concurrent multipath scheduling. New text on that topic has been included in the latest draft and the chairs are now asking if there are addional concerns or issues that the working group ought to consider, and specifically any comments on the proposal to publish this on the standards track.

This request for WG Feedback will run for 2 weeks, ending on June 23rd 2023. Please respond to this email thread if you have additional comments on the intended status of the specification.
Best wishes,
Gorry and Marten
(tsvwg co-chairs)
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-multipath-dccp/
Expectations for a PS are described in RFC 2026,  Section 4.1.1.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.