HTTP/2 Priority <draft-ietf-httpbis-http2-17>

Bob Briscoe <bob.briscoe@bt.com> Fri, 06 March 2015 16:45 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ietf.org@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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6361A0140 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 6 Mar 2015 08:45:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 4ViOhtzYnAS0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 6 Mar 2015 08:45:44 -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 1994A1A0107 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 6 Mar 2015 08:45:44 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YTvJr-0006rB-2A for ietf-http-wg-dist@listhub.w3.org; Fri, 06 Mar 2015 16:41:47 +0000
Resent-Date: Fri, 06 Mar 2015 16:41:47 +0000
Resent-Message-Id: <E1YTvJr-0006rB-2A@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <bob.briscoe@bt.com>) id 1YTvJk-0006qU-Qx for ietf-http-wg@listhub.w3.org; Fri, 06 Mar 2015 16:41:40 +0000
Received: from hubrelay-rd.bt.com ([62.239.224.99]) by maggie.w3.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <bob.briscoe@bt.com>) id 1YTvJe-0001J5-H8 for ietf-http-wg@w3.org; Fri, 06 Mar 2015 16:41:40 +0000
Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 6 Mar 2015 16:41:06 +0000
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 6 Mar 2015 16:40:58 +0000
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Fri, 6 Mar 2015 16:40:57 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.111.19.140]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id t26Gerrf014194; Fri, 6 Mar 2015 16:40:53 GMT
Message-ID: <201503061640.t26Gerrf014194@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 06 Mar 2015 16:40:54 +0000
To: mbelshe@chromium.org, fenix@google.com, martin.thomson@gmail.com
From: Bob Briscoe <bob.briscoe@bt.com>
CC: ietf-http-wg@w3.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_718060137==.ALT"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Received-SPF: pass client-ip=62.239.224.99; envelope-from=bob.briscoe@bt.com; helo=hubrelay-rd.bt.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.763, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: maggie.w3.org 1YTvJe-0001J5-H8 95d4dedb0f6459f56f9f9f23d6241ca4
X-Original-To: ietf-http-wg@w3.org
Subject: HTTP/2 Priority <draft-ietf-httpbis-http2-17>
Archived-At: <http://www.w3.org/mid/201503061640.t26Gerrf014194@bagheera.jungle.bt.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28900
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>

HTTP/2 folks,

The comments below are largely only issues of comprehensibility or 
accuracy. However, the one about dependency on completion could be 
technically significant, depending on the answer.

===Stream multiplexing===

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-2>2. 
HTTP/2 Overview
"  Streams are largely independent of each other, so a blocked or
    stalled request or response does not prevent progress on other
    streams.
"

That's often (or even commonly?) untrue. If a loss causes the stall, 
HTTP/2 suffers HOL blocking for at least a RTT, because it 
multiplexes all the streams through a single ordered TCP stream. 
HTTP/2 only solves HOL blocking, if the cause of the stall is in the 
application. Admittedly such stalls generally last longer than a RTT, 
but perhaps they are less frequent than losses.

Whatever, this spec is not meant to be a marketing pitch for selling 
HTTP/2. It's meant to be objective.

===Priority===

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3>5.3. 
Stream priority

The directionality of Priority messages needs to be clarified.

It seems to be implied that priority is requested by a client, then 
used by a server. However, a stream is bidirectional. I think the 
implication is that the server has no role in deciding priorities in 
either direction:
* C-S the client just sends with unilaterally decided priorities 
between streams, and tells the server its priorities so that the 
server can manipulate flow control accordingly.
* S-C the client tells the server the priorities to use between 
streams when sending, and uses its own priority decisions to 
manipulate flow control.
If these assumptions are correct, they ought to be stated. And there 
will be associated error conditions if a server attempts to send 
priority frames, or to place priority fields in headers frames.

There is no mention of how or whether the priorities defined by the 
client should be propagated by a proxy into the next hop connection. 
Presumably a proxy can weight different clients as a whole when doing this.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3>5.3. 
Stream priority
"  Streams can be prioritized by marking them as dependent on the 
completion of other streams"

Is it correct to define 'dependency' as 'dependent on /completion/ of 
the other stream'?
For instance, an image stream depends on the HTML stream that places 
the image. But it does not depend on the HTML continuing beyond that 
point to completion. Indeed, as soon as the HTML has declared the 
image, the image has no further dependency on it.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.1>5.3.1. 
Stream Dependencies
"  Inside the dependency tree, a dependent stream SHOULD only be
    allocated resources if all of the streams that it depends on (the
    chain of parent streams up to 0x0) are either closed, or it is not
    possible to make progress on them.
"
If not MUST, what case warrants the SHOULD?

And my previous question about dependency on completion applies here too.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.1>5.3.1. 
Stream 
<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.1>Dependencies
"  A stream cannot depend on itself.  An endpoint MUST treat this as a
    stream error (Section 5.4.2) of type PROTOCOL_ERROR.
"
Should this not be stated to more clearly include the case where a 
stream does not directly depend on itself, but it does eventually via 
a dependency loop?

Also, I think the pair of sentences need to be rephrased so that 
(paraphrasing):
#1 says "an endpoint MUST NOT set a dependency loop"
#2 says "an endpoint receiving a message that sets a dependency loop, 
MUST treat it as a PROTOCOL_ERROR."

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.4>5.3.4. 
Prioritization State Management

The first 3 paras describe a non-problem as if it's a problem: loss 
of state if a node is removed from the dependency tree. If you want C 
to get half the resources if D blocks, then surely you just don't 
remove A from the tree (even if A is idle or closed, it can still be 
assigned priority).

  ?             ?
/ \           /|\
A  B    ==>  / | \
|\ 1/2      C  D  B
| \       1/4 1/4 1/2
|  \
C   D
1/4 1/4

"For equal starting weights, C receives one third, rather than one 
half, of available resources."
I don't think there's any scenario where the numbers in this example 
could be correct. It should say either:
"For equal starting weights, C receives one third, rather than one 
two thirds, of available resources."
or
"For equal starting weights, C receives one quarter, rather than one 
half, of available resources."

HTH


Bob


________________________________________________________________
Bob Briscoe,                                                  BT