Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)

[Gorry Fairhurst <[e-mail]>]

On 27/04/2020 17:19, Lars Eggert wrote:

> Folks who care about a change here need to prioritize progressing this 
> issue. We're close to being able to last-call the specs, and would 
> like this resolved in time.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/quicwg/base-drafts/issues/3529#issuecomment-620088318>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/ABYLLETADUCHE7WAN5IFIWDROWWBNANCNFSM4LOJ4RQA>.
>
We’ve completed a round of updated analysis of the proposed change to 
the QUIC spec, using quicly (changing to a 1:10 policy), and chromium 
(which currently does 1:10 by default). Our hope is that this change to 
the spec,  to actually make standard end-to-end QUIC work better than 
TCP over asymmetric paths!

This is a short slide deck about the performance of the proposed change:
https://erg.abdn.ac.uk/users/gorry/ietf/QUIC/QUIC-ack10-24-april-00.pdf

There have been a number of other change made by the QUIC ID editors 
relating to ACK processing, so we wanted to be sure these results were 
up to date. (These results do not consider additional ACKs after 
re-ordering - reflecting the latest text removing that.)

We also really hope this will motivate a change the practice of forcing 
of QUIC fallback to TCP (with PEP/Thining) over highly asymmetric paths. 
People may also be interested in work for L4S to evaluate the impact of 
ACK Thining for TCP-Prague.

Please do provide feedback, or any questions on this - as Lars notes, we 
think the time is running out for considering new changes, even 
relatively simple ones like this.

Gorry

P.S. First email: 
https://mailarchive.ietf.org/arch/msg/quic/NZBbuY88v0lrVspQE2A5br83asA/



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3529#issuecomment-620551738