Frame Type Extensibility #95

Closed
jasnell opened this Issue May 11, 2013 · 11 comments

Projects

None yet

4 participants

@jasnell
Contributor
jasnell commented May 11, 2013

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
Member
mnot commented Jun 13, 2013

To be covered by the Layering TF.

@martinthomson
Member

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
Member
mnot commented Oct 11, 2013

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.
@MikeBishop
Contributor

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
Member

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

@mnot
Member
mnot commented Jan 23, 2014

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
Contributor
jasnell commented Jan 23, 2014

Why?

@mnot
Member
mnot commented Jan 23, 2014

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.

@shigeki shigeki added a commit to shigeki/http2-spec that referenced this issue Feb 18, 2014
@shigeki shigeki remove description of unsupported or unrecognized settings
Extension of settings was dropped in #95
f4cd329
@mnot
Member
mnot commented May 23, 2014

Reopening after further discussion on-list.

@mnot mnot reopened this May 23, 2014
@mnot
Member
mnot commented Jun 5, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment