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

[Kazuho Oku <[e-mail]>]

It seems to me that this issue is an alternative resolution to one specific part of what is being proposed as the resolution to #3821. Specifically, quoting from https://github.com/quicwg/base-drafts/issues/3821#issuecomment-665393532, the approach proposed here is an alternative to the line being emphasized below.

> S1. To solve the first problem, we already have a condition in the recovery draft to _not_ arm the PTO on
1-RTT data until the handshake is complete (Section 6.2.1). This is not quite adequate, since it still allows
a client to arm a PTO timer on 1-RTT data on sending a CFIN and 1-RTT data, before ensuring that the server
has received the CFIN. The proposed solution here is to change this condition from "handshake complete" to
"handshake confirmed". Meaning that an endpoint only arms a PTO timer on 0-RTT or 1-RTT data when it knows
that the peer has the keys necessary to read and write in 1-RTT, and can therefore respond with an ACK.
> 
> We think this holds up, but we'd like to get this under everyone's eyes, to ensure that the discussion isn't
missing subtle deadlock issues.
> 
> S2. To solve the second problem, the proposal is to use ack_delay as reported by the endpoint that buffers
the data appropriately. ack_delay is the amount of the time the information (regardless of that being the
packet itself or the acknowledgement) being buffered intentionally. For this, we need the following:
> 
> - endpoints MUST report an ack_delay that is the sum of the controlled delay (i.e. the duration of the data
and the ack being buffered)
> 
> - __endpoints ignore max_ack_delay for acknowledgements of packets that were sent prior to handshake
confirmation. Those are the ones that might have been buffered at the peer until keys were ready.__
> 
> In addition, we explicitly recommend endpoints that asynchronously process handshake messages to buffer
1-RTT packets, instead of dropping them, as dropping packets has significant impact on congestion control.
Note that this matches what those implementations already do.

The proposed resolution in #3821 recommends the sender to retain one bit of constant for each packet it sends, and use it to see if ack_delay should be capped.

The resolution proposed here is to retain a mutable bit for each packet number space, and flip that bit when the seder receives the first ack. Until that bit is flipped, the sender does not cap ack_delay. As correctly pointed out in the [original comment](https://github.com/quicwg/base-drafts/issues/3980#issue-672131960), this approach relies on the receiver processing all the buffered packets at once then sending an ACK.

I think that both approaches work, and do not have a strong preference among the two.

I'd also note both approaches would work correctly once we adopt the basis of the latter approach; i.e. recommend the receiver to process all buffered packets before sending an ACK (the basis of the latter resolution.

Therefore, it seems to me that the only question is if we want to have that recommendation. If the answer is yes, then both approaches would work, and the choice between the approaches becomes an editorial preference (i.e. write down either or both).

-- 
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-668816044