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

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 13 Jan 2014 14:18:28 -0800
Message-ID: <CABkgnnUSjGm6GAGVrFTidcLTqX_gMki0mr-h3mvc0VGTy4j_fg@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>, William Chan <willchan@chromium.org>
First of all, thanks to Will for making this happen.  Is this your
first internet-draft?

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.

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

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.

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.

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.

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.
Received on Monday, 13 January 2014 22:18:56 UTC

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