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