Subject: [quicwg/base-drafts] hq: extensibility greasing (#1333)

From: Lucas Pardue <[email-masked]>
Date: Thu, 03 May 2018 01:50:53 -0700

Some recent chatter regarding SETTINGS extension  problems in H2 implementations got me thinking that the horse may have already bolted there. However, is there an opportunity to put something in place for HTTP/QUIC? This might just be reserving code points in settings or frame types to ensure they are ignored without 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/1333

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 03 May 2018 06:57:09 -0700

I think this would be a good idea. As background, we recently discovered
that some HTTP/2 client send a GOAWAY if the receive a SETTING for a
codepoint they do not understand. This is impacting the deployment of
WebSockets over HTTP/2. I think we should Grease All The Things (TM) and
HTTP SETTINGS seems like a fine place. Hopefully we can also do this in
HTTP/2 (and perhaps this should be spec'd at the HTTP level.)

-- 
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/1333#issuecomment-386304430

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 03 May 2018 07:38:25 -0700

To be clear, I'm not against a h2 equivalent but think that would need to be in some document that builds on it, whereas this is an opportunity to get it into the the base draft and exercise the behviour in implementations from day 1.

Also, it is not just the reservation of codepoints of description of the process. h2 and hq vary slightly in their approach to SETTINGS, for example.

I'm not sure if it can be spec'd to the HTTP semantic level, these seem more like version-specific syntax checks to me.

-- 
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/1333#issuecomment-386318171

---

From: Martin Thomson <[email-masked]>
Date: Thu, 03 May 2018 18:49:53 -0700

For transport parameters, I would be happy to accept a PR that reserves certain values (feel free to diverge from the 0x?a?a pattern in TLS).

We need to decide on a design for frame extensibility before we can move on this for that part of the protocol.

-- 
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/1333#issuecomment-386486911

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 04 May 2018 00:32:58 -0700

This issue was focused on HTTP / QUIC, which has frame extensibility
defined. Disentangling the two might make forward progress simpler.

-- 
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/1333#issuecomment-386525519

---

From: Mike Bishop <[email-masked]>
Date: Wed, 09 May 2018 16:38:18 -0700

While they'd be separate documents, I'd like to look at H2 and HQ together for a single design if we want it in both.  I agree that the transport needs to be treated separately, though.

There are only 255 frame types, so it's a much less expansive space from which to steal a swath of values.  Grease is most useful when you have such a large set of grease values that it's easier to properly handle unknown values than to hardcode the grease values.  We could reasonably do something like `0x?b` being reserved for GREASE in both H2 and HQ, but that's only 16 values, so it's hard to argue it's prohibitive for someone to just hardcode their handling of them.

Settings are easier, and `0x?a?a` seems fine there.

-- 
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/1333#issuecomment-387906668

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 May 2018 18:37:26 -0700

I'm a little concerned about exhaustion of frame types, and we probably should be more because 256 is a pretty small space and 16 is a non-trivial chunk of that space.

Maybe pick a number of frames to reserve and define a simple formula to match: `t = 0xa + 0x10 * rand()` isn't the only formula we can use here.  For instance, changing 0x10 to 0x1f halves the number of reserved codepoints.  Or just pick a handful of specific values to reserve.  Picking from a list of 3 or 4 values is easy for a greaser to use.

-- 
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/1333#issuecomment-387924236

---

From: Mike Bishop <[email-masked]>
Date: Thu, 10 May 2018 10:37:21 -0700

`0xa` is ALTSVC, so we should start at `0xb`.  But if we move to a very small number, we defeat the point of greasing, and it's also easy for a lazy implementation to specifically ignore.  `0xb + 0x1f * rand(7)` produces only eight values (`0x0b`, `0x2a`, `0x49`, `0x68`, `0x87`, `0xa6`, `0xc5`, `0xe4`), which verges on small enough to fear hardcoding.  However, it does have the nice property that it doesn't steal any of the experimental range, a space which is even more prone to exhaustion.  And if exhaustion is a concern, maybe eight is a good maximum.

-- 
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/1333#issuecomment-388127183

---

From: Mike Bishop <[email-masked]>
Date: Fri, 11 May 2018 10:53:25 -0700

http://mikebishop.github.io/http-misc-extensions/draft-bishop-httpbis-grease.html is a first pass at this on the HTTP/2 side.  I'm happy to reserve the same values and add the same advice to HTTP/QUIC.

-- 
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/1333#issuecomment-388437887