W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

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

From: 陈智昌 <willchan@chromium.org>
Date: Mon, 13 Jan 2014 19:55:19 -0800
Message-ID: <CAA4WUYg2-KOZLQNf7mcEqcK1f4WFGgaP12YFzx4aM_i_QBm6HA@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: Roberto Peon <grmocg@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
All priorities are advisory...

But herein lies the problem. If servers don't respect prioritization
information enough, then clients may be put in a situation where the
optimal strategy is to be heuristic about prioritization and hedge
their bets about the server respecting the advisory prioritization
info.

Stepping back a bit, what do you think about the prioritization scheme
overall? Is it a net improvement, and you're just commenting on the
part you'd like to see changed? And do you have a better alternative
proposal? We picked a mechanism as a straw man to get discussion
going. I'm open to changing it if there's a better alternative. I
don't consider the existing prioritization scheme a better
alternative.

On Mon, Jan 13, 2014 at 7:49 PM, Jeff Pinner <jpinner@twitter.com> wrote:
> 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
>>>> >
>>>> >
>>>>
>>>
>>
>
Received on Tuesday, 14 January 2014 03:55:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC