Re: Comments on draft-chan-http2-stream-dependencies-00

On Mon, Jan 13, 2014 at 2:18 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> First of all, thanks to Will for making this happen.  Is this your
> first internet-draft?

Yep

>
> I have quite a few concerns about END_STREAM_ACK.
>
> Primary of these is a concern that as protocol machinery, it seems too
> heavy for something like priority, which is - in essence -
> augmentation.  A big part of this is that it imposes a cost even where
> prioritization isn't used, and I don't like that sort of externality.
>
> The key use for END_STREAM_ACK is to force a server (* - I'm using
> server and client here throughout, though I understand the properties
> of this to be basically symmetric) to hold prioritization state until
> the client can signal that it has received the END_STREAM, thereby
> removing the closed stream from the set of candidate streams that can
> be referenced.  In part, this shifts the timing problems to the
> server, because the server needs to maintain timers to track
> unacknowledged stream endings.

Timers are only necessary if you'd like to garbage collect. Otherwise,
what are you doing on a timer?

>
> I'm not sure whether it makes sense to send END_STREAM_ACK when
> transitioning into one of the half-closed states.
>
> The handling of END_STREAM_ACK with respect to RST_STREAM needs to be
> specified.  If the intent is to ensure complete consistency regarding
> the set of streams that are available for reference, this is
> necessary.  An acknowledgement for RST_STREAM could resolve the
> problem whereby a sender of RST_STREAM has to ignore frames for some
> open-ended period.  But I'm not sure that we need that machinery.)

Indeed, I'll add that down to the list of things to update in the next version.

>
> As far as it goes, I think that garbage collection is trivial to
> accomplish.  If you accept the fact that sending too complex or too
> many prioritization dependencies could result in some forms of
> suboptimal prioritization, it gets very easy to bound the amount of
> state that you maintain.

We picked an option knowing that people would want to debate it. I'm
interested in hearing what others have to say here. It's not clear to
me that explicit END_STREAM_ACKs are better or worse than just relying
on garbage collection.

>
> I don't think that you need the ORDERED bit.  It seems to me like you
> could do "A <- B -- C" just as easily by having C reference A.  The
> single chain of antecedent-dependent nodes is something an
> implementation could easily do, even if this were the case.  I don't
> see the advantage to having ORDERED in the protocol.

Having C reference A brings us back to dependency trees instead of
lists. And if you have a D which is lower priority than both B & C in
your example, how do you express it? Maybe you have D depend on B? And
if you have an E, what happens if you mark E as depending on C? What's
the priority ordering between D and E, if any?

Once you open it up to a possible tree, it gets more complicated. In
terms of the complexity tradeoff, I think adding a bit for order is
simpler than having to have peers/siblings.

>
> If each stream has two priority-related properties, why not make them
> separate properties?  It's fairly obvious that an ORDERED dependency
> doesn't require it, but an unORDERED dependency can have two numbers:
> the stream ID of its parent, and a relative weight compared to its
> peers.  Then all streams would have both values, with streams
> inheriting a parent of 0 by default.  It's a framing change, but I
> don't see why you couldn't add two numbers to each stream.

OIC, this is something we didn't clean up. We don't want
siblings/peers. Just a single list.

>
> And just for completeness, here's my crazy idea of the day.  Split the
> 32 bits.  The first 16 could be a relative backwards reference to
> another stream, the second 16 could be a relative weight.  Or, go even
> crazier...  16 bits is a lot for weighting, so how about a third split
> that contains a priority horizon, beyond which the client promises
> never to reference a stream for prioritization (maybe: 8 weight/16
> relative stream/8 relative horizon) to allow for explicit release.
>
> Nits:
>
> Section 4 needs to come before all the protocol-stuff.  It contains
> all the actual useful information; before that, I was reading things
> and becoming confused about the whys and wherefores and whatnot.
>
> This:
>    "Updating dependencies when overwriting values is analogous to list
>       insertion."
> Is not quite correct.  Change is an atomic delete+add.
>
> Section 5 is a wee bit long.  I don't usually find that you need to
> include such detailed justification in a draft.  Motivating material
> (as most of this is), usually goes up front, and when things are
> up-front, short and sweet is the best way to go.  List discussion and
> meetings provide ample opportunity for expanding on all the nasty
> details.  That said, I'm surprised at how little mention there is of
> the intermediary bug that first caused this to arise.

OK, this is an artifact of the authors never having written
internet-drafts before. And I hope to hand this off to you at some
point sooner than later if it gets accepted for HTTP/2, at which point
the structure of this I-D will be irrelevant :)

Received on Wednesday, 15 January 2014 01:23:16 UTC