Re: [quicwg/base-drafts] Processing buffered packets can cause hugely inflated RTT measurements (#3980)

[Martin Thomson <[e-mail]>]

Repeating this here, so that the PR comments don't get lost:

This is about a sender having to buffer packets that might contain ACK frames.  Usually, this is because the sender doesn't have the keys necessary, so they hold the packets until they do.

When processing the ACK frame, some time might have passed.  So we now have 5 times in play:  when the largest acknowledged packet was a) sent, and b) received; and when the packet containing the ACK was c) sent, d) buffered, and e) processed.  The critical difference here is that we now recognize the intentional delays at the sender in addition to intentional delays at the receiver.

The receiver calculates and transmit `c - b` and sends that in ACK Delay.  We have a commitment that `c - b <= max_ack_delay`.  That doesn't need to change.

The spec currently assumes that the sender calculates RTT as `e - a - (c - b)` (or `e - a - min(c - b, max_ack_delay)` to include the cap on receiver delay).  That is, the time between when the ACK is processed and when the largest acknowledged was sent, less the ACK Delay.  But that's wrong.  It's `d - a - (c - b)` that we care about.

So all we need to say is that if the sender buffers packets for processing, then it needs to calculate RTT based on the time that the packet entered the buffer.  That is, we capture any intentional delays added *by the sender*.

Then we don't have to worry about the max_ack_delay cap, because receiver behaviour always follows the contract.

-- 
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/3980#issuecomment-668328330