IN SEARCH OF... MSS

[dannjr]

Here I'm out all day to come back to see just how far this ahs come..
Anyhow I tried to get to 1500 and I couldn't see half my pages.. Now Mystic finds this now I'm thinking twice about putting my MTU down from 1486 back to 1454 but we'll see.

Originally posted by Mystic:
Just when you had enough to worry about
http://support.microsoft.com/support...?LN=EN-US&SD=g

[Venom]

Hello

I remember when rmrucker started with the argument of RWIN not being necesary to calculate it by your MSS.

Well if you remember that PMTUDiscovery what it actually does in lame terms is, it discovers wich is the smallest MTU from both machines and uses it so if your MTU changes and we now that the MSS, it has been told that the "correct" calculation for this should be "MTU-40" then we know that the computer itself should be aware of this and if your MTU changes then your MSS should change, becase remember if you don't write down the MTU and MSS ib the registry by default they already are 1500 and 1460 so in that case I beielve if the MTU changes so does the MSS. And if that's the way it is, then I beleive if the machine doesn't atumaticaly change your RWIN, then the RWIN that was calcultes is not going to work as efficient because it is no longer a really good multiple of MSS because it changed, With that said I beileve that's where "Packet Loss" ocure. I might be wrong, I am not as knowlegible as rmrucker or robert_s, but as far as I am concern that's what happens when the PMTUDiscovery is on and if that is the correct case then "we" or should I say Microsoft over loked it.



------------------
\/E(\)()(\/)

[fbelcher]

Im just a dummy with all this stuff but when ever I change my rwin My speed changes dramaticaly.Here is my settings whats wrong with them.
* Results
* Your public IP address is xx.xx.xx.xx
Hops left before discard (TTL) is 53
TCPopts hex string is 020405b401010402
Max Segment Size is 1460
* Your MTU is set ok
SACK Permitted (RFC2018)
Ping stability 52 41 43 47 43 42 41 42 56 66
* Quick packet-loss tested ok
DefaultRcvWindow (RWIN) is 65535
Your RWIN limits you @47.3ms to 11084kbps
Your RWIN limits you @200ms to 2621kbps
* Your RWIN is set ok at 65535
Your Path MTU Discovery is ON
Max sized data packet from you 1500
* Conclusion.. HEALTHY SETUP!
* End

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"LMHostFile"="C:\\WINDOWS\\lmhosts"
"LocalCopyMade"="1"
"EnableDNS"="0"
"Lanabase"="0"
"NodeType"="1"
"NameServer2"=""
"DefaultRcvWindow"="373760"
"DefaultTTL"="64"
"PMTUDiscovery"="1"
"PMTUBlackHoleDetect"="0"
"SackOpts"="1"
"Tcp1323Opts"=dword:00000003

[fbelcher]

I forgot to add what kind of speed I get normaly from dsl Reports2000-11-17 14:21:40 Speed test 3950/83 kbps
2000-11-17 01:56:15 Speed test 4522/83 kbps
2000-11-16 14:45:15 Speed test 3650/86 kbps
2000-11-16 02:40:37 Speed test 4797/86 kbps
2000-11-16 02:29:42 Speed test 4522/80 kbps
2000-11-15 00:44:12 Speed test 3095/87 kbps
2000-11-14 02:26:52 Speed test 4146/77 kbps
2000-11-14 02:25:57 Speed test 3650/86 kbps
2000-11-13 02:05:11 Line quality 0% loss latency 41.0ms View..
2000-11-13 01:53:57 Speed test 4447/85 kbps
2000-11-13 01:55:27 Line quality 0% loss latency 41.2ms View..
2000-11-11 01:05:20 Speed test 3827/72 kbps
2000-11-11 01:03:14 Speed test 2845/85 kbps
2000-11-10 04:32:33 Speed test 4797/86 kbps
2000-11-08 01:13:54 Speed test 4224/85 kbps
2000-11-07 02:19:59 Line quality 0% loss latency 42.2ms View..
2000-11-07 00:34:00 Speed test 4070/91 kbps
2000-11-06 13:23:48 Speed test 3762/87 kbps
2000-11-06 00:07:01 Speed test 3700/87 kbps
2000-11-05 17:38:28 Speed test 4375/86 kbps
2000-11-05 16:51:25 Speed test 4361/84 kbps
2000-11-05 16:45:25 Speed test 3700/125 kbps
2000-11-05 14:07:24 Speed test 4224/86 kbps

[Mystic]

Originally posted by fbelcher:
IHere is my settings whats wrong with them.

Nothing is wrong with them. Its what works for your connection. A particular view that I have always held is that each and every connection is different. So what it really comes down to is what works for yours.

Don't be mislead by anything we may say here as some of this stuff is purely academic. However while I think that each and every connection is different I also think it worth while to look at things of this nature. All this is in the interest of forming a stable point from which everyone can begin and then improve upon to satisfy the conditions of their individual connections.

[Venom]

fbelcher:

I did think I noticed something. If you have windows 98 or 98SE the Tcp1323Opts should be a string and not a Dword, thats why that test at DSLReports shows that your RWIN is advertised as 65535 no matter what RWIN you change it to unless it's lower then the default Also that causes the TCPopts hex string to be short and not as long as the one you see from the test of Mystic. So in that case I can tell it's not doing much because that was one of my mistakes, change that value I just told you to string and make the test again and make some D/L test



------------------
\/E(\)()(\/)

[rmrucker]

OK, the referenced article just gives us a good example of why we should be pinging to find our correct MaxMTU setting. That's what SpeedGuide has said all along.

It also shows me that setting the MTU for PPPoE really should be at 1492 and NOT the 1500 default -- well, at least for ICS on Win2K (I shouldn't generalize...).

fbelcher- Venom is 100% right. The tweak test is showing 65535 because you don't have Tcp1323Opts active. You have used an older SpeedGuide patch (pre-9/22/00) or you have tried to follow the erroneous Microsoft instructions. Tcp1323opts is a String value in Win98. [Find my post on this issue about 6 weeks ago -- if you want a headache!]

Also, you may need to update your vtcp.386 file to version 4.10.2223 if you have not already. You cannot use large windows without it.

Venom totally clinches the TcpOptions line. It is small -- PROVING to everyone (even Philip ) that Tcp1323Opts MUST be a String value.

Now if I could only get Philip to correct the Win95 patches...

[This message has been edited by rmrucker (edited 11-18-2000).]

[fbelcher]

I tried changing the tcpopts to a string and my speed drops drastically so I changed it back,But the point is if I change my rcv window it allso drops.I have allso have changed my vtcp.386 file to the newer one.If I dont have scaling on and it defaults to 65535 why does it change so much when I change the rcv window.
Just a note that I have an Athome cable connection.

[rmrucker]

If your speed drops when you change it to String value, that means you are not benefiting from "large windows" or Timestamping -- and in fact they are harming your connection. Leaving it as a DWORD is the same as NOT having it there -- it is doing nothing for you as a DWORD. It cannot work as a DWORD. Your Tcp Options line CLEARLY demonstrates it is doing NOTHING for you.

You can change your RWIN up and down as much as you want -- but as long as you keep it over 65535 and you keep Tcp1323Opts as a DWORD, you will continue to see that your 'effective' RWIN is at EXACTLY 65535. This part of the Tweak test works perfectly well!!

If you don't have scaling on, that is the same as leaving the Tcp1323Opts as a DWORD -- in both cases you cannot have an RWIN over 65535.

With activated Tcp1323Opts, your speed may be getting worse because of activating Timestamping, or because of using *too high of an RWIN*. You would need to try various RWIN sizes, and then turning TSopt on and off.

I hopes this makes things clear -- I am only trying to help...

[This message has been edited by rmrucker (edited 11-18-2000).]

[Mystic]

Uhhh,,,its a string if your using one of the win9x flavors - if your using win2000 its a Dword

[Mystic]

Originally posted by rmrucker:
OK, the referenced article just gives us a good example of why we should be pinging to find our correct MaxMTU setting. That's what SpeedGuide has said all along.

It also shows me that setting the MTU for PPPoE really should be at 1492 and NOT the 1500 default -- well, at least for ICS on Win2K (I shouldn't generalize...).

fbelcher- Venom is 100% right. The tweak test is showing 65535 because you don't have Tcp1323Opts active. You have used an older SpeedGuide patch (pre-9/22/00) or you have tried to follow the erroneous Microsoft instructions. Tcp1323opts is a String value in Win98. [Find my post on this issue about 6 weeks ago -- if you want a headache!]

Also, you may need to update your vtcp.386 file to version 4.10.2223 if you have not already. You cannot use large windows without it.

Venom totally clinches the TcpOptions line. It is small -- PROVING to everyone (even Philip ) that Tcp1323Opts MUST be a String value.

Now if I could only get Philip to correct the Win95 patches...

[This message has been edited by rmrucker (edited 11-18-2000).]

Ahhhh,,,the mystery begins to unravel. I had forgotten completly about this.

[rmrucker]

Yes, Mystic, I don't always remember to clarify this! In Microsoft's infinite wisdom they have chosen to go form DWORD (Win95) to String (Win98) to DWORD (Win2K). This is just to keep us all on our toes!

[Venom]

rmrucker:

I know this thread was more dedicated to MSS and Not as much to RWIN, I guess we spoke a lot of it in the past week and 1/2, and I guess I might be a little late on mentioning this but I think and I have been checking that if the RWIN is a multiple of MSS well you should be able to divide the RWIN by your MSS and if it gives you a clean number (with out any decimals ponits) then that number should basically work and should be used.

For examble here is the one that philip did:
44 x 1460 = 64240 x 2^2 = 256960

Now to verify:
256960 / 1460 = 176

And if I was to do this:

45 x 1460 = 65700 x 2^2 = 262800

Then
262800 / 1460 = 180

So it goes up by 4 thanx to the scaling factor but then again the 65700 is higher then 65535 And suposedly we should use it lower, now the thing here is I would assume that as long as it is a multiple of 1460 it should work, why did I come to that conclussion there is a little program that speedguide has as one of it's downlaods called iSpeed, well it auto calculates the RWIN and all it does is multiply any number by what ever you have in the MSS but it only does in a range from 1 - 16 (SO the Max RWIN you can get in that multiplier is 1460 x 16 = 23360).

Any way thats besides the point I came to the conclution that if atleast the RWIN when you divide it by the MSS it gives you a clean number then it should work pretty good, then again I might be wrong for just 1 thing, my theory fits pretty well to the equation but it doesn't work for when I checked the default, The Default RWIN is 8192, so 8192 / 1460 = 5.6109589041095890410958904109589

Now the thing is I have noticed that the RWINs that have wroked the best with out me getting much packet loss or should I say that it seems I get packet loss, have actually been the ones that divde nicley by my MSS.

NOW! i am not saying to multiply any number by your MSS and use it as your RWIN I am saying to use this as a veryfier, to make sure that the RWIN will work for you.

Because not every one has an MSS of 1460 and not every one Actually calculates the MSS they just use the numbers they find, so in that case if you find a number you think you want to use, divide by your MSS if it's not a clean number it's not that good for you *LMAO*


I don't know I might have just mentioned something everyone else knew *lol* oh well my brain is kinda fried I'm doing this while at work too *lol* but then again if I am wrong please correct me, I don't want to confuese or miss lead anyone.



------------------
\/E(\)()(\/)

[Venom]

fbelcher

Like rmrucker saidf you might be dropping in speed dramticaly because your RWIN might be set to high when you turn on the TCP1323Opts I would sudgest to either try 327040 and if that still gives you "packet loss" or like Philip would say it seems lile packet loss then change the RWIN to 256960 and just in case here is an even lower one 128480, I would also sudgest to try to set up Tcp1323Opts as 1 instead of 3 so that way it only turns scaling on and not Time stamping.

Good Luck!

rmrucker:
I learned from the best



------------------
\/E(\)()(\/)

[rmrucker]

Dang, Venom -- I know you just post these questions to get me back for harassing you!
~~~~~~

This thread has been floating around the board for several days -- thanks to all the posters. The single most interesting thing about this thread is not what I posted, or you posted, or what Mystic posted, or even what robert posted -- it is clearly what was NOT posted!

Philip is quite used to me posting "teasing" statements to see what response I'll get. And he usually tries fairly hard to correct blatant errors in my posts, or anyone else's. Despite the fact that I continue in my personal effort to slowly erode his confidence in the "multiple of MSS" theory, he has posted nothing here.

Almost as quiet are the usually outspoken cablenut and dannjr. I love what these guys have done for tweaking and I respect their work tremendously. However, neither of them has decided to jump in here and offer SOLID evidence that their MaxMSS entries do anything more than take up space in the registry. I show clearly that the MaxMSS entry has no effect whatsoever on your MSS. So what do they think it is doing?
~~~~~~~

Now to your questions. OK, this thing goes full circle again -- and it's going to take a long answer to cover all bases... Do you remember when I demanded a statement from SG regarding the new RWIN size -- and you directed me to this:

"Note: For best results RWIN has to be a multiple of MSS (MaxMTU-40) lower than 65535 times a scale factor that's a power of 2, i.e. 44 x 1460 = 64240 x 2^2 = 256960."

Well, I initially I responded in a way that said that line is complete BS. I'm not sure you caught my first response, but I later edited down the tone of my response (believe it or not!) -- because I actually wanted to verify this first. Well, you didn't pick up on ALL my subtleties, but I *believe* I have already proven that line to be erroneous.

It goes a little deeper than that line simply being wrong. I actually feel partially responsible for it!! I was the one who convinced Philip to initially modify the huge RWIN to make it "a 16-bit number multiplied by a power of 2". At first I (being the self-righteous b@stard that I am) thought this was more significant than it was later proven to be. However, I still believe this concept leads to a "more accurate" or "more honest" RWIN value - that is all. Yes, robert, I was wrong.

How can I say that the SpeedGuide statement is not correct? Well, first I had to get it out of Philip as to WHY he chose the new RWIN. After pestering him long enough, he finally gave in. To completely paraphrase and misquote Philip, his answer was that it is needed to be 'backward compatible' with servers that are not RFC1323 compliant.

Well, in my earlier post (the MOD one), I looked into that. In short, I believe what Philip expected to happen, simply doesn't. He expected that if you chose an RWIN that is a "multiple of MSS (MaxMTU-40) lower than 65535", then THIS number would be the number chosen to be the receive window -- when and if you connected to server that could NOT handle "large windows" (i.e., non-RFC1323 compliant). His thoughts were logical, however, he did not look in the packets to see what actually happens. If he had, he would have seen that the initial receive window chosen when scaling is rejected is not the number he expected! It is NOT the "multiple of MSS (MaxMTU-40) lower than 65535" that he so carefully calculated. Instead, the receive window will be than dang, bloody SYN packet window field again – that I have incessantly harped on!!!!

For example: Philip chose a large RWIN of 256960 – keeping with the party line that RWIN should be multiple of MSS. But this number was also carefully selected so that it is a “multiple of MSS (MaxMTU-40) lower than 65535 times a scale factor that's a power of 2.” Philip assumed that when scaling is rejected, the window size would default to 64240. But as I have repeatedly beat into everyone’s head, that is not the number in the SYN packet window field. The SYN packet window field can be calculated as:

256960 mod 65536 => 60352

Since a non-RFC1323 compliant server REJECTS scaling, the window size is going to be based on the SYN packet window request. It is now apparent that in this situation the window size will NOT be a multiple of MSS:

60352 / 1460 = 41.3369863013698630136986301369863 (hardly a round number!)

So, first off – don’t go overboard trying to follow this SpeedGuide recommendation – it does not appear to have been investigated adequately… (IMHO).

Jeez, that was long! But it should fully clear up the issue (I hope!). What else did you ask? Oh, yeah.
~~~~~

The Strange case of the Default RWIN. Check the packets again!!! Yes, the “Default” RWIN is 8192 (Win9x). {Please note this uses typical Microsoft redundancy – that’s Default DefaultRcvWindow! Just like the MaxMaxTU!} When you use the default RWIN of 8192 – guess what the “ACK” packet shows your window to be? NOT 8192, but instead 8760. Yes, that’s 1460*6. There is an automatic increase in the receive window to be an even multiple of MSS. However, try entering 8200 for your RWIN, and this doesn’t happen! Go figure. I still have more work to do!

Although the literature is flooded with statements regarding RWIN being a multiple of MSS (I cannot argue that), I still have a hard time actually PROVING this – especially when RWIN is high…

I hope this is helpful to you! Take care.

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

[Philip]

rmrucker, your argument only goes to prove that IF the server does not have Tcp1323 implemented, then the number we chose would not be a multiple of MSS...

However, it is still better than most other numbers out there, since it gives a large enough RWIN value close to the 2^16 max.

Also, if the server is Tcp1323 compliant RWIN would be calculated as multiple of MSS. If anyone has a better idea (number) for RWIN we'll be happy to hear any argument

As a matter of fact, I use larger values (i.e. 513920) in some of our boxes with very good results.

I am almost convinced about the Timestamps not being much use, I have to do some more testing and it is likely we'll change the recommendation to 1...

[Mystic]

I'm getting a headache

[cablenut]

"RWIN has to be a multiple of MSS (MaxMTU-40) lower than 65535"

once rmucker realizes that there is no perfect rwin he will come back to this statement

------------------
Head webcheese and geek guru @ http://www.cablenut.com

[Philip]

are you going to ever argue with me about those dang Win95 patches? I may just have to take my toys and go away!

What was your argument about them ? I'm sorry I've been very busy and I tend to forget. Don't go away, just keep nagging me.

[rmrucker]

Hehehe!

Don't go away, just keep nagging me.

You don't need to worry! (as you are well aware!)

once rmucker realizes that there is no perfect rwin he will come back to this statement

cabelnut, welcome to the party! Wait, wasn't it me that argued there is no such thing as the perfect RWIN in the first place! As I said (and as you know), Philip's chose is FINE! But not necessarily for the all the reasons he initially thought.

Mystic- I have that effect on *everyone*! Pinan, are you here?

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