* [Cake] Fast snack, QUIC CAKE?
@ 2017-08-09 8:36 erik.taraldsen
2017-08-11 0:16 ` Benjamin Cronce
0 siblings, 1 reply; 4+ messages in thread
From: erik.taraldsen @ 2017-08-09 8:36 UTC (permalink / raw)
To: cake
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Cake] Fast snack, QUIC CAKE?
2017-08-09 8:36 [Cake] Fast snack, QUIC CAKE? erik.taraldsen
@ 2017-08-11 0:16 ` Benjamin Cronce
2017-08-14 20:06 ` Dave Taht
0 siblings, 1 reply; 4+ messages in thread
From: Benjamin Cronce @ 2017-08-11 0:16 UTC (permalink / raw)
To: erik.taraldsen; +Cc: cake
[-- Attachment #1: Type: text/plain, Size: 917 bytes --]
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.
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
>
[-- Attachment #2: Type: text/html, Size: 1507 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Cake] Fast snack, QUIC CAKE?
2017-08-11 0:16 ` Benjamin Cronce
@ 2017-08-14 20:06 ` Dave Taht
2017-08-17 6:17 ` Jonathan Morton
0 siblings, 1 reply; 4+ messages in thread
From: Dave Taht @ 2017-08-14 20:06 UTC (permalink / raw)
To: Benjamin Cronce; +Cc: erik.taraldsen, cake
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Cake] Fast snack, QUIC CAKE?
2017-08-14 20:06 ` Dave Taht
@ 2017-08-17 6:17 ` Jonathan Morton
0 siblings, 0 replies; 4+ messages in thread
From: Jonathan Morton @ 2017-08-17 6:17 UTC (permalink / raw)
To: Dave Täht; +Cc: Cake List, Benjamin Cronce
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
QUIC should interact with cake in the same way as with fq_codel. Since QUIC
aims to minimise the standing queue by itself, it should usually be seen as
a "sparse" flow which cake will automatically prioritise and avoid dropping
packets from. That, of course, is what you want in a streaming protocol.
If QUIC does persistently exceed the fair share bandwidth, it'll get
signalled using ECN (if marked capable) or packet drops at a linearly
increasing frequency, just like any other protocol. I haven't studied QUIC
enough to be sure about how it reacts to that, but cake is not really
different to any other AQM in that respect. I do know that QUIC can cover a
small amount of packet loss at the receiver.
- Jonathan Morton
[-- Attachment #2: Type: text/html, Size: 803 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-08-17 6:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-09 8:36 [Cake] Fast snack, QUIC CAKE? erik.taraldsen
2017-08-11 0:16 ` Benjamin Cronce
2017-08-14 20:06 ` Dave Taht
2017-08-17 6:17 ` Jonathan Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox