Frame type extensions

[quicwg]

Frame type extensions

[martinduke]

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.

[ianswett]

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?

[martinduke]

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.

[ianswett]

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.

[MikeBishop]

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?

[ianswett]

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.

[ianswett]

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.

[alagoutte]

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 !

[MikeBishop]

This is not currently needed; per scoping discussion, moving to v2.

[martinthomson]

Based on discussion in Melbourne (and since), I don't think that we can punt on this. There's a desire to have this capability, but no agreement on the mechanism.