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

I skimmed this response. AFAICT, we're in agreement on the
desirability of stream dependencies and seem to disagree on
interpretation of how to express this in the wire format. I'm going to
say that I don't really care. If an ORDERED bit is not necessary, then
it's not necessary. I'm happy to, if we have agreement on stream
dependencies, to walk through all the use cases and how to express
them in the wire format and make sure we accommodate them accordingly.
And if people want to make the relative weight explicit, I'm kinda OK
with that too, even though it's not clear to me that it's necessary.
I'm trying to resist the temptation to bike shed prematurely here :)

On Wed, Jan 15, 2014 at 9:43 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> 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).

This is true. And if many server implementations do this, then it will
make clients wary of relying on the prioritization mechanism, which
would be a bad state to end up in. The only thing I can think of to
mitigate this is having END_STREAM_ACK be required in order to
completely remove the stream from counting towards the stream limit.

>
>>> 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 22:36:10 UTC