[45966] in North American Network Operators' Group
Re: Satellite latency
daemon@ATHENA.MIT.EDU (Joe Abley)
Wed Mar 6 01:10:41 2002
Date: Wed, 6 Mar 2002 01:06:33 -0500
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: "'Tony Rall'" <trall@almaden.ibm.com>, <nanog@merit.edu>
To: "David Luyer" <david@luyer.net>
From: Joe Abley <jabley@automagic.org>
In-Reply-To: <002c01c1c4d3$3cd61090$638317d2@pacific.net.au>
Message-Id: <4F0624AC-30C8-11D6-860B-003065CD52E4@automagic.org>
Content-Transfer-Encoding: 7bit
Errors-To: owner-nanog-outgoing@merit.edu
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
