Re: HTTP/2 Priority <draft-ietf-httpbis-http2-17>
Roberto Peon <grmocg@gmail.com> Fri, 06 March 2015 22:27 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 5E0D31A1B22 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 6 Mar 2015 14:27:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Q8IIQhDNdlRJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 6 Mar 2015 14:27:32 -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 EEBA71A00A2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 6 Mar 2015 14:27:31 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YU0ed-00085G-AS for ietf-http-wg-dist@listhub.w3.org; Fri, 06 Mar 2015 22:23:35 +0000
Resent-Date: Fri, 06 Mar 2015 22:23:35 +0000
Resent-Message-Id: <E1YU0ed-00085G-AS@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <grmocg@gmail.com>) id 1YU0eV-00084A-OU for ietf-http-wg@listhub.w3.org; Fri, 06 Mar 2015 22:23:27 +0000
Received: from mail-oi0-f41.google.com ([209.85.218.41]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1YU0eU-0007cc-2l for ietf-http-wg@w3.org; Fri, 06 Mar 2015 22:23:27 +0000
Received: by oifu20 with SMTP id u20so20135092oif.11 for <ietf-http-wg@w3.org>; Fri, 06 Mar 2015 14:23:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pbt0UGxsOzGGpe4SHkwIVuHLfP6Dk32CbxyRqVmapUc=; b=fXdRGhtOU6De4f9/zvKflQ7byc+TqoJ8UW+zaC0NDTdilgn+bjDBYQMCnOObiNMt9Z rJFC7rrKmPFdl0T5Mu4wa0KhQovofa49lUu0fOutMCiahad/k2tgp8giZIj3aNplR+2O L2pmbBd9wT9VUaNowgECV8PGa6f3A8dIaEusTR2oQzlXwQNY69JbWsFZ3T0q3YbBVztY 0Ea+RBRoj8UwJsYbia4g5CyY1VRbjlSkE/OxwYTK3JPBEiGWTwDZ7teJ0rhDYSdeh0JH pKu58au5bjCz/RgmD9WShamDYeUrTShxJ0lO1mkvaNdHvHmd8LFKuYEs4HPpW4qnjjGQ EgfA==
MIME-Version: 1.0
X-Received: by 10.202.48.87 with SMTP id w84mr11854700oiw.17.1425680579948; Fri, 06 Mar 2015 14:22:59 -0800 (PST)
Received: by 10.76.19.241 with HTTP; Fri, 6 Mar 2015 14:22:59 -0800 (PST)
In-Reply-To: <201503061918.t26JIIKP015110@bagheera.jungle.bt.co.uk>
References: <201503061918.t26JIIKP015110@bagheera.jungle.bt.co.uk>
Date: Fri, 06 Mar 2015 14:22:59 -0800
Message-ID: <CAP+FsNdQHtU0q0X3TTmzAnKHNa8YO3+reYOWJ73ptTJu13_bnQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Bob Briscoe <bob.briscoe@bt.com>
Cc: mbelshe@chromium.org, Roberto Peon <fenix@google.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a113ce71a87f6f60510a620b6"
Received-SPF: pass client-ip=209.85.218.41; envelope-from=grmocg@gmail.com; helo=mail-oi0-f41.google.com
X-W3C-Hub-Spam-Status: No, score=-3.0
X-W3C-Hub-Spam-Report: AWL=-3.212, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: maggie.w3.org 1YU0eU-0007cc-2l 1a6af076744de896104f621bec9c0e48
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 Priority <draft-ietf-httpbis-http2-17>
Archived-At: <http://www.w3.org/mid/CAP+FsNdQHtU0q0X3TTmzAnKHNa8YO3+reYOWJ73ptTJu13_bnQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28906
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>
In practice for the server-side servers/reverse proxies define interfaces based on headers, which indicate what the server/proxy should do at the http/2 level. These are either stripped, or are uninterpreted and waste bytes, but do not otherwise cause harm. On the client-side, though I'd love to see a generic API that allowed for using the protocol's features explicitly, it isn't the IETF's bag to define the interface, really. For web applications, browsers do it on their own. -=R On Fri, Mar 6, 2015 at 11:18 AM, Bob Briscoe <bob.briscoe@bt.com> wrote: > This follows up my own post, 'cos I forgot one point... > > 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> > Subject: HTTP/2 Priority <draft-ietf-httpbis-http2-17> > Cc: ietf-http-wg@w3.org > > 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=== > > 2. HTTP/2 Overview > <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-2> > " 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=== > > > I believe HTTP/2 was intended to be retrofittable to an HTTP/1.1 > implementation. I think that will largely be true, except it seems an API > is needed to drive stream priorities from script logic. But I don't see any > mention of an API in the spec tho. > > Explanation: Presumably something has to determine the dependencies > between all the streams and assign the priority values. This might either > be manual, automated, or a hybrid. Assuming automated, that means something > at the HTTP/2 layer needs to parse all the content and analyse its > dependencies. A Web developer is unlikely to be able to precalculate > priorities, except for simple static content. In general, script > interactions with the client will alter the priorities. So APIs to set > priorities will have to be included in scripting languages, and developers > will have to write to these new APIs. > > So I think this means that HTTP/1.x content will rarely 'just work' over > HTTP/2. > > 5.3. Stream priority > <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3> > > 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. > > 5.3. Stream priority > <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3> > " 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. > > 5.3.1. Stream Dependencies > <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.1> > " 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. > > 5.3.1. Stream > <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.1> > Dependencies > <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.1>" > 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." > > 5.3.4. Prioritization State Management > <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.4> > > 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 > > ________________________________________________________________ > 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