Re: proposed WINDOW_UPDATE text for session flow control windows

William Chan (陈智昌) <> Sun, 10 February 2013 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B00821F8473 for <>; Sun, 10 Feb 2013 11:17:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.27
X-Spam-Status: No, score=-9.27 tagged_above=-999 required=5 tests=[AWL=0.406, 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 JoAhtJaXcWdG for <>; Sun, 10 Feb 2013 11:17:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 60F7521F842E for <>; Sun, 10 Feb 2013 11:17:28 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1U4cMy-0004Op-Oj for; Sun, 10 Feb 2013 19:15:20 +0000
Resent-Date: Sun, 10 Feb 2013 19:15:20 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1U4cMp-0004O5-94 for; Sun, 10 Feb 2013 19:15:11 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1U4cMn-0005vM-Ls for; Sun, 10 Feb 2013 19:15:11 +0000
Received: by with SMTP id v28so2013610qcm.11 for <>; Sun, 10 Feb 2013 11:14:43 -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=oJQHErCF19zivEILrR9D+OQCeimlOopj3CNK14wTjug=; b=oZjieMCU3fIgVjj0Zsy75vFCscjacDcFBXHqysSFgQAOUf6Pb2a4pr7t57Q5QNmL2p yJPHLRpFtuCggz2NITtMf08mH+HU2pRiPOKYVxUzlzKlyl8iko1+JHLONkj4xOPzOUeZ dfZ6AtDry8PSov7g1shI2mtyoi39p36zxEZDUzL0h5CWgJXWjF/y7I7RwG9pqQpT/PNr ZOBTpbpOupuNgVyRtFvBZxFdB5qQRGvHeQ+xk3abWBL6cKL9biy0S7sm1G3h/Tn1fHHC Z/rW4R9WGu4KQ0u5j/oBS6h+27mzHBS+fe0vfim2kXD6OXQqUNWbNejkS7h00jeX1bfq iJIg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=oJQHErCF19zivEILrR9D+OQCeimlOopj3CNK14wTjug=; b=TK0rY7BIxCIGKCEF5U2mKGx3xw7E0J9h0RPvzj4hJrAnt+aBRr0EmcRfcIqBYS3M9Y xg2VMroHj197n3KdEZY4KcSyzyira6I7J6T3LsYiZyfy3FN5/vbwR1Dp2sLzKOq/yOLH LOFqpsEWPBdBUyJWaRIMPo2x3J5t4mWxePjLA=
X-Google-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 :x-gm-message-state; bh=oJQHErCF19zivEILrR9D+OQCeimlOopj3CNK14wTjug=; b=HMUvA/WqdV3ishCa6s6nMFwO6boi3Jcwqo/PGjZ4xC/FHNiswciGUJ4xbCgXMaH5s7 Ur8ZTyq334OImbBEzRqPZdhSGslRYmTPRBnbWvVvmCesZp6rToOX2Lk21LEPQQy0rY08 EzNt/Lgbc883O9ksC1+kv3RpXlanlfmk311Xh3O2icDKu29qxmksE4fRbM5uoJaQyDs3 y90Q/ZRIWfPRoGATpUtT5OqnYpzbqazTWNUNoXdAntOPY77Ne3A+LTbCsiMYMeNSpEtI e7uVfChJ1piDs4SVvRk6M/4nBWd0ot2yFL2foJu+vEJKcZkeR/YOPsBzWRbR0zLsSodS 3GFA==
MIME-Version: 1.0
X-Received: by with SMTP id em22mr1063291qcb.2.1360523683699; Sun, 10 Feb 2013 11:14:43 -0800 (PST)
Received: by with HTTP; Sun, 10 Feb 2013 11:14:43 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Sun, 10 Feb 2013 11:14:43 -0800
X-Google-Sender-Auth: eSWC76AirRyzjnFletmE3zdiYd4
Message-ID: <>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
To: Patrick McManus <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=001636d33be2e01e1a04d5639a71
X-Gm-Message-State: ALoCoQlJxAPm1Za/DEGOBVcIFncpFShHePRa5KzWLyMDTX6/L2Ri6mJ9k9GVeLetBrzUoMHiJ4ATiDmkZsAgTppzwvOE1y056H2PoIiSp/Z5ZjFuWEr/qJa5+T1vv3txIlC3H/G37UmktPWjvjhVRS0wnXWAB0uithdNOQtd4goSkgiMKqxvs13tGR0ovNlOE3OBRXMhVmtD
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.569, 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: 1U4cMn-0005vM-Ls c7878425a537648d0e76b72b6c54af5d
Subject: Re: proposed WINDOW_UPDATE text for session flow control windows
Archived-At: <>
X-Mailing-List: <> archive/latest/16526
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Do servers often have a need to immediately revoke buffer size promises? In
absence of negative window updates, I would think servers would just stop
sending WINDOW_UPDATEs. Is that mechanism insufficient?

One thing I like about the lack of negative window updates is the ability
to assert (for streams that don't race with a SETTINGS frame that sets the
initial window size) that the sender is respecting flow control. I guess
you can still assert this as long as you aren't actively using negative
window updates.

All in all, I don't feel very strongly on this. I'd rather hear from more
proxy/server vendors that they want this, rather than adding it in just
because it might be useful. Or are you suggesting that Firefox would like
to use this?

On Sun, Feb 10, 2013 at 5:53 AM, Patrick McManus <>wrote;wrote:

> 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 (陈智昌) <
> > wrote:
>> 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:
>> ========================================
>> 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.