http2: what is the purpose of the "reserved" states?

Tom Bergan <tombergan@chromium.org> Tue, 20 September 2016 03:01 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 BFA9312B161 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Sep 2016 20:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.836
X-Spam-Level:
X-Spam-Status: No, score=-8.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKpaldgYXU0v for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Sep 2016 20:01:36 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B6B127071 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 19 Sep 2016 20:01:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bmBFD-0003JD-1K for ietf-http-wg-dist@listhub.w3.org; Tue, 20 Sep 2016 02:57:15 +0000
Resent-Date: Tue, 20 Sep 2016 02:57:15 +0000
Resent-Message-Id: <E1bmBFD-0003JD-1K@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tombergan@chromium.org>) id 1bmBF6-0003Fv-Ch for ietf-http-wg@listhub.w3.org; Tue, 20 Sep 2016 02:57:08 +0000
Received: from mail-io0-f173.google.com ([209.85.223.173]) by lisa.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tombergan@chromium.org>) id 1bmBEz-0000IP-Te for ietf-http-wg@w3.org; Tue, 20 Sep 2016 02:57:07 +0000
Received: by mail-io0-f173.google.com with SMTP id r145so7144752ior.0 for <ietf-http-wg@w3.org>; Mon, 19 Sep 2016 19:56:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=4VfUEMPuYFbbN6u1fSSAmiQX4cjEixTE4WKuKd7TjZk=; b=LdJNvB2vrucn0zDYAfgcnC1haj5E6nLVR61SrQSUUPfdska4djIW6pQqonWXXtC6I6 sXSdi6LViAEPRCESEU5crxDZpC6Luj6j3UOxYIA3VFTU2dv0O3g5mV8vs3iLJPDzcPMG 8EyV8VhAGjJ839Y7LywT19CYcc9X8SxtccYZw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4VfUEMPuYFbbN6u1fSSAmiQX4cjEixTE4WKuKd7TjZk=; b=fqDCNDvnk+ddvGXpn0OtpkRniTtWtOZo1XtqfJvO3iuVKm3XBuoxXH60cwBP+fZzbG boAB1fTwtQ5LlOjfdAh86qTLH24P8+DfqwQzyj84iA93lzdq5G6nU5sgzpPMsUl7ikza UE8Fah7VTIVe3d4COj5dDkwVJ5nO1CnjWG9+LP9cA5B0RGE8amHm6tqDnhIkMLgn0bGW VQ9Vr/TVj3OFi1j1NxJZs0TzNyA9xdnb4/f6dgGSMRLpM+SsgaHa1bgGDRn4zbu/yl64 d6Ybv28WJXjuvOwFAunHKSn22QPErtINWhPOkKcgy/ckDYYkjC6NjKpjUN7v+MAJHMDe YjZg==
X-Gm-Message-State: AE9vXwN8YLbpsHQK1UT9RhYI854hnAzptWfiwR+lvHZob8fkkkiMtalRWU/4eekMp2nXJ9f+
X-Received: by 10.107.160.83 with SMTP id j80mr39626343ioe.27.1474340195590; Mon, 19 Sep 2016 19:56:35 -0700 (PDT)
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com. [209.85.223.170]) by smtp.gmail.com with ESMTPSA id g78sm9319825itb.12.2016.09.19.19.56.34 for <ietf-http-wg@w3.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Sep 2016 19:56:35 -0700 (PDT)
Received: by mail-io0-f170.google.com with SMTP id q92so7090094ioi.1 for <ietf-http-wg@w3.org>; Mon, 19 Sep 2016 19:56:34 -0700 (PDT)
X-Received: by 10.107.135.22 with SMTP id j22mr39475746iod.2.1474340194593; Mon, 19 Sep 2016 19:56:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.48.136 with HTTP; Mon, 19 Sep 2016 19:56:34 -0700 (PDT)
From: Tom Bergan <tombergan@chromium.org>
Date: Mon, 19 Sep 2016 19:56:34 -0700
X-Gmail-Original-Message-ID: <CA+3+x5H79mPO6zXTanA5uRML1UQrnfeJaAmG_EONZJkj1ZmetQ@mail.gmail.com>
Message-ID: <CA+3+x5H79mPO6zXTanA5uRML1UQrnfeJaAmG_EONZJkj1ZmetQ@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a113f993e94055b053ce79303
Received-SPF: pass client-ip=209.85.223.173; envelope-from=tombergan@chromium.org; helo=mail-io0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-5.2
X-W3C-Hub-Spam-Report: AWL=-1.010, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bmBEz-0000IP-Te 9a52b24bd7bdcb555dcce9056118064c
X-Original-To: ietf-http-wg@w3.org
Subject: http2: what is the purpose of the "reserved" states?
Archived-At: <http://www.w3.org/mid/CA+3+x5H79mPO6zXTanA5uRML1UQrnfeJaAmG_EONZJkj1ZmetQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32414
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>

What is the purpose of the "reserved" states? A stream transitions into a
"reserved" state after sending or receiving a PUSH_PROMISE (Section 5.1).
However, sending a PUSH_PROMISE seems equivalent in spirit to receiving
HEADERS with END_STREAM. So, why doesn't sending a PUSH_PROMISE transition
directly to "half-closed (remote)"?

AFAICT, there are only two differences between "reserved (local)" and
"half-closed (remote)":

1) A stream in "reserved (local)" cannot send DATA, but a stream in
"half-closed (remote)" can. This means a promised response must start with
HEADERS. But this seems redundant, as this requirement already exists for
all responses. See step #2 in Section 8.1.

2) Section 5.1.2 says that "Streams in either of the reserved states do not
count toward the stream limit [specified by
SETTINGS_MAX_CONCURRENT_STREAMS]." Why? Each endpoint must allocate some
state when sending or receiving a PUSH_PROMISE. It seems like the client
might as well apply its limit when receiving the PUSH_PROMISE rather than
waiting for the first HEADERS. Otherwise, the server can send an arbitrary
number of PUSH_PROMISEs without push back. This same question was asked in
the following mail, but not answered:
https://www.ietf.org/mail-archive/web/httpbisa/current/msg24452.html

Given the above, I believe a conforming implementation could merge
"reserved (local)" into "half-closed (remote)" and "reserved (remote)" into
"half-closed (local)". Does that sound right?

-Tom