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

On Thu, Jan 16, 2014 at 7:35 AM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> 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.
>
>
+1 for mandatory END_STREAM_ACK to remove stream.
The current spec requires that if, for example, DATA frame is received
after a frame with END_STREAM flag set, it must respond with stream error,
but to do this, the receiver has to remember the all stream status,
including closed, which requires additional memory. I think it could be
connection error (I remember someone said that in this list), but we cannot
simply do this because of asynchronous nature of the stream closure.
Requiring additional memory for just dealing with bad peer is not a good
idea to me. With END_STREAM_ACK, both peers keep track of the streams in
bounded memory by MAX_CONCURRENT_STREAM. If a peer receives DATA frame and
whose associated stream does not exist, we can safely terminate connection
because it is a buggy client. Otherwise, we can check the stream state and
it is half-closed remote, then we can also make it connection error.

Best regards,

Tatsuhiro Tsujikawa

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