Re: Design Issue: Frame Processing Model

Martin Thomson <martin.thomson@gmail.com> Thu, 25 April 2013 23:25 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF1521F9668 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 16:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeaiSjiHMCyO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 16:25:02 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 010E721F9728 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 25 Apr 2013 16:25:02 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVVWV-0000xN-HT for ietf-http-wg-dist@listhub.w3.org; Thu, 25 Apr 2013 23:24:19 +0000
Resent-Date: Thu, 25 Apr 2013 23:24:19 +0000
Resent-Message-Id: <E1UVVWV-0000xN-HT@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UVVWR-0000wb-09 for ietf-http-wg@listhub.w3.org; Thu, 25 Apr 2013 23:24:15 +0000
Received: from mail-wi0-f177.google.com ([209.85.212.177]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UVVWQ-0006wg-8e for ietf-http-wg@w3.org; Thu, 25 Apr 2013 23:24:14 +0000
Received: by mail-wi0-f177.google.com with SMTP id hj19so23259wib.10 for <ietf-http-wg@w3.org>; Thu, 25 Apr 2013 16:23:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.194.235.196 with SMTP id uo4mr6721345wjc.30.1366932228092; Thu, 25 Apr 2013 16:23:48 -0700 (PDT)
Received: by 10.194.33.102 with HTTP; Thu, 25 Apr 2013 16:23:47 -0700 (PDT)
In-Reply-To: <CABP7RbdApN07gKKzGsU6UgqGci0_2ONai4iskLNS9k4uw+JSRw@mail.gmail.com>
References: <CABP7RbdApN07gKKzGsU6UgqGci0_2ONai4iskLNS9k4uw+JSRw@mail.gmail.com>
Date: Thu, 25 Apr 2013 16:23:47 -0700
Message-ID: <CABkgnnU7mjk7gwp=uBhYHBqX6SdedK-0UZYkPDg_DStqrWkcyg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.212.177; envelope-from=martin.thomson@gmail.com; helo=mail-wi0-f177.google.com
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: maggie.w3.org 1UVVWQ-0006wg-8e df4c53bd751b982e1c5c3f089f72be40
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: Frame Processing Model
Archived-At: <http://www.w3.org/mid/CABkgnnU7mjk7gwp=uBhYHBqX6SdedK-0UZYkPDg_DStqrWkcyg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17584
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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 <jasnell@gmail.com>; 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
>