[quicwg/base-drafts] QUIC PTO is too conservative, causing a measurable regression in tail latency (#3526)

[ianswett <[e-mail]>]

Google and Chrome have been running experiments with the new IETF QUIC PTO algorithms post-handshake for a few months with Google QUIC, and it appears the first PTO is too conservative relative to Google QUIC.  On the positive side, the rate of spurious TLPs/PTOs is MUCH lower, so that's WAI.

This slows down detection of tail losses and causes a regression in 95%(and higher) latency metrics.  It's also visible as an increase in rebuffers for YouTube.  The changes aren't enormous, but they're large enough I can't launch this as is. 

I believe it's possible to make the first PTO slightly earlier, and stay aligned with the principles of TCP TLP and RTO.  Specifically, my suggestion is to set first PTO expiry from the left edge(see Section 5 of 6398), not the right edge, but there's an additional safety measure of waiting 1.5RTTs since the last ACK-eliciting packet was sent(1.5 is from TLP).  

It'll be a few more weeks before we have data from Chrome Stable, but I believe this may be enough to remove the regression.  Chromium code [here](https://cs.chromium.org/chromium/src/net/third_party/quiche/src/quic/core/quic_sent_packet_manager.cc?sq=package:chromium&g=0&l=1054).

One other note is we found that only sending one PTO packet seems sufficient as long as a packet number is skipped, so the delayed ack timer doesn't come into play.

@mjoras or others may also have production metrics relevant to this issue.

-- 
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/3526