Questions about Flow control in SPDY3.1

[Programmist Setevik]

It is somewhat ambiguous in the RFC.

 

1. The window value in SETTING Frame applies to streams only or does it also apply to the Session-level flow control window ? In other words, both Stream and Session have default window value of 64KB. Yet SETTINGS Frame only allows to change it for Streams, not Session - which is kind of moot it seems. One would run out of Session Window (64KB) before running out of Stream-level Window (even it is jacked up to say 1GB)

 

And then you'd have to rely on WINDOW_UPDATE  to un-throttle the traffic

 

2.  What is is the max size of window one can advertise via SETTINGS Frame ? is it 4GB (2^32) or 2GB-1 byte (2^31 -2) ? I have a setup where I don't want to be bothered with WINDOW_UPDATE and instead, want the remote side to blast the data to me as fast as possible .

 

The RFC is ambiguous in that respect - it sez we can't allow WIN_UPDATE to result in window larger than 2^31-1. But can we _start_ with a window at 4GB ?

 

3. Do the client implementations out there (Chrome/FFox) actively enforce Session- level flow control  ? I can simply ignore session flow control when it comes down to inbound data . But what about the clients receiving the data - will they actively enforce Session-level flow control ?

 

[Patrick McManus]

On Mon, Aug 11, 2014 at 8:16 AM, Programmist Setevik <programmi...@gmail.com> wrote:

It is somewhat ambiguous in the RFC.

 

what rfc? :)

 

1. The window value in SETTING Frame applies to streams only or does it also apply to the Session-level flow control window ?

just streams.

 

In other words, both Stream and Session have default window value of 64KB. Yet SETTINGS Frame only allows to change it for Streams, not Session - which is kind of moot it seems. One would run out of Session Window (64KB) before running out of Stream-level Window (even it is jacked up to say 1GB)

a window update on stream 0 can be used to increase the session flow control window past the initial 64KB. Firefox pipelines such an update right after the initial settings frame.

 
 

2.  What is is the max size of window one can advertise via SETTINGS Frame ? is it 4GB (2^32) or 2GB-1 byte (2^31 -2) ? I have a setup where I don't want to be bothered with WINDOW_UPDATE and instead, want the remote side to blast the data to me as fast as possible .

 

The RFC is ambiguous in that respect - it sez we can't allow WIN_UPDATE to result in window larger than 2^31-1. But can we _start_ with a window at 4GB ?

Clever lawyering, but I'm pretty confident the intention here is that the window size can be represented with a signed 32 at any given moment. (there are cases where it goes negative). That ought to support any BDP you will see so there is no reason to expect a slow down.

 

 

3. Do the client implementations out there (Chrome/FFox) actively enforce Session- level flow control  ?

I can simply ignore session flow control when it comes down to inbound data . But what about the clients receiving the data - will they actively enforce Session-level flow control ?

Right now firefox will not complain if the peer over sends - but features are being designed that will indeed use this protocol guarantee and generate errors if the server is in non compliance.

 

[Johnny Graettinger]

3. Do the client implementations out there (Chrome/FFox) actively enforce Session- level flow control  ? I can simply ignore session flow control when it comes down to inbound data . But what about the clients receiving the data - will they actively enforce Session-level flow control ?

Chrome will indeed close the connection if stream or session flow control is violated.