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:
[b]
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...?LN=EN-US&SD=g