Re: [rmcat] New Version Notification for draft-ietf-rmcat-sbd-07.txt

Colin Perkins <> Thu, 08 June 2017 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40EDF129AF3 for <>; Thu, 8 Jun 2017 15:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HXXrQgNa3f3i for <>; Thu, 8 Jun 2017 15:45:33 -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 A60E61292D3 for <>; Thu, 8 Jun 2017 15:45:33 -0700 (PDT)
Received: from [] (port=42231 helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1dJ6BG-0001QM-T8; Thu, 08 Jun 2017 23:45:31 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Thu, 08 Jun 2017 23:45:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: David Hayes <>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: State = no_sa; Score =
Archived-At: <>
Subject: Re: [rmcat] New Version Notification for draft-ietf-rmcat-sbd-07.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: Thu, 08 Jun 2017 22:45:36 -0000

Hi David,

Thanks for making this update, and apologies for not responding earlier. The addition of the diagram and the new text around it helps tremendously – thank you! – and I think most of my concerns with the previous versions have been addressed.

I do still have some comments, however: 

Section 3.1.1 notes that the sender requires accurate OWD measurements, and suggests that these can be provided by draft-dt-rmcat-feedback-message. That draft provides relative one way delay metrics, and can be used to derive RTT measures, but can’t provide one way delay since the clocks aren’t synchronised. If relative one way delay is sufficient, and I’d guess it is, it'd be useful to clarify.

Also in that section, “The mechanism performs its calculation whenever it has received sufficient measurements in the feedback messages to cover the T base time interval.  The exact timing of these calculations will depend on the frequency of the feedback message” – I can see how to do this if the reporting interval is shorter than T, although there may be aliasing issues if they’re similar but out of phase. But, what should be done if the reporting interval is significantly larger than T? The answer is perhaps that SBD puts constraints on the RTCP reporting interval, but since that affects the reporting overhead the constraints need to be clearly documented. Maybe note that this bounds the maximum RTCP reporting interval based on the recommended value of T given in section 2.2?

Section 3.1.2: “the agreed summary statistics SHOULD be fed back” – use of SHOULD implies that there are circumstances when they might not be fed back. The draft should state what these are (I guess, if the rate is being calculated at the receiver, and the rate is fed back?).

Section 5.1: “Time stamp resolution such as that described by [I-D.dt-rmcat-feedback-message] should be sufficient” - I’m a little confused, since that draft doesn’t discuss the timestamp resolution. I think what this section is trying to say is that the “RTP media clock rate SHOULD be chosen to have resolution less than one hundredth of the typical path’s range of delays”? However, the media clock rate is determined by the payload format though, so this might not be possible to change. For example, audio formats generally use 8kHz clock, video often 90kHz – are these sufficient?


> On 8 Jun 2017, at 16:44, David Hayes <> wrote:
> Hi,
> This is an update of the draft that hopefully addresses all of the
> review comments (Thank you Colin!). Most changes are minor, the biggest
> change is the addition of a picture to illustrate the simple grouping
> algorithm.
> Kind regards,
> David
> On Thu, Jun 08 2017 at 17:38, wrote:
>> A new version of I-D, draft-ietf-rmcat-sbd-07.txt
>> has been successfully submitted by David Hayes and posted to the
>> IETF repository.
>> Name:		draft-ietf-rmcat-sbd
>> Revision:	07
>> Title:		Shared Bottleneck Detection for Coupled Congestion Control for RTP Media.
>> Document date:	2017-06-08
>> Group:		rmcat
>> Pages:		25
>> URL:  
>> Status:
>> Htmlized:
>> Htmlized:
>> Diff: 
>> Abstract:
>>   This document describes a mechanism to detect whether end-to-end data
>>   flows share a common bottleneck.  It relies on summary statistics
>>   that are calculated based on continuous measurements and used as
>>   input to a grouping algorithm that runs wherever the knowledge is
>>   needed.  This mechanism complements the coupled congestion control
>>   mechanism in draft-ietf-rmcat-coupled-cc.
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> The IETF Secretariat
> --
> David Hayes

Colin Perkins