[R-C] Timely reaction time (Re: Comments on draft-alvestrand-rtcweb-congestion-01)

[Randell Jesup]

On 4/10/2012 1:54 AM, Michael Welzl wrote:
>
> On Apr 10, 2012, at 7:13 AM, Harald Alvestrand wrote:

>> I would like to have at least some idea of the benefit we're gaining
>> from a short reaction time in order to evaluate what the cost/benefit
>> tradeoff is.
>
> Well okay, my statement here was handwavery. Let's put it this way, I
> imagine you causing problems with competing TCPs if you react slower,
> and I'd at least like to see this potential problem investigated (and
> that's how you can figure out the trade-off).

Please see my discussion elsewhere which shows that except for the 
huge-sudden-congestion case a delay-sensing algorithm such as this 
should sense and react to imminent congestion earlier than a loss-based 
algorithm such as TCP would.  (Otherwise it wouldn't be doing a very 
good job at avoiding delay!)

> On the other hand, as I keep saying: if you constantly receive SCTP ACKs
> from a parallel RTCweb data transfer, you should make use of that other
> feedback.

While there are use-cases for rtcweb which involve "infinite" data 
sources (or at least close enough), by far most uses in rtcweb of the 
data channel are short, bursty, or paced at relatively low bandwidth. 
There are a few use-cases where large background transfers are done 
(largish file transfer), but most of those are typically a short burst 
in a longer call/connection.  So it's a bad idea to plan on a "constant 
stream of SCTP ACKs"...

If you have some SCTP traffic, then yes it would be nice if that helped 
your algorithm, but I think you'll find that the existing media streams 
will typically be far more frequent (and reliable).  In a "normal" video 
chat, you'll have 10-30 frames/second of video (of 1 to (say) 6 packets 
per frame), plus typically 50 audio packets per second - in each 
direction, each carrying timing information.  So in normal situations, 
there's plenty of timing traffic to use from media streams.  There are 
cases where there may be one-way traffic, and knowledge of the idle 
direction's bandwidth will degrade - but that's ok, if the traffic 
starts up again is should see no delay (barring TCP causing standing 
queues).  At most the algorithm should revert back to the starting state 
(faster adaptation, perhaps start-point, though I'd want the restart 
point to be based on our last good estimate, etc).

So, does that answer your concerns?


-- 
Randell Jesup
randell-ietf at jesup.org