- From: 陈智昌 <willchan@chromium.org>
- Date: Sun, 10 Feb 2013 11:14:43 -0800
- To: Patrick McManus <mcmanus@ducksong.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAA4WUYg2gn7Um1FZk3KBcP5aH=RpSCbYduFz3M+hZGQ_A4tsxQ@mail.gmail.com>
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 <mcmanus@ducksong.com>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 (陈智昌) <willchan@chromium.org > > wrote: > >> 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. >> >> >
Received on Sunday, 10 February 2013 19:15:11 UTC