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

[Colin Perkins <[e-mail]>]

> On 13 Nov 2016, at 15:06, Anna Brunstrom <[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. 

- 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? 

- 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)?

- 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. 

Cheers,
Colin




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