Re: Fwd: New Version Notification for draft-chan-http2-stream-dependencies-00.txt

Thanks for the draft Will!

My main concern here is that this relies on a synchronous view of stream
state. I would prefer a mechanism that becomes consistent as the stream
state synchronizes instead of relying on an explicit mechanism
(END_STREAM_ACK).


On Mon, Jan 13, 2014 at 1:57 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> Hey Amos, thanks for taking a look!
>
> Sorry for the use of both FIN_ACK and END_STREAM_ACK. The original
> document used FIN_ACK, but we renamed to be consistent with the
> changing of SPDY FIN flags to HTTP/2 END_STREAM flags. I will rename
> the FIN_ACK in a future update to this document.
>
> On Mon, Jan 6, 2014 at 1:55 PM, Amos Jeffries <squid3@treenet.co.nz>
> wrote:
> > Taking a brief look through this it does look like a better form of
> > prioritization than before.
> >
> > Two things and out to me:
> >
> > * PUSH streams can be depended on by non-PUSH streams and vice versa.
> >
> > Possibly leading to a messy situation when an intermediary rejects the
> > PUSH'ed resource(s).
>
> I don't know if there's anything special here for push that wouldn't
> be addressed generally by how one handles the RST_STREAM case.
>
> >
> >
> > * what happens to the dependencies if a depended-on stream gets RST
> instead
> > of FIN_ACK ?
> >
> > Particularly relevant for the PUSH case above, but it can also happen
> > anytime.
>
> I think RST_STREAM should be treated similarly to END_STREAM_ACK.
> Originally, there was a dependency list. Now, a node has been removed
> from that linked list. Either the policy is to automatically
> re-connect the list, or the broken list becomes a new list. And
> explicit policy can be signaled via PRIORITY frames.
>
> >
> >
> > Security considerations would need to mention the possibility:
> >
> > * that an intermediary drops the FIN_ACK frames (or never sends them).
> >
> >  It would seem prudent to simply make
> >   a) the recipient ignore any priority information if the depended-on
> stream
> > has already completed from its viewpoint, and
> >   b) the sender not indicate dependencies on streams already finished
> > sending.
>
> I'm not sure if this is a security consideration, but I think it's
> correct policy. END_STREAM_ACK is intended to eliminate races here.
> Before its receipt, you can always receive references to a depended-on
> stream, even if it in the CLOSED state. So its location in the
> dependency list is still important and can't be ignored. After receipt
> of an END_STREAM_ACK, any future references to that stream are
> PROTOCOL_ERRORs.
>
> >
> >
> > * that a naive server can consume processing capacity on the client
> simply
> > by forcing rearrangements of the dependency state data.
> >
> >  Some measure of protection is made to prevent multiple updates in one
> > PRIORITY frame, but consecutive PRIORITY frames with repeating updates is
> > not handled.
> >  Transaction preempt may involve significant memory context shifts if the
> > client is an intermediary. Too-frequent re-prioritization from the server
> > can trigger this overhead. Same can happen from multiplexing, but at
> least
> > some data transfer occurs each frame to offset the inefficiency.
>
> I agree this is a general DoS consideration. As with many other
> control frames, the server has to be cognizant of abuse. I think
> http://http2.github.io/http2-spec/#rfc.section.10.5 already handles
> this, and even already mentions PRIORITY frames.
>
> >
> > Amos
> >
> >
>
>