Frame Type Extensibility

[jasnell]

There are a couple of issues relating to frame type extensibility:

1. Are frames end-to-end or hop-by-hop? This is currently undefined. Control frames appear to always be hop-by-hop, Header bearing frames might or might not be hop-by-hop, Data frames appear to always be end-to-end. What about new extension frame types?
2. Are new unsupported frame types subject to flow control? How can we differentiate new control frame types vs. data frame types?
3. There is no prescribed mechanism for rolling out support for new standard frame types vs. private use frame types.

Recommendation:

One approach we can take to dealing with this is to segment the 8-bit frame type namespace into two distinct categories and reserve a limited number of frame types from each for "private use". That is,

0xxxxxxx => Control Frames
1xxxxxxx => Data Frames

Control Frames (0x00-7F) are always hop-by-hop and are not subject to flow control. Frame types 0x6B-7F would be reserved for "private use", meaning that these types could not be registered within the IANA registry.

Data Frames (0x80-FF) are always end-to-end and are subject to flow control. Frame types 0xEB-FF would be reserved for "private use".

The frame type of the existing DATA frame would change from 0x00 to 0x80, all other existing frame types would remain unchanged.

This approach gives us a clear way of dealing with extension frames, flow control, etc without introducing undue complexity.

[mnot]

To be covered by the Layering TF.

[martinthomson]

We really need a text proposal that covers this issue. I suspect that the issues that needs to address include:

• Unsupported frames cannot alter the state of the stream or the connection. That's non-negotiable.
• We need to decide when and where unsupported frames can be sent. That is, what stream states permit the use of unsupported frames, and whether they can be sent on stream 0.
• We need to decide what intermediaries are permitted to do with unsupported frames. Giving them just two choices might be best: either forward all unsupported frames, or don't forward any unsupported frames. Selectively forwarding frames seems unlikely to be conducive to any sort of reliability.

[mnot]

Discussed in Seattle; no decisions yet, but covered:

• Having a pre-defined extension frame type makes sense; more flexible extension identifier (~4 bytes of org id). On non-stream0, act like HEADERS
• Stream0 extension frames would be effectively hop-by-hop (act like SETTINGS, but no ack)
• Roberto's proposal of using negotiation to determine requirements for proxies depends upon ALPN ClientHello issues.

[jasnell]

Updated proposal: http://www.ietf.org/internet-drafts/draft-snell-httpbis-ext-frames-01.txt

[MikeBishop]

Another proposal from about the same time as James'; including for completeness of the comments thread when it's reviewed: http://www.ietf.org/internet-drafts/draft-bishop-http2-extension-frames-00.txt

Discussion on the mailing list showed there are some fundamental philosophical differences here, and they need to be resolved by the WG and not by us individually.

What are the goals for extensions? Are we trying to prevent protocol variants by making experimentation easy within HTTP/2.0, or prevent fragmentation by tightly regulating the creation of new extensions? Or are we just trying to close the spec ASAP by leaving extensions out entirely and saying that adding extensions creates a new protocol that we (or someone) will tackle later?

All are good goals, and we have a draft each for the three directions once we pick one.

[martinthomson]

Discussed in Zurich; we will do extensibility, maybe. Need some more time to look at the proposals.

[mnot]

Discussed (again) in Zurich; agreed to drop frame type extensibility completely (i.e., IANA registry), along with settings. Recipient of unknown frame types MUST conn error; recipient of unknown settings MUST conn error.

[jasnell]

Why?

[mnot]

The WG discussed this extensively, and decided that ALPN identifiers were the primary mechanism for extensibility. Allowing extensions to change connection state was an issue of particular concern, and without those, the motivation for allowing extension frame types was much less. There was also a dearth of proposals for use cases.

Feel free to bring up on-list, of course.

[mnot]

Reopening after further discussion on-list.

[mnot]

Discussed in NYC; will take Martin's proposal with some tweaks (e.g., addressing flow control).