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

[Randell Jesup]

My apologies for not chiming in earlier since the IETF meeting; I've 
been very busy with post-IETF work and needed to find some time to dive 
into the flurry of messages here.  I'm really glad our proposals have 
generated such interest.

On 3/27/2012 7:16 PM, Michael Welzl 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?

I know the Google folk are working on numbers.

I'll tell you (per archive here) I designed and implemented a very 
similar delay-sensing algorithm back in 2004 which has been in use on 
the internet since that time (in residential videophones).  The primary 
differences in our algorithm were using the slope of the delay increase 
(filter output in Google's algorithm) to approximate the amount the 
bottleneck is over-bandwidth. (packets arriving 5% slow means something 
very different than packets arriving 50% slow).  (The updated draft from 
google might incorporate this idea now).  I also didn't have a 
TFRC-based limit in mine, though it also watches packet loss.

I also had a heuristic to watch for missing packets which were "fishy" 
due to an abrupt reduction of delay in the following packet(s) (a sign a 
the two packets had sat in a queue after the other packet had been 
lost).  It's not definitive, and I didn't react unless I saw two of them 
within a few seconds, but it definitely helped overall to keep delay 
down.  Overall, my algorithm worked similarly but was generally more 
heuristic.

> 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?

All excellent questions.  Very small queues in particular probably will 
force any such algorithm into loss-sensitive reactions or mode (which it 
must have); in that case the delay is inherently low anyways, so this 
isn't a problem.  It is important in that case that the delay-sensing 
part not react incorrectly.



-- 
Randell Jesup
randell-ietf at jesup.org