state management on connections

Stefan Eissing <stefan.eissing@greenbytes.de> Wed, 23 January 2013 09:42 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 A330F21F84D9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 23 Jan 2013 01:42:28 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6rp6OI9fUdr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 23 Jan 2013 01:42:27 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B5D0F21F84C7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 23 Jan 2013 01:42:27 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Txwpb-0000Jn-Ho for ietf-http-wg-dist@listhub.w3.org; Wed, 23 Jan 2013 09:41:19 +0000
Resent-Date: Wed, 23 Jan 2013 09:41:19 +0000
Resent-Message-Id: <E1Txwpb-0000Jn-Ho@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <stefan.eissing@greenbytes.de>) id 1TxwpW-0000HX-5l for ietf-http-wg@listhub.w3.org; Wed, 23 Jan 2013 09:41:14 +0000
Received: from mail.greenbytes.de ([217.91.35.233] helo=donbot.greenbytes.de) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <stefan.eissing@greenbytes.de>) id 1TxwpV-0005Tw-45 for ietf-http-wg@w3.org; Wed, 23 Jan 2013 09:41:14 +0000
Received: from delight.greenbytes.de (unknown [217.91.35.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id 90CE210C01B5 for <ietf-http-wg@w3.org>; Wed, 23 Jan 2013 10:40:50 +0100 (CET)
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <896143D9-6F5A-464F-BA59-81DE5031FE3E@greenbytes.de>
Date: Wed, 23 Jan 2013 10:40:54 +0100
To: Group HTTP Working <ietf-http-wg@w3.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass client-ip=217.91.35.233; envelope-from=stefan.eissing@greenbytes.de; helo=donbot.greenbytes.de
X-W3C-Hub-Spam-Status: No, score=-0.7
X-W3C-Hub-Spam-Report: RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1TxwpV-0005Tw-45 5a5f9203edfa0dfb27a172631a652ecc
X-Original-To: ietf-http-wg@w3.org
Subject: state management on connections
Archived-At: <http://www.w3.org/mid/896143D9-6F5A-464F-BA59-81DE5031FE3E@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16129
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>

With regards to state management on http2 connections and the burden it
imposes on servers, my understanding is:

- both endpoints of the communication built up the same "state" during
  header compression
- connection lifetime is ideally as long as clients want
- servers may run into problems regarding memory needs per connection
- clients have no problem keeping state

What if the server could somehow get rid of the state when it wants to,
without closing the connection?

Possibilities:
a) Introduce a "header reset" control frame 
b) Allow the server to retrieve the "state" from the client

Approach a) has the disadvantage of requiring communication when the
server just wants to deallocate resources.

Approach b) has the drawback that servers need to pull the state 
from the client while working on incoming requests after state clearing.
Also, certain compression schemes do require "state" to remain in sync
with requests. So retrieving state n+1 while decoding a request based
on state n might not work.

Have people really knowledgable in the server side considered
anything along these lines?

Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782