Who decided on 372300??

rmrucker · Post by **rmrucker** » Fri Oct 20, 2000 9:20 am

How did SpeedGuide come up with the number 372300? This number seems illogical to me as a default RWIN setting.

First off, very few people have a pipeline big enough to utilize this size RWIN. If RWIN is too high, your speed will be slower.

Second, at least in Win98, this size RWIN is not possible until you have updated vtcp.38 to v.4.10.2223.

Third, unlike the other recommended "really big" numbers (i.e., 186880, 93440), this number cannot be defined as a 16-bit binary number multiplied by a factor of 2 ("10" binary) -- as implied in RFC 1323.

If a really, really big RWIN was desired as a choice, why wasn't 373760 chosen?? It makes more sense.

This number follows in sequence with 93440 and 186880 (i.e., 186880 * 2 = 373760). It therefore meets the criteria of being a multiple of 1460 [although the utility of this criteria has been questioned]. And it is it is nicely 1460 * 2^8 (256)-- whatever that's worth!

NOTE: If you hate binary numbers -- stop reading here!!

Most importantly, unike 372,300 this number (373760) *can* be represented as a 16-bit binary number multipled by a power of 2 (10 binary). This *appears* to be a requirement for true Window Scaling to occur.

For example, in binary:
373760 = 101 10110100 00000000 = 10110110 10000000 * 1000

BUT...

372,300 = 101 10101110 01001100 cannot be represented as a "whole" 16-bit number multiplied by 1000.

For a brief history: Prior to RFC 1323, setting RWIN size was limited to a 16-bit number. Therefore, the size theoretically ranged from 0 to 65,535 (or 2^16 - 1).

When RFC 1323 was drafted, they wanted to increase the size of RWIN. They did NOT do this by simply adding more bits. Instead, they added a "scale factor" that had to be multiplied by the *16-bit number*. The "scale factor" is defined as a power of 2.

To get an RWIN >65,535, you must use Window *Scaling*. This takes a 16-bit binary number and multiplies it by a "scale factor". To have a valid RWIN >65535, you should be able to break down the binary number into a 16-bit base number times a power of 2.

As above:
373760 = 10110110 10000000 * 1000

or... 10110110 10000000 with a "scale factor" of 3. (2^3 = 1000 binary).

So, my vote is for SpeedGuide to change it's "really, really big" RWIN value to 373760. But -- way, way back to my original statement

-- I do NOT feel this should be the *default* setting for every computer. I think a lot of people will find that this slows them down -- it's too damn big. This is only useful for really, really big pipelines or really, really high latencies.

You constructive comments are greatly appreciated. Please send flames to my email address. Thanks.

Kip Patterson · Post by **Kip Patterson** » Fri Oct 20, 2000 9:25 am

Excellent!

TRS · Post by **TRS** » Fri Oct 20, 2000 9:47 am

I totally agree with you! My RWIN is set to 40656. I used a max avg. ping time of 200 ms. My DSL line is 1.5/256

1500 * 1024 = 1536000

1536000 * .2s = 307200

307200 / 8 = 38400

The MSS my machine is capable of handling is 1452.

38400 / 1452 = 26.44

Rounding up to the next even multiple (28) you get a RWIN value of 1452 * 28 or 40656.

Now of course during 3-way handshaking the other host may SYN/ACK back with a smaller MSS. In that case Win2K will use the next multiple of the smaller MSS that creates an RWIN no less than your desired RWIN. I watched this with a monitor last night.

Tim

Zporttech · Post by **Zporttech** » Fri Oct 20, 2000 11:15 am

Set it to 65535...........

------------------
Steve
www.zport.com

Prey521 · Post by **Prey521** » Fri Oct 20, 2000 11:20 am

65535 also seems to give me the best throughput. When I had Win98 and first applied the SG patch, there was a noticeable increase in my download speed, but once I used an RWIN of 65535 the speeds were even greater. I'm gonna give that 373760 a try and see what happens.

therealcableguy · Post by **therealcableguy** » Fri Oct 20, 2000 11:23 am

uhhh! uhhh! what? The integral of x + 2xy - 3
as 3 approaches 0 = ? I hope to know what the h#$$ you guys are talking about one day I'm just a cable dog.Me thinks me has a headache after reading that first post.

------------------
It is the mark of an educated mind to be able to entertain a thought without accepting it."
-Aristotle

[This message has been edited by therealcableguy (edited 10-20-2000).]

rmrucker · Post by **rmrucker** » Fri Oct 20, 2000 1:16 pm

Geeezz! therealcableguy, I told you to stop reading *before* it got too mathematical!

Kip and TRS, thanks for the input. Steve, you are right -- most people could/should set it to 65,535. But there are some out there with "big pipes" that can use higher. (I wish I was one of them). Prey521, you may not get better speeds at that high an RWIN setting UNLESS you've got a big, fat pipe!

I'll sit and wait for Philip, et al to comment...

[This message has been edited by rmrucker (edited 10-20-2000).]

Post by **Philip** » Fri Oct 20, 2000 2:01 pm

First of all, you're right, I have to agree with 373760 making a bit more sence than 372300.

I have a couple of comments though:

1. Why would you think a higher RWIN value would slow down your connection (in cases where everything else is equal and Windows scaling is enabled ) ?

2. Theoretically, RWIN shouldn't be the limiting factor in your connection. For example, I've seen 6Mbit downloads on a simple residential cable modem with RR. If you consider that some sites can have high latency, here's the minimum numbers for RWIN using the bandwidth*delay product :

50ms - 37,500
100ms - 75,000
200ms - 150,000
300ms - 225,000
400ms - 300,000
500ms - 375,000

So a RWIN value of ~373000 would ensure uninterrupted download at up to 6Mbit with a theoretical delay of up to ~500ms...

All this just shows the reasoning behind using such high numbers. Although the numbers are somewhat high for most DSL users, the large RWIN value should not affect throghput in a negative way.

The only catch I can think of is that enabling windows scaling does add a small overhead to every packet, and one could use RWIN of up to 65535 without scaling to avoid it (at the expence of limiting their throughput to ~1Mbit @ 500ms, ~2Mbit @ ~250ms.)

Thanks for the excellent point rmucker, I will update the patches with a RWIN of 373760.

[This message has been edited by Philip (edited 10-20-2000).]

HalfLifer · Post by **HalfLifer** » Fri Oct 20, 2000 2:40 pm

Mines set at 38600000 and my pages have never loaded faster

Michfan · Post by **Michfan** » Fri Oct 20, 2000 4:21 pm

u sure u didnt put 2 extra 0's?

Kip Patterson · Post by **Kip Patterson** » Fri Oct 20, 2000 4:41 pm

For Phillip:

A large RWIN can result in more retransmissions when packets are lost. This is supposed to be less of a problem with the new versions of the protocol which support a more sophisticated handling of lost packets, but it still has some cost. It is especially a problem with modem connections and the old version of the protocol, which is why the defaults were so low in the first place.

dannjr · Post by **dannjr** » Fri Oct 20, 2000 5:02 pm

I have adjusted to reflect the new setting 373760

I also have alway's had a Dialup patch
that reflects 4288

On my DSL connection from Earthlink/Mindspring I have tried the lower amounts and had quite a loss in speed about 300kbps I also had someone on cable report to me that when they had lowered the Rwin down to your suggested amount that they noticed a better D/L So go figure

Like I said I did update to the new amount
at the web site in the patch's

------------------
dannjr@microsyspro.com
Microsystems

THE WORLDS THINNEST BOOK: THINGS I CAN'T BUY By Bill Gates

Post by **Philip** » Fri Oct 20, 2000 5:32 pm

Originally posted by Kip Patterson:
For Phillip:

A large RWIN can result in more retransmissions when packets are lost. This is supposed to be less of a problem with the new versions of the protocol which support a more sophisticated handling of lost packets, but it still has some cost. It is especially a problem with modem connections and the old version of the protocol, which is why the defaults were so low in the first place.

True, however with large RWIN you're still gaining throughput, while with small RWIN values you are limiting it. Higher throughput will cause greater amount of data being lost by default.

In cases with packet loss, higher RWIN values will cause greater amount of data being lost simply because of the higher throughput. It is a fact that you will have more retransmissions, but the RWIN value is not the cause, it simply improves your throughput, causing more packets to be lost for the same amount of time.

At least that's the way I look at it.

spaceman · Post by **spaceman** » Fri Oct 20, 2000 5:52 pm

Good topic !!!

Well, I tried them both.....I ran the 50 MEG download from Verizon and with the 372300 value I registered 340.8 KBs. With the 373760 value, I got 376.4 KBs. With my usual (364240), I got 412.2 KBs.

Believe me, I like 'em all !!!!

rmrucker · Post by **rmrucker** » Fri Oct 20, 2000 6:39 pm

Thanks, Philip. You know I like to help -- as long as no one calls me names!!

In my simple, layperson’s mind I can explain it the way I understand it. This is excerpted from a post I made earlier today:
~~~~~~~~~~~~~~~~~~~~~
“If RWIN is too high for your "pipeline size" (i.e., "speed"), then you will 'loose' data packets ("packet-loss"). TCP will not allow you to actually loose them, but instead it keeps asking the sender to re-send them until all the packets finally arrive.

If RWIN is too high, your computer is essentially asking the sender to shove a bunch of data down a pipe that is too small to handle it. You end up having your data spilling-out and getting 'lost'.

You reach a point where the benefits of asking for a lot of data to be sent (i.e., a large RWIN) are negated by the fact that so much of the data has to be re-sent to be received. When this occurs, your transfer rates with DROP. Therefore, *you can have your RWIN set too high.*

Unless you have a big pipeline (or a very high latency -- such as a satellite connection), it is unlikely that you can use an RWIN of >65,535 -- and definitely not an RWIN of >300,000!”
~~~~~~~~~~~~~~~
I don’t know if this is worded in a way other people understand (I tried), but it makes sense to me…

I will obviously defer to your expert opinion. But as I was taught, there is a point where the packet-loss problem does greater damage than the large window. Is this wrong??

If it is wrong, then YES every one should have a humongous RWIN. Why stop at a measly 373,760? Why not push it to the max? Let’s make RWIN = 2^30 (or 1,073,741,824). I believe someone figured out that wasn’t such I good idea…

I have read many posts on this site about how the “tweaks don’t work” because people are seeing lower rates AFTER tweaking. I think this might be due to the ‘excessive RWIN’ phenomenon.

I completely disagree with people that say the tweaks don’t work!! I believe the tweaks do work -- when implemented in a logical fashion. Despite my acerbic postings and notifications about relatively minor problems, I remain a big fan of this site!!

As for your bandwidth*delay numbers, I agree with them, I just wish I could see downloads of that speed -- 6Mbps!! Sadly in my piece of the universe, I am lucky to get close to 0.6Mbps! I think a lot of us out here are forced to live with these small numbers. And these are the people that I believe cannot benefit from a huge RWIN, and may even be harmed by it.

Philip, your comments and insight are always appreciated. Take care.

dannjr · Post by **dannjr** » Fri Oct 20, 2000 7:04 pm

Just one last thing to add

Thank You

downhill · Post by **downhill** » Fri Oct 20, 2000 8:16 pm

Oh man.....

I've been playing with multiples of 16 for this, and trying different combinations, on and off since I got cable.

Thanks for the heads up,rmrucker. And quite informative posts for sure.

This number for Rwin works faster on my system anyway.

Once again, thanks.D

Post by **Philip** » Sat Oct 21, 2000 12:10 am

Originally posted by rmrucker:
“If RWIN is too high for your "pipeline size" (i.e., "speed"), then you will 'loose' data packets ("packet-loss"). TCP will not allow you to actually loose them, but instead it keeps asking the sender to re-send them until all the packets finally arrive.

If RWIN is too high, your computer is essentially asking the sender to shove a bunch of data down a pipe that is too small to handle it. You end up having your data spilling-out and getting 'lost'.

Looking on a larger scale, Windows does have "Congestion Avoidance" and "Slow Start" algorithms that deal with the number of segments being sent before acknowledgement is received to avoid router congestion and packet loss.

However, looking at the RcvWindow in general, the sever negotiates with the client at the beginning of a transfer the amount of data it can send before receiving acknowledgement, basically negotiating the advertised RcvWindow with the client. Then, the server starts opening the SendWindow, initially 2xMSS, once ACK is received increases it to 4xMSS and so on exponentially. All that simply illustrates that the send window and the rate at which you receive data is controlled by the advertised receive window.

If a packet is lost, generally the assumption is that it results from a congested router, and the (questionable)remedy is lowering the transfer rate by cutting the advertised RWIN in half (at least that's how Windows 2000 handles it), then slowly opening up the send window again.

RWIN by itself is just the advertised buffer your PC can receive before transfer stops, while the server is waiting for acknowledgement. The only disadvantage of every client on a large scale network having a large RWIN value would be that routers can possibly get more congested, simply because higher bursts of data can be sent at any given time, overloading the router and causing higher packet loss.

From the client's viewpoint, you are still better of with a large RWIN value since your theoretical throughput can be higher. Packet loss is something caused by network congestion and other factors, not directly related to RWIN.

On the other hand, if we are considering large scale network implementation, lower RWIN values in all client PCs might lower packet loss by reducing congestion in the routers and somewhat the throughput of the clients. (I'm just speculating here)

I hope I didn't bore anyone to death.

"Of course all that's just my opinion, I could be wrong"

I'm by no means "the expert" and it is an interesting subject.

[This message has been edited by Philip (edited 10-21-2000).]

Alpha · Post by **Alpha** » Sat Oct 21, 2000 12:21 am

Holy Smokes!! I just d/l'ed a 15mb test file from AT&T broadband {formerly mediaone/RR} in 28 seconds, thats a new record for me. That's using the updated Sguide Win98 patch and dannjr's 1500 patch from his website along with the vtcp fix. Heh, you guys rule, all else drool! Thanks for the great stuff!

rmrucker · Post by **rmrucker** » Sat Oct 21, 2000 10:54 am

Thanks Philip. I think I understand (OK, some of it) -- but one last question I would like you to tackle:

Why not an RWIN of 2^30 if we have nothing to lose???

I think I am already seeing posts complaining about the "new" tweak settings... I fear this is due to the "too big ta eat" RWIN. Is this possible?

rmrucker · Post by **rmrucker** » Sat Oct 21, 2000 11:04 am

Philip,

Shoot -- I forgot a question that I meant to ask earlier -- but now you brought it up!

RWIN should be an "EVEN multiple" of MSS for better speed and not simply a "multiple" of MSS -- correct????
~~~~
And don't worry, I'm already doing a great job of boring people to death -- any one want some more binary number calculations?

[This message has been edited by rmrucker (edited 10-21-2000).]

Post by **Philip** » Sat Oct 21, 2000 11:44 am

Well, a RWIN of 2^30 is ~1Gigabyte, there would be no benefit of reserving a 1GB RAM buffer for such a thing...

It's true, RWIN should be an "even multiple" of MSS. You can also look at it as an even number, that's also multiple of MSS. The only case where you'd have to consider it is if you are using odd value for MSS and multiplying it by an odd number to get RWIN. As long as MSS is even, you can make RWIN any multiple of it.

372300 is a valid number as well, since it is an even multiple of MSS.

rmrucker · Post by **rmrucker** » Sat Oct 21, 2000 3:35 pm

Besides, Microsoft doesn't make up the rules for the Internet anyway -- I beleive it is the Internet Engineering Task Force (the guys who publish the RFC's). Microsoft should NOT be your only source of information, please!

I agree 372300 is a valid "even multiple of MSS", but I don't think it meets the RFC 1323 Window Scaling criteria (as above).

I have also been taught the "multiple of MSS" is a 'myth', however, I remain skeptical...

I think people can make a pretty good argument that RWIN should be an "EVEN multiple" of MSS, and not just an "even number, that's also multiple of MSS".

[therealcableguy, et al -- on the outside chance that you are a) still reading this, and b) not already completely bored stiff, stop reading NOW!!]

Here is an UN-authorized excerpt from EHS Company's Reading Rooms (www.ehsco.com):

"It's important to note the bits-in-flight value alone is not the optimal window size. You must also consider the maximum segment size (MSS) in use on the connection, and multiply that value by even numbers until you exceed the value derived for the maximum bits-in-flight. This is due to the way in which TCP's Delayed Acknowledgment algorithm refrains from sending acknowledgments until two fully sized TCP segments have been received. If the sender does not transmit enough data in even multiples, the recipient will not return acknowledgments quickly, and the exchange will be jerky.

For example, if the segment size is 1,460 bytes (common for Ethernet and PPP connections), the window must be an even multiple of 1,460 bytes. If the TCP window is an odd multiple of the MSS, eventually the recipient will not receive two full-sized segments, thereby holding off the acknowledgment until the delayed acknowledgment timer expires.

Actually, the default window value should be at least four times the MSS because a smaller receive window would not foster a steady data flow. If the receive window were only twice the MSS, the sender would transmit two segments and then stop to wait for an acknowledgment while the segments worked their way through the network. Once received, the recipient's acknowledgment would also have to return to the sender before more data could be sent, causing further delay. Having a default window size four times the size of the MSS would at least allow the sender to transmit four segments, with the last segment being sent just as the acknowledgment for the first two segments was being returned."

Post by **Philip** » Sat Oct 21, 2000 6:03 pm

You're right, according to RFC1323 the scale factor should be a power of 2, so it might be implemented by binary shift operations, that's why I agreed 373760 makes much more sense and chenged it in the patches, I'm not sure how I've managed to omit that earlier.

There are a couple of things that bother me in this excerpt you posted: "If the TCP window is an odd multiple of the MSS, eventually the recipient will not receive two full-sized segments, thereby holding off the acknowledgment until the delayed acknowledgment timer expires."

That is not entirely true for the maximum receive window, since the current receive window is a smaller buffer that "slides" within the max receive window and it can't reach such condition IMHO.

rmrucker · Post by **rmrucker** » Sat Oct 21, 2000 6:20 pm

Master, maybe one day you could even make me a Senior Member?

Actually, I suspect you just cringe whenever you see that I made a post... it just translates out to more work!!!

Enjoy your Saturday night.

TRS · Post by **TRS** » Sat Oct 21, 2000 7:18 pm

I ran a packet sniffer the other night to look at exactly what happens during the handshaking.

The behavior described below is for a TCPWindowSize of 65535 or less. I didn't look to see what happens when scaling is turned on.

Packet 1 (me -> [url=http://www.wpi.edu)]www.wpi.edu)[/url]
Window = 40656
MSS = 1452

Packet 2 (www.wpi.edu -> me)
Window = 33028
MSS = 1322

Packet 3 (me -> [url=http://www.wpi.edu)]www.wpi.edu)[/url]
Window = 40982

The final window size is a multiple (odd in this case) of the lower of the two MSS values. It appears a multiple of the lower MSS is used that will create a window size not less than you initial window size. In this case the 1322 * 31 = 40982. I checked this behavior with a number of other sites and it held true.

Tim

afaiky · Post by **afaiky** » Sat Oct 21, 2000 7:30 pm

Navas Cable Modem-DSL Tuning Guide says that for latency between 100 ms and 200 ms (normal latency--normal dsl, "good" cable), you should be using a 32k rwin for maximum performance! for latencies above 200 ms, 64k is good (for poor dsl or cable connections with higher latencies). anything above 64k is really only for cable users with ****TY latency readings and BIG pipes. check tha beCk at http://cable-dsl.home.att.net/

neo86 · Post by **neo86** » Sat Oct 21, 2000 7:53 pm

a number that is an even multiple of 1460 and also a 16bit number?

64240

[This message has been edited by neo86 (edited 10-21-2000).]

rmrucker · Post by **rmrucker** » Sat Oct 21, 2000 8:34 pm

Thanks TRS!! So "odd" multiples of MSS are "OK". But, does that mean they are as fast as even multiples?? Hmmm... if I had the time I could test it myself... But instead I spend my time answering other posts... Oh well, I know someone will address this issue.

[This message has been edited by rmrucker (edited 10-22-2000).]

neo86 · Post by **neo86** » Sun Oct 22, 2000 12:37 am

LOL, rwin doesn't have to be a even multiple of MSS . This is just another load of BS people madeup. No where on the entire planet does microsoft write that it has to be an even mutiple of mss.

Post by **Philip** » Sun Oct 22, 2000 12:44 am

If you follow Navas' ideas (sorry, I couldn't resist), then it is an urban myth.

However, if you actually do your research, you'll find that it's best and it makes a lot of sense to use a multiple of MSS.

BTW, if you search the Microsoft Knowledge Base, there are a number of references where it is clearly stated that RWIN should be a multiple of MSS for best results. Besides, if you read some RFCs all calculate RWIN based on MSS and it is common sense to use a number that will accommodate whole segments. Here is a recent example from Microsoft: "the value should be obtained by rounding up the TCPWindowSize to a multiple of the Ethernet Maximum Segment Size (MSS), which is 1460 for Ethernet" <-- http://support.microsoft.com/support/kb/articles/Q263/0/88.ASP

[This message has been edited by Philip (edited 10-21-2000).]

fbelcher · Post by **fbelcher** » Sun Oct 22, 2000 2:37 am

This is one of the best discussions I have seen in a long time.

rmrucker · Post by **rmrucker** » Sun Oct 22, 2000 5:09 am

Philip, not meaning to antagonize, but instead trying to understand... (btw, I am back from my party and I had a great time! Assume I had too much wine and, ignore all typos!!).

You said:
"Well, a RWIN of 2^30 is ~1Gigabyte, there would be no benefit of reserving a 1GB RAM buffer for such a thing..."

OK, that misses my point. IF you believe that there is no such thing as "too high an RWIN", why in the world would you ever recommend any number less than the maximum? If Windows is going to scale down any large number, then you should give the largest number possible, and let it scale down until it fits you system/connection.

For example, why stop at 372,300 or even 373,760?? If bigger is better, why not 747,520? or twice that big: 1,495,040?
OR, if you take it to the ULTIMATE extreme: 1,073,741,824??? If Windows scales down to whatever fits, then your recommended RWIN is too damn low!! Max it out to 1 billion and let it scale itself down to what ever number your need!

If you cannot specify "too high an RWIN", then you are a sucker for NOT specifying a tremendously huge RWIN!!! What's the point? Make it as big as possible -- it doesn't matter!

However, if on the contrary there such a thing as "too big an RWIN", then it behooves everyone to NOT choose an humongous RWIN.

dannjr · Post by **dannjr** » Sun Oct 22, 2000 6:24 am

http://msdn.microsoft.com/library/psdk/wmisdk/clascomp_5s8e.htm

Excerp:
The SetTcpWindowSize WMI class method is used to set the maximum TCP Receive Window size offered by the system. The receive window specifies the number of bytes a sender can transmit without receiving an acknowledgment. In general, larger receive windows improve performance over high delay and high bandwidth networks. For efficiency, the receive window should be an even multiple of the TCP Maximum Segment Size (MSS). This topic uses Visual Basic syntax.

Built on Monday, August 14, 2000

Just something to think about

rmrucker · Post by **rmrucker** » Sun Oct 22, 2000 2:34 pm

Thanks dannjr. This seems to add support for the "EVEN multiple" of MSS theory...
~~~~~~~
I know this is probably a dumb thing to ask at this point, but I am still intrigued at how the number 372300 came about. It seems to be specific design decision to not continue to double the numbers (186,880 is 2*93440). Was there a reason behind this, or was the decision completely random?

(I know, not real important, but more 'human interest' kinda stuff).

[This message has been edited by rmrucker (edited 10-22-2000).]

TRS · Post by **TRS** » Sun Oct 22, 2000 3:40 pm

I did some more sniffing...

Here are some important points:

1) When the scaling option is disabled, the actual receive window will be a multiple of the lower of the two MSS values sent during SYN and SYN/ACK. The actual receive window will be no less than the size of the desired receive window (the value use specified for the receive window the in the registry).

2) If you are not going to use scaling but want to use the largest receive window size possible you should choose a window size such

WindowSize = [integer [65535 / MTU] - 1] * MTU

Ex. MTU = 1452

WindowSize = [integer [65535 / 1452] - 1] * 1452

WindowSize = [integer [45.1343] - 1] * 1452

WindowSize = [45 - 1] * 1452 = 44 * 1452 = 63888

This is important because if one had chosen 45 * 1452 (65340) the actual receive window would not be able able to be atleast as large as your desired recieve window size unless both MTUs during handshaking were 1452.

3) When scaling is turned off the multiple is not guaranteed to be an even multiple of the lower MTU. You will not have any control over this as every host you hanshake with could have a different size MTU.

4) When scaling is turned on the receive window size present during SYN has absolutely no bearing on the actual window size that will be use. Nor will the MTU values as they do when scaling is turned off.

The actual window size is determined with the window size sent with the ACK packet in combination with the scaling factor sent during the SYN packet. The window size sent during the ACK segment is a righr shift of [scaling factor] bits.

Ex. TCPWindowSize = 7FFFF (524287)

SYN packet - window size advertised = FFFF (65535) (meaningless though), scaling factor = 4

SYN/ACK packet - whatever...

ACK packet - window size advertised = 7FFF (32767)

7FFF is 7FFFF shifted right 4 bits.

So your actual window size will be

32767 * 2^4 = 524272 (7FFF0)

Now Microsoft claims the actual size would be 65535 * 2^4 = 1048560. Internally to windows this may be true. The actual bytes allocated may be 1048560 but the RFC (RFC 1323) makes no statements regarding 65535 as the initial window size value to use when the scaling factor is 1 - 14. The sending host would have no way of know this. The sending how would only know the initial value of 32767 as send in each segment header from the receiver.

So what this all boils down to is that when scaling is used the multiple of MSS issues go out the window. You will always lose the least significant [scaling factor] bits of whatever window size you enter into the registry.

mindgarden · Post by **mindgarden** » Mon Oct 23, 2000 11:19 am

Ok. I've been silently reading and trying to learn something here, but I've just have to ask. If my MTU is 1492, my MSS is 1452, should my RWIN be a even multiple of my MSS ex. 1452*46=66792 or should I set my RWIN at 65535? My service is ADSL 1000/128. Thanx.

rmrucker · Post by **rmrucker** » Mon Oct 23, 2000 4:40 pm

Thanks, Tim (TRS) for this information -- and thanks for jumping in at DSLR. Great stuff! Heads are spinning -- especially mine...

There is still more for me to work out.

If you're still here Philip, I remain skeptical of the importance of the all the numbers -- and that is really why I started this post -- to help ME learn what it all means!

Thank you to all who responded. I am going out to learn some more...
~~~~~~
Tim, one last thing: in the equation, did you mean MTU or MSS?

WindowSize = [integer [65535 / MTU] - 1] * MTU

[This message has been edited by rmrucker (edited 10-23-2000).]

[This message has been edited by rmrucker (edited 10-23-2000).]

TRS · Post by **TRS** » Mon Oct 23, 2000 7:20 pm

MSS... sorry

rmrucker · Post by **rmrucker** » Mon Oct 23, 2000 9:07 pm

Tim-
I've been double checking your numbers, and a lot of what you say makes sense. Could you teach me how to "packet-sniff" this information? I know there are packet-sniffing programs out there, but which are you using?

Philip-
I am continuing to investigate this further. I think Tim is on to something.

Tim-
Walk me through this...
If we now re-look at 372300, in Hex this would be 5AE4C. [I gather the appropriate notation of this is 0x5AE4C.]

The SYN packet advertises the window as the lower 16-bits, or 0xAE4C => 44620, and the scale factor in this case would be 3??

Because 372,300/65,535 = 5.6809... This rounds up to 8 (the next power of 2), or 2^3 (scale factor 3).

Now, would DSLR tweak test show the RWIN as 356960??? (44620 with a scale factor of 3?) (I'll check that out later).

Then the ACK packet would show 372300 right shifted three places, or 0xB5C9 = 46,537.

The true window size would then be 372296 (46,537*2^3).

Did I follow you through any of this, or am I just as lost as I ever was?

[This message has been edited by rmrucker (edited 10-23-2000).]