[Bloat] About LEDBAT, µTP and BitTorrent

[Bloat] About LEDBAT, µTP and BitTorrent

[Juliusz Chroboczek]

Hi,

In his series of articles, Jim has mostly been concerned about
router-based solutions to the delay issues.  As you know, people have
also been working on end-to-end solutions, mostly within the framework
of TCP (people have already mentioned TCP-Vegas on this list).  There's
a couple things I'd like to add.

Linux allows switching congeston controllers on the fly.  I've used this
in the Transmssion BitTorrent client, which is now able to use TCP-LP (a
less aggressive variant of Vegas) on a system that uses the default
congestion controller for other TCP connexions [1].

Of particular notice is the LEDBAT congestion controller [2], which, to
my knowledge, is the only congestion controller that was explicitly
designed to bound delay [3].  It is also the only delay-besed controller
that has been deployed on a massive scale -- all recent versions of
µTorrent use LEDBAT by default.  If you'd like to experiment with LEDBAT
under Linux, I've recently ported the µTorrent code to Transmission [4],
and I'm told it's also in KTorrent and libtorrent.

I'd love to see LEDBAT in the Linux kernel, and I know people who'd love
to see it in Windows.  If you'd like to either do the work or fund it,
please do get in touch.

--Juliusz

[1] http://www.pps.jussieu.fr/~jch/software/bittorrent/tcp-congestion-control.html
[2] http://datatracker.ietf.org/wg/ledbat/charter/
[3] http://forum.bittorrent.org/viewtopic.php?pid=762#p762
[4] https://forum.transmissionbt.com/viewtopic.php?f=1&t=11130

Re: [Bloat] About LEDBAT, µTP and BitTorrent

[Luca Dionisi]

On Fri, Feb 4, 2011 at 10:36 AM, Juliusz Chroboczek <jch@pps.jussieu.fr> wrote:
> Hi,
>
> In his series of articles, Jim has mostly been concerned about
> router-based solutions to the delay issues.  As you know, people have
> also been working on end-to-end solutions, mostly within the framework
> of TCP (people have already mentioned TCP-Vegas on this list).  There's
> a couple things I'd like to add.

I think that the 2 things have to be carried on independently, because
the end-to-end solutions are not a real solution to the bufferbloat.
The problem is that one cannot make sure that end users will act
fairly, by adjusting their sending rate.
The only way to do this is dropping packets, so that they are obliged
to send again.
If the bottleneck is on a router that is not in your house, you can
enable any congestion control solution in your nodes and you will in
no way experience improved RTT, if other flows from other users do not
act fairly and pass through the same bottleneck.

Am I wrong with my reasoning?

Re: [Bloat] About LEDBAT, µTP and BitTorrent

[Juliusz Chroboczek]

> I think that the 2 things have to be carried on independently,

Yes.

> The problem is that one cannot make sure that end users will act
> fairly, by adjusting their sending rate.  The only way to do this is
> dropping packets, so that they are obliged to send again.

Well, the issues of increased delay and greedy, unresponsive flows are,
to a certain extent, distinct.  One can image AQMs that are only
concerned with penalising unresponsive flows but don't do anything to
reduce buffer size when all flows are well-behaved.  Conversely, one can
imagine solving the buffer bloat problem on the assumption that all
flows are TCP-friendly.

--Juliusz

Re: [Bloat] About LEDBAT, µTP and BitTorrent

[Luca Dionisi]

On Fri, Feb 4, 2011 at 11:04 AM, Juliusz Chroboczek <jch@pps.jussieu.fr> wrote:
>> I think that the 2 things have to be carried on independently,
>
> Yes.
>
>> The problem is that one cannot make sure that end users will act
>> fairly, by adjusting their sending rate.  The only way to do this is
>> dropping packets, so that they are obliged to send again.
>
> Well, the issues of increased delay and greedy, unresponsive flows are,
> to a certain extent, distinct.  One can image AQMs that are only
> concerned with penalising unresponsive flows but don't do anything to
> reduce buffer size when all flows are well-behaved.  Conversely, one can
> imagine solving the buffer bloat problem on the assumption that all
> flows are TCP-friendly.

I don't get it. Why do we need to make such an assumption?
If the routers keep a low buffer size (better if dynamically, if I am
correct) and much better if they *also* implement a AQM which
rate-limit the unresponsive flows, then we will have almost solved the
problem and *also* actually discouraged unfair behavior from clients.

Re: [Bloat] About LEDBAT, µTP and BitTorrent

[Luca Dionisi]

On Fri, Feb 4, 2011 at 11:18 AM, Luca Dionisi <luca.dionisi@gmail.com> wrote:
> On Fri, Feb 4, 2011 at 11:04 AM, Juliusz Chroboczek <jch@pps.jussieu.fr> wrote:
>>> I think that the 2 things have to be carried on independently,
>>
>> Yes.
>>
>>> The problem is that one cannot make sure that end users will act
>>> fairly, by adjusting their sending rate.  The only way to do this is
>>> dropping packets, so that they are obliged to send again.
>>
>> Well, the issues of increased delay and greedy, unresponsive flows are,
>> to a certain extent, distinct.  One can image AQMs that are only
>> concerned with penalising unresponsive flows but don't do anything to
>> reduce buffer size when all flows are well-behaved.  Conversely, one can
>> imagine solving the buffer bloat problem on the assumption that all
>> flows are TCP-friendly.
>
> I don't get it. Why do we need to make such an assumption?
> If the routers keep a low buffer size (better if dynamically, if I am
> correct) and much better if they *also* implement a AQM which
> rate-limit the unresponsive flows, then we will have almost solved the
> problem and *also* actually discouraged unfair behavior from clients.
>

Ah, I got. You say that if routers penalize unresponsive flows than we
discourage unfair behavior.
Ok.
But then, since we must enable routers to use AQM, why not also make
them reduce their buffer size.
Anyway, the end-to-end solution alone is not sufficient.

Re: [Bloat] About LEDBAT, µTP and BitTorrent

[Juliusz Chroboczek]

>> Well, the issues of increased delay and greedy, unresponsive flows
>> are, to a certain extent, distinct.

> I don't get it. Why do we need to make such an assumption?

I'm merely saying is that these are distinct issues, and that while
solving both would be great, solutions to just one of them are still
welcome.

--Juliusz