HI Timo,
As you know if you allows the ACE to use a window scale factor that essentially increases the size of the TCP send and receive buffers. The sender specifies a window scale factor in a SYN segment that determines the send and receive window size for the duration of the connection.
You have defined tcp-options scale allow in the parameter map but have not specified to which scale factor this should scale to.
The TCP window scaling feature adds support for the Window Scaling option in RFC 1323. It is recommend that increasing the window size to improve TCP performance in network paths with large bandwidth, long-delay characteristics. This type of network is called a long fat network (LFN).
But you have not configure a TCP window-scale factor which is essential for network paths with high-bandwidth, long-delay characteristics, using the "set tcp window-scale " command.
The window scaling extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit window field of the TCP header.
You can increase the window size to a maximum scale factor of 14.
Typical applications use a scale factor of 3 when deployed in LFNs but in you case if this is a LFN you are using default which is 0.
So here in your case you can select how much scale factor is needed to be defined from the range 0-14 , otherwise even if you have defined in the tcp-options windlow-scale allow, but as you have not define to what factor it should scale to , so it will always use the default scale factor which is 0, means no scaling at all.
To set the TCP window-scale factor to 3, add the second command as well in your parameter map:
host1/Admin(config-parammap-conn)# tcp-options window-scale allow ---> Defined already
host1/Admin(config-parammap-conn)# set tcp window-scale 3 ----> Needed to be added else "default scale factor 0" will be taken
You can check in the following URL at cisco docs wiki for how ACE handles Connection at Layer 4 (L4) and Layer 7 (L7):
http://docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_(ACE)_Module_Troubleshooting_Guide,_Release_A2(x)_--_Troubleshooting_Connectivity
Here are the details of how a tcp-options scale windows works:
The window scale extension expands the definition of the TCP
window to 32 bits and then uses a scale factor to carry this 32- bit
value in the 16-bit Window field of the TCP header (SEG.WND in RFC-793).
The scale factor is carried in a new TCP option, Window Scale.
This option is sent only in a SYN segment (a segment with the SYN bit on),
hence the window scale is fixed in each direction when a connection is opened.
(Another design choice would be to specify the window scale in every TCP segment.
It would be incorrect to send a window scale option only when the scale factor changed,
since a TCP option in an acknowledgement segment will not be delivered reliably
(unless the ACK happens to be piggy-backed on data in the other direction).
Fixing the scale when the connection is opened has the advantage of lower
overhead but the disadvantage that the scale factor cannot be changed
during the connection.) The maximum receive window, and therefore the
scale factor, is determined by the maximum receive buffer space.
In a typical modern implementation, this maximum buffer space is set
by default but can be overridden by a user program before a
TCP connection is opened. This determines the scale factor,
and therefore no new user interface is needed for window scaling.
Window Scale Option The three-byte Window Scale option
may be sent in a SYN segment by a TCP.
It has two purposes:
(1) indicate that the TCP is prepared to do both send and receive window scaling, and
(2) communicate a scale factor to be applied to its receive window.
Thus, a TCP that is prepared to scale windows should send the option,
even if its own scale factor is 1. The scale factor is limited to
a power of two and encoded logarithmically,
so it may be implemented by binary shift operations.
TCP Window Scale Option (WSopt):
Kind: 3 Length: 3 bytes
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+
This option is an offer, not a promise; both sides must send
Window Scale options in their SYN segments to enable window
scaling in either direction. If window scaling is enabled,
then the TCP that sent this option will right-shift its true
receive-window values by 'shift.cnt' bits for transmission in
SEG.WND. The value 'shift.cnt' may be zero (offering to scale,
while applying a scale factor of 1 to the receive window).
This option may be sent in an initial segment (i.e., a
segment with the SYN bit on and the ACK bit off).
It may also be sent in a segment, but only if a Window
Scale op- tion was received in the initial segment.
A Window Scale option in a segment without a SYN bit should be ignored.
The Window field in a SYN (i.e., a or ) segment itself is never scaled.
Using the Window Scale Option
A model implementation of window scaling is as follows
All windows are treated as 32-bit quantities for storage in
the connection control block and for local calculations.
This includes the send-window (SND.WND) and the receive- window
(RCV.WND) values, as well as the congestion window.
* The connection state is augmented by two window shift counts,
Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the
incoming and outgoing window fields, respectively.
* If a TCP receives a segment containing a Window Scale
option, it sends its own Window Scale option in the segment.
* The Window Scale option is sent with shift.cnt = R, where R
is the value that the TCP would like to use for its receive window.
* Upon receiving a SYN segment with a Window Scale option containing
shift.cnt = S, a TCP sets Snd.Wind.Scale to S and sets Rcv.Wind.Scale
to R; otherwise, it sets both Snd.Wind.Scale and Rcv.Wind.Scale to zero.
* The window field (SEG.WND) in the header of every incoming segment,
with the exception of SYN segments, is left-shifted by Snd.Wind.Scale
bits before updating SND.WND: SND.WND = SEG.WND << Snd.Wind.Scale
(assuming the other conditions of RFC793 are met,
and using the "C" notation "<<" for left-shift).
* The window field (SEG.WND) of every outgoing segment, with the
exception of SYN segments, is right-shifted by
Rcv.Wind.Scale bits: SEG.WND = RCV.WND >> Rcv.Wind.Scale.
TCP determines if a data segment is "old" or "new" by testing
whether its sequence number is within 2**31 bytes of the left
edge of the window, and if it is not, discarding the data as "old".
To insure that new data is never mistakenly considered old and vice- versa,
the left edge of the sender's window has to be at most 2**31 away
from the right edge of the receiver's window. Similarly with the
sender's right edge and receiver's left edge. Since the right and
left edges of either the sender's or receiver's window differ by
the window size, and since the sender and receiver windows can be
out of phase by at most the window size, the above constraints imply
that
2 * the max window size must be less than 2**31,
or max window < 2**30 Since the max window is 2**S
(where S is the scaling shift count) times at most 2**16 - 1
(the maximum unscaled window),
the maximum window is guaranteed to be < 2*30 if S <= 14.
Thus, the shift count must be limited to 14 (which allows windows of 2**30 = 1 Gbyte).
If a Window Scale option is received with a shift.cnt value exceeding 14,
the TCP should log the error but use 14 instead of the specified value.
The scale factor applies only to the Window field as transmitted
in the TCP header; each TCP using extended windows will maintain
the window values locally as 32-bit numbers. For example,
the "congestion window" computed by Slow Start and Congestion Avoidance
is not affected by the scale factor, so window scaling will not introduce
quantization into the congestion window.
Hope it will resolve your issue, else get back to us for further discussion.
Best regards,
Sachin Garg
Message was edited by: sachinga.hcl
