Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)

[Randell Jesup <[e-mail]>]

Open question to the list: should the congestion-control-geeks discuss 
here on the
list the nitty-gritty details required to build the requirements and 
especially to design
and debate a possible proposed "baseline" congestion-control algorithm?

We can certainly do that detailed discussion by email and come back with a
draft;  I had been planning to do it by email, but recent discussion on 
rtcweb
made me think I should ask for opinions on this.  Given the structure, 
if there's
any significant support for "on-the-list" I'll do that.  Realize though 
that they may
get pretty long and detailed without really touching on the larger 
issues being
discussed here.

Right now the bof members to discuss this and propose a draft would be 
myself,
Harald, Justin,  Stefan Holmer and Magnus.

On 9/19/2011 3:06 AM, Stefan Holmer wrote:
> On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On 9/16/2011 9:26 AM, Magnus Westerlund wrote:
>
>         1. Section 3: As delay based congestion control has been tried
>         a number
>         of times and meet with less than stellar success I wonder if
>         you have
>         any understanding of how this relates to the issues previously
>         encountered:
>
>     Do you have any pointers to these earlier attempts?  My separate
>     experience
>     with this class has been extremely successful, though perhaps with
>     a set of
>     real-world use-cases that don't cover the situations you're
>     referring to.
>     My understanding is that Radvision's NetSense is very similar from
>     their
>     description of it.
>
>
> I'm interested in any references you may have as well.


I doubt you'll find many/any, as the first published discussion I saw of 
delay-sensing
congestion control for RTP data was Radvision's posts about Netsense 
last year
and in their Android webcasts; and  that was pretty detail-free until 
their recent
blog posts.  There's plenty of un-published experience with them at 
various companies
I believe....  Not just Google and Radvision.

>
>         - Stability (especially on short RTTs)
>         - How it competes with TCP flows, which was a real issues for
>         TCP Vegas
>         but may be less of an issue here.
>
>     Perhaps Google can comment here about what tests they've done.  If
>     anything,
>     this class of algorithm when faced with aggressive TCP flows will
>     eventually
>     have problems, because TCP will tend to fill up the buffers at the
>     bottleneck.
>     Since this algorithm senses buffers starting to fill up, it will
>     tend to back
>     off before TCP is likely to see a loss event.  Now, it's more
>     complex than
>     that of course, and multiple flows make it more complex still.
>      It's also
>     sensitive to the adaptation rate of this algorithm and speed of
>     backoff.
>     If I remember, TFRC tends to back off more slowly than TCP but
>     also increase
>     more slowly; I suspect Google's algorithm is similar.
>
>
> As you're saying, it will always be hard for delay based congestion 
> control algorithms to compete with a packet loss based algorithm. The 
> delay based algorithm will detect over-use much earlier than the 
> packet loss based one, and that's basically what we've seen in the 
> tests we've been running as well. I do think we would benefit from 
> more tests in this area. For instance, we might want to go with an 
> additive increase approach rather than the current one which is 
> multiplicative, this would likely help improve the algorithms self 
> fairness as well.

Probably; additive increase is probably better, or possible using a 
fraction-of-
predicted-bandwidth increase.  If you use additive increase, it should 
probably be
partly proportional to the maximum "good" bandwidth seen during the 
connection.
This provides some needed scaling of the ramp-up rate to the absolute 
magnitude
of bandwidth available.


-- 
Randell Jesup
[e-mail]