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

[Colin Perkins <[e-mail]>]

Hi.

> On 31 Mar 2017, at 13:01, David Hayes <[e-mail]> wrote:
> 
> Hi Colin,
> 
> We really appreciate you going through this again. Thank you!. We will
> work on clarifying the text you have highlighted and submit a revision
> of the draft.

Thanks.

> With the change to sender based congestion control, the SBD mechanism is
> also meant to be a user of the RTP Control Protocol (RTCP) Feedback for
> Congestion Control under development (though I have been unable to
> attend the last few design meetings). The feedback message still seems
> to contain all the per-packet information required by the SBD mechanism
> with the logic placed at the sender.

Okay, but please don’t forget to also discuss report aggregation and timing.

Colin



> Kind regards,
> 
> David
> 
> On Wed, Mar 22 2017 at 18:39, Colin Perkins <[e-mail]> wrote:
> 
>> Hi,
>> 
>> (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 <[e-mail]> wrote:
>>> 
>>>> On 13 Nov 2016, at 15:06, Anna Brunstrom <[e-mail] <mailto:[e-mail]>> 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 <https://datatracker.ietf.org/doc/draft-ietf-rmcat-sbd/>
>>>> 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 [e-mail] <mailto:[e-mail]> list, although purely editorial comments may be sent directly to the authors at [e-mail] <mailto:[e-mail]> - if doing so, please cc: the WG chairs at [e-mail] <mailto:[e-mail]>.
>>>> 
>>>> 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
>>    interval.
>> 
>> 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.
>>> 
>> 
>> Thanks,
>> Colin
> 
> 
> --
> David Hayes
> 



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