[R-C] Comments on draft-alvestrand-rtcweb-congestion-01

[Michael Welzl]

On Mar 29, 2012, at 1:32 PM, Stefan Holmer wrote:

> Hi Michael,
>
> On Wed, Mar 28, 2012 at 1:16 AM, Michael Welzl <michawe at ifi.uio.no>  
> wrote:
> Hi all,
>
> I have read draft-alvestrand-rtcweb-congestion-01.
>
>
> High-level comments:
>
> Today, this has been called a "strawman proposal". I agree with this  
> way of looking at it. There are some quite interesting ideas there;  
> however, a lot seems to appear "out of the blue", leaving the reader  
> puzzled about the rationale behind some design choices. I wonder if  
> these design choices are based on some academic papers out there -  
> could citations help? Anyway, instead of trying to discuss the  
> algorithm "in the air", it would be better to first work with some  
> data: how does the mechanism really work in a real-life system? How  
> does it interact with TCP? How sensitive is this mechanism to the  
> typical issues raised for delay-based controls (the latecomer  
> unfairness problem, behavior with very small queues, ..)? How likely  
> is it for the derived rate of the mechanism to fall below the TFRC- 
> function limit, under what conditions will this happen?
>
> We are currently working on producing some numbers on performance.  
> It is very helpful to get suggestions on what kind of measurements  
> and scenarios are most interesting.

As a starting point, for interaction with TCP, you could perhaps use  
at least parts of the test suite:
http://caia.swin.edu.au/ngen/tcptestsuite/
And for showing that the mechanism works well and isn't prone to the  
typical problems of delay-based mechanism, take a look at the  
literature on delay-based congestion controls - papers on FAST, for  
instance, to check what the authors of these papers have investigated.

Getting such suggestions is what the ICCRG should be for, IMO - fellow  
ICCRGers, please make suggestions!


>
> In the draft a frame refers to a video frame. However, if an  
> extension such as http://tools.ietf.org/html/rfc5450 is used frames  
> can be substituted for packets. I agree that the draft shouldn't  
> mention video, as it might as well act on audio frames.

Oh! That really wasn't clear to me - my bet was that you're really  
talking about packets! Well that should just be clarified.


> Section 4: par 3, "This algorithm is run every time a receive report  
> arrives..." => so in case of severe congestion, when nothing else  
> arrives, this algorithm waits for 2 * t_max_fb_interval... so can we  
> rely on the mechanism to react to this congestion after roughly an  
> RTO or not? (sounds like not)  Is that bad?  (I guess)
>
> There is a need for some emergency break mechanism if no feedback  
> gets through.

I totally agree - what I meant is, it isn't clear to me if that  
emergency break is activated in time or too late. It should be in time  
(i.e. after roughly an RTO).

Cheers,
Michael