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

[Bob Briscoe <[e-mail]>]

Rob,

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


Bob

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.
>-=R
>
>On Fri, Mar 6, 2015 at 11:18 AM, Bob Briscoe 
><<mailto:[e-mail]>[e-mail]> wrote:
>This follows up my own post, 'cos I forgot one point...
>
>>Date: Fri, 06 Mar 2015 16:40:54 +0000
>>To: 
>><mailto:[e-mail]>[e-mail], 
>><mailto:[e-mail]>[e-mail], 
>><mailto:[e-mail]>[e-mail]
>>From: Bob Briscoe <<mailto:[e-mail]>[e-mail]>
>>Subject: HTTP/2 Priority <draft-ietf-httpbis-http2-17>
>>Cc: <mailto:[e-mail]>[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
>

________________________________________________________________
Bob Briscoe,                                                  BT