SG Broadband Community

Back to the drawing board, argh.

The problem is, MTU is not reported in the TCP/IP headers or options... We are trying to get it from the MSS field and the Header+option size but it seems there is another problem with that.

The server shouldn't crash on Win2k, it was down for a minute.

SpeedGuide.net TCP/IP Analyzer
TCP properties for IP = 24.xxx.xxx.xxx
TCP options string = 020405b4010303020101080a000000000000000001010402

MTU = 1512

Your MTU value seems to be larger than the Ethernet specs, consider lowering it to 1500 or 1496.
If you're on DSL that uses PPPoE, the maximum allowed packet size is 1492.

MSS = 1460

Default Receive Window (RWIN) = 256960
RWIN Scaling (RFC1323) = 2 bits
Unscaled Receive Window = 64240

RWIN is a multiple of MSS
Other values for RWIN that might work well with your current MTU/MSS:
256960 (MSS x 44 * scale factor of 4)
192720 (MSS x 44 * scale factor of 3)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 20556.8 kbps (2569.6 KBytes/s) @ 100ms
Your RcvWindow limits you to: 10278.4 kbps (1284.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 4111.36 kbps (513.92 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = 1

Time to live = 50 hops

Timestamps (RFC1323) = 1

Selective Acknowledgements (RFC2018) = 1

IP type of service = 0


Sorry about taking so long!

[ 03-06-2001: Message edited by: blebs99 ]

Those are the same results that I just got Blebs. We should just wait and see till Philip works out the kinks

Working on it, keep in mind it is an Alpha testing, so there are problems to be worked out ... We have an idea what
s going on, we'll get it right.

I'm on WIN ME it shows MTU of 1512 when I know it's 1500, all else is right, this is going to be neat!!!!!!!!!

Well, let's test again, Prey, can you post your results once again ?

Anyone else having problems ?
TIA

The information seems correct for mine, the box itself is alittle big, I use 800x600, pick,pick, pick, good job

Here are my results:
SpeedGuide.net TCP/IP Analyzer
TCP properties for IP = xx.xxx.xxx.xx
TCP options string = 0204059c01010402

MTU = 1476

MTU is not at an optimal value... Consider increasing your MTU to 1500 for optimal throughput.

MSS = 1436

Maximum useful data in each packet = 1436, which seems to be equal to MSS.

MSS is not fully optimized for broadband (although it might work well for slower connections). Consider increasing your MTU value.

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

RWIN is a multiple of MSS
Other values for RWIN that might work well with your current MTU/MSS:
252736 (MSS x 44 * scale factor of 4)
189552 (MSS x 44 * scale factor of 3)
126368 (MSS x 44 * scale factor of 2)
63184 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 1378.56 kbps (172.32 KBytes/s) @ 100ms
Your RcvWindow limits you to: 689.28 kbps (86.16 KBytes/s) @ 200ms
Your RcvWindow limits you to: 275.712 kbps (34.464 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = 1

Time to live = 117 hops

Timestamps (RFC1323) = 0

Selective Acknowledgements (RFC2018) = 1

IP type of service = 0


I think the MTU on mine is 1500 but the routers I dunno. Im a linksys and if I recall the linksys has that mtu. So seems great!

Sweetness, thanx Philip and to your friend whom helped you, You Guys Rock

TCP options string = 020405b0010303030101080a000000000000000001010402

MTU = 1496

MTU is at optimal value

MSS = 1456

Maximum useful data in each packet = 1444, which is less than MSS because of Timestamps, or other TCP options used

Default Receive Window (RWIN) = 373760
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 46720

For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
256256 (MSS x 44 * scale factor of 4)
192192 (MSS x 44 * scale factor of 3)
128128 (MSS x 44 * scale factor of 2)
64064 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 29900.8 kbps (3737.6 KBytes/s) @ 100ms
Your RcvWindow limits you to: 14950.4 kbps (1868.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 5980.16 kbps (747.52 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = 1

Time to live = 51 hops

Timestamps (RFC1323) = 1

Selective Acknowledgements (RFC2018) = 1

IP type of service = 0

Ah yes thanks tekelberry I know now what linksys uses now..

[ 03-06-2001: Message edited by: cablenut ]

Mine was done on purpose this way and it read it right Very cool...

TCP options string = 0204059c0103030301010402

MTU = 1476

MTU is not at an optimal value... Consider increasing your MTU to 1500 for optimal throughput.

MSS = 1436

Maximum useful data in each packet = 1436, which seems to be equal to MSS.

MSS is not fully optimized for broadband (although it might work well for slower connections). Consider increasing your MTU value.

Default Receive Window (RWIN) = 371712
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 46464

For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
252736 (MSS x 44 * scale factor of 4)
189552 (MSS x 44 * scale factor of 3)
126368 (MSS x 44 * scale factor of 2)
63184 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 29736.96 kbps (3717.12 KBytes/s) @ 100ms
Your RcvWindow limits you to: 14868.48 kbps (1858.56 KBytes/s) @ 200ms
Your RcvWindow limits you to: 5947.392 kbps (743.424 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = true

Time to live = 247 hops

Timestamps (RFC1323) = false

Selective Acknowledgements (RFC2018) = true

IP type of service =

Here is the new test results! I turned scaling off and everything appears correct. Thanks Philip and fellow engineers!
SpeedGuide.net TCP/IP Analyzer
TCP properties for IP = 24.xxx.xxx.xxx
TCP options string = 020405b40103030201010402

MTU = 1500

MTU is at optimal value

MSS = 1460

Maximum useful data in each packet = 1460, which seems to be equal to MSS.

Default Receive Window (RWIN) = 256960
RWIN Scaling (RFC1323) = 2 bits
Unscaled Receive Window = 64240

RWIN is a multiple of MSS
Other values for RWIN that might work well with your current MTU/MSS:
256960 (MSS x 44 * scale factor of 4)
192720 (MSS x 44 * scale factor of 3)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 20556.8 kbps (2569.6 KBytes/s) @ 100ms
Your RcvWindow limits you to: 10278.4 kbps (1284.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 4111.36 kbps (513.92 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = true

Time to live = 50 hops

Timestamps (RFC1323) = false

Selective Acknowledgements (RFC2018) = true

IP type of service field = 00000000

SpeedGuide.net TCP/IP Analyzer
TCP properties for IP = xxx.xxx.xxx.xxx
TCP options string = 0204059c010303030101080a000000000000000001010402

MTU = 1476

MTU is not at an optimal value... Consider increasing your MTU to 1500 for optimal throughput.

MSS = 1436

Maximum useful data in each packet = 1424, which is less than MSS because of Timestamps, or other TCP options used

MSS is not fully optimized for broadband (although it might work well for slower connections). Consider increasing your MTU value.

Default Receive Window (RWIN) = 274560
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 34320

For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
505472 (MSS x 44 * scale factor of 8)
252736 (MSS x 44 * scale factor of 4)
126368 (MSS x 44 * scale factor of 2)
63184 (MSS x 44)

bandwidth * delay product:

Your RcvWindow limits you to: 21964.8 kbps (2745.6 KBytes/s) @ 100ms
Your RcvWindow limits you to: 10982.4 kbps (1372.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 4392.96 kbps (549.12 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = true

Time to live = 110 hops

Timestamps (RFC1323) = true

Selective Acknowledgements (RFC2018) = true

IP type of service field = xxxxxxxx


Just a test WinME

TCP options string = 0204052a01010402

MTU = 1362
MTU is not at an optimal value... Consider increasing your MTU to 1500 for optimal throughput.

MSS = 1322
Maximum useful data in each packet = 1322, which seems to be equal to MSS.
MSS is not fully optimized for broadband (although it might work well for slower connections). Consider increasing your MTU value.

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

For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
507648 (MSS x 48 * scale factor of 8)
253824 (MSS x 48 * scale factor of 4)
126912 (MSS x 48 * scale factor of 2)
63456 (MSS x 48)

bandwidth * delay product:
Your RcvWindow limits you to: 2569.6 kbps (321.2 KBytes/s) @ 200ms
Your RcvWindow limits you to: 1027.84 kbps (128.48 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = true

Time to live = 248 hops

Timestamps (RFC1323) = false

Selective Acknowledgements (RFC2018) = true

IP type of service field = 000xxx00

Precedence (QoS) = xxx
Delay = x
Throughput = x
Reliability = x
Cost = x

NT 4 test

Think I'll start charging for tis

Question: How do I change my MTU in Win2k?

Mine is reading 1476 and I should set it 1500 for optimal performance.

The MTU Key in Win2K is in:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Class\{83870D99-673F-4C3B-98D3-2803C09BC71E}

hey prey, I can't seem to find that in my registry...I'm on Win2k too

It worked this time.

Bitchen'

I'll explain this without getting technical (hehe)

Windows 2000 has dynamically assigned GUID's that are stored in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\

for ethernet adapters you have to find the right one (usually the one that has your IP, dns, and gateway info in it) then create a DWORD called MTU and set it to your desired valued.

Thanks for the MTU location, mine is already set to 1500.....so why is it reporting 1476?
---------------------------------------------
---------------------------------------------

TCP options string = 0204059c010303030101080a000000000000000001010402

MTU = 1476
MTU is not at an optimal value... Consider increasing your MTU to 1500 for optimal throughput.

MSS = 1436
Maximum useful data in each packet = 1424, which is less than MSS because of Timestamps, or other TCP options used.
MSS is not fully optimized for broadband (although it might work well for slower connections). Consider increasing your MTU value.

Default Receive Window (RWIN) = 373760
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 46720
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
505472 (MSS x 44 * scale factor of 8)
252736 (MSS x 44 * scale factor of 4)
126368 (MSS x 44 * scale factor of 2)
63184 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 14950.4 kbps (1868.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 5980.16 kbps (747.52 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = true

Time to live = 21 hops

Timestamps (RFC1323) = true
Keep in mind that timestamps add 12 bytes to the TCP header of each packet, reducing the amount of useful data.

Selective Acknowledgements (RFC2018) = true

IP type of service field (RFC1349)= 00000000

BMED do you have a linksys or UGate3200 router if so it is limiting your MTU.

Originally posted by cablenut:
BMED do you have a linksys or UGate3200 router if so it is limiting your MTU.

Thanks cablenut, It looks like my linky is the culprit here. I guess there's no way around this unless I disconnect the Linksys. My speeds are very satisfactory right now, if it ain't broke don't fix it....

Thanks again,BMED

Philip, I suspect that people are getting MTU's of over 1500 if you are adding the 12 bytes of Timestamping to the total...
~~~~~~~~~~```

Edit: Hmmm... this appears to be fixed now.

[ 03-08-2001: Message edited by: rmrucker ]

By the way -- excellent job!!! And I like the TOS flag readings as well. NICE!

One thing to note. You might want to clarify the TTL reading. This is the TTL that is in the packet that YOU recieve -- not the TTL of the machine sending the packet. We had multiple questions on that and in the end TTL was scrapped.

GOOD WORK!! I LOVE the correct RWIN. Outstanding!! Bravo!

~~~~~~~~~~~~~~~

Ah, one more question -- do you want the Unscaled Recieve Window to be the window used by routers that are not using TCP1323Opts??

Then, don't you want to change this:

Default Receive Window (RWIN) = 200000
RWIN Scaling (RFC1323) = 2 bits
Unscaled Receive Window = 50000

Instead, the NON-Tcp1323Opts routers would be using an RWIN of 3,392.

That is: 200,000 mod 65536 = 3,392.

[ 03-08-2001: Message edited by: rmrucker ]

rmrucker, we get the unscaled RWIN value directly from the SYN packet I believe, that's where a non-TCP1323 router would get it too, isn't it ?

I mean, in the packet there is an unscaled value (which we report), and then there is the scale option.


~~~~~~~~~~~~~~~~~~

You can try turning off Tcp1323 Options and see whether you can get it to display an incorrect value, I believe we have it set right.

[ 03-08-2001: Message edited by: Philip ]

As far as the TTL value you are somewhat right, we have no way of knowing the exact value of TTL since it is reduced by one each hop (unless we actually traceroute to the client and count hops).

However the value that's reported is the TTL left on the client packet.

TTL- correct. My point is that you could put a sentence in there that says: "This is the TTL value as it was read by the Analyzer. It is equal to your TTL minus the number of Hops to SpeedGuide."

OK, that is too wordy, but you get the point! The only reason for doing this is to AVOID getting a bunch of posts on this board asking, "Why does the Analyzer give me the WRONG TTL value?" Then you have to spend time explaining how the TTL value works...

I am trying to save you guys from the problems we had!! In the end Justin just took the TTL result out of the test...

I have come up with TWO methods to determine the "set" TTL. Your way (tracert) is the more time and labor intensive!

The other method is to simply send an ICMP Echo Request (ping) to the user. The ICMP Echo Reply that returns will contain a TTL field in its IP header. By default, the ICMP Echo Reply TTL field starts out with a TTL of 255. It would be reduced by the number of Hops it takes to get to SpeedGuide's Analyzer. Therefore, the correct TTL would be:

x = TTL value in TCP/IP packets FROM user
y = TTL value in ICMP Echo Reply FROM user

SetTTL = x + (255 - y)
_______________________________________

Unscaled RWIN -

I would have to say YES and NO to this:

"we get the unscaled RWIN value directly from the SYN packet I believe, that's where a non-TCP1323 router would get it too, isn't it?"

That sentence is correct, however, the Analyzer did not do this. Instead the Analyzer is reporting the ACK packet Window field as the Unscaled value.

For example- on my test I got:

Default Receive Window (RWIN) = 200000
RWIN Scaling (RFC1323) = 2 bits
Unscaled Receive Window = 50000

Obviously, the top number is equal to the bottom number times 2 to the power of the scaling bits:

50,000 * 2^2 = 200,000.

Therefore, the 50,000 is taken from my ACK packet -- not my SYN packet.

The SYN packet Window field would be equal to my Registry's RWIN mod 65536 -- as I said above.
____________________________________

Regardless, I love your Analyzer!!!! Why didn't you email me on this! I get more email from cablenut!

[ 03-08-2001: Message edited by: rmrucker ]

Hmm, you might be right, I'll check. We do get the scaled RWIN from a non-SYN packet.

Anyway, thanks for the feedback, and I would've emailed you, just that the tool is not completely ready yet and I couldn't remember your address

Oh, the ICMP way of calculating TTL does sound good too We might add that at some point.

HUH?

I just saw the new TTL wording -- I think that is even more wordy that mine!

I know -- it is a work in progress. But, honestly, GREAT JOB so far!

I am thrilled that I can be of ANY help!! I'll keep an eye on your progress.

One more thing...

The TOS flags. Justin has pulled reporting those -- again because they were a source of a lot of confusion and questions.

I agree that users like cablenut, dannjr, you, and I are interested in seeing these, but Newbies might be confused. I guess the point is that you have to go out of your way to educate the users...

Your present format is this:

IP type of service field (RFC1349)= 01011100
Precedence = 010
Delay = 1
Throughput = 1
Reliability = 1
Cost = 0

There is no explanation or interpretation. It is left as a mystery.

"Precedence" is also a confusing term -- perhaps the term "importance" or something could be included afterwards? Then, the binary numbers are not entirely useful -- although I agree these are the standard...

Then, at least some interpretation could be considered. For example:

Precedence (importance) = 2 (immediate)
Delay = 1 (low delay)
Throughput = 1 (high throughput)
Reliability = 1 (high reliability)
Cost = 0 (normal cost)

Just some thoughts...

But part of me feels like I have just opened Pandora's Box...

rmrucker that box has been open for a long time I agree though about the different definitions of the bits...

I was planning to add descriptions, just being lazy

All feedback is appreciated.


~~~~~~~~~~~~~~~

K, descriptions added... Would you like them color coded too ?

[ 03-09-2001: Message edited by: Philip ]

I just ran the TCP/IP Analyzer and a few things seem to be incorrect.

The IP address under the title isnt mine. Do you think its a proxy server or something?

RWIN is incorrect, it says 49152 when it should read 256960.

MTU reads at 1500.... ok
MSS reads at 1460.... ok

What to do now??? Thx

TCP options string = 0204059c010303030101080a000000000000000001010402

MTU = 1476
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings.

MSS = 1436
Maximum useful data in each packet = 1424, which is less than MSS because of Timestamps, or other TCP/IP options used.
MSS is not fully optimized for broadband (although it might work well for slower connections). Consider increasing your MTU value.

Default Receive Window (RWIN) = 471712
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 58964
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
505472 (MSS x 44 * scale factor of 8)
252736 (MSS x 44 * scale factor of 4)
126368 (MSS x 44 * scale factor of 2)
63184 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 18868.48 kbps (2358.56 KBytes/s) @ 200ms
Your RcvWindow limits you to: 7547.392 kbps (943.424 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = true

Time to live left = 240 hops
TTL value is ok.
Note: Since TTL is decreased by 1 with each hop, the value above is equal to your TTL minus the number of hops to forums.speedguide.net

Timestamps (RFC1323) = true
Keep in mind that timestamps add 12 bytes to the TCP header of each packet, reducing the amount of useful data.

Selective Acknowledgements (RFC2018) = true

IP type of service field (RFC1349)= 00xxxx00
Priority = 00x (priority some)
Delay = x (what delay)
Throughput = x (something throughput)
Reliability = x (something reliability)
Cost = 0 (normal cost)I like that price..

Next I think I'll set the Rwin to
0xffffffff Maybe I'll get lucky and it won't BSOD on me...

Originally posted by Bigpoppapump:
I just ran the TCP/IP Analyzer and a few things seem to be incorrect.

The IP address under the title isnt mine. Do you think its a proxy server or something?

RWIN is incorrect, it says 49152 when it should read 256960.

MTU reads at 1500.... ok
MSS reads at 1460.... ok

What to do now??? Thx

The Analyzer reports information for the IP that initiated the request, in your case it could be a proxy server.

Try turning off proxy, if you're running Internet Explorer the setting is in Tools>Internet Options>Connections>LAN settings

Not much time...

I see you opted for the word "Priority" -- that is the word I initially typed, then deleted. "Importance" is another viable option -- but "Precedence" is the correct term. Do you want to list both of them (e.g., Precedence/Priority)?

The reason why I backed off from "Priority" was for the ambiguity of the "level 1 Precedence":

Priority = 001 (priority)
_____________________________________

Also, do you think the terms "true" and "false" are more useful than "on" and "off" -- or even "yes" and "no"? Perhaps even ENABLED / NOT ENABLED? Or ACTIVE / INACTIVE?

I just think true and false seem strange -- although correct from a binary point of view!

What does everyone else think??
___________________________________________

Philip- I read through RFC793 and as best I can tell, you are correct about the RWIN. I would LOVE to connect to a WinNT server and test this out (WinNT should not be able to process Tcp1323Opts). Can you give me the address of a WinNT server???? Or any other server that you KNOW is not RFC1323 compatible?

[ 03-09-2001: Message edited by: rmrucker ]

Philip - I am really reposting to make sure you saw my last editing -- but while I am here...

Here is the most recent output:

_______________________

Time to live left = 120 hops
TTL value is ok.
Note: Since TTL is decreased by 1 with each hop, the value above is equal to your TTL minus the number of hops to forums.speedguide.net

Timestamps (RFC1323) = ON
Keep in mind that timestamps add 12 bytes to the TCP header of each packet, reducing the amount of useful data.

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349)= 01011100
Precedence (priority) = 010
Delay = 1 (low delay)
Throughput = 1 (high throughput)
Reliability = 1 (high reliability)
Cost = 0 (normal cost)
________________________________

1) I like the ON/OFF better than true/false -- I guess enabled/inactive did not interest you.

2) I like the TTL statement! You *could* say "is decreased by at least 1..." if you wanted to be 1000% correct.

3) For continuity, the timestamps explanation could be made in *smaller type* (like TTL) and it could be worded similarly:
"Note: timestamps will add 12 bytes to the TCP header of each packet, reducing the space available for useful data."

4) I am not sure there is a "perfect" solution for Precedence. This way is fine, but you are now leaving off the description of the value.

5) Another thought is that you could add a line like this for MTU Discovery -- when it is OFF. "Note: if MTU Discovery is OFF, your Uploaded packets will be limited to a size of 576 bytes."

I recognize this is nit-picking!!! But I am just offering up suggestions!!

Cheers. Have a good week end.

Thanks for all the suggestions.

The TOS field not giving the description was a bug in the output parser, fixed.

Added/modified some descriptions as suggested.

Does turning MTU Discovery off limit MTU for all OSes ? I thought it's just a Windows glitch.

About RFC793, I read it the same way too, we still have to test to verify it.

As far as a non-1323 compliant test machine, I don't have one availale, but I'm sure some of our users have NT4 or older boxes... If anyone has one, please try the Analyzer and compare the RWIN/Unscaled Window result with your Registry setting and post some feedback. Or, if you are not sure how to help, just email me or rmrucker.

Thanks.