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

Gorry Fairhurst <> Fri, 23 June 2023 06:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D2CBC1575A8 for <>; Thu, 22 Jun 2023 23:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 875aXjWuoaFF for <>; Thu, 22 Jun 2023 23:45:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7E2EBC1575A0 for <>; Thu, 22 Jun 2023 23:45:52 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id EEAB01B001B6; Fri, 23 Jun 2023 07:45:45 +0100 (BST)
Content-Type: multipart/alternative; boundary="------------xadFpJx06s3OLm0Hiu4iexlr"
Message-ID: <>
Date: Fri, 23 Jun 2023 07:45:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0
References: <> <> <BE1P281MB1652CA9B069FA5274ED80C16FA5CA@BE1P281MB1652.DEUP281.PROD.OUTLOOK.COM>
From: Gorry Fairhurst <>
In-Reply-To: <BE1P281MB1652CA9B069FA5274ED80C16FA5CA@BE1P281MB1652.DEUP281.PROD.OUTLOOK.COM>
Archived-At: <>
Subject: Re: [tsvwg] WG Call for comments on intended document status for draft-ietf-tsvwg-multipath-dccp-08, by June 23rd 2023
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Jun 2023 06:45:57 -0000

See a comment at the end.

On 20/06/2023 16:02, 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: 
> Br
> Markus
> *From:*tsvwg <> *On Behalf Of 
> *
> *Sent:* Dienstag, 20. Juni 2023 15:58
> *To:* Gorry Fairhurst <>;
> *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 <> *De la part de* Gorry Fairhurst
> *Envoyé :* mardi 6 juin 2023 12:59
> *À :*
> *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)
> 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