Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-05.txt

Colin Perkins <> Wed, 22 March 2017 23:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56A811270A7; Wed, 22 Mar 2017 16:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A0UHxMLu6rzl; Wed, 22 Mar 2017 16:33:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C9FC9127201; Wed, 22 Mar 2017 16:33:21 -0700 (PDT)
Received: from [] (port=48490 helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1cqpkl-0002wi-Cp; Wed, 22 Mar 2017 23:33:20 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Wed, 22 Mar 2017 23:33:18 +0000
Cc: "rmcat WG (" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
X-Mailer: Apple Mail (2.3259)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: State = no_sa; Score =
Archived-At: <>
Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-05.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Mar 2017 23:33:24 -0000


I’ve reviewed this draft while preparing the IESG write-up and request for publication. I have a number of minor questions and comments:

- Section 2 defines a Flow and gives an example as “an RTP session, or a sub-session that is multiplexed onto a single RTP session”. I believe this example is incorrect, and what is intended is “an RTP Stream [RFC7656], or a group of RTP Streams multiplexed onto a single RTP session” (Section 2.1.10 of RFC 7656 defines the term RTP Stream carefully, so I think a reference is useful; it also defines the term RTP Session in Section 2.2.2). Can you please check and update are necessary.

- Section 3 discusses limitations of the proposed algorithms. Would it be appropriate to add a brief applicability statement either here, or in the Introduction, stating that the described mechanisms are believed safe to use, but are experimental and are presented for wider review and operational evaluation?

- Section 5.1, bullet 1, notes that flows share a bottleneck if they’re sent on the same 5-tuple and have the same DSCP value. Should this also note that they need the same ECT mark? With the proposed L4S ECN experiments, we’re likely to see quite different behaviour between flows with NotECT/ECT(0) and those with ECT(1) marking. 

- Section 5.2 defines the priority in the range 0.1 to 1. Assuming 0.1 is correct, it might be worth adding a brief note to explain this choice, since readers might think it a typo for the more typical range of 0 to 1. 

- Section 5.2, in the paragraph following the bullet points, the draft suggests mapping priority levels from RTCWEB using the values 1, 2, 4, and 8 – how do these relate to the 0.1 to 1 range?

- Section 5.3 defines terminology and describes the two algorithms. The terminology used is inconsistent, sometimes using FSE_R and sometimes FSE_R(f). If the intent is that these are the same variable, the terminology should be aligned (I assume to FSE_R(f) since they’re per-flow values, but the important point is that it’s consistent). If there’s intended to be a difference between the overall and per-flow values, can you please check that they’re used consistently, and add a sentence to clarify the meanings of the terms. 

- Section 5.3 also uses P and P(i) in a manner that suggests they’re referring to the same parameter. Similarly for CC_R – should it be CC_R(i)?

- Appendix C: similar terminology comments apply.

- Appendix C: “highly experimental” – It might be useful to add a brief applicability statement for implementors so they know whether this is safe to deploy outside of testbed environments.


> On 22 Mar 2017, at 22:49, Colin Perkins <> wrote:
> WG,
> There were no objections, so the chairs will prepare the write-up for this draft to send to the IESG in order to request publication.
> Colin
> (as WG co-chair)
>> On 9 Dec 2016, at 23:26, Colin Perkins <> wrote:
>> WG,
>> The authors recently submitted draft-ietf-rmcat-coupled-cc-05. Following the discussion in the working group session at IETF 97 in Seoul, this moves the text on how to use coupled congestion control with the Google congestion control (GCC) algorithm from the main text to an appendix, and makes the reference to GCC informative. The rest of the document is updated to use NADA as the example, rather than NADA and GCC. These changes are intended to prevent the coupled congestion control draft from blocking on a normative reference to GCC, since the GCC draft is not yet finished. They are not intended to change the scope of the work.
>> The authors have also taken the opportunity to add some minor clarifications to the general recommendations, adding text on Stateful algorithms and Rate Jumps, in what is now Section 6.2 of the draft.
>> This draft has completed working group last call. However, since there was some discussion around these changes in the meeting, the chairs would like to re-open the working group last call for an additional week to ensure there are no objections. If you object to the changes in this version of the draft, please comment to the list by 16 December 2016. If there are no objections, the chairs will prepare the write-up to send this to the IESG in early 2017.
>> Colin
>> (as WG co-chair)
>>> On 7 Dec 2016, at 13:49, wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the RTP Media Congestion Avoidance Techniques of the IETF.
>>>      Title           : Coupled congestion control for RTP media
>>>      Authors         : Safiqul Islam
>>>                        Michael Welzl
>>>                        Stein Gjessing
>>> 	Filename        : draft-ietf-rmcat-coupled-cc-05.txt
>>> 	Pages           : 25
>>> 	Date            : 2016-12-07
>>> Abstract:
>>> When multiple congestion controlled RTP sessions traverse the same
>>> network bottleneck, combining their controls can improve the total
>>> on-the-wire behavior in terms of delay, loss and fairness.  This
>>> document describes such a method for flows that have the same sender,
>>> in a way that is as flexible and simple as possible while minimizing
>>> the amount of changes needed to existing RTP applications.  It
>>> specifies how to apply the method for the NADA congestion control
>>> algorithm, and provides suggestions on how to apply it to other
>>> congestion control algorithms.
>>> The IETF datatracker status page for this draft is:
>>> There's also a htmlized version available at:
>>> A diff from the previous version is available at:
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at
>>> Internet-Drafts are also available by anonymous FTP at:
>> -- 
>> Colin Perkins