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

On 14 January 2014 17:22, William Chan (陈智昌) <willchan@chromium.org> wrote:
> Timers are only necessary if you'd like to garbage collect. Otherwise,
> what are you doing on a timer?

So what you are saying is that if you don't want to do priority
properly, you can ignore this END_STREAM_ACK message.  That sounds
reasonable I guess.  I'll note that those implementations will lose
any sanity checking on the message, such that a peer can send 0, 1, or
many instances of the message and it will be ignored (though it might
trip DoS counters).

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

Not really.  If you send A <- B followed by A <- C, then that
collapses to A <- B -- C.  You can do that based on the order that the
priorities are set (or by stream identifier numbers, but that would be
harder to work out).

> And if you have a D which is lower priority than both B & C in
> your example, how do you express it?

Depends.  The easiest way is to require that D depend on the last
stream in the priority class (i.e., D depends on C), which would be
exactly equivalent to what your draft says.  You could equally
stipulate that the first in the group is identified (D depends on B).
At the same time, it is possible (though less easy in practice due to
the need for a little searching) to allow D to depend on either B or
C.  No matter what the choice, it's trivial to have the receiver
translate that into A <- B -- C <- D.

> 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?

Again, if you stipulate a strict requirement to depend on the last
(prioritized) stream in the group of equivalent ordering dependencies,
then E would depend on C and produce A <- B -- C <- D -- E.

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

It's not really a tree in the sense that you think.  It's a list of
lists.  The exact same structure you describe in the draft in fact.
See:

A
^
B -- C
^
D -- E

The only difference is that in the draft you make statements about
what implementations do with their internal data structures, which
isn't really necessary.

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

That's an implementation choice.  Fact is, your nodes have two numbers
on each.  Why not make that explicit?

Received on Wednesday, 15 January 2014 17:44:20 UTC