Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Adding session windows to the flow control section #4

Merged
merged 2 commits into from

2 participants

William Chan grmocg
William Chan

Reading through the flow control section, it needs a lot of work. But here's a start.

grmocg grmocg commented on the diff
draft-mbelshe-httpbis-spdy-00.txt
((11 lines not shown))
- back to the original sender.) Flow control only applies to the data
- portion of data frames. Recipients must buffer all control frames.
- If a recipient fails to buffer an entire control frame, it MUST issue
- a stream error (Section 2.4.2) with the status code
- FLOW_CONTROL_ERROR for the stream.
+ The WINDOW_UPDATE control frame is used to implement per stream and
+ per session flow control in SPDY. Flow control in SPDY is per hop,
+ that is, only between the two endpoints of a SPDY 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. Recipients must buffer
+ all control frames. If a recipient fails to buffer an entire control
+ frame, it MUST issue a stream error (Section 2.4.2) with the status
grmocg Owner
grmocg added a note

This seems wrong. I suspect what we want here is to cease to read upon the connection, or close it down.
A stream error could be fatal to the session here for the wrong frame types, e.g. any which contain a Header Block and so is unsafe.

William Chan
willchan added a note

This isn't new.

William Chan
willchan added a note

And I agree with your comment. Note that our existing SPDY/3 specs and implementation are broken in this manner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
grmocg grmocg commented on the diff
draft-mbelshe-httpbis-spdy-00.txt
@@ -1345,6 +1345,27 @@ Belshe & Peon Expires February 2, 2013 [Page 24]
Internet-Draft SPDY August 2012
+ Flow control in SPDY is implemented by a data transfer window for
+ 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 pause transmitting data frames for that stream.
grmocg Owner
grmocg added a note

must pause is a bit ambiguous.

How about:
When a stream window size is less than or equal to
0, the sender MUST NOT send a data frame, unless it is a zero-length data frame with the FIN (or whatever it is called) flag set.

As an aside, we could allow zero-length data frames without a FIN to indicate that the stream is blocked (a max of one). We shouldn't put that in now.

William Chan
willchan added a note

This section isn't new either. I agree with your comments and thought so myself went adding the session window. I would like to do that separately from cleaning up existing problems with the spec, as I mean to propose this to the HTTPbis WG as per the action item given me. I think we should do the editorial cleanups in a separate change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
grmocg grmocg commented on the diff
draft-mbelshe-httpbis-spdy-00.txt
((4 lines not shown))
+ Flow control in SPDY is implemented by a data transfer window for
+ 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 pause transmitting data frames for that stream.
+ Likewise, when the session window size becomes less than or equal to
+ 0, the sender must pause transmitting any data frames for the
grmocg Owner
grmocg added a note

this should be similarly changed

William Chan
willchan added a note

I agree, but like the other suggestions, I'd like to postpone them to a separate change to really clean up this section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
grmocg grmocg commented on the diff
draft-mbelshe-httpbis-spdy-00.txt
((12 lines not shown))
is always 4.
Stream-ID: The stream ID that this WINDOW_UPDATE control frame is
- for.
+ for. If the stream ID value is 0, the WINDOW_UPDATE frame applies to
grmocg Owner
grmocg added a note

I don't think we've spec'd what happens when a receiver receives a WINDOW_UPDATE frame for one of its incoming streams. I'd guess we should say it should be ignored (it is another possible venue for indicating one is blocked)...

William Chan
willchan added a note

I thought about the WINDOW_UPDATE for the wrong direction of stream id as well. I'm inclined to treat it as a session error for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
grmocg grmocg commented on the diff
draft-mbelshe-httpbis-spdy-00.txt
@@ -1383,24 +1413,19 @@ Internet-Draft SPDY August 2012
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 its window size to exceed
- this limit, it must send RST_STREAM with status code
- FLOW_CONTROL_ERROR to terminate the stream.
+ 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.
grmocg Owner
grmocg added a note

Perhaps we should add something like: This is better than simply capping at 2^31 because it makes it significantly less likely for a buggy implementation to stall forever.

William Chan
willchan added a note

That's a good explanation of why to do it this way. Do specs often indicate why they say MUST or SHOULD or whatever? I'm happy to put this in if desired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
grmocg grmocg commented on the diff
draft-mbelshe-httpbis-spdy-00.txt
((4 lines not shown))
- In the case of option 2, both sides must compute the window size
- based on the initial window size in the SETTINGS. For example, if
- the recipient sets the initial window size to be 16KB, and the sender
- sends 64KB immediately on connection establishment, the sender will
- discover its window size is -48KB on receipt of the SETTINGS. As the
- recipient consumes the first 16KB, it must 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.
+ 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
grmocg Owner
grmocg added a note

We probably need a setting for session and for stream separately. Bleh.,

William Chan
willchan added a note

I had considered that, but decided it was unnecessary. The reason is that you should just send a WINDOW_UPDATE with stream id 0 with whatever delta to increase the session window size accordingly. In order to shrink it, you just let the sender send data and don't send WINDOW_UPDATE for the session window until it goes below the desired size.

The reason to prefer a SETTINGS frame is just for persistence. I don't think we're considering persisting it as of yet.

I did consider whether or not to rename the SETTINGS id to indicate it's only for the stream window. I can do that if desired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
grmocg
Owner

I've added in some in-line notes.

William Chan

I've responded to all the inline notes I saw. I agree with all the comments and thought of them myself while writing this down. I think the wording needs a fair amount of cleanup. I'm not sure if we should do that before or after submitting the wording to the working group. In any case, I'd like to do the cleanup/refactor as a separate pull request so this one is strictly about session windows.

grmocg grmocg merged commit 41abb89 into from
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Feb 6, 2013
  1. William Chan
  2. William Chan

    Update the text file

    willchan authored
This page is out of date. Refresh to see the latest.
Showing with 145 additions and 144 deletions.
  1. +138 −138 draft-mbelshe-httpbis-spdy-00.txt
  2. +7 −6 draft-mbelshe-spdy-00.xml
276 draft-mbelshe-httpbis-spdy-00.txt
View
@@ -96,8 +96,8 @@ Table of Contents
2.6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.9. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.10. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . 24
- 2.6.11. CREDENTIAL . . . . . . . . . . . . . . . . . . . . . . 26
- 2.6.12. Name/Value Header Block . . . . . . . . . . . . . . . 28
+ 2.6.11. CREDENTIAL . . . . . . . . . . . . . . . . . . . . . . 27
+ 2.6.12. Name/Value Header Block . . . . . . . . . . . . . . . 29
3. HTTP Layering over SPDY . . . . . . . . . . . . . . . . . . . 36
3.1. Connection Management . . . . . . . . . . . . . . . . . . 36
3.1.1. Use of GOAWAY . . . . . . . . . . . . . . . . . . . . 36
@@ -1324,18 +1324,18 @@ Internet-Draft SPDY August 2012
2.6.10. WINDOW_UPDATE
- The WINDOW_UPDATE control frame is used to implement per stream flow
- control in SPDY. Flow control in SPDY is per hop, that is, only
- between the two endpoints of a SPDY 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. Recipients must buffer all control frames.
- If a recipient fails to buffer an entire control frame, it MUST issue
- a stream error (Section 2.4.2) with the status code
- FLOW_CONTROL_ERROR for the stream.
+ The WINDOW_UPDATE control frame is used to implement per stream and
+ per session flow control in SPDY. Flow control in SPDY is per hop,
+ that is, only between the two endpoints of a SPDY 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. Recipients must buffer
+ all control frames. If a recipient fails to buffer an entire control
+ frame, it MUST issue a stream error (Section 2.4.2) with the status
grmocg Owner
grmocg added a note

This seems wrong. I suspect what we want here is to cease to read upon the connection, or close it down.
A stream error could be fatal to the session here for the wrong frame types, e.g. any which contain a Header Block and so is unsafe.

William Chan
willchan added a note

This isn't new.

William Chan
willchan added a note

And I agree with your comment. Note that our existing SPDY/3 specs and implementation are broken in this manner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+ code FLOW_CONTROL_ERROR for the stream.
@@ -1345,6 +1345,27 @@ Belshe & Peon Expires February 2, 2013 [Page 24]
Internet-Draft SPDY August 2012
+ Flow control in SPDY is implemented by a data transfer window for
+ 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 pause transmitting data frames for that stream.
grmocg Owner
grmocg added a note

must pause is a bit ambiguous.

How about:
When a stream window size is less than or equal to
0, the sender MUST NOT send a data frame, unless it is a zero-length data frame with the FIN (or whatever it is called) flag set.

As an aside, we could allow zero-length data frames without a FIN to indicate that the stream is blocked (a max of one). We shouldn't put that in now.

William Chan
willchan added a note

This section isn't new either. I agree with your comments and thought so myself went adding the session window. I would like to do that separately from cleaning up existing problems with the spec, as I mean to propose this to the HTTPbis WG as per the action item given me. I think we should do the editorial cleanups in a separate change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+ Likewise, when the session window size becomes less than or equal to
+ 0, the sender must pause transmitting any data frames for the
grmocg Owner
grmocg added a note

this should be similarly changed

William Chan
willchan added a note

I agree, but like the other suggestions, I'd like to postpone them to a separate change to really clean up this section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+ session, regardless of what stream it belongs to. 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.
+
Flow control in SPDY is implemented by a data transfer window kept by
the sender of each stream. The data transfer window is a simple
uint32 that indicates how many bytes of data the sender can transmit.
@@ -1372,10 +1393,19 @@ Internet-Draft SPDY August 2012
Length: An unsigned 16-bit value representing the number of bytes
which follow the frame header. For WINDOW_UPDATE frames, this value
+
+
+
+Belshe & Peon Expires February 2, 2013 [Page 25]
+
+Internet-Draft SPDY August 2012
+
+
is always 4.
Stream-ID: The stream ID that this WINDOW_UPDATE control frame is
- for.
+ for. If the stream ID value is 0, the WINDOW_UPDATE frame applies to
grmocg Owner
grmocg added a note

I don't think we've spec'd what happens when a receiver receives a WINDOW_UPDATE frame for one of its incoming streams. I'd guess we should say it should be ignored (it is another possible venue for indicating one is blocked)...

William Chan
willchan added a note

I thought about the WINDOW_UPDATE for the wrong direction of stream id as well. I'm inclined to treat it as a session error for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+ 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
@@ -1383,24 +1413,19 @@ Internet-Draft SPDY August 2012
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 its window size to exceed
- this limit, it must send RST_STREAM with status code
- FLOW_CONTROL_ERROR to terminate the stream.
+ 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.
grmocg Owner
grmocg added a note

Perhaps we should add something like: This is better than simply capping at 2^31 because it makes it significantly less likely for a buggy implementation to stall forever.

William Chan
willchan added a note

That's a good explanation of why to do it this way. Do specs often indicate why they say MUST or SHOULD or whatever? I'm happy to put this in if desired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
When a SPDY connection is first established, the default initial
- window size for all streams is 64KB. An endpoint can use the
- SETTINGS control frame to adjust the initial window size for the
- connection. That is, its peer can start out using the 64KB default
- initial window size when sending data frames before receiving the
- SETTINGS. Because SETTINGS is asynchronous, there may be a race
-
-
-
-Belshe & Peon Expires February 2, 2013 [Page 25]
-
-Internet-Draft SPDY August 2012
-
-
+ 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
@@ -1416,21 +1441,29 @@ Internet-Draft SPDY August 2012
default initial window size), and send WINDOW_UPDATE as it
consumes data.
- In the case of option 2, both sides must compute the window size
- based on the initial window size in the SETTINGS. For example, if
- the recipient sets the initial window size to be 16KB, and the sender
- sends 64KB immediately on connection establishment, the sender will
- discover its window size is -48KB on receipt of the SETTINGS. As the
- recipient consumes the first 16KB, it must 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.
+ 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
grmocg Owner
grmocg added a note

We probably need a setting for session and for stream separately. Bleh.,

William Chan
willchan added a note

I had considered that, but decided it was unnecessary. The reason is that you should just send a WINDOW_UPDATE with stream id 0 with whatever delta to increase the session window size accordingly. In order to shrink it, you just let the sender send data and don't send WINDOW_UPDATE for the session window until it goes below the desired size.

The reason to prefer a SETTINGS frame is just for persistence. I don't think we're considering persisting it as of yet.

I did consider whether or not to rename the SETTINGS id to indicate it's only for the stream window. I can do that if desired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+ interaction continues until the sender's window size becomes positive
+
+
+
+Belshe & Peon Expires February 2, 2013 [Page 26]
+
+Internet-Draft SPDY August 2012
+
+
+ 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
- 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.
+ 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.
@@ -1449,14 +1482,6 @@ Internet-Draft SPDY August 2012
contain at most one client certificate, the client needs a mechanism
to send additional client certificates to the server.
-
-
-
-Belshe & Peon Expires February 2, 2013 [Page 26]
-
-Internet-Draft SPDY August 2012
-
-
The server is required to maintain a vector of client certificates
associated with a SPDY session. When the client needs to send a
client certificate to the server, it will send a CREDENTIAL frame
@@ -1480,6 +1505,14 @@ Internet-Draft SPDY August 2012
different pages (in different tabs). When the renegotiation + client
certificate request comes in, the browser is unable to determine
which resource triggered the client certificate request, in order to
+
+
+
+Belshe & Peon Expires February 2, 2013 [Page 27]
+
+Internet-Draft SPDY August 2012
+
+
prompt the user accordingly.
0 1 2 3 4 5 6 7
@@ -1505,14 +1538,6 @@ Internet-Draft SPDY August 2012
Proof: Cryptographic proof that the client has possession of the
private key associated with the certificate. The format is a TLS
digitally-signed element
-
-
-
-Belshe & Peon Expires February 2, 2013 [Page 27]
-
-Internet-Draft SPDY August 2012
-
-
(http://tools.ietf.org/html/rfc5246#section-4.7). The signature
algorithm must be the same as that used in the CertificateVerify
message. However, since the MD5+SHA1 signature type used in TLS 1.0
@@ -1536,6 +1561,14 @@ Internet-Draft SPDY August 2012
credential (either missing or invalid), it must reply with a
RST_STREAM frame with the status code INVALID_CREDENTIALS. Upon
receipt of a RST_STREAM frame with INVALID_CREDENTIALS, the client
+
+
+
+Belshe & Peon Expires February 2, 2013 [Page 28]
+
+Internet-Draft SPDY August 2012
+
+
should initiate a new stream directly to the requested origin and
resend the request. Note, SPDY does not allow the server to request
different client authentication for different resources in the same
@@ -1560,15 +1593,6 @@ Internet-Draft SPDY August 2012
The HeaderBlock compressor (described later) is subject to the
following constraints:
-
-
-
-
-Belshe & Peon Expires February 2, 2013 [Page 28]
-
-Internet-Draft SPDY August 2012
-
-
TotalHeaderStorageSize : default(16k)
MaxHeaderGroups: default(1)
@@ -1594,6 +1618,13 @@ Internet-Draft SPDY August 2012
without reconstructing the headers, and thus be able to represent and
interpret headers with less memory and CPU.
+
+
+Belshe & Peon Expires February 2, 2013 [Page 29]
+
+Internet-Draft SPDY August 2012
+
+
The Name/Value Header Block is found in the SYN_STREAM, SYN_REPLY and
HEADERS control frames, and shares a common format:
@@ -1618,13 +1649,6 @@ Internet-Draft SPDY August 2012
0x0 (reserved) -- this is not used and is reserved in case a
token-based delimiter is required in the future.
-
-
-Belshe & Peon Expires February 2, 2013 [Page 29]
-
-Internet-Draft SPDY August 2012
-
-
0x1 (Toggle) indicates that the data which follows will be an lru-
index. That lru-index, if present in the current header-group
will be removed from the header group. If it is not present in
@@ -1649,6 +1673,14 @@ Internet-Draft SPDY August 2012
0x2 (Eref) indicates that the data which follows will be two
string literals. The first such string represents key, and the
second string represents a value. Unlike KVSto, the Eref does not
+
+
+
+Belshe & Peon Expires February 2, 2013 [Page 30]
+
+Internet-Draft SPDY August 2012
+
+
modify the compressor state-- it only specified a key-value which
will be interpreted as being part of the meta-data for the frame
which includes the HeaderBlock.
@@ -1674,13 +1706,6 @@ Internet-Draft SPDY August 2012
|0| 7 bit-ascii |00000000|
+-|-------+========+--------+
-
-
-Belshe & Peon Expires February 2, 2013 [Page 30]
-
-Internet-Draft SPDY August 2012
-
-
The NumOps field encodes one minus the number of operations that
follow. Since the field-width is 8 bits, a maximum of 256 ops can be
represented. If more than 256 operations are required, simply repeat
@@ -1705,6 +1730,13 @@ Internet-Draft SPDY August 2012
Detail of an operation with an opcode of 0x2 (Clone):
+
+
+Belshe & Peon Expires February 2, 2013 [Page 31]
+
+Internet-Draft SPDY August 2012
+
+
0 1
+--------+--------+
|00000010| NumOps |
@@ -1721,22 +1753,6 @@ Internet-Draft SPDY August 2012
Detail of an operation with an opcode of 0x3 (KVSto):
-
-
-
-
-
-
-
-
-
-
-
-Belshe & Peon Expires February 2, 2013 [Page 31]
-
-Internet-Draft SPDY August 2012
-
-
0 1
+--------+--------+
|00000011| NumOps |
@@ -1769,6 +1785,14 @@ Internet-Draft SPDY August 2012
Each header name must have at least one value. Header names are
encoded using the US-ASCII character set [ASCII] and must be all
+
+
+
+Belshe & Peon Expires February 2, 2013 [Page 32]
+
+Internet-Draft SPDY August 2012
+
+
lower case. The length of each name must be greater than zero. A
recipient of a zero-length name MUST issue a stream error
(Section 2.4.2) with the status code PROTOCOL_ERROR for the
@@ -1786,13 +1810,6 @@ Internet-Draft SPDY August 2012
Compressed Data Format Specification Version 3.3 as part of RFC1950.
[RFC1950]
-
-
-Belshe & Peon Expires February 2, 2013 [Page 32]
-
-Internet-Draft SPDY August 2012
-
-
For each HEADERS compression instance, the initial state is
initialized using the following dictionary [UDELCOMPRESSION]:
@@ -1824,6 +1841,14 @@ Internet-Draft SPDY August 2012
The stream-group table for group zero looks like this:
0: ":host", "www.foo.com"
+
+
+
+Belshe & Peon Expires February 2, 2013 [Page 33]
+
+Internet-Draft SPDY August 2012
+
+
1: "cookie", "SOMELONGSTRINGHTATISMOSTLYOPAQUE;BLAJHBLA"
2: ":path", "/index.html"
3: "date", "Wed Jul 18 11:50:43 2012"
@@ -1841,14 +1866,6 @@ Internet-Draft SPDY August 2012
SYN_STREAM 3, stream-group (G)=0
Header-block:
Store(0x1): level(G),index(2),v: "/index.js"
-
-
-
-Belshe & Peon Expires February 2, 2013 [Page 33]
-
-Internet-Draft SPDY August 2012
-
-
Store(0x1): level(G),index(3),v: "Wed Jul 18 11:50:44 2012"
At this point the connection headers table is unchanged:
@@ -1880,6 +1897,14 @@ Internet-Draft SPDY August 2012
Store(0x1): level(G),index(3),v: "Wed Jul 18 11:50:44 PDT 2012"
Connection level-headers are implied.
+
+
+
+Belshe & Peon Expires February 2, 2013 [Page 34]
+
+Internet-Draft SPDY August 2012
+
+
Stream-group level headers are implied.
For this example, using TaCo (truncate and concatenate) wasn't useful.
@@ -1897,14 +1922,6 @@ Internet-Draft SPDY August 2012
2: "user-agent", "blah blah browser version blah blah"
3: "accept-encoding", "sdch, bzip, compress"
-
-
-
-Belshe & Peon Expires February 2, 2013 [Page 34]
-
-Internet-Draft SPDY August 2012
-
-
The stream-group table for group zero looks like this:
0: ":host", "www.foo.com"
1: "cookie", "SOMELONGSTRINGHTATISMOSTLYOPAQUE;FOOBLA"
@@ -1939,23 +1956,6 @@ Internet-Draft SPDY August 2012
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Belshe & Peon Expires February 2, 2013 [Page 35]
Internet-Draft SPDY August 2012
13 draft-mbelshe-spdy-00.xml
View
@@ -626,7 +626,8 @@
</section>
<section anchor="WINDOW_UPDATE" title="WINDOW_UPDATE">
- <t>The WINDOW_UPDATE control frame is used to implement per stream flow control in SPDY. Flow control in SPDY is per hop, that is, only between the two endpoints of a SPDY 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. Recipients must buffer all control frames. If a recipient fails to buffer an entire control frame, it MUST issue a <xref target="StreamErrorHandler">stream error</xref> with the status code FLOW_CONTROL_ERROR for the stream.</t>
+ <t>The WINDOW_UPDATE control frame is used to implement per stream and per session flow control in SPDY. Flow control in SPDY is per hop, that is, only between the two endpoints of a SPDY 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. Recipients must buffer all control frames. If a recipient fails to buffer an entire control frame, it MUST issue a <xref target="StreamErrorHandler">stream error</xref> with the status code FLOW_CONTROL_ERROR for the stream.</t>
+ <t>Flow control in SPDY is implemented by a data transfer window for 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 pause transmitting data frames for that stream. Likewise, when the session window size becomes less than or equal to 0, the sender must pause transmitting any data frames for the session, regardless of what stream it belongs to. 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.</t>
<t>Flow control in SPDY is implemented by a data transfer window kept by the sender of each stream. The data transfer window is a simple uint32 that indicates how many bytes of data the sender can transmit. After a stream is created, but before any data frames have been transmitted, the sender begins with the initial window size. This window size is a measure of the buffering capability of the recipient. The sender must not send a data frame with data length greater than the transfer window size. After sending each data frame, the sender decrements its transfer window size by the amount of data transmitted. When the window size becomes less than or equal to 0, the sender must pause transmitting data frames. At the other end of the stream, the recipient sends a WINDOW_UPDATE control back to notify the sender that it has consumed some data and freed up buffer space to receive more data.</t>
<figure>
@@ -644,22 +645,22 @@
</figure>
<t>Length: An unsigned 16-bit value representing the number of bytes which follow the frame header. For WINDOW_UPDATE frames, this value is always 4.</t>
- <t>Stream-ID: The stream ID that this WINDOW_UPDATE control frame is for.</t>
+ <t>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.</t>
<t>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.</t>
- <t>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 its window size to exceed this limit, it must send RST_STREAM with status code FLOW_CONTROL_ERROR to terminate the stream.</t>
+ <t>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.</t>
- <t>When a SPDY connection is first established, the default initial window size for all streams is 64KB. An endpoint can use the SETTINGS control frame to adjust the initial window size for the connection. That is, its peer can start out using the 64KB default initial window size when sending data frames before receiving the SETTINGS. 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:
+ <t>When a SPDY 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:
<list>
<t>immediately send RST_STREAM with FLOW_CONTROL_ERROR status code.</t>
<t>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.</t>
</list>
</t>
- <t>In the case of option 2, both sides must compute the window size based on the initial window size in the SETTINGS. For example, if the recipient sets the initial window size to be 16KB, and the sender sends 64KB immediately on connection establishment, the sender will discover its window size is -48KB on receipt of the SETTINGS. As the recipient consumes the first 16KB, it must 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.</t>
+ <t>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.</t>
- <t>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 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.</t>
+ <t>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.</t>
<t>The data frames from the sender and the WINDOW_UPDATE frames from the recipient are completely asynchronous with respect to each other. This property allows a recipient to aggressively update the window size kept by the sender to prevent the stream from stalling.</t>
</section>
Something went wrong with that request. Please try again.