On Tue, Apr 10, 2012 at 4:55 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 4/10/2012 10:40 AM, Stefan Holmer wrote:


On Tue, Apr 10, 2012 at 4:02 PM, Randell Jesup <randell-ietf@jesup.org
<mailto:randell-ietf@jesup.org>> wrote:
   As do I.  Also, I *REALLY* worry about the interaction of LEDBAT
   flows and rtcweb flows...  If it targets 100ms queuing delay as the
   "I'm out of the way of TCP" level, that could seriously negatively
   impact us (and general VoIP as well, but even more so us, since
   we'll again get driven into the ground trying to keep the queues
   drained.  It may take longer, but LEDBAT flows tend to be
   close-to-infinite I would assume.
   If it targets 25ms, that's less problematic I suspect.

   I'm not saying I know there will be a problem here, but that I fear
   there will be since LEDBAT has a non-0 queuing target - it may
   "poison the waters" for any delay-based algorithm that wants to
   target a lower number.


Yes, having two algorithms with different delay targets compete should
be approximately the same thing as having a delay-based algorithm
compete with a loss-based algorithm, although the effects seen may be
more or less bad depending on how close the targets are. To be clear,
our draft (draft-alvestrand-rtcweb-congestion) has a 0 delay target,
which means that it will always let the queues drain before increasing
the rate.

Right - which means someone should raise this issue about LEDBAT ASAP. Which WG is handling it?

Gave this some more thought, and the problem might not be as big as I first anticipated. 

When an receive-side inter-arrival time-based congestion control algorithm such as RRTCC (will refer to draft-alvestrand-rtcweb-congestion as Receive-side Real-Time Congestion Control, RRTCC for now. Other suggestions are welcome) compete with LEDBAT we will see a situation where the the LEDBAT flow builds up queues of 100 ms. RRTCC will observe increased inter-arrival time and react back off (although, it will probably not back off too far). Sooner or later I think we will reach a steady state with 100 ms delay, and that point RRTCC will act as normal. If the LEDBAT flow stops, RRTCC will see decreasing inter-arrival time for some time and let the queue flush before trying to grab the newly available bandwidth.
 




--
Randell Jesup
randell-ietf@jesup.org
_______________________________________________
Rtp-congestion mailing list
Rtp-congestion@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtp-congestion