Re: [quicwg/base-drafts] 0-RTT status of new transport parameters (#3433)

[Martin Thomson <[e-mail]>]

So I'm reviewing this and the only case I'm concerned about is max_ack_delay for 0-RTT.  The server's values might be remembered by the client and applied to its logic.  But I can't see any reason why this might cause actual problems as long as the client adjusts its value when it can.

If the server increases this value, then any increase might accrue to the RTT estimates that are received before the client installs the new value.  But the client won't be generating RTT estimates based on application data, so this is a wash.  And the effect on the PTO duration has no effect because you don't arm PTO because the recovery draft [forbids it](https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#section-5.2.1-5).

So, I see three valid choices:

1. Say nothing.  Let people work out that max_ack_delay has no effect prior to the handshake completing on their own.

2. Explain this.  Probably just by saying "Note that max_ack_delay has no effect during the handshake therefore cannot be violated by a client sending 0-RTT data." OR something along those lines.

3. Explicitly forbid remembering this parameter, by adding it to the [MUST NOT use remembered values](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-7.3.1-3) list but don't explain it.

I'm inclined toward number 3 here, if only to save people the effort of working through this one.

-- 
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/3433#issuecomment-602377571