[R-C] LEDBAT vs RTCWeb

[Randell Jesup]

On 4/10/2012 12:17 PM, Piers O'Hanlon 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.

Yeah... Not pretty.  Any delay-based algorithm should target 
minimal/zero queue lengths to ensure fairness, otherwise it's an evil 
game/race where whomever cares least about delay gets all the bandwidth.

>> Right - which means someone should raise this issue about LEDBAT ASAP. Which WG is handling it?
>>
> LEDBAT WG ;)
>
> Though for the moment it's not clear how many flows are using LEDBAT - It's been mentioned that a few bittorrent clients are using it but I'm not clear on numbers - also some of them seem to implement a 'variant' called uTP, which I'm guessing isn't going to err on the side of lower throughput and delay....
>
> I noticed that LEDBAT now ships as an available congestion control for TCP on OSX Lion for 'background' flows though again it's unclear how many apps actually use it.

Also not good.  We should actively discourage it, IMHO, until this is 
resolved.

> It seems that the 100ms is an agreed maximum delay bound which seems to have been adopted after an earlier 25ms proposal. As mentioned in the draft it is a question of balancing their throughput concerns with achieving suitable a accommodation with TCP flows.
>
> The 100ms is a default for the OSX implementation, whilst the (telecom-paristech.fr) Linux one has the earlier 25ms target.

100ms is just bad, bad, bad for VoIP on the same links.  The only case 
where I'd say it's ok is where it knows it's competing with significant 
TCP flows.  If it reverted to 0 queuing delay or close when the channel 
is not saturated by TCP, then we might be ok (not sure).  But I don't 
think it does that.

-- 
Randell Jesup
randell-ietf at jesup.org