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

From: Bob Briscoe <[email-masked]>
Date: Fri, 6 Mar 2015 19:18:18 +0000

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

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 6 Mar 2015 14:22:59 -0800

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 <[email-masked]> wrote:

>  2. HTTP/2 Overview
> <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-2>
> 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.
>
> 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.
>
> 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>
>
> 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>
> 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>
>  5.3.1. Stream
>  <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
> 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?
>
> #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
>

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 7 Mar 2015 15:36:57 +0000

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.
>On Fri, Mar 6, 2015 at 11:18 AM, Bob Briscoe 
><<mailto:[email-masked]>[email-masked]> wrote:
>>To: 
>><mailto:[email-masked]>[email-masked], 
>><mailto:[email-masked]>[email-masked], 
>><mailto:[email-masked]>[email-masked]
>>From: Bob Briscoe <<mailto:[email-masked]>[email-masked]>
>>Cc: <mailto:[email-masked]>[email-masked]
>>
>>HTTP/2 folks,
>>
>>The comments below are largely only issues of 
>>comprehensibility or accuracy. However, the one 
>>about dependency on completion could be 
>>"Â  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.
>
>>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 
>>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.
>>
>>"Â  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.
>>
>>"Â  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.
>>"
>>"Â  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):
>>#2 says "an endpoint receiving a message that 
>>sets a dependency loop, MUST treat it as a PROTOCOL_ERROR."
>>
>>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
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 7 Mar 2015 17:37:51 +0000

Bob,

> On 6 Mar 2015, at 19:18, Bob Briscoe <[email-masked]> wrote:
> 
> 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. 

Priority is optional in HTTP/2 and doesn't exist in HTTP/1.x so I'm not sure what makes you think HTTP/1.x content will rarely "just work". It will work just fine. 

Ben