Design Issue: Frame Processing Model

James M Snell <jasnell@gmail.com> Thu, 25 April 2013 22:31 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 79CEA21F8FA4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 15:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 CLDbGYzDK1ku for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 15:31:02 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id E71E721F8F33 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 25 Apr 2013 15:31:01 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVUfa-00070E-GB for ietf-http-wg-dist@listhub.w3.org; Thu, 25 Apr 2013 22:29:38 +0000
Resent-Date: Thu, 25 Apr 2013 22:29:38 +0000
Resent-Message-Id: <E1UVUfa-00070E-GB@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UVUfQ-0006xT-B8 for ietf-http-wg@listhub.w3.org; Thu, 25 Apr 2013 22:29:28 +0000
Received: from mail-oa0-f45.google.com ([209.85.219.45]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UVUfP-0006jJ-Nl for ietf-http-wg@w3.org; Thu, 25 Apr 2013 22:29:28 +0000
Received: by mail-oa0-f45.google.com with SMTP id o17so3429535oag.32 for <ietf-http-wg@w3.org>; Thu, 25 Apr 2013 15:29:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=PXmpZ7mTett6P64vj+WGIRmMb061DkZ8/LO5+qxL+gU=; b=VP3XvECf5NR2Nm+lE5UCuh516PjvHYIxnZoASqPSnJaKW8w/TzBLjwD1PJufCR+CxD bi9bFbjgwchFXhnpwhTxnZCRo2hRiyb9EIdl/GItnDmqs8UIymuuYzfZDAtO+otDFW/f X1Djtz/hiX4cHQsi0TgtpDHm9/D5p77QTbhQPnuIYSWoRY9HxcUFOf5kodDmABRrvZ5w dn6ozfjewb6pJaOsoLPmj2r3xfRZxsx6bzfB8g81ZAGkDimCu4a8kMmcADy9EN5f2kyN 8t0fIDPs7qxkTzWDPo0ynlZz7WUYN41FiiiKgjc7MUzEdypVmHrO0KsTMclVqrCBZCH0 3LIw==
X-Received: by 10.182.204.5 with SMTP id ku5mr5150009obc.22.1366928941744; Thu, 25 Apr 2013 15:29:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Thu, 25 Apr 2013 15:28:41 -0700 (PDT)
From: James M Snell <jasnell@gmail.com>
Date: Thu, 25 Apr 2013 15:28:41 -0700
Message-ID: <CABP7RbdApN07gKKzGsU6UgqGci0_2ONai4iskLNS9k4uw+JSRw@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.219.45; envelope-from=jasnell@gmail.com; helo=mail-oa0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.637, 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: lisa.w3.org 1UVUfP-0006jJ-Nl 31e8a0702427aa86143ba1aff925bcdf
X-Original-To: ietf-http-wg@w3.org
Subject: Design Issue: Frame Processing Model
Archived-At: <http://www.w3.org/mid/CABP7RbdApN07gKKzGsU6UgqGci0_2ONai4iskLNS9k4uw+JSRw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17577
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>

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