Re: Satellites running IP

William Ivancic <wivancic@grc.nasa.gov> Fri, 14 June 2002 15:51 UTC

Message-Id: <4.2.1.20020614113450.00bcec60@popserve.grc.nasa.gov>
X-Sender: caivanc@popserve.grc.nasa.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1
Date: Fri, 14 Jun 2002 11:51:53 -0400
To: Lloyd Wood <L.Wood@eim.surrey.ac.uk>, David Carek <David.A.Carek@grc.nasa.gov>
From: William Ivancic <wivancic@grc.nasa.gov>
Subject: Re: Satellites running IP
Cc: tcpsat@grc.nasa.gov
In-Reply-To: <Pine.SOL.4.43.0206141340090.6324-100000@artemis.ee.surrey. ac.uk>
References: <3D08EADE.7000006@grc.nasa.gov>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_4754627==_.ALT"
Sender: owner-tcpsat@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 3740
Lines: 96

At 01:52 PM 6/14/02 +0100, Lloyd Wood wrote:
>On Thu, 13 Jun 2002, David Carek wrote:
>
> > I'm looking for existing satellites that use IP or other Internet
> > protocols on board or in their air to ground communications.  .....
>
>
>Really, isn't this what NASA et al. have been developing SCPS for?
>
>L.

Does anyone know of someone "flying" an onboard SCPS stack?

Does anyone know of any commercial applications that call the SCPS-TP 
options.  SCPS-FP is the only application one I know of.

Does anyone know of a commercial vendor implementing a SCPS-NP router?  To 
take full advantage of some options in SCPS-TP, one needs as SCPS-NP router.

We performed high-speed testing those SCPS options we could test and found 
no significant performance improvements.
The report is being written, but not yet available.  The results were 
presented as the 2nd Space Internet Workshop in June and will be
presented at SpaceOps 2002.

http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html

Under PRESENTATIONS

"SCPS-TP, TCP and Rate-Based Protocol Evaluation," (Includes multi-flow 
data) SpaceOps 2002 at Houston, TX, October 9-12, 2002 (Powerpoint) file 
size 951,808 bytes


By the way, SCPS-TP advertises TCP's protocol number for reliable transport 
protocol selections.  It does this even if the pure rate-based transmission 
is used.  IMO, this is terrible as it  make QoS and queue management very 
difficult.  I may be putting a rate-based protocol into a WRED 
queue.  Guess who loses.

Will