Re: [Bloat] TCP congestion detection - random thoughts

[Ingemar Johansson S <ingemar.s.johansson@ericsson.com>]

Hi

FYI SCReAM (Self-Clocked Rate Adaptation for Multimedia) is an offspring of the LEDBAT algorithm
http://tools.ietf.org/wg/rmcat/draft-ietf-rmcat-scream-cc/ 
The congestion control part of SCReAM is designed to be a tad more opportunistic than LEDBAT, the reason to this is that the source in this case is a rate adaptive video encoder.

/Ingemar

> Message: 1
> Date: Mon, 22 Jun 2015 09:12:18 -0700
> 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
> Message-ID:
> 	<CAA93jw4gyCR9SfXd9fiAQsqgc2WO1XgMCmPUNOGpBtTPG7
> +3WQ@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> 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
> 
> 
> ------------------------------
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> 
> 
> End of Bloat Digest, Vol 54, Issue 39
> *************************************