RE: HTTP performance issues

From: Barry Raveendran Greene ([email protected])
Date: Sat Feb 20 1999 - 16:08:02 EST


Hello Guy,

> The plan is to us proxies on each remote and one on the VSAT HUB.
> We are now
> testing Satbooster and Venturi, do you know similar products like this ?

Several people have worked this with Squid. Other WWW Cache products are
doing this as part of a TCP Stack modification or integrated into the
product. For example, we've got the following going into the latest version
of the Cache Engine (2.0):

+ TCP slow start
+ Congestion avoidance
+ Fast retransmit / fast recovery algorithms
+ No delayed-ACK in the TCP establish phase
+ Reduced the initial smooth threshold value to avoid the slow start process
ramp up too quickly to cause network congestion (based on Janey C. Hoe's
work)
+ No re-start the slow start when the connection has been idle
+ Better TCP timers mechanism to cut the TCP timers process times
+ Window scale option (RFC 1323). It can go as high as 1,073,725,440 bytes
(64k x 2 power of 14)
+ SACK/PMTU and Path MTU Discovery will be in version 2.1.

All of this is common sense for a WWW Cache manufacturer - we keep up with
the research, IDs, and RFCs to work the features into make friendlier to
satellite links. Just working through RFC1223 and RFC2488/BCP28 provides a
lot of information.

The parallel step would be to work more of the http 1.1 compliance into the
WWW Cache Software. It's not just http 1.1 persistent connection. For
example, IMS (If-Modified-Sense) also has a role to play in the performance
optimization over a satellite link.

Barry



This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:53 EST