W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

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

From: Bob Briscoe <bob.briscoe@bt.com>
Date: Fri, 6 Mar 2015 16:40:54 +0000
Message-ID: <201503061640.t26Gerrf014194@bagheera.jungle.bt.co.uk>
To: <mbelshe@chromium.org>, <fenix@google.com>, <martin.thomson@gmail.com>
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===

HTTP/2 Overview
"  Streams are largely independent of each other, so a blocked or
    stalled request or response does not prevent progress on other

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.


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 
#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 
Received on Friday, 6 March 2015 16:41:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:43 UTC