Benjamin Cronce <bcro...@gmail.com> writes: > CAKE only works for endpoints you control. QUIC can benefit in > situations where you don't control the chokepoints. Not sure how QUIC > interacts with CAKE. I can't see it being more than a small percent > better or worse.
It is not so much quic vs cake as the underlying congestion control algorithm being used by quic - the codel component of cake works well against cubic or reno, but BBR treats much of codel's signaling as noise. The core benefit of cake (or fq_codel) against BBR is in the "FQ" part which makes multiple flows share more equally, immediately. There is a lot to QUIC to like, but much of the stuff innovated there has migrated back into regular linux tcp stacks (pacing, notably) > > On Wed, Aug 9, 2017 at 3:36 AM, <erik.tarald...@telenor.com> wrote: > > Has anybody here done any experimentation on CAKE (and others) > when using QUIC? Or other real world insights into other aspects > of QUIC? For example proper CAKE and TCP version of youtube vs > crappy quing/latency and QUIC. > > > The overlapping design goals is making the user experience snappy, > but QUICs approach is to control the end points with a new > protocol to replace TCP. (Or improve TCP in the future). > > > https://en.wikipedia.org/wiki/QUIC > > > > -Erik > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
