-----Original Message-----
From: rmcat [mailto:rmcat-bounces(_at_)ietf(_dot_)org] On Behalf Of Colin
Perkins
Sent: den 26 augusti 2014 11:48
To: Randell Jesup
Cc: rmcat(_at_)ietf(_dot_)org
Subject: Re: [rmcat] Last Call: <draft-ietf-rmcat-cc-requirements-05.txt>
(Congestion Control Requirements For RMCAT) to Informational RFC
Hi Randell,
That all sounds good - thanks!
Colin
On 26 Aug 2014, at 04:40, Randell Jesup <randell-ietf(_at_)jesup(_dot_)org>
wrote:
On 8/20/2014 8:14 AM, Colin Perkins wrote:
- 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.
I'm loathe to give a hard number here, and instead leave that to the
evaluation, since as with all things like this it's a tradeoff. I could
state that
"quickly" means a timescale on the order of RTT times (i.e. O(RTT)), and
certainly well sub-second. (IMHO, a congestion mechanism needs to adapt
down ASAP to avoid delay buildup it will then have to drain out).
I agree that we don't want to give a hard number, but I think some
guidelines
to set expectations would be useful. React within some small multiple of the
RTT
would seem appropriate, possibly with some wording about possible codec
constraints also (e.g., react on the next video frame, or maybe at the start
of the
next talk spurt)? Agree that sub-second reaction is desirable.
Saying "In this memo, a 'quick' reaction to congestion means..." would then
cover the later uses of the term.
Ok, I'll do that.
- 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"?
Sure.
- 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.
I would say local interface changes should be noticed and both
directions should take this into account if possible (for example as
a sender by restarting adaptation from a known startpoint, or
increase sensitivity/adaptation-rate temporarily in combination with
an immediate drop in send rate as a precaution). On the receive
side, it can indicate an interface change via RTCP, or just let the
other side adapt if the bottleneck has changed. (Indicating a
change may be preferable in order to more-intelligently adapt, but
may not be required, and might not even help or help much.)
Really I'm interested to see what the proposals find are the best way to
handle this problem, without constricting the solution space.
Agree, and agree that those are likely mechanisms for doing this.
Suggested wording changes?
Maybe something like "It should detect handover between different
interfaces (e.g., Wi-Fi to 3G) at sender or receiver, and signal these to the
congestion control algorithm where possible, to help the algorithm respond
quickly to such path changes"?
Ok, I'll come up with something like that.
- 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"?
"the algorithm must deal with traffic bursts caused by actions such as
webpage loading [by an aggressive browser/website combination]"? (with the
part in [] being perhaps removable). Again, the definition of "quickly" comes
into play.
Perhaps "Short-term bursts of competing traffic (e.g., due to local web
browser use) can saturate a local bottleneck link, but also clear quickly. The
algorithm needs to be able respond quickly to such events to help prevent
queue build-up; it is desirable if it can also quickly recover its sending
rate when
they conclude"?
That sounds pretty good, thanks
- 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?
Perhaps that's a good rewording; that's a tough/painful case since they
may
smoke your router's buffers regardless of what you do, so you may want to
keep sending at a "normal" rate or close once the algorithm realizes it's
lost the
battle (temporarily).
Sure, it's difficult. If it's a transient burst that fills the queue for a
short time
then disappears, then you want to back off to avoid making the situation
worse,
then continue, but if the competing traffic is determined to keep the queue
full,
you're better keeping sending and accepting the latency, and let the user
hang-
up if it gets too bad.
Right. Maybe I'll combine your original and some of that.
- 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.
This is "fair" of course. I'm not sure how I can say much more without
constraining the solution-space artificially. And it's worse because it's
not a
single-point measurement; defining it in detail would require looking at
startup
ramp, steady-state, reaction to BW changes and cross-traffic (does it remain
"roughly equal"), etc. Down this road lives insanity...
Of course.
I can try alternate wiggle-words, or some additional somewhat-vague
phrases.
Add a "It is difficult to give a definition of 'roughly equal' because..."
to make
it clear why the definition is imprecise? I'm less concerned that the
definitions
are vague, than that they're vague without explanation of the factors that
affect
them.
Sure, sounds good.
- 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?
A "minimal quality media stream" may be 8Kbps (or less!) or it might be
8Mbps, so that makes it hard to define here....
True, but the issue ought to be discussed. Quickly ramping up to get a
useful
VoIP flow is straight-forward (as you say, 8kbps), but it's a much harder
problem for higher rate media. This draft should be setting expectations that
the
ramp-up will take longer the higher your useful rate, and that doesn't come
across now.
Ok, how about "a useful share of the bandwidth" and "A useful share will
depend on the media types involved and total bandwidth available, but should
allow reasonable communication quickly assuming similar media types and
required bandwidths". Also, it's more about the existing flows ramping down
fast enough so that the new flow (which will likely start at a "reasonable
minimum" bandwidth) doesn't cause all the flows to start seeing delay and/or
loss. Likely applications using this will lower-limit the bandwidth and when
forced down there will live with extra delay (i.e. the compete with greedy TCP
case), and if delay is egregious or if loss builds up badly as well then it
may
decide to drop that stream or indicate connection failure.
- Requirement 3A is unclear. Is the intent that there is no requirement
that the algorithm compete equally with TCP flows that have different
RTT?
3A says "don't be a hog" (likely not a problem anyways, but since once an
algorithm has "given up" on low delay due to TCP competition you don't want it
to starve the TCP streams by going CBR for example.) And for long-lived
flows, it
can't compete equally even with flows with the same RTT.
I got that from 3, but don't see how 3A adds to it. I'd possibly suggest
removing 3A, since I think it's covered elsewhere in 2.
ok
- 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.
Those were to push the solutions in the direction of having a reasonable
start-of-call/stream behavior, which otherwise might get ignored and not
looked at or optimized for. I agree they're somewhat editorial.
Pushing solutions in that direction makes sense, but to fit the way this
draft is
structured as a set of requirements, I think these need to be rephrased.
I'll take a shot at that.
- 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.
"must deal with"?
Maybe, although might be better to just merge with 5A.
- 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?
<t>After stream resumption, the algorithm should attempt to regain a
share of bandwidth as quickly as possible.</t> ("useful share"?)
*ducks*
"After stream resumption, the algorithm should attempt to rapidly regain
its
previous share of the bandwidth; the aggressiveness with which this is done
will
decay with the length of the pause"??
That's better. (I'd say "may decay" or "should decay" to avoid
hard-restricting
the solutions).
- 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?
The latter. I thought it was clear; wording suggestions?
"across multiple RTP streams sent between two endpoints, when those RTP
streams share a common bottleneck, whether or not those streams are
multiplexed onto the same ports"?
ok
- Requirement 6C gives a possible use for information, but it's not clear
what requirement is being placed on implementations.
Right, it's editorial reminding them they can do that.
Sure, but it's in the requirements section, so needs to be phrased as such.
Suggest changing "it should be possible for the application to control" to
"the
algorithm should allow the application to control"
ok
--
Randell Jesup -- rjesup a t mozilla d o t com
--
Colin Perkins
http://csperkins.org/