Phil's tips for improving the network performance of hosts

For all machines

Enable large windows (RFC 1323)
Enable MTU discovery (RFC 1191)
Increase socket buffer sizes (to at least the bandwidth*delay product)
- Both in the Operating System - typical system MAXIMUM is 128KB to 1MB
- And in the application, and/or OS DEFAULT (if you have lots of memory)

To learn how to do these things, see PSC's Performance Tuning notes.
For PC's a tool like TweakDUN may be helpful.

For machines with multiple interfaces

Make sure you are using a high bandwidth interface
- Your default route should be via your high speed interface.
- This may require running e.g. gated to ignore routing information from slow speed interfaces.
Make sure the DNS lists your high speed interface first.
- Though some hosts today round-robin or randomize which of multiple interface addresses from the DNS get used, so this isn't fool proof.
Minimize use of 10 Mbps interfaces.
Consider turning off your slower speed interfaces so that they are sure not to be used.

For the Campus Network

Try to limit 10 Mbps segments to LEAVES only.
Eliminate slower speed forwarders, e.g. hosts that gateway 155 Mbps ATM to 10 Mbps ethernet (ugh).
Try to never reduce an MTU between a source host and the campus "backbone", and between the backbone and connections off campus.

Every host should have a path exiting the campus that

does not reduce the bandwidth, and
does not reduce the MTU.

   Typical MTU's:
   Ethernet 1500  (same for 10, 100, and 1000 Mbps)
   FDDI 4352
   ATM  9180  (9188 SPANS)

For Web Browsers

Make sure your browser cache is on a local disk drive (it defaults to your home directory which is often remotely mounted).
If on a dialup connection, use a web cache to decouple the TCP behavior over the dialup line from that over the wide area network.

Some notes on performance measurements between ARL, ASC, and NAVO

From ARL I am seeing round trip times (rtt's) of 65 msec to NAVO and 16 msec to ASC. With a "standard" TCP, i.e. one restricted to 64KB windows, this would imply maximum TCP throughputs of (window/rtt):

	NAVO:	65536*8/0.065 = 8.07 Mbps
	ASC:	65536*8/0.016 = 32.8 Mbps

The ~8 Mbps limit reported between ASC and NAVO may well be because of a TCP window size limit.

For some great notes about how to tune TCP, see:

	http://www.psc.edu/networking/perf_tune.html

For PC's, see some of the following tools:

	http://www.sysopt.com/maxmtu.html

For a checklist of possible performance limits:

	http://www.ittc.ukans.edu/~ldasilva/table/tips.html

TReno is a tool by Matt Mathis et.al. to measure the Bulk Transfer Capacity as defined by the IETF BMWG. It simulates an advanced TCP in user mode with UDP packets, using "port unreachables" as ACK's. It gives you an idea of the throughput that should be obtainable by a modern well-tuned TCP, in other words, an upper bound. You can find TReno from the mother-of-all-measurements page:

	http://www.caida.org/Tools/taxonomy.html

Running TReno from ARL to cfs01-f at ASC I get ~40 Mbps. To maury at NAVO I get ~37 Mbps. [To crab-fddi here at ARL I only get ~25 Mbps. Tom Kile and I are looking into that. We think there may be a 10 Mbps ethernet in the return path.]

Why isn't it 155 Mbps to ASC and NAVO? Several reasons. One may be my host (SGI R5k Indy w/OC3 ATM) - I don't know what TReno is capable of on a local interface. One may be load and packet loss on DISC, and/or the campus nets. For an excellent paper about the effects of packet loss, MTU, and RTT on TCP throughput, see:

	http://www.psc.edu/networking/papers/model_abstract.html
	http://www.psc.edu/networking/papers/ - and other good stuff

We are working on additional measurements. Don Merritt has been working with bprobe/cprobe to measure bottleneck and congestion bandwidths over DISC, etc. Will let you know what we learn.

P. Dykstra