Design Issue: Frame Processing Model

At the (very real) risk of adding a bit too much formalism to the
Frame processing model, I have noticed a number of areas in the
current -02 draft where references are made to an endpoint being
required to receive and accept frames but being permitted to ignore
them if necessary, etc. There is also a concern over where exactly in
the processing model steps such as header compression state management
ought to occur, whether or not that occurs before sending RST_STREAM
and GOAWAY frames, etc.

In thinking it over, I think it would be very beneficial in the long
term for us to define specific processing levels or tiers for Frames.
Below is a strawman example:

Tier 1: "Session Tier"
  A frame received and parsed. This is where basic validation of the
frame syntax occurs and where state management based on frame
structure (e.g. compressed headers) happens. Any processing errors
that occur here are considered to be Session Errors and will typically
be related to incorrect protocol support, malformed frames, malformed
headers, etc. At this tier, frames are examined individually and not
yet processed as being part of a stream.

Tier 2: "Stream Tier"
  The next tier is to process the frame in context of a stream. This
is where we look at things like whether the frame has a valid known
stream identifier, whether the associated stream is open, half-closed,
closed or whatever. The errors that occur here can be Session or
Stream errors.

Tier 3: "Application Tier"
  The Frame data is passed on for application-level handling. All of
the basic parsing and stream validation has occurred already. This is
where we start applying HTTP specific semantics. The errors that occur
here are typically HTTP level errors with associated HTTP status
codes.

Given these tiers, we can then begin speaking in very concrete terms
about what kinds of processing may be required at different points in
the session lifecycle.

For instance:
 - Protocol upgrade negotiation, SETTINGS frames, GOAWAY and flow
control are all handled in Tier 1. None of that ever passes on to
higher tiers.
 - When we say things like, "an endpoint MUST be continue to accept
frames after a RST_STREAM", we're really saying that Tier 1 processing
must still occur, but that frames may not have to be passed on to Tier
2
 - When we deal with HTTP specific semantics, we assume that all of
the Tier 1 and Tier 2 processing has been dealt with

I believe these layers already informally exist in the model we have,
even if it's not entirely obvious in the current design.

- James

Received on Thursday, 25 April 2013 22:29:28 UTC