Re: Stream State and PRIORITY Frames

Scott Mitchell <scott.k.mitch1@gmail.com> Fri, 20 January 2017 17:05 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 406EC126D73 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 20 Jan 2017 09:05:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.699
X-Spam-Level:
X-Spam-Status: No, score=-9.699 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vWcbAPXbuNhf for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 20 Jan 2017 09:05:21 -0800 (PST)
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 526EB12968B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 20 Jan 2017 09:05:18 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cUcZY-0005RE-5T for ietf-http-wg-dist@listhub.w3.org; Fri, 20 Jan 2017 17:01:56 +0000
Resent-Date: Fri, 20 Jan 2017 17:01:56 +0000
Resent-Message-Id: <E1cUcZY-0005RE-5T@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <scott.k.mitch1@gmail.com>) id 1cUcZT-0005Px-5R for ietf-http-wg@listhub.w3.org; Fri, 20 Jan 2017 17:01:51 +0000
Received: from mail-lf0-f41.google.com ([209.85.215.41]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <scott.k.mitch1@gmail.com>) id 1cUcZH-0003KV-PY for ietf-http-wg@w3.org; Fri, 20 Jan 2017 17:01:44 +0000
Received: by mail-lf0-f41.google.com with SMTP id z134so61883399lff.3 for <ietf-http-wg@w3.org>; Fri, 20 Jan 2017 09:01:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g8AqNkm8gWJG7WssMizjZhUsEvJQodKCnsCQYSwOSsw=; b=P3v8jcZllNuYGoSAIGtt429NNXSfMGp3XIMLIzUBeZThkn/qMAfm8DpbVXVXOyvemW OufOBjYv5HdxYBjP4sbTDaW7rjfs3EEZGSUKC0P+IVUPgQ+tA4PCn8cOMqnec50C+p/q XukgYrvDvu4GeS0gVCzxyQFWjOtIq3ji/5jufC3qhKsLmYRnyTTIE9oEdrVXifRq/KBd EB24g85+I69J4rEbKg09QBIHcZCiehpWEGBvXVtsGnrGw8+jqqmOfp8/gFO8SWj/aziF Ey5JiPQ2P25eLaNmjUok5smD8U7RBsnaKrFMu8s8SjV2DGvrPzz74q1iRvElVmTiy2Ls 7WnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g8AqNkm8gWJG7WssMizjZhUsEvJQodKCnsCQYSwOSsw=; b=EILDJCDor5uedVYxFmdlksyHLt0iF6uVswtQZPvonVf0chU0PiRzuvvOv0sR0awAYV k8IM1oImbZbwUknRNPF26X/BtIhd0s74S+gCEx8WnZh0bjD0/4l+O6hBp47rF7Ee7HIx iPZNm9SD91krrjBpFfzEeZ7heCxsW2cz9mXPiyCHD63HUmojM4OZ4Wphx9Ogz6UK01Xk +ya1k1h6jRXS5S0iebkhhEN7YG4tWxgwAcskDYFnybBOQ2KxM6fh7hz0Db0ODMSiCFYb Ng5w0mhj1tcSjNdJJ5M5C/woKVAD5+malyN0RJ4EUbF9ZkUwtqwJkJcPT1dxvgPaiLRO 4f6g==
X-Gm-Message-State: AIkVDXKe5XpXQlGl6xFYlLfUcklfJOmGY9lmYBzmKAbraSbibTkzY/cPisOoCzqPcdmwvuqIVArCqsy7vewb+Q==
X-Received: by 10.25.202.83 with SMTP id h19mr5289315lfj.33.1484931672012; Fri, 20 Jan 2017 09:01:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.18.200 with HTTP; Fri, 20 Jan 2017 09:01:10 -0800 (PST)
In-Reply-To: <CAJutW=dX1Z8z+XJ10+uX729bxgWh417kXdd27kg=RO6VbcbvgA@mail.gmail.com>
References: <CAFn2buAYWHQSWhhoKZ2GKbqXR1A+tScjkAwZmOuQ9gV9jMp2bA@mail.gmail.com> <CAPyZ6=Kh3n+RJi=RqgFBojgRDpfJ=nbr0i4kvO20ET0Kt7UA8Q@mail.gmail.com> <CABkgnnWmPdDXVS+CvmChRjyqkJooSKgy6KdUdN+9nGzOyJazhg@mail.gmail.com> <CAFn2buDrHtB1z16iTWE945bU_qhxTypr05A=5B_nrQoyQijyOw@mail.gmail.com> <CAFn2buB_RpbwaTzDgYUNt0e9=vFyu--SYgSLBrfAd1Tf0b1_nQ@mail.gmail.com> <CAJutW=dX1Z8z+XJ10+uX729bxgWh417kXdd27kg=RO6VbcbvgA@mail.gmail.com>
From: Scott Mitchell <scott.k.mitch1@gmail.com>
Date: Fri, 20 Jan 2017 09:01:10 -0800
Message-ID: <CAFn2buDuGVBJ8WBptM3cNS_Wy_hnF1v_TMO5VzXriE6B9m-oqQ@mail.gmail.com>
To: laike9m <laike9m@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="f403045e9f50d37ddf05468998f8"
Received-SPF: pass client-ip=209.85.215.41; envelope-from=scott.k.mitch1@gmail.com; helo=mail-lf0-f41.google.com
X-W3C-Hub-Spam-Status: No, score=-2.9
X-W3C-Hub-Spam-Report: AWL=1.081, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cUcZH-0003KV-PY eb099e40f67acc53b2dfcff74502d339
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Stream State and PRIORITY Frames
Archived-At: <http://www.w3.org/mid/CAFn2buDuGVBJ8WBptM3cNS_Wy_hnF1v_TMO5VzXriE6B9m-oqQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33346
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>

On Fri, Jan 20, 2017 at 5:17 AM, laike9m <laike9m@gmail.com> wrote:

> If you don’t include RESERVED streams in the count for
> SETTINGS_MAX_CONCURRENT_STREAMS then how do you limit the amount of
> RESERVED streams, and how does your peer know about this limit? I have
> imposed an implementation specific metric in the past, but this seems less
> preferable than relying on something in the RFC that the peer is aware of.
> Either way having infinite of something doesn’t work in practice.
>
> As Martin has explained, H2 doesn’t limit the amount of RESERVED streams,
> based on the notion that HEADERS are close to free.
>

"HEADERS are free" sounds like an over simplification which becomes more
apparent as the concurrency of streams and connections grows. There are
other provisions in the RFC to limit the amount of state consumed by
HEADERS (SETTINGS_HEADER_TABLE_SIZE, SETTINGS_MAX_HEADER_LIST_SIZE).

In addition to headers this may require additional state to be allocated
for stream management. The specification also has mechanisms to limit state
consumed by streams.

It’s true that one trying to send infinite number of PUSH_PROMISEs to
> client can cause problems, but 1. This only happens if the server is
> malicious, and if it’s malicious,having a limit in the RFC won’t prevent
> anything, and 2. Not counting PUSH_PROMISEs is a tradeoff for fast delivery
> of PUSH_PROMISEs, which stops client from sending more requests. I guess
> this is what Martin meant by “If you limit server push by applying a stream
> limit, then you prevent it from being used in time for the client to use
> it.”
>
(Forgot to reply to all :P)
>

Malicious actors is a concern and must be dealt with. However there may be
proxy-like systems with large amounts of concurrency or other memory
constraint systems that already control their resources but the peer's only
mechanism to know about these limits is to try-then-fail. Assuming clients
impose some limit to their state (infinite state isn't practical) then the
problem of "the client won't accept this push" exists if the server knows
about it before hand or not. Knowing about it before hand gives the server
the ability to potentially prioritize which resources it wants to push or
make other more informed decisions.



> On Thu, Jan 19, 2017 at 9:21 AM, Scott Mitchell <scott.k.mitch1@gmail.com>
> wrote:
>
>>
>>
>> On Tue, Jan 17, 2017 at 2:43 PM, Scott Mitchell <scott.k.mitch1@gmail.com
>> > wrote:
>>
>>> From my perspective I would like to see two clarifications:
>>>
>>> 1. It is clear to me that PRIORITY doesn't impact state.
>>>
>>
>> Just to clarify ... it is clear that a PRIORITY frame doesn't impact the
>> state of the stream  it is carrying priority information for. The impacts
>> PRIORITY frames have on other streams is not clear due to the wording in
>> section 5.1.1.
>>
>>
>>> However Section 5.1.1 states "first use of a new stream identifier"
>>> which makes no reference to stream state. If stream state is
>>> important/implied here better to be specific about it. I don't think the
>>> one-off example below this text is sufficient to convey the intended
>>> implications of this statement.
>>>
>>> 2. Section 5.1.2 states "Streams in either of the 'reserved' states do
>>> not count toward the stream limit." which seems to conflict with section
>>> 8.2.2 "A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to
>>> limit the number of responses that can be concurrently pushed by a
>>> server.". These two statements appear to contradict each other. Since
>>> SETTINGS_MAX_CONCURRENT_STREAMS is really the only mechanism to limit
>>> resources due to server push I'm assuming section 5.1.2 is overly
>>> restrictive.
>>>
>>>
>>> On Tue, Jan 17, 2017 at 2:27 PM, Martin Thomson <
>>> martin.thomson@gmail.com> wrote:
>>>
>>>> On 18 January 2017 at 01:37, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
>>>> wrote:
>>>> > If my understanding is correct, this only refers to the new stream ID
>>>> used
>>>> > by HEADERS, and PUSH_PROMISE frames which open or reserve streams.
>>>> The
>>>> > example text following that statement uses HEADERS which opens new
>>>> stream.
>>>> > PRIORITY frame does not change stream state, and there is no reason
>>>> to close
>>>> > all unused streams lower than bearing stream ID.  That said, I agree
>>>> that
>>>> > this is not crystal clear in the document.  In practice, this is
>>>> probably
>>>> > rather rare case.
>>>>
>>>> This is, I think, the expectation.
>>>>
>>>> I think that we probably want to clarify the point by explicitly
>>>> saying that PRIORITY doesn't affect stream states.  We say that it can
>>>> be sent in any state, but we don't also mention that important point.
>>>> Do people here agree that an erratum on this point is appropriate
>>>> here?
>>>>
>>>
>>>
>>
>