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

[Gorry Fairhurst <[e-mail]>]

See a comment at the end.

On 20/06/2023 16:02, [e-mail] wrote:
>
> 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]> *De la part de* Gorry Fairhurst
> *Envoyé :* mardi 6 juin 2023 12:59
> *À :* [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.

If and when this moves to standards track, my take is that it could 
indeed be used with MP-DCCP.

The current maturity level of RFC6356 is EXP, that would make a 
statement advocating usage in a PS a DOWNREF, which I think we ought to 
avoid.

Gorry