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

From: Martin Thomson <[email-masked]>
Date: Sun, 22 Mar 2020 21:24:34 -0700

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

---

From: ianswett <[email-masked]>
Date: Mon, 23 Mar 2020 11:26:20 -0700

I agree with your analysis and your recommendation(3) that clients MUST NOT remember it.  We're pretty clear that the max_ack_delay is 0 until you receive the value in TPs, and this fits with that model.

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

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 27 Mar 2020 08:51:06 -0700

The proposed resolution in PR 3545, although short and sweet, categorises a TP as a MUST NOT. In the interest of process, I'm marking this issue as design. Since there is a proposal things should make the next round of consensus call, unless some objections are raised in the meantime.

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

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 27 Mar 2020 08:51:08 -0700

Closed #3433.

-- 
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#event-3172987656

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 27 Mar 2020 08:51:12 -0700

Reopened #3433.

-- 
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#event-3172987982

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 27 Mar 2020 08:52:29 -0700

Accidental close, sorry. 

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