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

So what should the receiver do if it receives a dependency for a garbage
collected node?


On Mon, Jan 13, 2014 at 4:35 PM, Roberto Peon <grmocg@gmail.com> wrote:

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