Re: proposed WINDOW_UPDATE text for session flow control windows

[William Chan (陈智昌) <[e-mail]>]

I don't think it's a big deal. Note that it's unlikely that we'll want to
issue a WINDOW_UPDATE for every DATA frame. Implementations hopefully would
do smarter batch window updating, and the session window batch update
probably would reopen the window consumed by multiple streams.


On Mon, Feb 11, 2013 at 10:09 AM, Roberto Peon <[e-mail]> wrote:

> Sometimes you don't want to increase it when a stream has consumed it
> though.
>
> I agree that it is probably the common case though, and that a flag could
> be used to indicate whether or not this behavior is desired.
>
> The question then is whether or not having two codepaths for this right
> now is a big deal.
> On Feb 11, 2013 7:04 AM, "RUELLAN Herve" <[e-mail]>
> wrote:
>
>> >From my understanding, when the recipient has consumed some data from a
>> stream, it needs to send two WINDOW_UPDATE frames to notify the sender:
>> - One for updating the stream window size.
>> - One for updating the session window size.
>>
>> These two frames could be merged into one by stating that a WINDOW_UPDATE
>> for a stream window also applies to the session window.
>> This impacts the WINDOW_UPDATE frames received for a closed stream: they
>> should still be applied to the session window.
>>
>> I find that sending only one WINDOW_UPDATE frame is slightly better from
>> the design point of view. I'm not sure of the impact at the implementation
>> level. I would think it is better to process one "complex" frame than two
>> "simple" ones.
>>
>> Opinions?
>>
>> Hervé.
>>
>> > -----Original Message-----
>> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> > William Chan (???)
>> > Sent: dimanche 10 février 2013 09:03
>> > To: HTTP Working Group
>> > Subject: proposed WINDOW_UPDATE text for session flow control windows
>> >
>> > Here's my commit in my github fork of the HTTP/2.0 spec:
>> > https://github.com/willchan/http2-
>> > spec/commit/8ba562d34e33e784aad3549a8bab8a6bba87d508
>> >
>> > Here's the HTML generated for that (it looks very broken, sorry, I am
>> n00b at
>> > this tooling):
>> > http://htmlpreview.github.com/?https://github.com/willchan/http2-
>> > spec/blob/master/draft-ietf-httpbis-http2.html#WINDOW_UPDATE
>> >
>> > Roberto and I have had some minimal discussion about this at my pull
>> > request to his SPDY spec repo: https://github.com/grmocg/SPDY-
>> > Specification/pull/4.
>> >
>> > Note, I did not update the flow control principles section. I also did
>> not
>> > update the SETTINGS section, although arguably the SETTINGS id
>> > SETTINGS_INITIAL_WINDOW_SIZE should be renamed to
>> > SETTINGS_INITIAL_STREAM_WINDOW_SIZE to be explicit.
>> >
>> > My diff is rather simple. It changes the text to indicate stream 0 is
>> used for
>> > the session window. It also does some minor wordsmithing because the
>> > original text was pretty ambiguous. I'm included the full updated
>> > WINDOW_UPDATE text here:
>> >
>> > ========================================
>> > 3.6.8.  WINDOW_UPDATE
>> >
>> >    The WINDOW_UPDATE control frame is used to implement per stream and
>> >    per session flow control in HTTP/2.0.  Flow control in HTTP/2.0 is
>> >    per hop, that is, only between the two endpoints of a HTTP/2.0
>> >    connection.  If there are one or more intermediaries between the
>> >    client and the origin server, flow control signals are not explicitly
>> >    forwarded by the intermediaries.  (However, throttling of data
>> >    transfer by any recipient may have the effect of indirectly
>> >    propagating flow control information upstream back to the original
>> >    sender.)  Flow control only applies to the data portion of data
>> >    frames.
>> >
>> >    Flow control in SPDY is implemented by a data transfer window for
>> >
>> >
>> >
>> > Belshe, et al.           Expires August 14, 2013               [Page 26]
>> >
>>
>> > Internet-Draft                  HTTP/2.0                   February 2013
>> >
>> >
>> >    each stream and one for the entire session.  The data transfer window
>> >    is a simple uint32 that indicates how many bytes of data the sender
>> >    can transmit.  When the session starts, the sender initializes the
>> >    session window to the initial session window size.  After a stream is
>> >    created, but before any data frames have been transmitted, the sender
>> >    initializes the stream window to the initial stream window size.  The
>> >    window size is a measure of the buffering capability of the
>> >    recipient.  The sender MUST NOT send a data frame with a data length
>> >    greater than the session window size or the stream window size.
>> >    After sending each data frame, the sender decrements both the per
>> >    stream window size and the session window size by the amount of data
>> >    transmitted.  When a stream window size becomes less than or equal to
>> >    0, the sender MUST NOT send data frames for that stream, except for a
>> >    zero length data frame with the FIN flag set.  Likewise, when the
>> >    session window size becomes less than or equal to 0, the sender the
>> >    sender MUST NOT send data frames for that stream, except for a zero
>> >    length data frame with the FIN flag set.  The recipient can send a
>> >    WINDOW_UPDATE frame back to notify the sender that it has consumed
>> >    some data and freed up buffer space to receive more data for the
>> >    stream or session.
>> >
>> >    +----------------------------------+
>> >    |1|   unused     |         9       |
>> >    +----------------------------------+
>> >    | 0 (flags) |     8 (length)       |
>> >    +----------------------------------+
>> >    |X|     Stream-ID (31-bits)        |
>> >    +----------------------------------+
>> >    |X|  Delta-Window-Size (31-bits)   |
>> >    +----------------------------------+
>> >
>> >    Control bit: The control bit is always 1 for this message.
>> >
>> >    Unused
>> >
>> >    Type: The message type for a WINDOW_UPDATE message is 9.
>> >
>> >    Length: The length field is always 8 for this frame (there are 8
>> >    bytes after the length field).
>> >
>> >    Stream-ID: The stream ID that this WINDOW_UPDATE control frame is
>> >    for.  If the stream ID value is 0, the WINDOW_UPDATE frame applies to
>> >    the session window.
>> >
>> >    Delta-Window-Size: The additional number of bytes that the sender can
>> >    transmit in addition to existing remaining window size.  The legal
>> >    range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes.
>> >
>> >
>> >
>> >
>> > Belshe, et al.           Expires August 14, 2013               [Page 27]
>> >
>>
>> > Internet-Draft                  HTTP/2.0                   February 2013
>> >
>> >
>> >    The window size as kept by the sender must never exceed 2^31
>> >    (although it can become negative in one special case).  If a sender
>> >    receives a WINDOW_UPDATE that causes the window size to exceed this
>> >    limit, then if the Stream-ID was 0, it MUST send a GOAWAY frame with
>> >    status code FLOW_CONTROL_ERROR to terminate the session.  And if the
>> >    Stream-ID references an active stream, it must send a RST_STREAM
>> >    frame with status code FLOW_CONTROL_ERROR to terminate the stream.
>> >
>> >    When a HTTP/2.0 connection is first established, the default initial
>> >    window size for all streams is 64KB and the initial window size for
>> >    the session is 64KB.  An endpoint can use the SETTINGS control frame
>> >    to adjust the initial window size for the streams in the session.
>> >    That is, its peer can start out using the 64KB default initial stream
>> >    window size when sending data frames before receiving a SETTINGS
>> >    frame.  Because SETTINGS is asynchronous, there may be a race
>> >    condition if the recipient wants to decrease the initial window size,
>> >    but its peer immediately sends 64KB on the creation of a new
>> >    connection, before waiting for the SETTINGS to arrive.  This is one
>> >    case where the window size kept by the sender will become negative.
>> >    Once the sender detects this condition, it must stop sending data
>> >    frames and wait for the recipient to catch up.  The recipient has two
>> >    choices:
>> >
>> >       immediately send RST_STREAM with FLOW_CONTROL_ERROR status
>> > code.
>> >
>> >       allow the head of line blocking (as there is only one stream for
>> >       the session and the amount of data in flight is bounded by the
>> >       default initial window size), and send WINDOW_UPDATE as it
>> >       consumes data.
>> >
>> >    In the case of option 2, both sides must compute the stream window
>> >    size based on the initial stream window size in the SETTINGS.  For
>> >    example, if the recipient sets the initial stream window size to be
>> >    16KB, and the sender sends 64KB for a stream immediately on session
>> >    establishment, the sender will discover its window size is -48KB on
>> >    receipt of the SETTINGS.  As the recipient consumes the first 16KB,
>> >    it can send a WINDOW_UPDATE of 16KB back to the sender.  This
>> >    interaction continues until the sender's window size becomes positive
>> >    again, and it can resume transmitting data frames.
>> >
>> >    After the recipient reads in a data frame with FLAG_FIN that marks
>> >    the end of the data stream, it should not send WINDOW_UPDATE frames
>> >    for the stream as it consumes the last data frame.  A sender should
>> >    ignore all the WINDOW_UPDATE frames associated with the stream after
>> >    it send the last frame for the stream.
>> >
>> >    The data frames from the sender and the WINDOW_UPDATE frames from
>> > the
>> >    recipient are completely asynchronous with respect to each other.
>> >
>> >
>> >
>> > Belshe, et al.           Expires August 14, 2013               [Page 28]
>> >
>>
>> > Internet-Draft                  HTTP/2.0                   February 2013
>> >
>> >
>> >    This property allows a recipient to aggressively update the window
>> >    size kept by the sender to prevent the stream from stalling.
>>
>