RE: proposed WINDOW_UPDATE text for session flow control windows

Roberto Peon <grmocg@gmail.com> Mon, 11 February 2013 18:11 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 E60CC21F8821 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Feb 2013 10:11:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.848
X-Spam-Level:
X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 OMuXIt8O67Dr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Feb 2013 10:11:44 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5934C21F87D2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 11 Feb 2013 10:11:44 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U4xpR-0008FI-Ao for ietf-http-wg-dist@listhub.w3.org; Mon, 11 Feb 2013 18:10:09 +0000
Resent-Date: Mon, 11 Feb 2013 18:10:09 +0000
Resent-Message-Id: <E1U4xpR-0008FI-Ao@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1U4xpH-0006zB-82 for ietf-http-wg@listhub.w3.org; Mon, 11 Feb 2013 18:09:59 +0000
Received: from mail-oa0-f43.google.com ([209.85.219.43]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1U4xpF-0001ka-Bb for ietf-http-wg@w3.org; Mon, 11 Feb 2013 18:09:59 +0000
Received: by mail-oa0-f43.google.com with SMTP id l10so6541382oag.16 for <ietf-http-wg@w3.org>; Mon, 11 Feb 2013 10:09:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+WlAWk5x+2YLqaA1ox0+Ss3IUkjxhUeAshZ+c18Qte0=; b=gBWboXqtP9r1kSmQxTGvQhCUHNEYnXpjIidcVthiJdvhvwZjGa46coDydkPeGX4XjM R+OVksMdoQ90fCDcgkrLFxVivP8OyyspbsxFsSdCKeurNoI3iVO2Q800eKT90DRRQl7y PrhcGZN0U9AwhJxSwXd12dCYLzoMmL2uSeiZEcUqM88wrU8r7BOsnxxWJxMRpVAW0r3u UXAwi2iWh4zA/Vp8oxBCvCQy5VNtgX/GB0DqN3STEdJmGwh96jnG99BZYrK4xdalYdGj uoD5Ru4kuEDrUDhwYVH+59WZh4TrIPf8d4FGt39ygCoulPh/tVA2Pg9mB+cHVCSQAYsn 0d1g==
MIME-Version: 1.0
X-Received: by 10.182.115.34 with SMTP id jl2mr3036007obb.9.1360606170855; Mon, 11 Feb 2013 10:09:30 -0800 (PST)
Received: by 10.76.167.193 with HTTP; Mon, 11 Feb 2013 10:09:30 -0800 (PST)
Received: by 10.76.167.193 with HTTP; Mon, 11 Feb 2013 10:09:30 -0800 (PST)
In-Reply-To: <6C71876BDCCD01488E70A2399529D5E52E8A2C@ADELE.crf.canon.fr>
References: <CAA4WUYiH8tCF83=jsk_jsvhXkYvmJ+pPLFzhacAMq3O54z2YBw@mail.gmail.com> <6C71876BDCCD01488E70A2399529D5E52E8A2C@ADELE.crf.canon.fr>
Date: Mon, 11 Feb 2013 10:09:30 -0800
Message-ID: <CAP+FsNcrdNoOSiS+gsx3igaqjsbK82ZhW6vhETBU2YVRjEEcBQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=f46d044481417e378704d576cf66
Received-SPF: pass client-ip=209.85.219.43; envelope-from=grmocg@gmail.com; helo=mail-oa0-f43.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1U4xpF-0001ka-Bb aefd04b08dffa61632f10bc0de53bcec
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/CAP+FsNcrdNoOSiS+gsx3igaqjsbK82ZhW6vhETBU2YVRjEEcBQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16566
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>

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.
>