On 30 Jul 2014, at 21:47, The IESG <iesg-secretary(_at_)ietf(_dot_)org> 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(_at_)ietf(_dot_)org 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/