Large TcpWindowSize

[Eugene Firsov]

Hi.

I am trying to make a very large TCP receive window size in Windows XP SP2.
According to Microsoft I should set following registry parameters:

Tcp1323Opts = 1 or 3
in HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
to turn on TCP window scaling, and

TcpWindowSize = 0xffffff (1048575) (for example)
in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{adapter
ID}

OK, for the experiment, I set up this parameters on two computers connected
via LAN and make a test TCP connection between them. But Network Monitor
shows that window size in SYN packets is still equal to 65535 and scale
factor is 0.

3 2.241148 {TCP:94382, IPv4:94381} 192.168.0.2 192.168.0.1 TCP TCP:
Flags=.S......, SrcPort=1057, DstPort=3125, Len=0, Seq=1063837360, Ack=0,
Win=65535 (scale factor 0) = 65535
- TCPOptions:
- WindowsScaleFactor:
...
ShiftCount: 0 (0x0)

What am I doing wrong? May be there are other factors that affects TCP
window?

[Michael K. O'Neill]

You might also need to set GlobalMaxTcpWindowSize in Tcpip\Parameters.

See
http://technet2.microsoft.com/WindowsServer/en/library/db56b4d4-a351-40d5-b6b1-998e9f6f41c91033.mspx .

Post by Eugene Firsov
Hi.
I am trying to make a very large TCP receive window size in Windows XP SP2.
Tcp1323Opts = 1 or 3
in HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
to turn on TCP window scaling, and
TcpWindowSize = 0xffffff (1048575) (for example)
in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interf
aces\{adapter

Post by Eugene Firsov
ID}
OK, for the experiment, I set up this parameters on two computers connected
via LAN and make a test TCP connection between them. But Network Monitor
shows that window size in SYN packets is still equal to 65535 and scale
factor is 0.
Flags=.S......, SrcPort=1057, DstPort=3125, Len=0, Seq=1063837360, Ack=0,
Win=65535 (scale factor 0) = 65535
...
ShiftCount: 0 (0x0)
What am I doing wrong? May be there are other factors that affects TCP
window?

[Eugene Firsov]

Thank you very much, Michael. It works!


But now a second question has emerged. May be you can help me. There is a
parameter called TcpAckFrequency. It specifies the number of packets that
will be received before ACK will be sent. By default it is equal to 2. That
means that every other packet will be acknowledged. And it is really true
according to Network Monitor.
<= <= => <= <= => ...
Whan I set this parameter to some large value, for example 200 and send a
large amount of data over TCP, I should expect that every 200th packet will
be acknowledged. (Providing that TcpWindow is sufficiently large to accept
all 200 packets) But in practise I see that ACK is sent only after 30-40
packets. Why is it happens? Network connection is reliable, no one packet
are lost.

Post by Michael K. O'Neill
You might also need to set GlobalMaxTcpWindowSize in Tcpip\Parameters.

[Michael K. O'Neill]

That parameter is only one of the parameters that affects the delayed-ACK
algorithm. You also need to adjust the delayed-ACK timer, which is set by
TcpDelAckTicks. From the same site I mentioned before ( i.e., from
http://technet2.microsoft.com/WindowsServer/en/library/db56b4d4-a351-40d5-b6b1-998e9f6f41c91033.mspx )
:

TcpDelAckTicks
Key: Tcpip\Parameters\Interfaces\interfaceGUID

Value Type: REG_DWORD-number

Valid Range: 2-6

Default: 2

Description: Specifies the number of 100-millisecond intervals to use for
the delayed-ACK timer on a per-interface basis. By default, the delayed-ACK
timer is 200 milliseconds. If you set this value to 0 or 1, the delayed-ACK
time is 200 milliseconds. Microsoft does not recommend changing this value
from the default without careful study of the environment.

Post by Eugene Firsov
Thank you very much, Michael. It works!
But now a second question has emerged. May be you can help me. There is a
parameter called TcpAckFrequency. It specifies the number of packets that
will be received before ACK will be sent. By default it is equal to 2. That
means that every other packet will be acknowledged. And it is really true
according to Network Monitor.
<= <= => <= <= => ...
Whan I set this parameter to some large value, for example 200 and send a
large amount of data over TCP, I should expect that every 200th packet will
be acknowledged. (Providing that TcpWindow is sufficiently large to accept
all 200 packets) But in practise I see that ACK is sent only after 30-40
packets. Why is it happens? Network connection is reliable, no one packet
are lost.

Post by Michael K. O'Neill
You might also need to set GlobalMaxTcpWindowSize in Tcpip\Parameters.

[Michael K. O'Neill]

Incidentally, you need to understand that since you are making changes to
the registry, your changes will affect *all* TCP connections from that
machine, even for applications you did not write. In other words, these
changes are not somehow per-process changes, or per-socket changes. They
will affect every single application on the machine, like the web browser,
email client etc, even though you did not write those other applications.

As an end-user, I would be very angry at you if you made these changes to my
machine. For example, if these changes were made automatically when I
installed your software, then this is unfair and would cripple my machine
for other purposes.

If you are making these changes to your machine only, for a special purpose
application that you are not deploying elsewhere, then fine, do what you
want. But if you expect to make these changes to machines other than yours,
then you should also expect to get plenty of grief.

Mike

Post by Michael K. O'Neill
That parameter is only one of the parameters that affects the delayed-ACK
algorithm. You also need to adjust the delayed-ACK timer, which is set by
TcpDelAckTicks. From the same site I mentioned before ( i.e., from

http://technet2.microsoft.com/WindowsServer/en/library/db56b4d4-a351-40d5-b6b1-998e9f6f41c91033.mspx )

Post by Michael K. O'Neill
TcpDelAckTicks
Key: Tcpip\Parameters\Interfaces\interfaceGUID
Value Type: REG_DWORD-number
Valid Range: 2-6
Default: 2
Description: Specifies the number of 100-millisecond intervals to use for
the delayed-ACK timer on a per-interface basis. By default, the delayed-ACK
timer is 200 milliseconds. If you set this value to 0 or 1, the delayed-ACK
time is 200 milliseconds. Microsoft does not recommend changing this value
from the default without careful study of the environment.

Post by Eugene Firsov
Thank you very much, Michael. It works!
But now a second question has emerged. May be you can help me. There is a
parameter called TcpAckFrequency. It specifies the number of packets that
will be received before ACK will be sent. By default it is equal to 2.

That

Post by Eugene Firsov
means that every other packet will be acknowledged. And it is really true
according to Network Monitor.
<= <= => <= <= => ...
Whan I set this parameter to some large value, for example 200 and send a
large amount of data over TCP, I should expect that every 200th packet

will

Post by Eugene Firsov
be acknowledged. (Providing that TcpWindow is sufficiently large to accept
all 200 packets) But in practise I see that ACK is sent only after 30-40
packets. Why is it happens? Network connection is reliable, no one packet
are lost.

Post by Michael K. O'Neill
You might also need to set GlobalMaxTcpWindowSize in

Tcpip\Parameters.

[Eugene Firsov]

Post by Michael K. O'Neill
As an end-user, I would be very angry at you if you made these changes to my
machine. For example, if these changes were made automatically when I
installed your software, then this is unfair and would cripple my machine
for other purposes.

Yes, of course, I understand that. In any way, I am not going to change
anything without strict user permission (after explanation of the all
changes) and possibility to roll back all changes.

[Eugene Firsov]

Yes, I saw it. But according to
[http://msdn.microsoft.com/library/en-us/randz/protocol/delayed_acknowledgments.asp],
TcpDelAckTicks is used in Win2000 and in WinXP TcpAckFrequency is used
instead of it. And on the other hand, my experimental network is fast enough
to transmit all 256 packets at a time interval less then 100 ms. So
TcpDelAckTicks can't affect on that.

Post by Michael K. O'Neill
That parameter is only one of the parameters that affects the delayed-ACK
algorithm. You also need to adjust the delayed-ACK timer, which is set by
TcpDelAckTicks. From the same site I mentioned before ( i.e., from
http://technet2.microsoft.com/WindowsServer/en/library/db56b4d4-a351-40d5-b6b1-998e9f6f41c91033.mspx )