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

It doesn't rely on it-- it uses it as a better hinting that state can be
discarded.
One can always discard it, but when one does for an unacked node, one has
knowledge that it might still be used in the future. One should garbage
collect ack'd nodes with preference.

-=R


On Mon, Jan 13, 2014 at 4:24 PM, Jeff Pinner <jpinner@twitter.com> wrote:

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