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@jesup.org