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

[Michael Welzl]

On Apr 10, 2012, at 7:13 AM, Harald Alvestrand wrote:

> On 04/07/2012 07:37 PM, Michael Welzl wrote:
>>>
>>> What's the RTO in this case, since we're talking UDP media  
>>> streams?  TCP RTO?
>>
>> Something in the order of that is what I had in mind. An RTT is the  
>> control interval that we can and should act upon, and of course  
>> you'd rather have an estimate that is averaged, and you really want  
>> to avoid having false positives from outliers, so you want to give  
>> it a reasonable safety margin. The TCP RTO has all that.
>
> Forgive me for being dense, but what is the metric by which the RTT  
> is the right interval to act upon?
>
> I know that it's the shortest interval we CAN react upon, because  
> it's impossible for signals to travel source -> destination ->  
> source in less time than the RTT, but what's the logic that says  
> it's the interval we MUST act upon?
>
> In particular, for the "bad" case of an unidirectional media stream  
> that would normally use the AVP profile, with RTCP packets going  
> back every 5 seconds, there's a real engineering cost in requiring  
> that reactions happens on the RTT timescale, especially if the  
> algorithm is required to react to the absence of feedback signals.
>
> 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).

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.

Cheers,
Michael