Re: [quicwg/base-drafts] Change PTO to be per packet number space (#3066)

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.



>  
 The PTO value MUST be set to at least kGranularity, to avoid the timer expiring
 immediately.
 
+A sender computes its PTO timer every time an ack-eliciting packet is sent.
+When ack-eliciting packets are in-flight in multiple packet number spaces,
+the timer MUST be set for the packet number space with the earliest timeout,
+except for ApplicationData, which MUST be ignored until the handshake
+completes; see Section 4.1.1 of {{QUIC-TLS}}.  Not arming the PTO for
+ApplicationData prioritizes completing the handshake and prevents the server
+from sending a 1-RTT PTO packet before it has the keys to process a 1-RTT
+packet.  This simplifies to setting the PTO on the lowest active packet number
+space if packets from two different packet number spaces are sent when the PTO
+fires.

I'm not sure if I understand this sentence. Consider the server that has just sent ServerHello and it's certificate, i.e. has outstanding Initial and Handshake data.
Isn't the whole point of this PR to arm the PTO timer based on both packet number spaces?

This is what I'd imagine would happen if no ACKs from the client are received:
t = 0: send Initial, immediately afterwards send Handshake. Set PTO timer for the Initial.
t = 1: PTO timer expires for the Initial packet. Send an Initial probe packet. Now the Handshake packet sent at t = 0 is the earliest outstanding packet, so set a PTO timer (with exponential backoff) for this packet.
t = 2: PTO timer expires for the Handshake packet. Send a Handshake probe packet. Now the Initial probe packet sent at t=1 is the earliest outstanding packet. The PTO timer for this packet would expire at t=5.

Is this correct?

-- 
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/pull/3066#pullrequestreview-310863196