On Wednesday, March 6, 2002, at 12:53 AM, David Luyer wrote:
Often the server TCP stack and the customer TCP stack may be dodgy and sometimes even unable to directly communicate, but the good TCP stack in the middle can communicate to both of the dodgy TCP stacks at either end as well as providing a good window size to receive from the server and splitting the latency in half on each TCP connection leg as to a direct connection.
Putting a cache on the US side and using it to feed the cache in the Pacific was also something that I heard about people doing -- that way you got to fine-tune the TCP stacks either side of the satellite circuit, and the customer and origin server TCP stacks only needed to be tuned for cross-country latency. Depending on your caches, you might also be able to use a pool of persistent HTTP connections between the caches to avoid per-connection TCP setup latency. Similar pairs of caches could be used either side of sub-1500-byte-MTU access circuits to eliminate path MTU discovery failures due to poorly configured firewalls, which sounds like it should be useful when your trans-Pacific bandwidth comprises some hideous mixture of unidirectional satellite and GRE tunnels, not that I would know of course. Joe