Subject: [quicwg/base-drafts] Consider making SETTINGS part of the control stream header (#2783)

From: Lucas Pardue <[email-masked]>
Date: Tue, 11 Jun 2019 06:21:02 -0700

Right now we have a SETTINGS frame that can only be sent once (in each direction), and if it is sent it has to be sent at a very precise point (the start of the stream) or the connection is bust. 

For these reasons, it strikes me that we could simplify things, in line with **today's** HTTP/3 design, by unframing settings and placing them as the control stream header. For illustration this would look something like below, where Identifier and Value can be sent multiple times.

```
0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           0x00 (i)                          ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Setting Length (i)             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Identifier (i)                       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Value (i)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

**For**
* Simplifies some parts of error handling. 
  - The HTTP_MISSING_SETTINGS snowflake becomes redundant
  - Not possible to send multiple SETTINGS on the control stream to trigger HTTP_UNEXPECTED_FRAME
  - Not possible to send a SETTINGS frame on the wrong stream to trigger HTTP_WRONG_STREAM 
* A peer that is happy with defaults can send 00 (2 bytes) rather than 040 (3 bytes). This is a tinsy tiny benefit
* Forces endpoints to commit to SETTINGS very early (this is of dubious benefit if SETTINGS only loosen values)

**Against**
* We already have implementations that handle SETTINGS just fine
* Keeping the frame allows us change today's design to allow multiple SETTINGS in the future.

The arguments for and against seem to net out evenly. Changing control stream seems like a cleaner design to me but shipping is a feature :tm: .

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

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 11 Jun 2019 06:23:29 -0700

aprops @dtikhonov: another way to avoid the need of HTTP_MISSING_SETTINGS is to loosen the restriction that SETTINGS must be sent as the first frame. 

-- 
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/2783#issuecomment-500838730

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 11 Jun 2019 18:35:46 -0700

While the proposal is interesting, I think my preference goes to retaining the current design.

I agree that HTTP_MISSING_SETTINGS is unnecessary, it is my view that it should be merged to HTTP_UNEXPECTED_FRAME.

But once it gets done, it would be my view that the complexity is indifferent; there is no difference in the encoding-side (just sending different series of octets). On the decoding-side, it either having a state that receives series of special octets or a state that receives a particular frame.

That said, the reason I prefer using a frame for carrying the settings is because it makes the design consistent. Having a layer that is used for "frame"-ing all the information being exchanged is a good thing.

IMO the use of HTTP_UNEXPECTED_FRAME or HTTP_WRONG_STREAM in relation to SETTINGS frame is fine, because use of these errors are the design pattern we use for other frames too. For example, HTTP_UNEXPECTED_FRAME is used to indicate error when the peer sends a DATA frame before a HEADERS frame. Or transmission of a HEADERS frame on the control stream triggers the HTTP_WRONG_STREAM error.

I prefer using that same design pattern for everything, rather than creating different rules for the way things are being sent in each state.

-- 
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/2783#issuecomment-501085962

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 12 Jun 2019 08:12:40 -0700

I remembered that we touched on some of this in https://github.com/quicwg/base-drafts/issues/2526

Thanks for the feedback @kazuho 

> I prefer using that same design pattern for everything, rather than creating different rules for the way things are being sent in each state.

Push streams break this pattern but c'est la vie.

I think I'm happy to kill this issue/proposal.

-- 
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/2783#issuecomment-501319048

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Jun 2019 11:33:58 -0700

If we took this proposal, we'd be cementing a new pattern:  Unidirectional streams might have a header following the type.  Push already does (and in London we rejected a proposal to make Push ID behave the way SETTINGS does instead, #2526).  I like that pattern, and alongside #2781 this would remove the concept of frame-that-can-only-be-first.  That's decidedly appealing.

However, we're close to late-stage and this isn't demonstrably *better*, just cleaner.

-- 
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/2783#issuecomment-501401099

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Jun 2019 22:54:01 -0700

I think that Push Streams is a good argument for pushing this change, although I might argue the Push Streams header is not a length-value structure.

I think I'd prefer reusing the type-length-value structure (i.e. frames) for sending SETTINGS rather than defining it's own length-value structure just for one purpose.

(not that I care much, but just my two cents)

-- 
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/2783#issuecomment-501559061