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

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 <bob.briscoe@bt.com> wrote:

>  This follows up my own post, 'cos I forgot one point...
>
> Date: Fri, 06 Mar 2015 16:40:54 +0000
> To: mbelshe@chromium.org, fenix@google.com, martin.thomson@gmail.com
> From: Bob Briscoe <bob.briscoe@bt.com>
> Subject: HTTP/2 Priority <draft-ietf-httpbis-http2-17>
> 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===
>
>  2. HTTP/2 Overview
> <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-2>
> "  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.
>
>  5.3. Stream priority
> <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3>
>
> 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.
>
>  5.3. Stream priority
> <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3>
> "  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.
>
>  5.3.1. Stream Dependencies
> <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.1>
> "  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.
>
>  5.3.1. Stream
> <https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.1>
> Dependencies
>  <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
>    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."
>
>  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
>
> ________________________________________________________________
> Bob Briscoe,                                                  BT
>
>  ________________________________________________________________
> Bob Briscoe,                                                  BT
>