Re: [quicwg/base-drafts] Remove EOED v2 (#1798)

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Some small suggestions that may apply to the other PR as well.

> @@ -656,13 +655,14 @@ all the acknowledgements necessary to reach the same state.
 
 After all CRYPTO frames for a given encryption level have been sent and all
 expected CRYPTO frames received, and all the corresponding acknowledgments have
-been received or sent, an endpoint starts a timer.  To limit the effect of
-packet loss around a change in keys, endpoints MUST retain packet protection
-keys for that encryption level for at least three times the current
-Retransmission Timeout (RTO) interval as defined in {{QUIC-RECOVERY}}.
-Retaining keys for this interval allows packets containing CRYPTO or ACK frames
-at that encryption level to be sent if packets are determined to be lost or new
-packets require acknowledgment.
+been received or sent, an endpoint starts a timer.  For 0-RTT keys, which do not
+carry CRYPTO frames, this timer starts when the first packets protected with

The 0-RTT timer can be much more aggressive than 3 * RTO, since nothing now ever needs to be retransmitted at 0-RTT, it can always be sent with 1-RTT keys instead.

> @@ -656,13 +655,14 @@ all the acknowledgements necessary to reach the same state.
 
 After all CRYPTO frames for a given encryption level have been sent and all
 expected CRYPTO frames received, and all the corresponding acknowledgments have
-been received or sent, an endpoint starts a timer.  To limit the effect of
-packet loss around a change in keys, endpoints MUST retain packet protection
-keys for that encryption level for at least three times the current
-Retransmission Timeout (RTO) interval as defined in {{QUIC-RECOVERY}}.
-Retaining keys for this interval allows packets containing CRYPTO or ACK frames
-at that encryption level to be sent if packets are determined to be lost or new
-packets require acknowledgment.
+been received or sent, an endpoint starts a timer.  For 0-RTT keys, which do not
+carry CRYPTO frames, this timer starts when the first packets protected with
+1-RTT are sent or received.  To limit the effect of packet loss around a change
+in keys, endpoints MUST retain packet protection keys for that encryption level
+for at least three times the current Retransmission Timeout (RTO) interval as
+defined in {{QUIC-RECOVERY}}.  Retaining keys for this interval allows packets

I think the key goal here is allowing retransmitted CRYPTO data to be acknowledged with the correct encryption level?

-- 
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/1798#pullrequestreview-158718706