Re: END_FLOW_CONTROL for particular stream interpretation

2013/07/25 8:22 "Kulkarni, Saurabh" <sakulkar@akamai.com>:
>
> Conversely any WINDOW_UPDATE frames for individual streams (stream_id:
non zero) need to be rejected when connection level flow control is turned
OFF, right?. (Either by WINDOW_UPDATE with END_FLOW_CONTROL bit set for
stream_id:0 or by SETTINGS_FLOW_CONTROL_OPTIONS).
>

My understanding is that:

If SETTINGS_FLOW_CONTROL_OPTIONS with 0x1 is sent, both connection and
stream level flow control are disabled, so yes, it can be rejected.
But only with WINDOW_UPDATE with stream id 0 and END_FLOW_CONTROL flag, it
only disables connection level flow control and stream level flow control
is still alive unless it is turned off individualy.

Best regards,

Tatsuhiro Tsujikawa

> - Saurabh
>
> From: Patrick McManus <pmcmanus@mozilla.com>
> Date: Wednesday, July 24, 2013 4:16 PM
> To: Saurabh Kulkarni <sakulkar@akamai.com>
> Cc: HTTP Working Group <ietf-http-wg@w3.org>
> Subject: Re: END_FLOW_CONTROL for particular stream interpretation
>
> I believe the session window is still in effect as usual.. so normally
the max-send is min(stream-window, session-window) and after the
window-update, at least when sending on stream 2 in your example, it is
simply session-window.
>
>
> On Wed, Jul 24, 2013 at 7:01 PM, Kulkarni, Saurabh <sakulkar@akamai.com>
wrote:
>>
>> What happens to session level flow control when a WINDOW_UPDATE frame
with END_FLOW_CONTROL flag set is received with a particular stream id
(stream_id other than "0")?
>>
>> E.g.
>> Session Window Size: 64kb
>> Stream Window Size: 64kb, stream_id: 2
>> Receive WINDOW_UPDATE  with END_FLOW_CONTROL bit set, stream_id:2
>>
>> Should the sender follow the session level flow control or ignore flow
control for stream_id:2?
>>
>> - Saurabh
>
>