On 30 Jul 2014, at 21:47, The IESG <iesg-secretary@xxxxxxxx> wrote: > The IESG has received a request from the RTP Media Congestion Avoidance > Techniques WG (rmcat) to consider the following document: > - 'Congestion Control Requirements For RMCAT' > <draft-ietf-rmcat-cc-requirements-05.txt> as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2014-08-13. Apologies for the late response, but I have some extensive comments on this draft: - Requirement 1A states that the congestion control algorithm should try to keep delays to a minimum. I agree that this is a primary goal. However, as I noted at IETF 90, I think the draft should also include a secondary requirement to keep delay variation (jitter) down, where possible, since larger delay variation needs larger receiver-side buffers to compensate, increasing overall latency. - Requirement 1B states that the algorithm should react "quickly" to any reduction in bandwidth or increase in delay. The draft needs to define what quickly means in this context, since the expected timing could be different to other congestion control algorithms. Is the expectation that the response occurs with an RTT, or with next video frame, GoP, or talkspurt? This comment also applies to requirements 1C, 1E, 1F, and 4. - Requirement 1B uses an "increase in bottleneck delay" as a congestion signal, but it's not clear how the congestion control can distinguish an increase in delay at the bottleneck from an increase in delay elsewhere. Perhaps this should be “an increase in observed delay”? - Requirement 1C requires the congestion controller to react to interface changes. Does this apply to changes in the local interface only, or to changes in either the local or remote interface? One is a local matter, while the other requires signalling, so the distinction may be important. - Requirement 1D seems to describe possible behaviour of the system, but the requirement on the algorithm is not clear. Can you either clarify, or remove if there is no concrete requirement? - Requirement 1E states that "the algorithm must not overreact". Can you define (even approximately) what overreacting means in this context? Without this definition, it's not clear how this requirement could be translated into protocol behaviour. Similarly, what is "short-term"? - Requirement 1F states that the algorithm "must avoid too much delay buildup during those bursts". This is, at least partly, outside the control of the algorithm, since it depends on the behaviour of the cross traffic. Perhaps the requirement ought to be that the algorithm does not significantly increase the delay buildup during the bursts? - Requirement 2 states that flows should get "roughly equal" shares of bandwidth, but gives no definition of “roughly equal". I realise that this is a difficult issue, but some guidance, however approximate, would be helpful. - Requirement 2A is written in terms of "a useful share" of bandwidth. Again, defining "useful" would help: perhaps for the flow to ramp up to a bandwidth that allows it to support a minimal quality media stream? - Requirement 3A is unclear. Is the intent that there is no requirement that the algorithm compete equally with TCP flows that have different RTT? - Requirement 3B is unclear. Is the requirement that "the congestion control should prioritise achieving a useful (as defined in Requirement 2A) share of the bandwidth over achieving as low as possible transit delay, when these two requirements are in conflict"? - Requirements 4A, 4B, and 4C seem to describe possible behaviours of the system, but the actual requirements are unclear. Requirment 4A could be that the algorithm must reach a useful sending rate for audio calls fast enough that the initial "Hello" is not clipped; it's not clear how this applies to other media. - Requirement 5 is for "stable" behaviour, but it is not clear what stability means with discontinuous transmission, since the media will have an on-off profile that is not stable. - Requirement 5A lists possible behaviour for the algorithm, but it is not clear what requirement is being placed on an implementation. It "may adapt more quickly", but is it required to do so? Previous bandwidth estimates "may need to be aged or thrown away", but are they required to be? - Requirement 6 could be interpreted as requiring general multipath congestion control. Is that the intent, or is the goal only to share information between flows between two endpoint when those flows share a common bottleneck? - Requirement 6C gives a possible use for information, but it's not clear what requirement is being placed on implementations. - Requirement 8 talks about mechanisms, using RTCP feedback and/or header extensions. It's appropriate that this draft gives give general feedback requirements, but I don't think it should be making explicit requirements on how RTCP or RTP header extensions are used without justification, especially since the RMCAT working group has a milestone to produce a draft giving such recommendations. I suggest keeping requirement 8E, but removing the rest of requirement 8. I also noted some editorial issues: - The RMCAT working group should have a limited lifetime. Accordingly, the title might be better written as "Congestion Control Requirements for Interactive Real-time Media Transport”? - The 4th paragraph of Section 1 talks about "requirements for RMCAT" and "The RMCAT congestion control algorithm". I suggest these be changed to "requirements for congestion control of interactive real-time media" and "A congestion control algorithm for interactive real-time media". - The last paragraph of Section 1 states that terminology from the WebRTC overview is used. This is appropriate. It might also be appropriate to align with draft-ietf-avtext-rtp-grouping-taxonomy and cite that draft. - Requirement 1E talks about "short-term bursts (such as web-browsing)". This would be clearer if written "short-term bursts of competing traffic (such as web browsing)", since the bursts are not due to the congestion control algorithm. Colin -- Colin Perkins http://csperkins.org/