Who decided on 372300??

[~WarockZIII]

I have 1 question though, Im running on 1500/128 Cable. So what do you suggest my Rcwin should be?

[rmrucker]

Wow. A lot more here. First I really *despise* you guys making me have to go to the OLD, LONG post -- it takes longer to get to the bottom of page 2!
~~
Venom-
You have hit my present area of interest and investigation -- Path MTU Discovery. I believe this is exactly the behavior TRS describes above. TRS reports that the initial receive window is decided on by a "bidding" process in the 3-way handshake. SYN offers an RWIN and MSS. SYN,ACK offers back another RWIN and MSS. ACK comes back with the final RWIN and MSS -- reportedly with MSS the lesser of the two offered, and the receive window as a multiple of this MSS that exceeds the proposed RWIN in the SYN packet.
~~~~
Here is a quote from MS's White Paper on TCP/IP:
PMTU discovery... When a connection is established, the two hosts involved exchange their TCP maximum segment size (MSS) values. The smaller of the two MSS values is used for the connection.
TCPWindowSize... TCP adjusts to even increments of the MSS (maximum segment size) negotiated during connection setup.
~~~~
Sounds just like what TRS found -- except, he actually found that the window size was NOT always at even increments...

Now, the implications of this is that RWIN does NOT have to be a multiple of MSS at ALL!! MS TCP/IP *seems* to take care of that itself. One problem. I investigated this myself and I could not demonstrate the described PMTU Discovery behavior!!! I had someone else try as well -- but again, what TRS described and what is printed in the MS White Paper did not seem to occur. INTERESTING... I am still looking into this.

That is why I asked you if you packet-sniffed. It is quite enlightening. I have gone into detail on interpreting the Tcp Option string here: http://www.dslreports.com/forum/rema...s,61;mode=flat

[Philip - it you want *final* proof about Tcp1323Opts as a Dword vs. String - check out my posting and packet sniff yourself. If it doesn't show "0103030n" (n=scale factor) in the TcpOptions line of the Tcp Header, then you can be *sure* the Dword doesn't work.]

[Oh, and Venom -- that is EXACTLY how you can prove to yourself that SackOpts doesn't belong in the "Parameters" sub-key.]

You can't trun off PMTU Discovery or your MTU will crash down to pre-RFC1191 levels of 576!! Try it yourself and run a Tweak test at dslreports.

Mystic-
I agree with where you are coming from (so insert "Yes" almost anywhere I don't address) except:

1) The RFC's are the LAWS of the Internet -- they are not just theories.
2) Different users on the same service may have different routing, etc. I don't think you can generalize.
3) There cannot be one magical number. I have argued this incessantly.
4) You are HORRIBLY wrong in one spot:
"Microsoft and who ever else - they are all right." I must strongly disagree with this. Why??? I can show you several spots where the MSKB is simply erroneous.

The best example that comes to mind are the comments for "Tcp1323Opts". In one place it says that for Win98 this a DWORD -- wrong!!! In other place, it correctly states this is a String value, but the lines exactly above that state that Tcp1323Opts are **enabled** by default -- wrong again!!!

So, the RFC's are the laws of the Internet, but don't expect Microsoft to be 100% correct.

[Venom]

Hello rmrucker:

sorry to keep posting here I thought about opening a new thread and posting a link of this thread and continue to the new one but some how I thought people would post on both threads and it might be worse *lol*

Well I guess I.m starting to feel a little more right about the MSS and the PMTUDiscovery, and if this keeps up like this it start to make you wonder why the heck go through the trouble of calculating your correct RWIN when the conection that you get has a totaly diferent MSS and MTU and there for RWIN. I asume that micorosoft is gona have to create another option to auto calculate the correct RWIN and everything else depending on the conection that you establish, BUT THEN AGAIN! the RWIN is nothing more then a buffer and if your gona treat the RWIN buffer like a normal Swap file that changes in size I assume before every conection it will pause to change besides the fact that the way it is now you would have to reboot *lol*, I don't see why it's not a simpler buffer where if you have certain amount of RAM you can afford to make the buffer bigger in order to download more information faster. But in that theory it would obligate people to buy more RAM even though that's the way the mayority of things are in the computer worls so I guess it wouldn't matter.

I don't know but i have a feeling that Microsoft is writing thier own "bible" what I mean by that is something that contradicts it's self and I am sorry to use that example for all those who are faithfull to it, please accept my apologies.

But to continue if things contradict themself like that I assume there will never be a way to cominicate properly or should I say with all the benifits and the Max speed.

I hope Microsoft does something soon cuz this is a little to wiered to have to dig in so deep in to the microsoft manuals and knowledge base to just the it confues people *lol*



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

[SavageHrt]

rmrucker-

I didn't realize it was so inconvenient to go to page 2. I will have to remember that in the future. Thanks for the heads up.

Note to self-

If thread is 2 pages DO NOT post.

Sav

[rmrucker]

I came back to this post for that?? Ouch! You got me. Love it, Sav. Take care.

[Philip]

the conection that you get has a totaly diferent MSS and MTU and there for RWIN.

Actually, most servers/routers/switches are compliant to the Ethernet standard and quite capable of transfering 1500 byte packets.

RWin is a buffer and it's not imperative to make it a multiple of anything, however it's a good idea and there are reasons behind it, such as:

While transfering large files, if the buffer is filled, chances are you'll get more non-fragmented packets.

When packet loss occurs (or at the beginning of each transfer) the implemented algoritms are based on MSS and the current window is opened in multiples of MSS.

Also there will be less calculations required to advertise the current receive window by your end... (although I haven't proven it mathematically )

Oh, btw all RFCs and "RWin" related articles base their calculations on MSS...

You mention RWin's relevance to swap files, since it is a buffer. When you assign virtual memory you do it in Megabytes,or you essentially make it a multiple of bytes/kb/MB since they are your base units. When figuring out RWin, it only makes sense to do the same, by using MSS for a base unit instead...

I hope I make some sense, my argument is that although not necessary, it's better to calculate/implement it that way

------------------
Life would be much easier if I had the source code...

[This message has been edited by Philip (edited 11-07-2000).]

[Buggyman]

rmrucker,
I do have one question though.
Why is that I can get faster speeds with my scaling turned off?
All my testings has shown that with a low Rwin and scaling turned off I get the most out of my non DOCSIS certified connection.
If scaling is base on adjustments according to handshakes. Then somebody got robbed in my case.
Any Comment?

[dbnukes]

I have DSL 1.5/256 and I had applied the 98 mtu patch, the vtcp.386 update, the fast web page loading patch. My speeds did increase but not that much. I then downloaded the @home speed patch and Wa-bam, my speed shot up greatly. Go figure, with its 373360 Rwin! By the way, I'm running on Windows 98 with a 350Mhz processor and Internet Explorer 5.5. With all the diffrent factors involved, the moon phase, the rising and falling of the tides, the shift of the tectonic plates, etc. it's amazing how diffrent people's connections are affected diffrently. Get my drift? I've tried several diffrent combos and I keep going back to this one time and time again. I don't know why, but this @home patch really beefed my speeds up for me!!!

[Buggyman]

dbnukes,
You've got the right Ideal....That's why tweaking is a must and nobody's is the same.
In my case Cablenut had to make mine for me.
My cable is not DOCSIS ready because it's one of the oldest in town and AT&T is having to upgrade the sytem.
If I use a High Rwin I got speed all right but packet Loss was real high.
So Cablenut lowered the Rwin and turned the scaler off.... as a result my overall performance went up.
This is why I ask rmrucker what I did in the above post. Seems to me the scaling plays a VERY important role in overall performance.
Which by the way......
Yooo-hoooo....
Mr. rmrucker..... I'm waiting on my answere!

[dannjr]

I couldnt resist besides it took forever to find again..

I wanted to refrence this and found a couple of links broke due to Microsofts updates.. But no matter how you look at this I think its one fine thread that if you have the time should be read.

I know rmrucker is gonna shoot me

HAPPY HOLIDAYS

[x-guest]

Welp, I was too lazy to read thru every single drip of text on all these posts but I did skim thru all of them to get a basic idea of what you's are talking about....

One question (and forgive it for its possible ignorance).. But doesn't the automatic PMTU discovery play a role in any of this? Isn't there any way that can be disabled without having you surfing at ghey 576MTU speeds?

What about selective ACK, and Timestamping? And finally has anyone ever heard of the scrump-diddly-umptious sounding "TCP Daytona" that I've been trying so hard to fully understand which would theoretically allow one to SUCK up all available bandwidth of a server (regardless of capping) by effectively fooling or in essence CHEATING at the TCP level by "not playing fair" using its 3 specially defined and outlined methods?

thanks..

[dannjr]

(11-07-00 11:54 PM) Last true date of this thread you might want to start a new topic.
AND yes you can disable PMTUD and surf where you want it.

Read Read Read Its good for the soul

[x-guest]

Whoops sorry I didn't realize that a thread so old would automatically invalidate any further posts.. LOL! hehehe..

Hell, maybe I will post a new topic.