Subject: Re: initial window size

From: Vernon Schryver <[email-masked]>
Date: Thu, 29 Mar 2001 16:51:53 -0700 (MST)

> From: "David St. Germain" <[email-masked]>

> Although I agree with you that this is how one would tweak the window size,
> the OS still has to default to something.  With Windows NT 4.0, I know the
> default upon installation is 512 (I just recently saw that statistic), I'm
> not sure what the other OS's default to upon installation, but I believe the
> original RFC recommendation was to start with a default of 512 and use the
> slow start algorithm to ramp up.

Please consider the difference between initial congestion window size
and window size.  One of the biggest differences is that one is used by
the sender and the other is used by the receiver.  Please also consider
RFC 2414.  In other words, I doubt that even NT 4.0 had a default window
size of 512, although I wouldn't be surprised if NT 4.0 used a initial
congestion window of 1 segment.

Isn't the NT 4.0 initial window size controled by the 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize 
value?
http://www.winguides.com/registry/display.php/268/ claims the default
is 8760, which is about what I vaguely recall seeing in the registries of
a few Windows boxes.  My recollections put the parameter in a slightly
different registry "hive," "path," or whatever, but I'm probably wrong.

Stevens' "TCP/IP Illustrated Volume 1" has a good description of what
might be meant by "use the slow start algorithm to ramp up," athough it
is to instead of from the configured or default TCP window size.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 29 Mar 2001 20:45:24 -0700 (MST)

> From: arun <[email-masked]>

> wow!  that was a nice discussion. I got cleared up with many of my doubts.
> But  whatever discussion which went about this is abou the Congestion window
> (cwnd). But my basic doubt is the selection of  the send window ( snd.wnd) or
> in other terms it is the peer's receive window which is advertised to the
> sender . Selecting this receive window might be implementation dependent , but
> I like to know what will be criteria and what all parameters affect this
> selection. I hope atleast this time Iam clear ..

"All of the parameters" covering the initial send or congestion
window cover a lot of ground.  Didn't someone else point out RFC 2414?
What about RFC 2416?  RFC 2001 says "initialization for a given
connection sets cwnd to one segment."

If they're not clear, then about what looking for the string snd_cwnd
in the files netinet/tcp_output.c and netinet/tcp_input.c in the
nearest stash of BSD kernel source?  The NetBSD and FreeBSD source
can be found on the net, at URL's like
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/netinet/

---

From: Mark Allman <[email-masked]>
Date: Fri, 30 Mar 2001 09:19:32 -0500

A couple of comments....

Oleg Vishnapolsky said:
>
> Practically speaking, most stacks use a hard-wired default (32k or
> 8k or whatever).

Yep.  In a study of our web server traffic last year we found that
the median advertised window size was roughly 8KB and the average
was about 18KB in web clients.  These numbers were essentially
invariant over the 18 months of data we examined (I really should
crunch the data since the paper, but haven't found the cycles yet).
Further, for transfers that sent enough data to open their cwnd to
the advertised window we found that 70% were likely performance
limited by the advertised window.  So, I agree with Vernon -- crank
those default socket buffers up (or, use something like autotuned
socket buffers).  More details in:

    Mark Allman. A Web Server's View of the Transport Layer. ACM
    Computer Communication Review, 30(5), October 2000. 
    http://roland.grc.nasa.gov/~mallman/papers/webobs-ccr.ps

Vernon Schryver said:
>
> RFC 2001 says "initialization for a given connection sets cwnd to
> one segment."

RFC 2001 is obsoleted by RFC 2581 -- which allows an initial
congestion window of up to 2 segments (up to MSS bytes in each).

Sally Floyd and Jitu Padhye have been using tbit to determine what
initial cwnd web servers are really using.  You can see their
results at: http://www.aciri.org/tbit/

allman

---
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 30 Mar 2001 08:05:38 -0700 (MST)

> From: Lloyd Wood <[email-masked]>

> ...
> Am I right in thinking that we can blame the existence of this on:
> a. the MTU of edge system (good old ethernet) not scaling upward?
> b. TCP's back-to-back busrtiness behaviour?
>
> Fix either one of those, and an initial window of more than one
> segment looks less compelling.

The 1500 byte MTU of Ethernet has worse consequences than anything
mentioned in RFC 2414, but has nevertheless resisted fixing.  According
to a trade rag I saw this week, Ethernet claims 90% of the LAN market,
which sounds low to me.

The consequences I mean can be seen with your favorite TCP benchmark, a
pair of computers, and a LAN medium that is faster than the computers and
has an MTU of at least 4500.  (By "faster" I mean that the computers cannot
saturate it with a single TCP stream.)  Vary the MTU used by the computers
from 1000 through the medium's maximum while measuring single stream TCP
through-put.  Notice that the local peaks ans valleys that correspond to
various things in your computers, but also notice that throughput increases
linearly or faster with MTU.

Or equivalently, somehow measure total CPU cycles/byte on a fast
pair of computers.

Or look at router performance advertisments in the trade rags and
notice that the honest ones are in packets/second.

In other words, the 1500 byte Ethernet MTU makes bridging among
10, 100, and 100 MHz Ethernet easy, but it does terrible things
to performance.

---

From: Mark Allman <[email-masked]>
Date: Fri, 30 Mar 2001 10:09:39 -0500

OK.  I am getting your points, now...

> 1. is, I think, basically a problem with delayed-ack
> implementations, which should ack the first packet immediately
> before going into delay.  (I'd guess that paced TCP should make
> the effects of delayed acks less desirable; acking the first
> packet strikes me as a good idea regardless.)

So, you're trading one hack for another.  Fine.

> 2. is made moot by a larger MTU on edge systems leading to larger
> path MTU throughout.

I'll buy that.

> 3. as for 1., and the effect on slow-start should be ameliorated
> by byte-counting.

But, byte counting+larger initial window is better yet.  They are
orthogonal, I think.

One more note that was not true when 2414 was written...  With
limited transmit, using an initial window of more than one segment
makes loss recovery more robust and less reliant on the RTO.

allman

---