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

[Martin Thomson <[e-mail]>]

Ah, I slipped into the same trap as usual.  Mean absolute difference from the mean is the EWMA approximation we are using.  Mean absolute difference is always less than standard deviation, with the factor being ~0.8 for a normal distribution.

Do you have information on the distribution of RTT values that might help determine whether 2 is the right multiplier?  If you have a normal distribution or something approximating that, then 3 would be closer (3.2 and change even).

I can justify capping PTO, but it requires that you be comfortable with being more aggressive.  But, at least to me, it seems like this is all about more aggressive sending.  Which naturally improves performance most of the time.  The network is likely to be able to absorb a minutely higher rate of probe packets as a result.

Based on recent history of the RTT estimate, the peer can produce an acknowledgment within sRTT most of the time.  Anything more than value is included only to allow more time for the peer to respond.  However, if this is the trailing edge of a flight of packets, then any packet in that flight can be acknowledged.  Allowing for some amount of variation in delays relative to the leading edge seems sensible, but delays on the trailing edge do not need any such justification.  The only reason not to use the leading edge alone is that you don't want to send probes when you are sending productive data within the congestion window.

On that basis, probing on the RTT estimate is fine.  That means dead air of one RTT, and maybe some wasted probes because of jitter in the network that extends the effective round trip time.  But you don't need to avoid unnecessary probing with very high confidence, you just need to avoid it most of the time.

The risk with probing sooner is that RTT might genuinely increase, so that probes - which might exceed the congestion window - don't help at all.  That should be rare; we have to treat past performance as a predictor for future gains, that's the basis of all of these systems.  As long as there is an exponential backoff on PTO, we're unlikely to cause significant congestion as you only ever send a handful of probes before flipping to persistent congestion.

A shorter and more aggressive timer here also results in hitting persistent congestion earlier.  So if there really is a routing flap that increases RTT significantly - a case where you really want to reset the congestion window anyway - then you will just end up in hitting that state sooner.

Another justification for a shorter PTO is that your estimation disadvantages shorter sequences of packets.  A single packet flight doesn't get probed any sooner under your algorithm, but that is more likely to see loss of the entire flight than a longer sequence of packets.

-- 
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#issuecomment-599863594