bug (or not) with tcp/ip analyser

[Andrzej]

I noted that in ADSL
RTT can increased with increase of RWIN value
IMVHO formulas given RWIN value should be optimized
to keep RTT in range < 120-130 ms (in my case)

OTOH too simplified my experiments
I resigned from all RWIN value registry settings
and use only one at NIC key
[SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-ID}]
MTU=1492
TcpWindowSize=43560

BTW above for ADSL 2496/320 (PPPoE|A w2k)

[Philip]

Well, you're still tweaking the one most important value (by far), the Default Receive TCP Window (RWIN)

[Philip]

philip

not sure i have all understand your reply (sorry english is not my fist language) But one thing i know, if you are right why the optimizer set tcpwindows instead of DefaultReceiveWindowSize ??? Because the optimizer is for ALL windows ?

The Optimizer looks at all 3 locations for the TCP Receive Window (RWIN):
The "GlobalMaxTcpWindowSize", the "TcpWindowSize" and the AFD "DefaultReceiveWindow". It removes the AFD parameter, so that it does not override the other two. You can see exaclty what it is doing after you hit the "Apply" button, all the affected Registry branches/keys are displayed, along with their prior and modified values.

If XP SP2 need to be tweak a different way, the optimizer need to be modify. If not, members tweak XP SP2 internet connection with it and lose her time in tweaking tcpwindow. Because according to you DefaultReceiveWindows is THE one that is negociate onto the net and have to be tweak with SP2

The Optimizer was modified shortly after MS changed the precedence of the AFD key to override the other RWIN values in the TCP branch of the Registry.
It has worked correctly ever since SP2 came out... There are no other modifications necessary, it works correctly, as intended.

[mccoffee]

If that's case how come then we use static for any values mtu rwin what's so ever though in the case of routers handling sin ack then why sent a recive or send window size other then slow start it's odd to me that even cisco saids a send window is needed http://www.cisco.com/web/about/ac123/ac147/ac174/ac196/about_cisco_ipj_archive_article09186a00800c8417.html


The size of TCP buffers in each host is a critical limitation to performance in WANs. The protocol is capable of transferring one send window of data per round-trip interval. For example, with a send window of 4096 bytes and a transmission path with an RTT of 600 ms, a TCP session is capable of sustaining a maximum transfer rate of 48 Kbps, regardless of the bandwidth of the network path. Maximum efficiency of the transfer is obtained only if the sender is capable of completely filling the network path with data. Because the sender will have an amount of data in forward transit and an equivalent amount of data awaiting reception of an ACK signal, both the sender's buffer and the receiver's advertised window should be no smaller than the Delay-Bandwidth Product of the network path. That is:
[size=-2]Window size (le or eq) Bandwidth (bytes/sec) (times) Round-trip time (sec)[/size]
The 16-bit field within the TCP header can contain values up to 65,535, imposing an upper limit on the available window size of 65,535 bytes. This imposes an upper limit on TCP performance of some 64 KB per RTT, even when both end systems have arbitrarily large send and receive buffers. This limit can be modified by the use of a window-scale option, described in RFC 1323, effectively increasing the size of the window to a 30-bit field, but transmitting only the most significant 16 bits of the value. This allows the sender and receiver to use buffer sizes that can operate efficiently at speeds that encompass most of the current very-high-speed network transmission technologies across distances of the scale of the terrestrial intercontinental cable systems.
Although the maximum window size and the RTT together determine the maximum achievable data-transfer rate, there is an additional element of flow control required for TCP. If a TCP session commenced by injecting a full window of data into the network, then there is a strong probability that much of the initial burst of data would be lost because of transient congestion, particularly if a large window is being used. Instead, TCP adopts a more conservative approach by starting with a modest amount of data that has a high probability of successful transmission, and then probing the network with increasing amounts of data for as long as the network does not show signs of congestion. When congestion is experienced, the sending rate is dropped and the probing for additional capacity is resumed.
The dynamic operation of the window is a critical component of TCP performance for volume transfer. The mechanics of the protocol involve an additional overriding modifier of the sender's window, the congestion window , referred to as cwnd . The objective of the window-management algorithm is to start transmitting at a rate that has a very low probability of packet loss, then to increase the rate (by increasing the cwnd size) until the sender receives an indication, through the detection of packet loss, that the rate has exceeded the available capacity of the network. The sender then immediately halves its sending rate by reducing the value of cwnd , and resumes a gradual increase of the sending rate. The goal is to continually modify the sending rate such that it oscillates around the true value of available network capacity. This oscillation enables a dynamic adjustment that automatically senses any increase or decrease in available capacity through the lifetime of the data flow.

[Philip]

Mcoffe, you already know and recommend most of these

We can't use static values for RWIN because it is dependent on the bandwidth * delay product, it varies for different connection speeds and latencies.

We cant's use static MTU/MSS values because different protocols have different limitiations, and different header overhead (PPPoE ? ).

And you also just started another topic... TCP Send Window. Not to be confused with TCP Receive Window... There exists indeed, a TCP Send window, which determines how much data your machine is going to send, before awaiting acknowledgements from the other end of the connection. The TCP Send Window gets negotiated (as the TCP Receive Window) during the same TCP Handshake.

The reason why you don't need to tweak that particular value is actually very simple: By default, Windows accepts whatever value the other end can support (their RWIN value) and uses it as the TCP Send Window. If you manually tweak the TCPSendWindow on your end, you're only limiting the other end's TCP Receive Window. You can never increase their TCP Receive Window, you can only limit it down to your TCP Send Window Size, which is a somewhat mute point (unless you have a reason to force TCP to throttle down outgoing packets).


The rest of your post deals with the "slow start" congestion control algorithm... It is part of the TCP theory, nothing to do with registry values. In the presence of packet loss, that's how TCP handles retransmissions of lost packets, it slowly builds the speed back up, it deals with network congestion by throttling your speed down, that's about all

Mcoffee, all I'm trying to say with my other posts in this thread (as I've always claimed) is that there is only one TCP Receive Window value going out on the Internet in TCP/IP packets. It's not something I came up with, it's just that way by definition. Also, I claim that the Analyzer reports that one RWIN value that is negotiated on the internet, and the other RWIN-related Registry values are internal to Windows.

[mccoffee]

Mcoffe, you already know and recommend most of these ]bandwidth * delay product[/URL], it varies for different connection speeds and latencies.

We cant's use static MTU/MSS values because different protocols have different limitiations, and different header overhead (PPPoE ? ).

And you also just started another topic... TCP Send Window. Not to be confused with TCP Receive Window... There exists indeed, a TCP Send window, which determines how much data your machine is going to send, before awaiting acknowledgements from the other end of the connection. The TCP Send Window gets negotiated (as the TCP Receive Window) during the same TCP Handshake.

The reason why you don't need to tweak that particular value is actually very simple: By default, Windows accepts whatever value the other end can support (their RWIN value) and uses it as the TCP Send Window. If you manually tweak the TCPSendWindow on your end, you're only limiting the other end's TCP Receive Window. You can never increase their TCP Receive Window, you can only limit it down to your TCP Send Window Size, which is a somewhat mute point (unless you have a reason to force TCP to throttle down outgoing packets).


The rest of your post deals with the "slow start" congestion control algorithm... It is part of the TCP theory, nothing to do with registry values. In the presence of packet loss, that's how TCP handles retransmissions of lost packets, it slowly builds the speed back up, it deals with network congestion by throttling your speed down, that's about all




Mcoffee, all I'm trying to say with my other posts in this thread (as I've always claimed) is that there is only one TCP Receive Window value going out on the Internet in TCP/IP packets. It's not something I came up with, it's just that way by definition. Also, I claim that the Analyzer reports that one RWIN value that is negotiated on the internet, and the other RWIN-related Registry values are internal to Windows.

That's what i figured with the send window on the throttle it according to that those values when static that will help with the covergence of it all if you only have x amount of send bandwith then why not set it staticlly so that you don't flood the other guy sorta speak. Not aruging or anything to understand some things somewhat better I admit it's been a wile since i read this stuff so it's reinforcement

[kinkymaster]

May be completly out of Piranxa's first point, but i also have a question about cablenut :

How calculates the rwin value?

Remember me? ]Do you just make up your own formula?[/quote]

cool Doc

[dannjr]

This feals like the thread "who Decided Rwin" or whatever...

There really is no problem with the Analyzer other then understanding your options.. mnosteele and Phillip have a great understanding of it. But till you see the real results from a local analyzer on your own machine you might still think everything is a little out of wack

For instance when I come threw WinXP to here to get the Analyzer test result I get 1484 for my MTU but when I watch it locally I get 1500.. OHH now Im really confusing this.. I have dual business connections so dont read allot into the MTU from me..
As soon as the Handshake is done.. Watching this threw the analyzer, on my local machine the MTU drops off considerably to around 300 and can go as low as 30MTU but the initial was 1484MTU(the real one threw the router)
My initial handshake for Rwin was 570800 threw the SG Analyzer. Thats my initial setting for the DefaultReceiveWindow.. Again I wont give my reasons for that value.. Just take it as it is and move to the next thing..

Your TcpWindowSize is whats accepted by the other server.. Scaled this can also be a little taxing on someone worried about being to big..
But its still used for an initial handshake.
I see it all the time on Windows 2003 dedicated web servers, the differance now is that with Scaling you acually see the TcpWindowSize change during the connection. Most of the time I see the TcpwindowSize run in the 46383 to 34284 avg range and can go higher or lower. But you still need to set it esp. with a DSL connection threw a router to the web, from a workstation

As Phillip knows I'll argue MSS in Win98 "without" Microsoft documentation So I wont document why I set things to large or small a values...
Dont get me started on Berkley and MIT stuff I'm already nuts enough. ANd microsoft deletes older info that was still good. So RFC is the only other recourse..

What I do sugest is that you load a Packet Analyzer on your machine and look for yourself.. http://www.winpcap.org/default.htm requires a little reading and works on WinXP SP2. I got it to work on Win2003 too
The Clue is reading.. Which is something allot of people don't want to do, Most just want it given to them.

Again I dont see a problem with the way the Analyzer reads. Its symantics. (I dont mean norton)
You enter a TcpWindowSize its still working..
I also found on a good portion of DSL connections if you use the AFD options you best set a TcpWindowSize.
IF your a big Gamer and I'm not but have friends that are TcpWindowSize Scaled works well with the right AFD and TCP options..

To me the only debate here is the learning curve.

OR look at it this way if you set TcpWindowSize to big its a packet hog
You setup DefaultReceiveWindow to big its a resource hog
Install wwwcoolsearch and its someone elses hog.
And With WinXP SP2 its tough to get the right read on the Rwin now according to what I see in the packet analyzer.. IF it was easy to do I wouldve pointed it out awhile ago

Altho do we need to mess with TCP options anymore ? tiss a question that could haunt you.
For instance not one person mentioned setting the Gateway from Automatic to Static 1

This all said above I dont have a lot of time to go back and forth over this topic(busy with business) other then to say give the packet analyzer a try on your own machine. wether or not you use the one from the link above or something differant. The SG analyzer is still one of the best out here ITs fast and gives great info. Unless you want to start adding overhead to this site to have it read your registry settings with a ActiveX control your gonna have to take the programs that input values for there face value, that they are putting in the write info even when you put in the wrong value.
Here's that link again to the packet analyzer http://www.winpcap.org/default.htm


For the record this is a untweaked Windows 2003 web server enabled this morning. The Analyzer test results are threw a old Dlink router thats updated over PPPoE

TCP options string = 020405a401010402

MTU = 1484
MTU is somewhat optimized for broadband. If you're not on a PPPoE DSL connection that limits packet size, consider increasing your MTU to 1500 for optimal throughput.

MSS = 1444
Maximum useful data in each packet = 1444, which equals MSS.

Default TCP Receive Window (RWIN) = 65535
RWIN Scaling (RFC1323) = 0 bits
Unscaled TCP Receive Window = 65535

Note: TCP 1323 Options need to be enabled for RWIN over 2^16 (65535). Windows 9x might also need the MS Vtcp386 fix.
For optimum performance, consider changing RWIN to a multiple of MSS.
Other RWIN values that might work well with your current MTU/MSS:
508288 (MSS x 44 * scale factor of 8)
254144 (MSS x 44 * scale factor of 4)
127072 (MSS x 44 * scale factor of 2)
63536 (MSS x 44)

bandwidth * delay product (Note this is not a speed test):

Your TCP Window limits you to: 2621.4 kbps (327.675 KBytes/s) @ 200ms
Your TCP Window limits you to: 1048.56 kbps (131.07 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 119 hops
TTL value is ok.

Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 00000000 (0)

Here's the same machine with only the TcpWindowSize set.

TCP options string = 020405a401010402

MTU = 1484
MTU is somewhat optimized for broadband. If you're not on a PPPoE DSL connection that limits packet size, consider increasing your MTU to 1500 for optimal throughput.

MSS = 1444
Maximum useful data in each packet = 1444, which equals MSS.

Default TCP Receive Window (RWIN) = 64240
RWIN Scaling (RFC1323) = 0 bits
Unscaled TCP Receive Window = 64240

For optimum performance, consider changing RWIN to a multiple of MSS.
Other RWIN values that might work well with your current MTU/MSS:
508288 (MSS x 44 * scale factor of 8)
254144 (MSS x 44 * scale factor of 4)
127072 (MSS x 44 * scale factor of 2)
63536 (MSS x 44)

bandwidth * delay product (Note this is not a speed test):

Your TCP Window limits you to: 2569.6 kbps (321.2 KBytes/s) @ 200ms
Your TCP Window limits you to: 1027.84 kbps (128.48 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 119 hops
TTL value is ok.

Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 00000000 (0)


If I impliment the AFD it becomes the primary information then it would read the DefaultReceiveWindoh

again get the packet analyzer. theres nuttin wrong with the SG analyzer.

I hope everyone had a great holiday...

Nice thread
Thanks Philip and piranha

[Philip]

Hey Dannjr, long time. Nice to see you around, and thanks for the post

I'd just like to summarize everything we've been going over in this thread regarding RWIN...


1. There are 3 places in the registry for setting the Default TCP Receive Window, two in the TCP branch ("GlobalMaxTcpWindowSize" and "TcpWindowSize"), one in the AFD branch ("DefaultReceiveWindow").

2. All those Registry settings can have different values, and affect Windows differently internally, however at the end all 3 affect the one "Default TCP Receive Window" value that goes out in TCP/IP packets, and is negotiated during the TCP handshake. That is the one value that your end advertises to servers on the internet as its maximum supported RWIN. It is in bytes.

3. The Registry setting that takes precedence and gets negotiated on to the Internet is different, depending on your Windows version and Service Pack (XP SP2 changed so the AFD registry branch takes precedence, before SP2 the TCP branch used to take precedence. Seems now the AFD branch RWIN value overrides not only the TCP branch RWIN value, but also disregards other TCP branch values, such as the Tcp1323Opts setting)

4. The RWIN (Default TCP Receive Window) value that goes out to the Internet is best optimized if multiple of MSS. Even if not a multiple of MSS, if large enough to never get filled, the RWIN will work almost as well, but we've agreed that theoretically making it a multiple of MSS is best.

5. The Analyzer is right in the RWIN number that it reports, the RWIN (Default TCP Receive Window) as negotiated in the TCP handshake, as advertised by your machine, and the only RWIN number negotiated during the TCP handshake, when the two ends agree on what the other can accept.

* Note 1: The above registry settings, and the Analyzer all affect and report the "Default TCP Receive Window" or RWIN. Not the "TCP Send Window", not the free portion of the sliding tcp window that changes values during transfers, not the moon phase or the time of day. During transfers, the free tcp window at the moment changes up and down, that's why it is refered to as a "sliding window", however this value is not being set anywhere in the OS manually, it's just part of the protocol present in post-handshake packets showing the current state of the tcp window.

* Note 2: One can easily test that the AFD branch overrides the TCP (or v.v. depending on your Windows vesion) by setting one to a very small number, and the other to a high number. The Analyzer will report the RWIN value that goes out and is negotiated in TCP/IP packets, and if it is small your transfer rates will be much slower, since you'd be killing your RWIN, your end will be negotiating a RWIN value that's too small.


I believe we've all come to the same conclusions pretty much. If we all agree to the above, we can move on to bigger and better things

[mccoffee]

Hey Dannjr, long time. Nice to see you around, and thanks for the post

I'd just like to summarize everything we've been going over in this thread regarding RWIN...


1. There are 3 places in the registry for setting the Default TCP Receive Window, two in the TCP branch ("GlobalMaxTcpWindowSize" and "TcpWindowSize"), one in the AFD branch ("DefaultReceiveWindow").

2. All those Registry settings can have different values, and affect Windows differently internally, however at the end all 3 affect the one "Default TCP Receive Window" value that goes out in TCP/IP packets, and is negotiated during the TCP handshake. That is the one value that your end advertises to servers on the internet as its maximum supported RWIN. It is in bytes.

3. The Registry setting that takes precedence and gets negotiated on to the Internet is different, depending on your Windows version and Service Pack (XP SP2 changed so the AFD registry branch takes precedence, before SP2 the TCP branch used to take precedence. Seems now the AFD branch RWIN value overrides not only the TCP branch RWIN value, but also disregards other TCP branch values, such as the Tcp1323Opts setting)

4. The RWIN (Default TCP Receive Window) value that goes out to the Internet is best optimized if multiple of MSS. Even if not a multiple of MSS, if large enough to never get filled, the RWIN will work almost as well, but we've agreed that theoretically making it a multiple of MSS is best.

5. The Analyzer is right in the RWIN number that it reports, the RWIN (Default TCP Receive Window) as negotiated in the TCP handshake, as advertised by your machine, and the only RWIN number negotiated during the TCP handshake, when the two ends agree on what the other can accept.

* Note 1: The above registry settings, and the Analyzer all affect and report the "Default TCP Receive Window" or RWIN. Not the "TCP Send Window", not the free portion of the sliding tcp window that changes values during transfers, not the moon phase or the time of day. During transfers, the free tcp window at the moment changes up and down, that's why it is refered to as a "sliding window", however this value is not being set anywhere in the OS manually, it's just part of the protocol present in post-handshake packets showing the current state of the tcp window.

* Note 2: One can easily test that the AFD branch overrides the TCP (or v.v. depending on your Windows vesion) by setting one to a very small number, and the other to a high number. The Analyzer will report the RWIN value that goes out and is negotiated in TCP/IP packets, and if it is small your transfer rates will be much slower, since you'd be killing your RWIN, your end will be negotiating a RWIN value that's too small.


I believe we've all come to the same conclusions pretty much. If we all agree to the above, we can move on to bigger and better things

What's better then talking about tcpip

[Philip]

What's better then talking about tcpip

Well... I didn't mean to stray from the topic... Since you asked, here is the next step for you mister :


1. If the AFD branch RWIN value is negotiated out on the Internet, you should probably make it multiple of MSS, shouldn't you ?

2. If the AFD branch RWIN overrides and disregards the TCP branch RWIN value AND Tcp1323Opts, why use it ?

3. According to the MS documentation the default AFD branch RWIN value (when not present in the registry) is 4KB or 8KB. If that's the case, why doesn't it override the TCP branch RWIN when at default ? It surely overrides the TCP branch RWIN when you set the AFD RWIN in the registry manually ?

4. If the TCP DefaultSendWindow always is negotiated by Windows to whatever the other end can support (their RWIN), why would you limit it ? What would be the benefit of setting it, if any ? You can't "increase" their RWIN, you can only limit it down to your DefaultSendWindow value.

[mccoffee]

Well... I didn't mean to stray from the topic... Since you asked, here is the next step for you mister :


1. If the AFD branch RWIN value is negotiated out on the Internet, you should probably make it multiple of MSS, shouldn't you ?

2. If the AFD branch RWIN overrides and disregards the TCP branch RWIN value AND Tcp1323Opts, why use it ?

3. According to the MS documentation the default AFD branch RWIN value (when not present in the registry) is 4KB or 8KB. If that's the case, why doesn't it override the TCP branch RWIN when at default ? It surely overrides the TCP branch RWIN when you set the AFD RWIN in the registry manually ?

4. If the TCP DefaultSendWindow always is negotiated by Windows to whatever the other end can support (their RWIN), why would you limit it ? What would be the benefit of setting it, if any ? You can't "increase" their RWIN, you can only limit it down to your DefaultSendWindow value.

so were going to beat the horse till it's dead I was usuing statically as in terms in routers like you said though either way that cisco article send the same thing really about setting the value or not. It's just intreasting how it's all inrerpative data thanks to postel to bad he isn't living anymore he could clear the fog up. This conversation on rwin is to much fun for me

[dannjr]

mcoffee wait you think its fun now theres about 3 pages of PM waiting on you.. I really dont see a problem with the analyzer at all... This is definetly a learning curve situation

[mccoffee]

mcoffee wait you think its fun now theres about 3 pages of PM waiting on you.. I really dont see a problem with the analyzer at all... This is definetly a learning curve situation

I'm not blamming the analyzer it's just odd that the header info got changed no one can show proof what they changed. Alot of theroy of what and why no turth behind it sorta speak. I think it's fair to say if this question has been killing us all about why is it showing like that we all need hobbies and to get more out of life. Tcpip is causing more headaches then most of the women i do meet. This reminds of learning subnetting. On the other hand it's reasearch that keeps us going keeps us on top of the ever changing world of computers.