Re: [rmcat] RMCAT WGLC: draft-ietf-rmcat-sbd-05 - ends Dec 4

Colin Perkins <> Wed, 22 March 2017 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 677171294B1 for <>; Wed, 22 Mar 2017 10:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 kYCYYeMIKjXs for <>; Wed, 22 Mar 2017 10:39:27 -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 5989C1294E5 for <>; Wed, 22 Mar 2017 10:39:27 -0700 (PDT)
Received: from [] (port=62087 by with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1cqkEF-00009V-Fm; Wed, 22 Mar 2017 17:39:24 +0000
From: Colin Perkins <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2697BEA4-AC15-498F-A3D2-14A142C30876"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 22 Mar 2017 17:39:17 +0000
In-Reply-To: <>
Cc: "" <>, David Hayes <>
To: Anna Brunstrom <>
References: <> <>
X-Mailer: Apple Mail (2.3259)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: State = no_sa; Score =
Archived-At: <>
Subject: Re: [rmcat] RMCAT WGLC: draft-ietf-rmcat-sbd-05 - ends Dec 4
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 17:39:30 -0000


(Posting as an individual participant, not as WG co-chair)

I reviewed the changes in version -06 of this draft. Comments below.

> On 6 Dec 2016, at 18:35, Colin Perkins <> wrote:
>> On 13 Nov 2016, at 15:06, Anna Brunstrom < <>> wrote:
>> This email announces a RMCAT Working Group Last Call (WGLC) on:
>> Shared Bottleneck Detection for Coupled Congestion Control for RTP Media
>> draft-ietf-rmcat-sbd-05 <>
>> Due to the IETF week, this WGLC will run for 3 weeks, ending at midnight US Eastern Time on Sunday, December 4.  Comments should preferably be sent to the <> list, although purely editorial comments may be sent directly to the authors at <> - if doing so, please cc: the WG chairs at <>.
>> We are looking for at least a couple of reviews during WGLC, so please help review the document. 
> (Posting as an individual participant, not as WG co-chair)
> I’ve reviewed this draft. In general, I think it’s in very good shape, and suitable for publication as an experimental RFC. I do, however, have some comments:
> - If I understand correctly, the draft replies on feedback sent every T seconds, where T=350ms by default. Such feedback is, presumably, to be sent by RTCP, since that is the standard back-channel for RTP flows. The RTCP reporting interval depends on the allocated RTCP bandwidth, the number of participants, and the size of the RTCP packets, and can vary between tens of milliseconds and tens of seconds. It’s unlikely to be exactly 350ms, although values of that order are not unreasonable. To what extent does the proposed mechanism depend on the precise timing of the feedback, and what are the acceptable upper- and lower-bounds on the feedback interval if the mechanism is to work? It would be useful if the draft could include some discussion of this, to aid both implementors and those looking to design congestion control and feedback mechanisms. 

A note has been added in -06 saying:

    Note that the mechanism bases its calculations on the interval T.  It	
    does not require T to be the feedback interval, only that	
    calculations can be performed over measurements made in that	

I don’t think this is sufficient. How are the measurements made? The draft suggests using draft-ietf-rmcat-feedback-message but that doesn’t provide measurements over the same timescale. It might be reasonable to use this, or some other XR block, with aggregation across multiple reports, but the draft should explain – or at least, outline – what aggregation needs to be done, and how.

> - Section 3.3.1 has a sequence of steps that start “group flows whose…”. I find this a little hard to follow, in particular it’s not clear what flows are left ungrouped after each stage. Would changing these steps to start “From the remaining set of ungrouped flows, group those flows whose…” reflect the intent and be clearer? 

The revised text is still not clear. It says, for example, “Subdivide freq_est groups”, but doesn’t say what a “freq_est group” is. Similarly for the other steps. If the goal is that step 3 sub-divides the groups identified in step 2, for example, then say that.

> - Are the mechanisms in sections 3.4 and 3.5 required to be implemented, or are the optional? Some normative language might help to make it clearer what an implementation should do with these. It’s not clear if they’re essential parts of the algorithm, or enhancements for some situations.
> - In general, for a protocol specification, I think the draft would benefit from a more prescriptive (“when this happens, do this”) style of writing. I don’t think that’s a blocker for Experimental, but something to consider if it’s later revised for standards track.
> - Section 4.1, 2nd paragraph: I assume the suggestion is that each flow should use its media clock? Do any issues that arise when trying to group flows that use RTP different clock rates (e.g., the case where the audio flow has an 8kHz clock and the video flow has a 90kHz clock)?

Perhaps I missed it, but this doesn’t appear to have been addressed.

> - The draft says little about how feedback is to be conveyed. Is the expectation that the information can be extracted from the standard RTCP reception reports, or maybe XR blocks? It would be helpful if the draft could either point to existing feedback mechanisms that are suitable, or state that RTCP extensions will be needed. 


Colin Perkins