Broadband Optimizer for Revolution?

[Dar Scott]

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
**********************************************