Subject: Re: [rmcat] Last Call: <draft-ietf-rmcat-cc-requirements-05.txt> (Congestion Control Requirements For RMCAT) to Informational RFC

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Aug 2014 15:49:02 +0100

On 30 Jul 2014, at 21:47, The IESG <[email-masked]> 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
> [email-masked] 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/