On May 31, 2005, at 3:53 PM, Mark Wieder wrote:
DS> (To me it seems strange to call the MTU a transmit window.)
Here's my understanding of this - I'm sure someone will correct me if
I'm too far off - there's a maximum transmit window size and a maximum
receive window size. You can crank your receive window up without too
much problem. However, if you start messing with your transmit window
one of several things may happen:
Honestly, Mark, I have never heard the the MTU called a transmit window.
The TCP receive window is very different. It is THE TCP window.
There is a congestion window that is an implementation optimization.
It varies in size to adapt to the network, up to the advertised TCP
window from the receiver. Normally, you don't set that, but it seems
for Internet systems something is set.
I looked around online and see that the congestion window is called
called a transmit window in some circles (Windows and Unix), but I
don't know what it would mean to set it. I suspect that imposes a
maximum on the congestion window.
So, that is an implementation optimization parameter, not a TCP
parameter.
Traditionally the receiver controls the TCP window, but it seems some
implementers think the sender should. This can hurt LAN performance,
but might improve Internet performance.
1. You'll get the size too low (I think windows enforces a minimum
88-byte window even if you try to set it lower), in which case you'll
be sending out lots of small packets and the packet overhead will
significantly affect your transmission speed.
Here you are talking about MTU again. I suspect the Windows minimum of
88 is to support some UDP protocols without fragmentation. I don't
remember the TCP/IP minimum. 40?
The MTU is not a sliding window. It is the fixed maximum of a total
packet size.
2. You'll set the size too high, which should theoretically increase
your throughput - sending lots of data with low overhead. However, if
there are any routers in between (i.e., you're on some system other
than a two-computer point-to-point system) then somewhere along the
line some device will have an MTU smaller than the size you've set and
it will break up the packet into smaller pieces, again probably
slowing things down for you.
Of course, these are *maximum* windows sizes - TCP is constantly
testing performance and adjusting the window sizes as necessary, but
it won't go above the MTU.
The TCP window can go above the MTU. The MTU is just the maximum
packet size.
The TCP window is the maximum number of bytes not ack'd.
It might be that some implementations use the MTU as a hint for the
initial value of the congestion window size and that's where your
confusion is.
My confusion is that I'm standards oriented and not implementation
oriented since I use TCP on a lot more than just Windows and Unix.
Maybe there are some standards on congestion control that I have
missed. Well, very likely.
Dar
--
**********************************************
DSC (Dar Scott Consulting & Dar's Lab)
http://www.swcp.com/dsc/
Programming and software
**********************************************
_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution
