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

From: David Hayes <[email-masked]>
Date: Thu, 08 Jun 2017 17:44:20 +0200

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, [email-masked] 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:            https://www.ietf.org/internet-drafts/draft-ietf-rmcat-sbd-07.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-rmcat-sbd/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-rmcat-sbd-07
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-sbd-07
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-sbd-07
>
> 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 tools.ietf.org.
>
> The IETF Secretariat

--
David Hayes

---

From: Colin Perkins <[email-masked]>
Date: Thu, 8 Jun 2017 23:45:27 +0100

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?

Cheers,
Colin

> On 8 Jun 2017, at 16:44, David Hayes <[email-masked]> wrote:
> 
> Hi,
> 

-- 
Colin Perkins
https://csperkins.org/