[Bloat] TCP congestion detection - random thoughts

[Dave Taht]

On Mon, Jun 22, 2015 at 8:55 AM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> wrote:
> To add to what my honourable prelocutors have said, µTP, which is used by
> modern BitTorrent implementations, uses the LEDBAT congestion control
> algorithm, which is based on delay.  The fact that LEDBAT is crowded out by
> Reno is a desirable feature in this case -- you do want your BitTorrent
> traffic to be crowded out by HTTP and friends.
>
>     https://en.wikipedia.org/wiki/LEDBAT

Yep. I note that OWD is more desirable than RTT, particularly in
modern asymmetric networks that have a ratio of up to down bandwidths
of 1x10 or more.

A lot of folk have treated that return path as inconsequential when it
can actually be the biggest source of delay or be the most contested
part of the path.

After having much success in squashing torrent down to being invisible
using classification in cake last week, I realized this morning that
also putting the short acks into the same bin was perhaps not always
the right thing as that hurt download throughput..... Perhaps
stretch(ier) acks are feasible in ledbat/torrent? Or revisiting the
packet size to shrink once again under contention? Reducing the number
of flows?

>
> -- Juliusz
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast