Re: proposed WINDOW_UPDATE text for session flow control windows

William Chan (陈智昌) <willchan@chromium.org> Fri, 15 February 2013 23:55 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042D621F85B1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Feb 2013 15:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.318
X-Spam-Level:
X-Spam-Status: No, score=-9.318 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90zO5iU5MeCX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Feb 2013 15:55:35 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D330821F84C8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 15 Feb 2013 15:55:32 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U6V59-0002WU-MT for ietf-http-wg-dist@listhub.w3.org; Fri, 15 Feb 2013 23:52:43 +0000
Resent-Date: Fri, 15 Feb 2013 23:52:43 +0000
Resent-Message-Id: <E1U6V59-0002WU-MT@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1U6V4u-0002Vk-EA for ietf-http-wg@listhub.w3.org; Fri, 15 Feb 2013 23:52:28 +0000
Received: from mail-qe0-f50.google.com ([209.85.128.50]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1U6V4s-0001Yi-R3 for ietf-http-wg@w3.org; Fri, 15 Feb 2013 23:52:28 +0000
Received: by mail-qe0-f50.google.com with SMTP id 7so1677658qea.23 for <ietf-http-wg@w3.org>; Fri, 15 Feb 2013 15:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cLvPJZDlBSX/ol3rMVOxTFiHrnq+N/ZistvVzmXAD5k=; b=nbbOs9O/LGyIM9csdJdSEUQh1PDPs/yEGwayeKmWT9uuZDOHkSGZWaSeUtB5sP8pBT WmDUIO5W3+wvTBMWC62wK6yh+chUgzVpJWCUnAzbM1Fh5nJLk7T1NBv5AV+FtCnd6wOF fWqwVGBgWKg8zYFWWGqvMOaAZDGnjqE99zhvBlVfi3WfmvrQIx1saSIPl/sJmzKe3jTb PiHtoAebHBik9Omqk6/VCIspbVX9gGF2TaSqdGI5wv1PN2Q+T5wVvM5PspJB+KIAm4SJ CDVp7zZRsiff38efvhf3L8fkkglTJPmcVpE1rGnd+9ChpMzH6b+cvFxpOHudc+K4G0J7 LV4w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cLvPJZDlBSX/ol3rMVOxTFiHrnq+N/ZistvVzmXAD5k=; b=BBSfUm8X5utK+J1KDvEElNGJSQnr9rnnOCUJVmrH3RQBJgGOjQCiaGtxz6PmWEcWEK NB8QdV61A5jqqu9pgCDXhjb85JGfgZ2/eFVgf/mFIFHBt3YRZWubxuXH7u3VXmwFk0Ds LgX+ecU1Ls4MAw5XtrQDxvM0Pgrbj3lAPQaPo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=cLvPJZDlBSX/ol3rMVOxTFiHrnq+N/ZistvVzmXAD5k=; b=a6rS6qidiyhgAmIu2jAYaMY4wbpXRNDUBH0fWp6tmh8GKKg9bGIfPHyqWD+IHw4lo6 0cIL66VB+WTuISxaYOfu3Fs0oNOCdBle82EGKlLNLZL1xYL+Y4hfgEiAiT2TKEBP6YTT y4tGKbufycYLZpFhTndxemFmu2hSusYOBesTePZebay+MBM+6yrWCjGWtpu7p+4zVSwH 0si5ExlLPAe5krKHdjPXWFM1SWpoJ5+eyHw870g7UCav3rvmWkI4MNT1qBcxJ0gLz/Yu INTLK6IYf0kDpxRfGW5IxHqEGWGxLgqcSnrNpGncC+XoBQn6l3iM45fkikcWMtKTengu uhkQ==
MIME-Version: 1.0
X-Received: by 10.49.48.113 with SMTP id k17mr1668510qen.51.1360972320851; Fri, 15 Feb 2013 15:52:00 -0800 (PST)
Sender: willchan@google.com
Received: by 10.229.135.210 with HTTP; Fri, 15 Feb 2013 15:52:00 -0800 (PST)
In-Reply-To: <CAP+FsNcrdNoOSiS+gsx3igaqjsbK82ZhW6vhETBU2YVRjEEcBQ@mail.gmail.com>
References: <CAA4WUYiH8tCF83=jsk_jsvhXkYvmJ+pPLFzhacAMq3O54z2YBw@mail.gmail.com> <6C71876BDCCD01488E70A2399529D5E52E8A2C@ADELE.crf.canon.fr> <CAP+FsNcrdNoOSiS+gsx3igaqjsbK82ZhW6vhETBU2YVRjEEcBQ@mail.gmail.com>
Date: Fri, 15 Feb 2013 15:52:00 -0800
X-Google-Sender-Auth: xIVLs04_ZVgj9JsVvNH_t2nfc0c
Message-ID: <CAA4WUYg0XnojjgWB=_+d35XUWrswOdT+n8yW7ttW49DkNMhn6g@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Roberto Peon <grmocg@gmail.com>
Cc: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=047d7b6da460bbc89804d5cc0f60
X-Gm-Message-State: ALoCoQnV4+HsduBD4bkKDwxUUvZxmnxRx6dHvmLKSxyx1STlS3rNb3lHDhbkXAC0F30p3kZC2WXfVRwjH1TKUKWHuAc3mS2Zn1uLUock7MHVRzDcHczfkyKheUwu15ZOiI1jMQA0KYt6kH9oVAy0WK76u4nxbzP0hAeGrXWSd+Y5qMDhrhwzL6Dcv9u/oHJVbufD34uWmsJG
Received-SPF: pass client-ip=209.85.128.50; envelope-from=willchan@google.com; helo=mail-qe0-f50.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.655, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1U6V4s-0001Yi-R3 293ec918c5e7d5300bb0a569c6108938
X-Original-To: ietf-http-wg@w3.org
Subject: Re: proposed WINDOW_UPDATE text for session flow control windows
Archived-At: <http://www.w3.org/mid/CAA4WUYg0XnojjgWB=_+d35XUWrswOdT+n8yW7ttW49DkNMhn6g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16613
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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 <grmocg@gmail.com> 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" <Herve.Ruellan@crf.canon.fr>
> 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: willchan@google.com [mailto:willchan@google.com] 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.
>>
>