Re: [ledbat] [R-C] LEDBAT vs RTCWeb

[Rolf Winter <[e-mail]>]

> On 4/23/2012 5:27 PM, Rolf Winter wrote:
> >> I searched the email archives and didn't see anything discussing it
> >> (though I might have missed it) or discussing interaction with VoIP
> >> (other than that one paper, which also showed the sensitivity to the
> >> allowed delay and the advantage of a user willing to accept longer
> >> delays, plus how latecomers could mis-read the buffer state.
> >>
> >> The problem is that a 100ms-delay-scavenger algorithm like this
> >> "poisons the well" for any application that desires/needs lower
> delay.
> >> That's why I believe there are only two reasonable targets: 0
> >> (drained
> >> queues) and full queues (assuming AQM isn't implemented to keep
> >> queues low).
> > I think worrying about a poisoned well is a little late with loss-
> based congestion control being deployed.
> 
> We know when faced with deep buffers and large loss-based flow, a delay
> flow will lose or have to transition to loss-based and live with delay
> (see Cx-TCP).  We also know that in practice, the (residential)
> bottleneck links are almost always the access link (DSL, fiber, etc) or
> sometimes the WiFi connection. Corporate/educational can be a bit
> different, but there's a better chance of AQM or service-based traffic
> shaping there.
> 
> We can deal (mostly) with fighting with TCP and expected it.  We didn't
> expect scavenger protocols to be pumping the queues up when TCP is idle
> or bursty.

Here is where you lose me a bit. How do you "fight" TCP and its queue build-up exactly. I don't think we talk about protocols with the same design goals, are we. One of LEDBAT's design goals e.g. is to use all available bandwidth.

> >> I don't think this is just a theoretical problem, I think it's a
> very
> >> serious issue, which if LEDBAT gets used a lot will cause a lot of
> >> problems.  Perhaps it's *better* than old-style saturating
> bittorrent
> >> flows, in that VoIP will be possible without shutting down
> >> bittorrent, but that doesn't mean it's good, and the perception that
> >> bittorrent doesn't break other apps with the new protocols will
> >> encourage people to leave it running - and depending on the vagaries
> >> of bittorrent, it might be fine when you start the call and then
> slam
> >> you.  I'm especially worried about OS's and apps using it for
> >> background update transfers with no user control or knowledge, etc.
> > Well, this reads a bit too dramatic for my taste.
> 
> Perhaps.  But I think a fundamental "how does this affect the network"
> case was glossed over/ignored.
> 
> >   LEDBAT typically comes with the app so you're a bit more agile
> regarding the congestion control parameterization (and even the
> implementation as the BitTorrent folks have shown).
> 
> I note that LEDBAT is now in Linux and MacOS, so it's not just in
> application code anymore, and app developers (even OS developers) may
> assume it's safe to blindly use without user involvement.  (And even if
> informed, assuming users understand the interaction of protocols is ...
> a stretch.)

And I think it is good that LEDBAT sees some deployment. It is an experimental congestion control algorithm. These experiments will provide us with good feedback and we might need to revisit some design decisions. There are millions of deployed LEDBAT-enabled clients out there and unfortunately the only thing we know about this "experiment" is that the experimenters have assured us that LEDBAT was deployed with "good success". 

> 
> > BTW, as long as update services do not use the uplink capacity of
> customers, I don't see much of a problem (assuming we agree that the
> biggest problem is home gateways).
> 
> It's not just uplink, but also downlinks (though uplinks typically are
> the worst-configured).  An update service for the OS or a large app can
> fill the downstream buffers with 100ms of packets, and then any
> incoming VoIP data is delayed with no real way to solve it until the
> update/download ends.  In some cases that might be hours or even days.
> Other apps like cloud backup services might assume it's safe to use
> LEDBAT for their background transfers, and keep your upstream saturated
> at 100ms delay at all times.
> 
> > Not sure how BITS compares in all of this either. In either case it
> beats TCP and that is used without the users' knowledge, too. The best
> you could probably do is design better home gateways which would solve
> many of the problems we see today (the better ones actually today
> implement traffic shaping with really good results, probably better
> than any end-to-end congestion control algorithm).
> 
> Note that no routers are likely to recognize rtcweb traffic as VoIP
> since the signaling is opaque and application-dependant, so ALGs and
> the like have nothing to work against.  It would have to 'guess' that
> the packet stream leading byte pattern and STUN/ICE traffic signified
> use of the port for VoIP.  Eventually they may learn, but it will take
> years.
> 
> I stand by the contention this is a real, significant problem which
> could get far worse if non-user-centric services start using LEDBAT.

Maybe, but the alternative protocol that these apps you describe above can use is TCP. I remain unconvinced that TCP makes the problem less severe than LEDBAT would.



NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014