Subject: [quicwg/base-drafts] HTTP/3 settings frames and prioritization (#2772)

From: "Tom D." <[email-masked]>
Date: Wed, 05 Jun 2019 07:04:24 -0700

My issue is the following: The current HTTP/3 specifications say that a SETTINGS frame must be sent as the first frame of the control stream directly following QUIC connection establishment.

```
While connection-level options pertaining to the core QUIC protocol are set in the initial crypto handshake, HTTP/3-specific settings are conveyed in the SETTINGS frame. 
After the QUIC connection is established, a SETTINGS frame (Section 7.2.5) MUST be sent by each endpoint as the initial frame of their respective HTTP control stream (see Section 6.2.1).
```

Depending on how connection establishment is defined, this could result in some awkward client-sided behavior. There are two ways to interpret connection establishment as far as I can tell:
1. The moment the server has 1-RTT send-keys available (i.e., after Client Hello)
2. On receipt of the client finished TLS packet

In the first case, the server can specify its settings before the client makes its first request. In the second case however, the client can already send its first request before having received the server's settings. To handle this case, the specifications say the following:

```
An HTTP implementation MUST NOT send frames or requests which would be invalid based on its current understanding of the peer’s settings. 
All settings begin at an initial value, and are updated upon receipt of a SETTINGS frame. 
For servers, the initial value of each client setting is the default value.
```

Now say for example that a client wants to use Firefox's prioritization scheme and connection establishment is defined in the second way (receipt of client finished packet). Ideally it would use placeholders to structure the dependency tree, but as it has not yet received a settings frame, it is not allowed to do so (default placeholder count is 0). This gives the client two options from what I can tell: 
1. Wait for the settings frame to arrive (and therefore block, which isn't exactly elegant)
2. Use a fallback prioritization scheme and reprioritize requests later when the settings frame has been received and it allows the placeholders the client wants to use (which we'd also ideally like to avoid).

As neither of these options are preferred, the importance of the definition of connection establishment is highlighted even more. My request is, if a clear answer has already been thought out, to add a more verbose description of what connection establishment actually means in this situation.

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Jun 2019 17:59:21 -0700

I agree that this is an unnecessary complexity, and I think #2753 might solve the issue.

-- 
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/2772#issuecomment-499309380

---

From: Mike Bishop <[email-masked]>
Date: Thu, 06 Jun 2019 16:39:13 -0700

The first is true -- the server SHOULD send its SETTINGS frame immediately.  However, any packet can be delayed, so the client can't count on having seen SETTINGS prior to being able to send a request.  This constrains the use of placeholders, header compression, extensions, etc.

The current design permits the implementation to choose -- block on the SETTINGS frame (which used to be required) or send requests under the (very conservative) default constraints and do better once SETTINGS arrives.  Our decision was to open up this flexibility of design rather than requiring either behavior.

Do you have suggestions on how to make this clearer?

-- 
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/2772#issuecomment-499706920

---

From: "Tom D." <[email-masked]>
Date: Fri, 07 Jun 2019 12:15:22 -0700

In my opinion, adding something like you just said to the specifications would be perfect. Given that section 7.2.5.2 already mentions default settings values, it might not be bad to just expand it there. For example:

```
For clients using a 1-RTT QUIC connection, the initial value of each server setting is the default value. When a 0-RTT QUIC connection is being used, the initial value of each server setting is the value used in the previous session. 
Clients MUST store the settings the server provided in the session being resumed and MUST comply with stored settings until the current server settings are received.
```

could be appended with something along the lines of:

```
These values can be used by a client in a situation where it wants to send requests before the server's settings frame has arrived. 
This removes the need for a client to block and wait before sending its first request.
```

I think the most important part here is being a little more verbose about the edge case instead of just implying its existence by mentioning the default values for settings. 
If anyone has any other thoughts about it I'd love to hear them.

-- 
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/2772#issuecomment-500006509

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Jun 2019 13:48:20 -0700

Closed #2772 via #2776.

-- 
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/2772#event-2408678487