Satellite latency

Joe Abley jabley at automagic.org
Wed Mar 6 06:06:33 UTC 2002



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




More information about the NANOG mailing list