Re: Design Issue: Frame Processing Model

[Martin Thomson <[e-mail]>]

Semi-formally, the Tier 2/3 division is made.  The 1/2 split hasn't been.

We've been talking about a "framing layer", which refers to 1+2.  I
originally thought that the distinction would be 1=framing, 2=streams,
3=application (http).  You can go further and split the streams layer
into planes: control and data.  But I agree, formalism only gets you
so far.

Otherwise, I think that you have it.  I'm not sure whether the spec
needs to say anything.  Maybe you could save it for the book that you
are writing on HTTP/2.0.

On 25 April 2013 15:28, James M Snell <[e-mail]> wrote:
> 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
>