Re: Design Issue: Frame Processing Model

Martin Thomson <> Thu, 25 April 2013 23:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAF1521F9668 for <>; Thu, 25 Apr 2013 16:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SeaiSjiHMCyO for <>; Thu, 25 Apr 2013 16:25:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 010E721F9728 for <>; Thu, 25 Apr 2013 16:25:02 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVVWV-0000xN-HT for; Thu, 25 Apr 2013 23:24:19 +0000
Resent-Date: Thu, 25 Apr 2013 23:24:19 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVVWR-0000wb-09 for; Thu, 25 Apr 2013 23:24:15 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVVWQ-0006wg-8e for; Thu, 25 Apr 2013 23:24:14 +0000
Received: by with SMTP id hj19so23259wib.10 for <>; Thu, 25 Apr 2013 16:23:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JRqsy9wwDrjOu1idIjHXW9QOj6BDLW99V1Y28CaOrm4=; b=oebwP/1gx2FUZvo0lacwdBQYzzidf7lyePwvqq4pi2GV1B3nDopSfeOH5Wis+2p/Jf ltg3heyBLHo5qFCvxJ8jzMt0sR81PKWpXpOqapmgSR95nVTbsBIdSh3VlgdohKgjNuOf POPUTGFt4XlL8Bz0762TSY0FThogpFbOyC0puTcow3cCyWHtG3JSyjjEabd8o8OiWUxR f0F60n0m0l6xe5Il4h3IGcER893oUftOn8eXFnAlETwJSpbpgO2udu9TbUz9CL1Fw+T8 YQBPBEyLNiiAK14esole39YO9DkJV5WRrp5DriAXHWm9HUm/MvwJNqMJjmb1tr8V8/T5 VXdA==
MIME-Version: 1.0
X-Received: by with SMTP id uo4mr6721345wjc.30.1366932228092; Thu, 25 Apr 2013 16:23:48 -0700 (PDT)
Received: by with HTTP; Thu, 25 Apr 2013 16:23:47 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 25 Apr 2013 16:23:47 -0700
Message-ID: <>
From: Martin Thomson <>
To: James M Snell <>
Cc: "" <>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.746, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UVVWQ-0006wg-8e df4c53bd751b982e1c5c3f089f72be40
Subject: Re: Design Issue: Frame Processing Model
Archived-At: <>
X-Mailing-List: <> archive/latest/17584
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 <> 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