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


Thx - so, as I thought, it's unlikely that 
general purpose HTTP/2 code will be able to apply 
stream priorities that take account of script 
logic written for HTTP/1.x. We'll have to wait 
for developers to manually add HTTP/2 priority 
logic, or for tools to be developed to help them.

[PS. I did not intend the rest of my email to 
look like it was earlier in the thread. I only 
say this, because I notice you only replied to 
the para I had added to my own earlier email.]


At 22:22 06/03/2015, Roberto Peon wrote:
>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.
>On Fri, Mar 6, 2015 at 11:18 AM, Bob Briscoe 
><<>> wrote:
>This follows up my own post, 'cos I forgot one point...
>>Date: Fri, 06 Mar 2015 16:40:54 +0000
>>From: Bob Briscoe <<>>
>>Subject: HTTP/2 Priority <draft-ietf-httpbis-http2-17>
>>Cc: <>
>>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===
>>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.
>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.
>>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.
>>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.
>>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.
>>"  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."
>>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."
>>"For equal starting weights, C receives one 
>>quarter, rather than one half, of available resources."
>>Bob Briscoe,                  
>>                                BT
>Bob Briscoe,                  
>                                BT

Bob Briscoe,                                                  BT 

Received on Saturday, 7 March 2015 15:37:32 UTC