RE: Re IP over Satellite

Hans Kruse <hkruse1@ohiou.edu> Tue, 16 June 1998 23:21 UTC

X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcppep@lerc.nasa.gov using -f
X-Sender: kruse@oak.cats.ohiou.edu
Message-Id: <v0300782cb1acad9d0229@[132.235.75.17]>
In-Reply-To: <01BD9924.3C3328A0.anthony.m.hughes@cdc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 16 Jun 1998 19:21:59 -0400
To: "tcppep@lerc.nasa.gov" <tcppep@lerc.nasa.gov>, "tcp-over-satellite@achtung.sp.trw.com" <tcp-over-satellite@achtung.sp.trw.com>
From: Hans Kruse <hkruse1@ohiou.edu>
Subject: RE: Re IP over Satellite
Sender: owner-tcppep@lerc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1297
Lines: 29

At 12:42 -0700 6/16/98, Tony Hughes wrote:
>I am guessing here, but I would say it would work over geo, meo, etc
>depending on your IP stack.  If you have a large enough window size and you

To be fair, _any_ window size will "work".  The amount of bandwidth that
can be utilized does depend on the window.  So the window is an issue if
one user wants to transfer a non-trivial amount of data and has uncontested
access to a fair amount of bandwidth.

>generate a long enough timeout value before you retransmit, you should be
>OK.  From what I have found in some of my IP books with no reference to
>IETF standards, the timeout value can be anything.  Of course you would
>want it to be longer than your round trip time + processing but not so long
>that it has a negative effect on transmission, especially since the
>connection isn't all that cheap.

In modern TCP stacks the timeout values are updated based on round trip
time measurements, so they _should_ self-adjust to the long delay.  Some
stacks have bugs in this area.  They still work, but not as efficient as
they should.



Hans Kruse, Associate Professor and Director
McClure School of Communication Systems Management, Ohio University
9 S. College Street
Athens, OH 45701
614-593-4891 voice,  614-593-4889 fax,  hkruse1@ohiou.edu