IN SEARCH OF... MSS

[rmrucker]

OK, this post is not for everyone! If you have not been following this all along, this post will either bore the hell out of you, or give you the worst headache of you life. Read on if you wish, but you have been fore-warned!!

~~~~~~~

My Set up: Win98SE, capped Cable 512/128, no ICS

My Registry:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"LMHostFile"="C:\\WINDOWS\\lmhosts"
"LocalCopyMade"="1"
"EnableDNS"="0"
"Lanabase"="0"
"PreloadHeapCount"="6"
"DefaultTTL"="128"
"PMTUDiscovery"="1"
"SackOpts"="1"
"DefaultRcvWindow"="127424"
"PMTUBlackHoleDetect"="0"
"Tcp1323Opts"="3"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Parameters]
"MaxDupAcks"=dword:00000003

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0003]
"MaxMTU"="1500"
"MaxMSS"="1200"

~~~~~~~~~

OK, let me make some guesses here and see if I am right. Based *only* on the above numbers, here are my guesses:

1) SYN packet window field = 127424 mod 65536 = 61888 => 0xF1C0

Alternatively, this could be figured out in Hex:

127424 => 0x1F1C0; lower 16-bits are "F1C0" => 61888

2) MSS = MaxMTU - 40 => 1500 - 40 = 1460 => 0x05B4

3) Scaling bit(s):

127424/65535 = 1.944... [Rounds up to 2 - the next highest power of 2]
log 2 / log 2 = 1 [=> Scaling bits = 1]

3) ACK packet window field:

{I am only POSITIVE about how to do this in binary - there is probably an easier way}

127424 => 1 11110001 11000000

Shift this over by the number of scaling bits:

11111000 11100000 => 63712 => 0xF8E0

Also, since the 'terminal bit' that I dropped above was a "0", I know ahead of time that the true "scaled" initial receive window will be *exactly* the same as my set RWIN!

*OK, lets look at the data!

~~~~~~~~

Packet sniffer (sniffing the dslrepeort Tweak test:

SYN Packet: (both IP and TCP Headers)

45 00
00 40 5E 00 | 40 00 80 06 | 66 CC D8 CF | CF 58 XX XX
XX XX 04 0E | 1F 93 00 09 | 71 45 00 00 | 00 00 B0 02
F1 C0 79 64 | 00 00 02 04 | 05 B4 01 03 | 03 01 01 01
08 0A 00 00 | 00 00 00 00 | 00 00 01 01 | 04 02

SYN,ACK Packet: (TCP Header)

1F 93 | 04 0E CF 2E | 74 33 00 09 | 71 46 80 12
16 D0 49 FA | 00 00 02 04 | 05 B4 01 01 | 04 02 01 03
03 00

"ACK" Packet: (TCP Header)

04 0E | 1F 93 00 09 | 71 46 CF 2E | 74 34 50 10
F8 E0 A8 B4 | 00 00

The "Packet after the ACK Packet" (i.e., first data transmitted):

04 0E | 1F 93 00 09 | 71 46 CF 2E | 74 34 50 10
F8 E0 A3 00 | 00 00 (followed by exactly 1460 bytes of data!)

~~~~~~~

OK, what did I find...

In the SYN packet:

1) The 02 before the window field shows that this is flagged only with "SYN".
2) The 'advertised' window size was as I calcuated: F1C0 => 61888
3) The MSS was as I calculated: 05B4 => 1460
4) The scale bit was as I calculated it: 1

In the SYN,ACK packet:

1) Flags at 12 = SYN and ACK are set
2) Window request from dslreports is as it always is, but this is ignorred.
3) This packet's main purpose (for us) is to verify that the computer we are connecting to *is* RFC1323 compliant. We can tell this because the TCP header shows a window scale factor request -- the 030300 above! IF it was not RFC1323 compliant, this would not be present.

In the "ACK" packet:

1) Flag at 10 = only ACK set
2) Window field is exactly as I calculated: F8E0 => 63712
3) There is no TCP options line in the ACK packet

In the "NEXT" packet:

1) All of the subsequent packets asked to be ACKnowledged
2) We see that the ACK packet window request WAS accepted (F8E0)
3) The TCP header SEEMS to have stayed the EXACT SAME size - 20 bytes!
4) The data that follows is EXACTLY my "MSS" size - 1460 bytes.

~~~~~~

OK, what does this mean to me?

1) The initial receive window size will NOT be based on the SYN packet window field, but instead on the "ACK" packet window field. What will it be?

63712 * 2^1 = 127424 (My set RWIN!)

2) The MSS will be set at MTU - 40 by MSTCP no matter what Tcp Options you set and no matter what value you enter into "MaxMSS".
3) I have yet to demonstrate how the TSopt and SackOpts effect the Tcp Header and the ultimate size of your data -- but I am not sure I have done the correct test! I plan to look into this further...


~~~~~~

OK, just to take this FULL circle, let's look at the Tweak test results. But first, let me GUESS how they will turn out -- and I'll show you how. I'll grab the SYN packet from above:

45 00
00 40 5E 00 | 40 00 80 06 | 66 CC D8 CF | CF 58 XX XX
XX XX 04 0E | 1F 93 00 09 | 71 45 00 00 | 00 00 B0 02
F1 C0 79 64 | 00 00 02 04 | 05 B4 01 03 | 03 01 01 01
08 0A 00 00 | 00 00 00 00 | 00 00 01 01 | 04 02

1) 40 is in the Flag area of the IP header. This says "Don't Fragment", so the Tweak test will tell me my PMTU-Disc. is "ON".
2) 80 is in the TTL area of the IP header (0x80 => 128). I should use up about 10 hops, so I should have about 118 left over.
3) My IP address is grabbed out of the IP header as well! I X'd it out!
4) The tweak test will erroneously scale my SYN packet window field, so...

F1C0 => 61888 -- 'scaled' up: 61888 * 2^1 => 123776

5) The Tweak test should find my MSS as 05b4, my scaling bit(s) at "1", Timestamping and SACK are "ON".

And here you go:

~~~~~~

Tweak test result:

* Results
* Your public IP address is (none of your business)
Hops left before discard (TTL) is 119
TCPopts hex string is 020405b4010303010101080a000000000000000001010402
Max Segment Size is 1460
* Your MTU is set ok
Window Scaling 1 bits (RFC1323)
TSOPT - time stamp option (RFC1323)
SACK Permitted (RFC2018)
Ping stability 120 90 92 90 89 102 89 91 90 89
* Quick packet-loss tested ok
Scaled DefaultRcvWindow (RWIN) is 123776
Your RWIN limits you @94.2ms to 10511kbps
Your RWIN limits you @200ms to 4951kbps
* Your RWIN is advertised as 123776 (scaling is on)
(Beyond 65k, advertised RWIN is scaled)
Your Path MTU Discovery is ON
Max sized data packet from you 1500
* Conclusion.. HEALTHY SETUP!
* End

~~~~~~

Everybody on the same page now??

Your comments and alternative interpretation is welcome. Cheers!

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

[Mystic]

[quote]Originally posted by rmrucker:

OK, what did I find...

In the SYN packet:

yada yada yada....


*******************************
Ooook....I followed what you were trying to do , but up to a point. When you threw in the SYN information it kinda confused the issue for me a little. In previous posts you stated that the information in the SYN packet wasn't of any concern and that the ACK information is what we were needing to see.Maybe I misquoted a little but I think I got most of it right. So the reason i'm getting a little confused here is it seems now that you want to know the information in the SYN. Or possibly I read this one wrong but I read it several times.

So now, why is the information in the SYN packet important to us for purposes of determining the initial window size other than to just see whats there?

[This message has been edited by Mystic (edited 11-16-2000).]

[This message has been edited by Mystic (edited 11-16-2000).]

[rmrucker]

Mystic- you are 100% right. I only listed the SYN packet window stuff so I could again verify my prior point -- and for the benefit anyone who might be joining us 'late in the game'. I wanted to show ALL the data so if anyone wants to interpret it differently, they can see EVERYTHING. The only things I hid were the MAC header and my IP address in the IP header -- for my own paranoid security reasons!

I still stand behind the statement that the SYN packet window request is of no consequence to the subsequent TCP transmission -- that is for RWIN over 65,535.

We are on the same page.

[robert_s]

Originally posted by rmrucker:
3) I have yet to demonstrate how the TSopt and SackOpts effect the Tcp Header and the ultimate size of your data -- but I am not sure I have done the correct test! I plan to look into this further...

If you look at the ACK packet from the other side, you'll see that the server did not Ack the TimeStamp option, so it's not being used.

Actually, I found out that TimeStamps are hardly ever used in FTP transfers, even if enabled! Why? Because when starting an FTP transfer (no matter which direction!), the TCP connection is initiated from the server (unless you use passive mode, I suppose, I haven't tried that out. And all FTP servers I tried appear to "frown" on the TimeStamps option! I found the following:

1. The FTP "control" connection, initiated from my machine, does use the TimeStamps option, the server happily complies with my machine's request to use this option.

2. When starting a download, the server initiates the FTP data connection without the TimeStamps option. Since the initial SYN from the server doesn't contain it, my machine can't use this option either.

So it appears that even though the TCP/IP stacks of those FTP servers do support TimeStamps, they've apparently been programmed not to use them, unless explicitly requested by the client - and for data connections, that would only be possible in PASSIVE mode (IIRC).

But you can reproduce the negative effect of the TimeStamps option anyway. Do the following:

1. Enable your TCP sniffer

2. Open a DOS box and run "telnet www.dslreports.com 80"

3. In the telnet window, blindly type "GET /" and press RETURN.

This will retrieve DSLreports main page via HTTP - on a connection initiated from your side. Thus, the TimeStamps option will be enabled. And look what it does:

TCP: .A...., len: 1440, seq: 250468374-250469814, ack:2879219745, win:31944, src: 80 dst: 3072

Every single data packet has a payload of only 1440 bytes now, where the normal net payload of my PPPoE connection would be 1452 bytes - The timestamps option ate 12 bytes out of every data packet transferred.

That, in conjunction with the observation that most FTP servers seem to frown on the TimeStamps option as well, confirms my believe that this option is better disabled.


------------------

[rmrucker]

Very cool robert! Thanks for your interest! I'll muck around some more -- but I've got to work now. I only get to packet sniff in the wee hours of the morning -- when my family is asleep!

[Mystic]

robert_s:

So what your saying is time stamps really do not affect it all that much?

Was this just in conjunction with FTP transfers?

I never asked this question before, or maybe I did and forgot or someone else mentioned it.If we disable the timestamps option will it be enabled on connections that need it by default? If so what size of payload in bytes does it add to the total packet and what does this default do to the MSS and RWIN?

The second part of my third question is kinda obvious to an extent but for the benefit of those that don't know....

I know that disabling the timestamp any effect is probably not going to be seen on 99% of the connections, that is unless your sniffing the packet or something. Of course this is just from my own experience.

[Comet]

rmrucker:
I only get to packet sniff in the wee hours of the morning -- when my family is asleep!
-------------
I can see it now...a new drug that seems to be as addictive as crack....packet sniffing in the wee hours of the morning, and it is sucking in people by the millions.
Sorry I couldn't resist...thought I would lighten up things just a little.

Comet

[Venom]

I'd like to play! *lol* but I don't have much time I'm at work but I'll just point out one thing that uhm i'm sure probably rmrucker was kinda saving for last *lol*

Why was your MSS calculated and showed as 1460 when in your registry settings it is 1200?

Don't know if this was part of your point but I noticed it *LOL*



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

[rmrucker]

Your too quick there Venom. I told you before to test out the MaxMSS theory, didn't I?

Well hidden inside my data is proof that the MaxMSS entry is NOT a viable entry. If it REALLY did anything, my MSS would have been held to a Max of 1200.

As anyone can see, the MaxMSS entry was ineffective.

~~~~~~~

Question for robert:

"The timestamps option ate 12 bytes out of every data packet transferred"

Are you quite sure that is not 10 for Timestamping and 2 for SackOpts??

[robert_s]

Originally posted by Mystic:
So what your saying is time stamps really do not affect it all that much?

Was this just in conjunction with FTP transfers?

I never asked this question before, or maybe I did and forgot or someone else mentioned it.If we disable the timestamps option will it be enabled on connections that need it by default? If so what size of payload in bytes does it add to the total packet and what does this default do to the MSS and RWIN?

I'm saying that RFC1323 time stamps are obsolete. RFC 1323 is from 1992 and actually mentions SAck, but states it is "not standardized yet" - that was in 1992. SAck was standardized in 1996 and REMEDIES the problem that time stamps were supposed to fix in a much better way.

If you disable time stamps in the registry, they won't be used at all, and that's IMHO a good thing(TM).

If enabled, the time stamps option eats 12 bytes out of the net payload of each data packet. Note that the packet does NOT (and cannot) grow in size beyond 1500/1492, so you really lose data space to the additional overhead, i.e. your overhead/userdata ratio deteriorates - for a (IMHO) superfluous option that once upon a time was supposed to fix an issue which is today fixed by SAck.


------------------

[robert_s]

Originally posted by rmrucker:
Question for robert:

"The timestamps option ate 12 bytes out of every data packet transferred"

Are you quite sure that is not 10 for Timestamping and 2 for SackOpts??

Yes, I am. SackOpts is only indicated in the SYN/SYN-ACK packets, after that, both ends "know" it is being used.

While it's true that the TimeStamp option actually only requires 10 bytes, the problem is that the "TCP header length" field contains the length of a TCP header divided by *four*. The default (minimum) TCP length is 20 (5 in the TCP header length field), and that leaves no room for any options. So only a TCP header with no options has the minimum size of 20 bytes - but since all options except for the time stamps are only negotiated in SYN/SYN-ACK, that means that unless timestamps are enabled, all TCP DATA packets won't have any options, so there'll be only 20 bytes.

And since a TCP header length of 30 bytes is not possible, since 30 is not a multiple of four, the TCP header length must be rounded up to 32 to accomodate the timestamp option.


------------------

[rmrucker]

Superb. I've got to print this out now and read it over and over!!!! Thank you.

Why do they bother to have both options then? Jeez, WinNT never even gave you an option for Timestamps, but WIn2K does!! And it's too late!

[rmrucker]

robert_s-

OK, I have more to do, but I just sniffed a Speed Test at dslreports, and I want you to see what I found. I use a different Sniffer than you, so I actually can't make sense out of these types of lines:
"TCP: .A...., len: 1440, seq: 250468374-250469814, ack:2879219745, win:31944, src: 80 dst: 3072".
I suspect that is just dividing and interpreting the raw data for you. For now, I'll just stick to raw data. Here it is:
~~~~~~~~

SYN packet header (minus the first line):

00 40 36 21 | 40 00 80 06 | 93 9F XX XX | XX XX D8 C8
B0 06 06 1B | 1F 90 05 66 | 8B 73 00 00 | 00 00 B0 02
F1 C0 5C C3 | 00 00 02 04 | 05 B4 01 03 | 03 01 01 01
08 0A 00 00 | 00 00 00 00 | 00 00 01 01 | 04 02

"SYN, ACK" packet header (Tcp header only):

XX XX 1F 90 | 06 1B CE 3B | 90 AA 05 66 | 8B 74 A0 12
7D 78 59 87 | 00 00 02 04 | 05 B4 04 02 | 08 0A 5F 26
CB 6D 00 00 | 00 00 01 03 | 03 00

"ACK" packet (Tcp header):

XX XX 06 1B | 1F 90 05 66 | 8B 74 CE 3B | 90 AB 80 10
F8 E0 40 6D | 00 00 01 01 | 08 0A 00 0D | CC 69 5F 26
CB 6D

First big packet from them:

XX XX 1F 90 | 06 1B CE 3B | 90 AB 05 66 | 8C 55 80 18
7D 78 61 26 | 00 00 01 01 | 08 0A 5F 26 | CB 71 00 0D
CC 69 (followed by EXACTLY 1448 bytes of data!)

~~~~~~~

OK, so what did I find:

1) The dslreports speed test DOES use the Timestamp option. See 08 0A in the SYN,ACK packet.
2) The rearrangement of the Tcp Options line in the SYN,ACK packet is strange to me. The order beyond MSS is EXACTLY the opposite of the SYN packet! WHY? And SackOpts is squished down to two octets with no NOP padding! Scaling remains at it's own 32-bits.
3) Timestamps do take up 12 bytes -- seemingly to allign the option at the begining of its own 32-bit starting spot. It uses two "01" NOP codes (No OPtion) to space itself correctly. There is no sign of any header change from SackOpts.
4) My data is exactly as you said -- 1448. Twelve bytes were eaten up by the TSopt.

What this doesn't show:

1) If many (or any) other sites use TSopt.
2) If TSopt adversely or positively effects download speed
3) If TSopt adds anything beneficial to SackOpts
4) If I need to readjust RWIN because of TSopt.

However, I think the last one needs clarification. If you argue that RWIN must be a multiple of MSS, then you may need to re-think how you determine MSS. One thing is clear -- if TSopt is NOT helpful, then you should TURN IT OFF, and the issue goes away!!

Just more thoughts... Comments welcome.

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

[Mystic]

OK let me get this straight so far - and for the benefit of our viewers just tuning into the "The wild world of TCP/IP" -


robert_s

1. so far in mosts of the posts it has been shown that the MSS setting is not needed in most cases or adds very little if any to the connection. If it isn't then does it becomes impossible to calculate what the MSS should be without the TSOpt?

2. The timestamp is not needed - sackopt does what we need, right?

rmrucker

1. If DSLreports indicated that the TSOpt is active, does this really mean that the TSopt is used? or is this a case of dslreports just using it to give feedback because its present?

To anyone

1. Does not all of this violate the standard MTU-40=MSS calculation for ethernet connections?

2. Does this mean that MSS can become anything it wants to be and if TSopts is not present is the value of MSS re-calculated somewhere in the stack for each and every connection? In other words does it constantly change according to the server your connected to? What happes to MSS when you connect to a server that wants to see the TSopts setting and none is present? Is it dynamically created and MSS changed to suit the connection?

[This message has been edited by Mystic (edited 11-17-2000).]

[robert_s]

Originally posted by rmrucker:
I use a different Sniffer than you, so I actually can't make sense out of these types of lines:
"TCP: .A...., len: 1440, seq: 250468374-250469814, ack:2879219745, win:31944, src: 80 dst: 3072".

FWIW, this is from Microsoft's NetMon...

2) The rearrangement of the Tcp Options line in the SYN,ACK packet is strange to me. The order beyond MSS is EXACTLY the opposite of the SYN packet! WHY? And SackOpts is squished down to two octets with no NOP padding! Scaling remains at it's own 32-bits.

No that's not strange. If you look closely at the packets sent by your Windows machine, you'll see that the Microsoft developers have just been "lazy" and padded each single option to a multiple of four to add them easier. Their code seems to work like this:

- Start with TCP length field 5 (=20 bytes)
- append TCP MSS option 02 04 xx xx, increase TCP length field by one
- check if window scaling is enabled, and if it is, append 01 03 03 xx and increase TCP length field by one
- check if time stamps is enabled, and if it is, append 01 01 08 0A xx xx xx xx xx xx xx xx and increase TCP length field by three
- check if SAck is enabled, and if it is, append 01 01 04 02 and increase TCP length field by one

A "better" algorithm would add options bytewise and then round the size up to the next multiple of four, which would have shortened the TCP header length in your case by four bytes.

And as you can see, the DSLreports machine is doing it like this. Apparently, it is not running Windows.

> 2) If TSopt adversely or positively
> effects download speed

I'd say adversely. Let's say you have a 768kbps service, with 768kbps being the speed of the ATM channel on top of which a bridged Ethernet connection is running.

Without TSopt, a full-sized Ethernet frame of 1518 bytes (14 Bytes header, 1500 bytes payload, 4 bytes FCS) carries 1460 bytes user data (1500 bytes Ethernet payload minus 20 bytes IP header minus 20 bytes TCP header). So your net data rate would be

768000/8 * (1460/1518) = 92.332 bytes/sec

With TSopt leaving only 1448 bytes user data, that is reduced to

768000/8 * (1448/1518) = 91.573 bytes/sec

So the question is - does TSopts add any BENEFIT that can make up for this loss? Which, incidentally, is also your next question:

> 3) If TSopt adds anything beneficial to
> SackOpts

I'd point to RFC 1323, page 2, 1.1, (2) about this, which IMHO, basically states that SAck might be a better solution to the problem they were trying to fix, but SAck was still stuck in the standardization process at that time, so it wasn't "available" as a solution then. Well, it is now, and it is working pretty well...

> 4) If I need to readjust RWIN because of
> TSopt.

You'd probably have to adjust RWIN to be a multiple of the reduced MSS, 1448. Problem is - it wouldn't be a multiple of the unreduced MSS, 1460, is TSopt can not be negotiated with a server on the Internet. Only the more reason to forget about TSopt and rely on SAck instead...


------------------

[rmrucker]

robert-
Thanks again. I realized your data was from MS NetMoniter -- it is in the exact same format as in the MSKB's. But I actually learned to sniff with a different sniffer (Analyzer) and I don't want to change!

So, I should expect the TCP option strings in SYN,ACK from other sources to follow the lazy Microsoft pattern? I'll try to check more later -- this takes a lot of time!

I agree with you completely -- the question is can TSopt more than make up for it's deficit? I will be testing this later as well. I am also re-reading RFC1323 and RFC 2018 again...

There seems to be 2 functions of TSopt -- the RTTM and PAWS. Are both of these replaced by SackOpts? I suspect you will say "yes" -- but then why didn't they just do away with TSopt? Someone must have wanted it preserved. I have more to read...

~~~~~

Mystic-
The MaxMSS entry has always been "questionable" at best. MS-TCP automatically calculates the "MSS" Tcp Option by subtracting 40 from whatever you enter in your "MaxMTU" entry. I have found NO way to adjust or override this.

How adding the TSopt "12" to the header effects this is still a little beyond me. It definintely decreases the amount of data transmitted per second. But I still don't clearly understand how the change in the header effects the appropriate RWIN size -- if the MTU is still 1500 regardless. I admit, simple things still escape my understanding...


DSLreports shows the TSopt active in EVERY packet. See this part:
~~~~~~~
First big packet from them:

XX XX 1F 90 | 06 1B CE 3B | 90 AB 05 66 | 8C 55 80 18
7D 78 61 26 | 00 00 01 01 | 08 0A 5F 26 | CB 71 00 0D
CC 69 (followed by EXACTLY 1448 bytes of data!)
~~~~~~~

This is how essentially *all* the subsequent packets look. See the 01 01 NOP "padding", followed by the telltale "08 0A" for timestamps option? What follows I assume is 8 octets that record the exact time of the packet. Then the data has been decreased to 1448 bytes -- not the usual 1460. I think this completely proves that DSLR is using timestamps in this transfer.


Venom is correct. If PMTU-Dscovery is really out there modifying MTU on-the-fly during our connection, then how important can it be to set the RWIN to be variable that may change at any minute.

All interesting points. Thanks to all.

[Mystic]

Of everything said in this thread so far, It seems as tho there would never be any need to set an MTU parameter to any certain value in the registry.

However we know thats not true for all connections because DSL PPOE sets the MTU to 1492 does it not?

From a vague picture thats beginning to emerge (at least to me but then again I need to have my eye glass's perscription changed) it seems as tho all the thoughts here are beginning to converge on a single point. The differences I see still remaining center around, once again, the window size and its scaling.

Taking both robert_s's and rmrucker's comments into account and disregarding the TSOpts thing for a moment I see that MSS and MTU settings are not needed at all as MSS (which is based upon MTU) used to calculate the window size doesn't really matter.

The TSopts thing doesn't appear to matter either but then if it doesn't matter how is window size calculated reliably in terms of scaling?

[Mystic]

Just for giggles:

* Results
* Your public IP address is xx.xx.xxx.xx
Hops left before discard (TTL) is 47
TCPopts hex string is 020405b40103030e0101080a000000000000000001010402
Max Segment Size is 1460
* Your MTU is set ok
Window Scaling 14 bits (RFC1323)
TSOPT - time stamp option (RFC1323)
SACK Permitted (RFC2018)
Ping stability 95 63 84 99 103 63 129 77 46 93
* Quick packet-loss tested ok
Scaled DefaultRcvWindow (RWIN) is 805306368
Your RWIN limits you @85.2ms to 75615621kbps
Your RWIN limits you @200ms to 32212254kbps
* Your RWIN is advertised as 805306368 (scaling is on)
(Beyond 65k, advertised RWIN is scaled)
Your Path MTU Discovery is ON
Max sized data packet from you 1500
* Conclusion.. HEALTHY SETUP!
* End

I set the window to 1073725440

[rmrucker]

Excellent Mystic! You get the idea. Just play around and see what you find! I love the window size -- and check out what it did to your ping latency -- I would say NOT MUCH!

You average ping time (latency, Round Trip Time, RTT) was 85.2msec. That is not bad. Again showing that RWIN should have no effect on your latency.

However, despite all I read and write about MTU and PMTU-D -- I still believe that setting MaxMTU is important. To a point!

Perhaps it is just that as long as you don't set it TOO LOW, then you are OK! It may just set a Maximum for your NIC.

What I want is someone on PPPoE set their MaxMTU to 1500 (not 1492) and then sniff the packets. What becomes of the actual MSS? Could it possibly be any different?? I don't think so -- the packet sizes are still limited to 1500. Hmmm... One more thing to check out. There is no end.

[Mystic]

Just when you had enough to worry about
http://support.microsoft.com/support/kb/articles/Q259/7/83.ASP?LN=EN-US&SD=g

[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/kb/articles/Q259/7/83.ASP?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).]