Re: proposed WINDOW_UPDATE text for session flow control windows

Patrick McManus <> Sun, 10 February 2013 13:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4EF721F84DC for <>; Sun, 10 Feb 2013 05:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.751
X-Spam-Status: No, score=-9.751 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4jwSve1LvKCd for <>; Sun, 10 Feb 2013 05:56:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B85CD21F84C9 for <>; Sun, 10 Feb 2013 05:56:01 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1U4XM6-0005eF-6k for; Sun, 10 Feb 2013 13:54:06 +0000
Resent-Date: Sun, 10 Feb 2013 13:54:06 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1U4XLx-0005dU-G6 for; Sun, 10 Feb 2013 13:53:57 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1U4XLv-0001AM-Rf for; Sun, 10 Feb 2013 13:53:57 +0000
Received: by with SMTP id 16so5314137obc.5 for <>; Sun, 10 Feb 2013 05:53:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=5aef8dW4RMqL0ao4z4vxe/mQ6hmeg4psIryOsya3DBU=; b=cI5x49dVBhqfWLoBfzWmND01pmN427olwrYnKe5UJpXfyUbxOK0v+HE5O/WjpIO1t2 C2aJK53nbPTaPj6mAzYE8Y7MG6uama5k5vVDZBIcEoL8F3VZy5XlElTBEHZEszbVsVWL 7VT6hsvMdl6R09SG2BcbjqAciI6yWs/p2AWXWzQgN5pLa6YKUuEpS6HJ5h+kP+MfoGd9 KgrA0G7lxOwGTcQUpgsxC6sshz/vEdqi1/VX1rIbkoRd4RWaXU7KsvMQ4OCelfIo35TA q84iQ0X0D3CRC+gZQSF29lmaH/ZqUa5TlKdx4s+c4iHaQUD81/EstA6ewwwlKbi7Ztjv N8DQ==
MIME-Version: 1.0
X-Received: by with SMTP id xm8mr2253267obc.1.1360504409830; Sun, 10 Feb 2013 05:53:29 -0800 (PST)
Received: by with HTTP; Sun, 10 Feb 2013 05:53:29 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Sun, 10 Feb 2013 08:53:29 -0500
X-Google-Sender-Auth: _so4M8e1E-pawwqJaDMiTeZbSb0
Message-ID: <>
From: Patrick McManus <>
To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=14dae93a0d9510333d04d55f1ef9
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.760, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1U4XLv-0001AM-Rf 1f4ff881ec64b5eea45b6bf2221743f2
Subject: Re: proposed WINDOW_UPDATE text for session flow control windows
Archived-At: <>
X-Mailing-List: <> archive/latest/16521
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

>From time to time I bang the drum for allowing negative window updates
(i.e. allowing the receiver to revoke, given a rtt, a portion of previously
granted and unused window due to local resource changes on the receiver).
This proposal doesn't contain that provision - but it has an obvious unused
bit where it could go.

If nobody else sees the value in that I'll stop banging the drum - but this
is sort of a last call to sanity check that.

On Sun, Feb 10, 2013 at 3:03 AM, William Chan (陈智昌)

> Here's my commit in my github fork of the HTTP/2.0 spec:
> Here's the HTML generated for that (it looks very broken, sorry, I am n00b
> at this tooling):
> Roberto and I have had some minimal discussion about this at my pull
> request to his SPDY spec repo:
> 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
> 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:
> ========================================
>    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.