Subject: TCP customization for httpd

From: Thomas Bohn <[email-masked]>
Date: Thu, 1 Feb 2001 12:23:22 -0900 (AKST)

All:

Please excuse this post if inappropriate.

Am seeking any interest in an opportunity to test research
projects/products in a working satellite environment:  am working on a US
Federal telehealth project in the state of Alaska -- we have a statewide
network interconnected by a combination of satellite-based and terrestrial
T1 and sub-DS1 links.  We have developed a web-based application for
digital acquisition of medical imagery in remote areas, with a
store-and-forward function for referral of medical data to distant
providers/specialists.  The application has been developed on Win2K
platforms (both client and server) using ColdFusion middleware and SQL
database backends.  I am currently porting the application to Linux.

We have run into the well-known snag with sat links and TCP:  short bursty
data transfers over TCP don't do so well on high-band/long delay nets.

I am seeking information related to Open Source TCP stack modifications
for a web proxy to be placed on the web server LAN in order to accelerate
the transfer of data out over the WAN to distant client machines.  We do
*NOT* want to modify the stack on the webserver itself, but on an
accelerating proxy for outlying satnet clients.

Our network is private, e.g. is NOT connected to the public Internet.  We
are built out on RFC 1918 address space, use Cisco network elements and
standard transport offerings from Alaska-based space segment providers.

If anyone on this list has an interest in testing within such an
environment (whether your solution is commercial or non-commercial) we
would like to speak with you.  We are, as stated, seeking non-commercial
Open Source variants of standard TCP implementations -- primarily on the
sender side.  Link layer framing is typically standard serial, as
ATM-based cell protocol offerings in the Alaska market were recently
pulled by AT&T (e.g. we use HDLC, PPP, etc.)

I am particularly interested in any TCP mods that have been developed for
BSD-derived unices.

Please contact:

Thomas Bohn
Alaska Federal Healthcare Access Network (AFHCAN) Project
c/o AFHCAN Telecom and Networking
907.729.2266
[email-masked]

reference:  http://www.afhcan.org --> this site in progress of update, so
please check back more than once in the coming weeks.

Thanks!

---

From: Craig Partridge <[email-masked]>
Date: Thu, 01 Feb 2001 16:53:55 -0500

In message <Pine.GSO.3.96.1010201121155.19332A-100000@calvino>, Thomas Bohn wri

>data transfers over TCP don't do so well on high-band/long delay nets.

Does HTTP 1.1 help?

Craig

---

From: Jon Mansey <[email-masked]>
Date: Thu, 1 Feb 2001 14:18:19 -0800

You will probably want to tweak the stack on the receivers more than 
the senders as this is where the bottleneck happens due to windows 
woefully small TCP window size.

Anyway here is a great page of info on TCP tuning.

http://www-didc.lbl.gov/tcp-wan.html

jm

-- 

[email-masked]                          Chief Science Officer
------------------------------------------------------------------
           "The Global Leader in Internet Via Satellite"
InterPacket Networks,                   http://www.interpacket.net
      (A Verestar Company)                  http://www.verestar.com
1901 Main St.                                   tel (310) 382 3300
Santa Monica, California 90405                  fax (310) 382 3310
------------------------------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Feb 2001 14:14:04 -0800

> pulled by AT&T (e.g. we use HDLC, PPP, etc.)

Sounds like what you want to do is:

	- run HTTP 1.1 (or at least +persistent connections, which predates 1.1)

	- turn TCP's congestion management
		one way to do this using private space is to have the endpoints
		on the same subnet. that causes many implementations to turn 
		off congestion management

	- use large MTUs (the same trick - same subnet will trigger use of link MTU
	  rather than path MTU discovery, but be careful of black holes if that size
	  is too large -- it can be reset at the interfaces themselves)

	- make sure your socket buffers, etc are tuned properly (see www.psc.edu)

Note that none of these necessitate the use of a proxy. 
Some can be implemented at the proxy, but that runs the risk
of having the proxy be the bottleneck.

Joe