[45920] in North American Network Operators' Group
Re: Satellite latency
daemon@ATHENA.MIT.EDU (Mark Allman)
Wed Feb 27 23:03:48 2002
Message-Id: <200202280401.XAA23506@lawyers.grc.nasa.gov>
To: "Tony Hain" <alh-ietf@tndh.net>
From: Mark Allman <mallman@grc.nasa.gov>
Reply-To: mallman@grc.nasa.gov
Cc: "Jim Mercer" <jim@reptiles.org>,
"Steven M. Bellovin" <smb@research.att.com>,
"Tim Devries" <zsolutions@cogeco.ca>, nanog@merit.edu
Date: Wed, 27 Feb 2002 23:01:04 -0500
Errors-To: owner-nanog-outgoing@merit.edu
> > if you adjust the window size on the sending and receiving
> > systems, you can improve this, but this solution is impractical,
> > as you would need to get everyone on the internet (or at least
> > all of the webservers and websurfers you are servicing) to make
> > adjustments to their local TCP stack.
>
> The receiver is the one that informs the sender how large of a
> window it can accept, so it can be practical for a subscriber
> installation. It wouldn't be a good idea to park a bunch of
> servers behind one of these links, but any receiving node that set
> its TCP receive window to 2x the byte/sec capacity of the link
> should see decent throughput.
No, you need to set things on both sides. The sender has to buffer
data until it is ACKed in case it needs to retransmit. So, its
buffer needs to be as big as the advertised window or the sender
buffer will effectivly limit the advertised window.
allman
--
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/
