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

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Mon, 20 Jan 2014 10:36:29 +1300
To: ietf-http-wg@w3.org
Message-ID: <4c9c01cf77f63ab445e4f9d97600eacb@treenet.co.nz>
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
Received on Sunday, 19 January 2014 21:36:55 UTC

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