Re: Re IP over Satellite

Hans Kruse <hkruse1@ohiou.edu> Thu, 18 June 1998 13:59 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: <v03007835b1aecd03c03e@[132.235.75.17]>
In-Reply-To: <af959124.35884686@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 18 Jun 1998 09:59:37 -0400
To: tcppep@lerc.nasa.gov, tcp-over-satellite@achtung.sp.trw.com
From: Hans Kruse <hkruse1@ohiou.edu>
Subject: Re: Re IP over Satellite
Cc: Telford001@aol.com
Sender: owner-tcppep@lerc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1166
Lines: 27

At 18:43 -0400 6/17/98, Telford001@aol.com wrote:
>With careful link layer and router configuration
>good performance was possible.  Without such
>careful configuration, no matter how much TCP
>parameters were tweaked, TCP performance
>would be miserable.  The local link considerations
>far outweighed the effect of end-to-end
>TCP parameter tweaking.

Good point, and one we (I think) inserted into the "Standards Mechanisms"
draft.  All the work being done on TCP and TCP-based applications (the
"tweaking") assumes that the link layer protocol has already been optimized
to utilize the channel.  This is in somes ways an easier problem, since -
as you point out - the layer 2 protocol terminates (or can terminate) at
the ends of the satellite link.

What makes TCP issues so thorny is the end-to-end assumption inherent in
layer 4 protocols.  The satellite link is ideally supposed to be unaware of
TCP; in the real world we get into the PEP issues.


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