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

strong agreement with everything Amos wrote


On Sun, Jan 19, 2014 at 10:36 PM, Amos Jeffries <squid3@treenet.co.nz>wrote:

> On 2014-01-19 16:37, Tatsuhiro Tsujikawa wrote:
>
>  On Thu, Jan 16, 2014 at 7:35 AM, William Chan (陈智昌) 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.
>>
>
> Wrong. For both ACK'd and non-ACK'd models only the active streams state
> needs remembering.
>
> 1) Stream IDs are incremental and always increasing.
>
> 2) Any stream ID which is not currently remembered as active is
> ended/closed and needs to be responded with that stream error.
>
> So the total state requirements is a 32-bit largest stream-ID, and a list
> of currently active streams. The rest is easily calculated and responded
> with stream error or connection error.
>
> The END_STREAM flag acts as an ACK frame with payload. Reducing the
> overhead of an explicit END_STREAM_ACK frame to be scheduled and possibly
> dropped or broken in other ways. If the final frame with DATA (or HEADERS)
> carrying the end flag has not been received then truly the stream is not
> yet fully received and must be handled as such.
>
>
>
>  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.
>>
>
> END_STREAM_ACK increases statefulness between client and server, which in
> turn adds high risk of DoS from malicious senders simply choosing to omit
> sending the END_STREAM_ACK.
>
> To mitigate that error receivers would have to implement a mechanism for
> ending streams without the ACK. The HTTP design (even in HTTP/1 keep-alive)
> makes that mechanism the default and avoids all the problems of creating
> two parallel mechanisms for closure.
>
> Many problems in HTTP/1 are created by its multiple mechanisms for
> closure. HTTP/2 reduces that to 1 mechanism which is a VERY good design
> choice.
>
>
>  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.
>>
>>
> These actions must be done regardless of END_STERAM _ACK and are common,
> making a good case for -1 on END_STREAM_ACK.
>
> Amos
>
>
>