persistent TCP-connections between squids

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

Hallo Duane,

It's well known that HTTP/1.0 isn't efficient for low bandwidth/high latency
links (as most transatlantic links are).
It's suffering from 'TCP slow start' and from high RTT when opening a
new TCP connections.
        http://www.w3.org/Protocols/MUX/WD-mux-961023.html
        http://www.w3.org/Protocols/HTTP/Performance/

Question:
-----------
I know HTTP/1.1 will improve this situation. When do you expect HTTP/1.1
to be implemented in squid? (I know it has the priority 2 in your
to-do list - it seems to be a lot of work).

Proposal:
---------
What about implementing (a configurable number of) multiple
persistent TCP connections between two neighbor proxies?

Having persistent connections will save the time for opening
TCP connections many times and will speedup the transfer because
there is only once a 'slow start' period when opening a new connection.

The implementation of such a feature is possibly much easier than the
implementation of HTTP/1.1 ?
Once persistent TCP connections are implemented the efficiency of ICP
could be improved as well in using them.

Our motivation for persistent TCP connections:
-----------------------------------------------
We would like to use such a feature mainly to improve the efficiency of our
transatlantic link in placing a proxy at each end of the line.
There are about 160.000 TCP request for .com per day and about 12.000
requests in a peak hour.
May be we could improve the connection to our child-proxies and to
our siblings in other European countries too in using persistent
connections.

What is your opinion about this idea?

Best regards,
Ernst

----------------- SWITCH Swiss Academic & Research Network ------------------
Ernst Heiri Voice: +41 1 268 1540 (direct: 1543)
SWITCH Head Office Fax : +41 1 268 1568
Limmatquai 138 Mail : heiri@switch.ch
CH-8001 Zurich, Switzerland Mail : S=heiri;O=switch;P=switch;A=400net;C=ch;

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:42 MDT