General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] TCP congestion detection - random thoughts
Date: Mon, 22 Jun 2015 09:12:18 -0700	[thread overview]
Message-ID: <CAA93jw4gyCR9SfXd9fiAQsqgc2WO1XgMCmPUNOGpBtTPG7+3WQ@mail.gmail.com> (raw)
In-Reply-To: <87vbefn3el.wl-jch@pps.univ-paris-diderot.fr>

On Mon, Jun 22, 2015 at 8:55 AM, Juliusz Chroboczek
<jch@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@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

  reply	other threads:[~2015-06-22 16:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-21 16:19 Benjamin Cronce
2015-06-21 17:05 ` Alan Jenkins
2015-06-21 17:33   ` Jonathan Morton
2015-06-21 19:34   ` Benjamin Cronce
2015-06-21 17:53 ` G B
2015-06-22  1:50 ` Stephen Hemminger
2015-06-22 15:55 ` Juliusz Chroboczek
2015-06-22 16:12   ` Dave Taht [this message]
2015-06-23  5:20 Ingemar Johansson S

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw4gyCR9SfXd9fiAQsqgc2WO1XgMCmPUNOGpBtTPG7+3WQ@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=jch@pps.univ-paris-diderot.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox