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
- HTTP/2 Priority <draft-ietf-httpbis-http2-17> Bob Briscoe
- Fwd: HTTP/2 Priority <draft-ietf-httpbis-http2-17> Bob Briscoe
- Re: HTTP/2 Priority <draft-ietf-httpbis-http2-17> Roberto Peon
- Re: HTTP/2 Priority <draft-ietf-httpbis-http2-17> Bob Briscoe
- Re: HTTP/2 Priority <draft-ietf-httpbis-http2-17> Ben Niven-Jenkins