Subject: [Tsvwg] TCP window scale option query

From: "Gaurav" <[email-masked]>
Date: Tue, 30 May 2006 12:26:37 +0530

Hi,
	I am a novice trying to modify TCP for large BDP (wireless) and i have some
doubts regarding window scale option.
	It'd be great if someone can answer these queries and also correct
misunderstood concepts, if any.

	I have understood that both sides of the TCP store the window sizes as 32
bit values and before transmitting the sender 	will right shift it by R bits
and the receiver will left shift it by R bits on reception.
	The number R bits is indicated in the window scale option at the time of
signaling (SYN/ACKs etc.).
	But, what i cannot understand is that by using these we will only be able
to send a window size which is a multiple of 	2^R (or 2**R). While this
might turn out to be a favourable option for slow start but not so for the
phase after the 	slow start phase.
	RFC 1323 writes "The scale factor is limited to a power of 2 only".

	Numerically, can i transfer a window size (in binary) of 00111111.....1 (
last 30 bits set) using the window scale 	option? If not, then shall i round
it off to the largest available power of 2^R which is less than the present
window 	size?

	My second doubt is regarding the change in the value of R.
	According to the RFC 1323 we can only send the scale factor "R" with a SYN
or SYN-ACK packet only.
	What do i do if BDP decreases/increases suddenly and i want to change "R"
the EST state?
	The implementation i am working on presently ignores the SYNs received in
EST state.

Thanks and regards
Gaurav Bhati

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: David Borman <[email-masked]>
Date: Tue, 30 May 2006 09:29:54 -0500

> 	RFC 1323 writes "The scale factor is limited to a power of 2 only".

Yes.  In effect, the window scale option determines the granularity  
of the window updates.  This works just fine, because window updates  
do not have to be exact.

As a practical matter, you do not want to advertise a window scale  
factor that makes the granularity of the updates larger than the  
largest window you ever intend to advertise;  i.e., if your largest  
window will only be 8K, it wouldn't make any sense to use a window  
scale of 13 or 14, because with those values the granularity of the  
window updates will be 8K and 16K, respectively.

In practice, as long as your window scale has a granularity that  
still allows you to divide up your maximum window space into at least  
4 or 8 pieces, things should work ok.  A window scale of 10 give you  
a granularity of 1K in your window updates which should accommodate  
any reasonable amount of buffer space, and allows you to advertise a  
67 mbyte window.  In most situations today with ethernet sized  
packets, you don't really need or want to be advertising window  
updates of less than 1K.  Read up on Silly Windows for more  
information on that.  If you do need to advertise window updates  
smaller than that, then you probably shouldn't be using the window  
scale option (or should use a more realistic window scale value.)

> 	Numerically, can i transfer a window size (in binary) of  

Yes.  It is ok to have more receive buffer space available than you  
advertise in the window, but not ok to advertise a larger window than  
you are willing to accept.

The largest window you can advertise with the maximum window scale of  
14 is:
	(2^16 - 1) << 14 == 0x3FFFC000.

> 	The implementation i am working on presently ignores the SYNs  

You can only reliably negotiate the window scale factor during the  
initial SYN exchange.  Trying to change the window scale factor after  
the connection has been established is problematical, as TCP options  
are not reliably exchanged.  You have to know at which point in the  
data stream the new window scale factor should take effect, and that  
becomes difficult without adding a whole new reliability mechanism  
within TCP for the exchange of options.  You get the reliability for  
free during the initial 3-way handshake.  It's better to over  
estimate your window needs a bit up front if you think you might need  
more later on.  For example, a window scale of 4 allows up to 1 mbyte  
of window, but since the granularity is only 2^4 == 16 bytes, you'll  
never notice the difference from an un-scaled window; window updates  
are done on a much larger granularity than 16 bytes.

The goal of the window scale option isn't to make it a "best fit" to  
the current size of the available buffer space, it's goal is to  
accommodate the largest window that you will ever want to reasonably  
advertise.  It's perfectly fine to over-estimate the window scale (as  
long as you don't go wildly overboard as mentioned above.)

Another option as noted in RFC 1323 would be to send the window scale  
with every packet; while that allows flexibility, it also introduces  
overhead in the processing of every packet, and it was felt that the  
extra overhead on every packet wasn't worth the added flexibility.

> Gaurav Bhati

			-David Borman