Subject: [quicwg/base-drafts] Server's SETTINGS can be omitted in 0-RTT (#1809)

From: Mike Bishop <[email-masked]>
Date: Thu, 27 Sep 2018 16:49:57 -0700

#1808 adds a requirement to error out if the first frame on the control stream is not SETTINGS.  There's an existing error for duplicate control streams.  But what if the control stream never opens at all?

The current state of SETTINGS is that:
- In 1-RTT: Clients MUST wait until they see the server's SETTINGS frame before sending requests; the server MUST see the client's SETTINGS before sending any responses.  If either side fails to open the control stream and send SETTINGS, the connection stalls.
- In 0-RTT:  Servers MUST wait until they see the client's SETTINGS frame before sending responses; this is no different.  Clients, however, assume previous settings and update them *when* the server's SETTINGS frame is eventually seen.

It is a violation for the server to send responses without having sent the SETTINGS frame.  However, there is no requirement that clients validate this behavior because of reordering.  This means that a spec-conformant client would interop just fine with a server that never sends SETTINGS on 0-RTT connections.

Should we introduce a wait-for-SETTINGS requirement later in the connection (for example, before sending new requests in 1-RTT), or just hope that it's easier for servers to do the same compliant thing for both 0-RTT and 1-RTT connections?

-- 
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/1809

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 27 Sep 2018 20:52:24 -0700

This is an interesting issue!

I might argue for banning the server from sending SETTINGS when 0-RTT is used. The client will assume that the SETTINGS obtained in the previous connection to be valid for during 0-RTT _and 1-RTT_.

-- 
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/1809#issuecomment-425313079

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Sep 2018 12:20:37 -0700

I would prefer to have the SETTINGS frame always present.

-- 
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/1809#issuecomment-425539820

---

From: Mike Bishop <[email-masked]>
Date: Fri, 28 Sep 2018 13:22:42 -0700

I agree; I don't like the idea of banning SETTINGS, because it means rejecting 0-RTT any time the server's settings are different, not just when they've become more restrictive.  The real question is whether it's worth introducing a mechanism to ensure the SETTINGS frame is present.

-- 
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/1809#issuecomment-425555176

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Sep 2018 13:35:27 -0700

That's an implementation choice.  I think that #1808 covers things well enough.  I don't see any reason to - for example - force the client to wait on SETTINGS before writing requests in 1-RTT, for example.

-- 
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/1809#issuecomment-425558307

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 30 Sep 2018 18:15:58 -0700

My understanding is that the approach @martinthomson suggests is what we do in H2, and I think that's workable.

-- 
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/1809#issuecomment-425767183