Subject: [quicwg/base-drafts] Frame type extensions (#58)

From: Martin Thomson <[email-masked]>
Date: Thu, 01 Dec 2016 15:30:55 -0800

Do we want them? How do we accommodate them?  What are their semantics if they aren't understood?

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

---

From: martinduke <[email-masked]>
Date: Mon, 05 Dec 2016 16:48:02 -0800

I suggest we have a single frame type for "experimental", much like a TCP option. Similarly, there would be mandatory type field afterwards and a mandatory length field. Any QUIC endpoint MUST be able to parse the length field, at a minimum.

While many use cases for an experimental frame may be handled by the COPT tag, additional frames in the handshake would not be. Nor would frames sent before receipt of SHLO.

-- 
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/58#issuecomment-265026720

---

From: ianswett <[email-masked]>
Date: Tue, 06 Dec 2016 06:18:15 -0800

Another approach would be:
1) Negotiate what experimental frame types are to be used in the handshake by the client listing the ones it'd like to use. 
2) If the server doesn't repeat back some or all of the suggested frame types, then the client knows the server doesn't support them.
3) Assign them frame numbers on a per-connection basis in the order the server repeats them back.
4) Experimental frames must always be sent post-SHLO with 1RTT keys.
5) If non-negotiated experimental frames are used, close the connection with an error.

In some cases, such as FEC, the sender really needs to know the receiver supports it.  and if they don't, why send it?

-- 
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/58#issuecomment-265160297

---

From: martinduke <[email-masked]>
Date: Tue, 06 Dec 2016 08:15:55 -0800

I admit I'm theorizing about experimental extensions I can't even imagine, but the post-SHLO requirement seems like a pretty significant restriction.

Using TLVs instead is a pretty well-established concept for Transport people to grasp, with no restrictions.

-- 
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/58#issuecomment-265193226

---

From: ianswett <[email-masked]>
Date: Tue, 06 Dec 2016 08:29:35 -0800

In the case of the server, everything is post-SHLO, and in the case of the client, it's just 0RTT data that couldn't use extensions, which I wouldn't expect to need any special features.

Agreed TLV is simple.  My thinking is all the extensions I can think of will want negotiation anyway, so both sides know they're available.  In which case, you wouldn't really want to use the new frames until after the handshake, because you want to use the handshake to do feature negotiation of the existence of said frames.

Another option would be to add any extensions into new versions, but that doesn't seem to scale well outside experimentation.

-- 
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/58#issuecomment-265197271

---

From: Mike Bishop <[email-masked]>
Date: Tue, 06 Dec 2016 12:31:26 -0800

Scale was the argument for not using the ALPN token for h2 extensions.  I like the posture that we settled on there:

- Unknown frame types are ignored -- clients MAY send extensions that don't require peer understanding (hints, for example) without confirmation.  Obviously, if you have a signal yes/no, you can save some wasted bytes.
- Frames that are state-changing or otherwise alter the contract of the core spec require positive acknowledgement that the peer understands them before sending (alternatives to HEADERS, DATA, etc.)

"Alters the contract of the core spec" may be worth a version bump, since you might have incompatible extensions.  And in general, anything that is MUST-understand and in the client's 0-RTT needs to be a version number change.  You can get away without it in most other cases.

The other thing that sticks out here -- this has the potential to make versions non-incremental.  What does that do to the version negotiation, where the client might not want to burn an RTT attempting the fanciest variant it knows, but would like to discover server support for other variants for future 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/58#issuecomment-265263806

---

From: ianswett <[email-masked]>
Date: Tue, 06 Dec 2016 12:42:54 -0800

In the case of HTTP/2, we can use alt-svc to avoid burning an RTT learning what versions are supported.

But I think we'd like the ability to negotiate fairly large changes without requiring a version bump.  These could be nice to have features, not required ones, and might include a new ack frame, FEC frame, etc.  SACK and timestamps in TCP fit into this category for TCP today.

If we think there are lots of things in the first category, where ignoring frames is fine, then using a TLV approach seems fine, but every extension I can imagine is in the second category, which is why I'm not that excited about TLV in practice.

-- 
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/58#issuecomment-265266460

---

From: ianswett <[email-masked]>
Date: Tue, 06 Dec 2016 12:44:35 -0800

I should add, that we could actually do both of these if we think they both have value.  If we add a TLV one, it'd have to be a MUST support, whereas the handshake negotiation could be a MAY.

-- 
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/58#issuecomment-265266820

---

From: Alexis La Goutte <[email-masked]>
Date: Thu, 08 Dec 2016 12:22:05 -0800

for experimental frame, it is a good idea to use the same logic like TCP (or H2) add a magic value after (but it will also better to fix the length of this magic word because with TCP there is 3, 4 or 8 bytes of length... and not easy to check !

-- 
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/58#issuecomment-265844793