Re: [Cake] Fast snack, QUIC CAKE?

[Dave Taht <dave@taht.net>]

Benjamin Cronce <bcronce@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.taraldsen@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