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

[Bob Briscoe <[e-mail]>]

This follows up my own post, 'cos I forgot one point...

>Date: Fri, 06 Mar 2015 16:40:54 +0000
>To: [e-mail], [e-mail], [e-mail]
>From: Bob Briscoe <[e-mail]>
>Subject: HTTP/2 Priority <draft-ietf-httpbis-http2-17>
>Cc: [e-mail]
>
>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===

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.

><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

________________________________________________________________
Bob Briscoe,                                                  BT