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 <[email protected]> > To: Juliusz Chroboczek <[email protected]> > Cc: bloat <[email protected]> > Subject: Re: [Bloat] TCP congestion detection - random thoughts > Message-ID: > <CAA93jw4gyCR9SfXd9fiAQsqgc2WO1XgMCmPUNOGpBtTPG7 > [email protected]> > Content-Type: text/plain; charset=UTF-8 > > On Mon, Jun 22, 2015 at 8:55 AM, Juliusz Chroboczek <[email protected] > 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 > > [email protected] > > 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 > [email protected] > https://lists.bufferbloat.net/listinfo/bloat > > > End of Bloat Digest, Vol 54, Issue 39 > ************************************* _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
