Subject: Satellites running IP

From: David Carek <[email-masked]>
Date: Thu, 13 Jun 2002 14:56:30 -0400

I'm looking for existing satellites that use IP or other Internet 
protocols on board or in their air to ground communications.  If you 
know of any currently flying satellites with such capabilities I'd 
appreciate the references.

We use TCP/IP onboard the shuttle for some systems, but we have a custom 
unreliable protocol for the air to ground segment.  I'd like to identify 
  processors, operating systems, and tcp/ip stacks that have already 
been used in space.

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 14 Jun 2002 13:52:42 +0100 (BST)

> processors, operating systems, and tcp/ip stacks that have already

Chris Jackson presented a paper on SSTL's use of Internet Protocols on
the upcoming disaster monitoring constellation missions at the Second
Space Internet Workshop at Goddard Space Flight Centre, 21-22 May.
This is based on previous work; UoSAT-12 has demonstrated an onboard
TCP/IP stack, although the satellite's not really relying on it for
TT&C:

http://siw.gsfc.nasa.gov/abstracts.html

Really, isn't this what NASA et al. have been developing SCPS for?

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: William Ivancic <[email-masked]>
Date: Fri, 14 Jun 2002 11:51:53 -0400

At 01:52 PM 6/14/02 +0100, Lloyd Wood wrote:
> > protocols on board or in their air to ground communications.  .....
>
>

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

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 14 Jun 2002 17:37:03 +0100 (BST)

> data) SpaceOps 2002 at Houston, TX, October 9-12, 2002 (Powerpoint) file

the rest of the presentations are at
http://siw.gsfc.nasa.gov/agenda.html

(SIW1 has html conversions of all slides online; SIW2 is wholly
powerpoint.  Really, I'd like to see pdfs of the lot - all the
read-anywhere-platform-independent convenience of one, all the
download-a-single-file convenience of the other.)

> difficult.

QoS and queue management shouldn't depend on what traffic is, but on
what traffic does imo - otherwise there's a semantic gap. When
rate-based, SCPS-TP is still sending TCP-style packets, so the
protocol identifier is valid.

L.

> I may be putting a rate-based protocol into a WRED
> queue.  Guess who loses.
>
> Will

---

From: "Adrian J. Hooke" <[email-masked]>
Date: Fri, 14 Jun 2002 11:45:28 -0700

>Really, isn't this what NASA et al. have been developing SCPS for?

Hi Lloyd:

Possibly the first commanding of an in-flight spacecraft operating as a 
node on the Internet (with its own IP address) was done over six years ago 
(January 1996) from Eric Travis's bedroom in Rockville, MD., to STRV-1b in 
geostationary transfer orbit, using SCPS:

http://www.sdl.usu.edu/conferences/smallsat/proceedings/10/sess1/strv.pdf

Since then the SCPS protocol suite http://www.scps.org has been finished 
and is being commercially deployed, e.g.:

http://xiphos.ca/xiplink/index.html

http://www.skipware.com/index.html

http://www.snapgear.com/datasheets/SnapGearSE_Datasheet.pdf

Best regards
Adrian

Adrian J. Hooke
Chairman, CCSDS Subpanel-1F (Advanced Orbiting Systems)
NASA Jet Propulsion Laboratory,
Interplanetary Network Directorate
M/S 303-400, 4800 Oak Grove Drive
Pasadena, California 91109-8099, USA
+1.818.354.3063 OFFICE
+1.818.653.9553 MOBILE
+1 818.354.6290 FAX
http://www.ccsds.org
http://www.ipnrg.org

---

From: William Ivancic <[email-masked]>
Date: Fri, 14 Jun 2002 15:07:18 -0400

>download-a-single-file convenience of the other.)

I'll get around to making PDFs  sometime for the appropriate 
presentations.   I've been using animation in some presentations which 
doesn't translate well to PDF.  But, for some things, animation is very 
effective to make the point.  I don't think the HTML conversion works for 
animations.

>what traffic does imo - otherwise there's a semantic gap.

I agree, but, it takes far more energy to look at per flow information and 
determine the traffic pattern and then put it in a queue.  Assuming that 
certain protocols react in certain ways is much easier and manageable - 
albeit somewhat dangerous.

>  When rate-based, SCPS-TP is still sending TCP-style packets, so the

I disagree.  IMHO, one should not knowingly advertise a protocol number if 
one is not conforming to those protocol characteristics.  Just because the 
header is the same style does not mean that it is the same 
protocol.   IMHO, SCPS should advertise it's own protocol number when 
running rate-based, no congestion control.

Will

=======================================
Will Ivancic
NASA Glenn Research Center
21000 Brookpark Road    MS 54-5
Cleveland, Ohio  44135
Phone +1 (216)433-3494
Fax +1 (216) 433-8705
Yahoo Instant Messenger  ID: ivancic
http://roland.grc.nasa.gov/~ivancic

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 14 Jun 2002 20:26:58 +0100 (BST)

On Fri, 14 Jun 2002, William Ivancic wrote:

> one is not conforming to those protocol characteristics.

well, that would be enough to kill pwe3 work entirely if anyone there
agreed with that.

And that doesn't lead to robust implementations; Savage attacks could
bot be carried out because Savage would be compelled to use a
different protocol number...

> Just because the header is the same style does not mean that it is
> the same protocol.

So I should change the protocol number if I e.g. turn off the Nagle
algorithm? I don't think so; there's a lot of timing slack in the
evolving TCP specifications and a lot of variation in their
implementations.

> Assuming that certain protocols react in certain ways is much
> easier and manageable - albeit somewhat dangerous.

and does not lead to robust implementations.

> IMHO, SCPS should advertise it's own protocol number when

just so that any assumptions made by intermediate systems hold true?
not very e2e of you.

And I don't see
http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.ps
http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.txt
advocating a new protocol number either, even though it modifies the
congestion control mechanisms.

L.

---

From: [email-masked] (Keith Scott)
Date: Fri, 14 Jun 2002 16:59:38 -0400

At 11:51 AM 6/14/2002 -0400, William Ivancic wrote:
>Does anyone know of any commercial applications that call the SCPS-TP options.  SCPS-FP is the only application one I know of.

Xiphos (http://www.xiphos.com) is developing an in-kernel SCPS-TP implementation.  Presumably they'll have some sysadmin-settable 'default' settings (I'd set SNACK and Vegas both on by default, e.g.) and then individual applications can use setsockopt calls if they want to fine-tune things.  The point is, using xiphos' stack, all applications will have access to the SCPS enhancements.

Other companies have also had great success with FreeBSD-based systems, using them to provide high-speed Internet connectivity to remote regions.  A number of remote schools using SCPS gateways to access the internet have provided excellent load testing for us, both in terms of number of simultaneous connections and sheer volume.

>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.

To which TP option are you referring?  If you use NP in conjunction with TP you can do better with respect to compression, as NP specifies things like 1-byte connection identifiers (useful mostly in highly-managed situations where bandwidth is limited, like communicating with spacecraft).  For TP to make use of link outage notifications, it needs some mechanism to generate and relay the notifications (not unlike cumulative ETEN, though the specification is somewhat older).

>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  
>"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 

Interesting.  Slide 14 shows the rate-based theory for a 10Mbyte (80 Mbit) file transfer across a 500msec delay link.  Accounting for just clocking the data (0.8 sec) and one round-trip for some sort of end-of-file acknowledgement (0.5sec) brings the maximum throughput to ~61Mbps.  Perhaps the theoretical maximum was for a longer transfer and only accounted for header (and retransmission) overhead.

What's more curious is why all the rate-based protocols are down around 30Mbps, especially since it's trivial to run SCPS to 60 or 80Mbps, even on 266 to 300MHz-class machines.  You say that the rate-based protocols need more work, but question anyone will immediately ask is: why?  Were there losses at the network interface like you were seeing for NetBSD, or is Solaris just really slow?  What do the tcpdumps show?  Do the various protocols simply pause transmitting periodically, and if so, why?  Are you able to push the average throughput closer to the theoretical value as file size increases?  If not, why not?  Obviously you've done a lot of work understanding and comparing the various protocols; maybe you could let that section of the paper leak out a bit early?

All slide 17 shows is that TCPs that assume congestion back off a lot in the face of loss.  I'm curious as to why you didn't show TCP Vegas with the default source of loss assumed to be corruption.  This is still 'congestion-friendly' as it will slow down when it detects queueing, but performs quite well when confronted with a lightly loaded network with moderate error rates.

As for the warning on the last slide, it should be considered in conjunction with your observation that non-congestion-controlled flows should be used only when they will not overly interfere with congestion-controlled ones.  Unless one specifically chooses to disable all congestion control in SCPS, it uses rate control in conjunction with a congestion control algorithm (VJ or Vegas).  This allows us to ensure that the congestion control algorithm doesn't overrun the bottleneck link rate and auto-congest the network.  When using congestion control, SCPS-TP behaves like, and interoperates with, other TCP implementations, and it is appropriate for it to use IPPROTO 6.  For the case when SCPS-TP is running without congestion control, it should only be used on networks where it will not interfere with congestion controlled traffic.  Note that the CBQ mechanisms of Linux kernels since 2.2 (and the traffic engineering mechanisms of common commercial routers) can appropriately segregate flows.

>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

---

From: "Adrian J. Hooke" <[email-masked]>
Date: Fri, 14 Jun 2002 13:55:45 -0700

At 02:56 PM 6/13/2002 -0400, David Carek wrote:
>protocols on board or in their air to ground communications.  If you know 
>of any currently flying satellites with such capabilities I'd appreciate 
>the references.

David: what problems are you trying to solve, and why?

At 04:02 PM 6/14/2002 -0400, William Ivancic wrote:
>??? I don't understand the comment.  I'm taking SCPS-TP end-to-end, not 
>SCPS-TP as a gateway.

And in what operational configurations are you trying to solve them?

///adrian

---

From: William Ivancic <[email-masked]>
Date: Fri, 14 Jun 2002 16:02:43 -0400

>well, that would be enough to kill pwe3 work entirely if anyone there

If I read the workings of this group correctly, it is more like gateway 
implementations were one knows the network between the gateways and is 
controlling things appropriately.

>congestion control mechanisms.

If I interpreted the draft correctly, congestion control is still used 
here, just modified.

Will

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 14 Jun 2002 21:42:45 +0100 (BST)

> controlling things appropriately.

the network between those gateways is an IP cloud, with all the
possibility for reordering, jitter, loss etc. that that implies. In
particular, the timing expectations for the tunnelled protocol traffic
may be imperfectly met and outside the specification of the emulated
network and its applications - and those changes in timing form the
analogy with changes in TCP timing here.

Timing changes, but things are still made to work.

> ??? I don't understand the comment.  I'm taking SCPS-TP end-to-end, not

likewise.

You stressed the importance of preserving e2e behaviour, and gave the
example of something in the middle was inspecting protocol type and
using assumptions about expected e2e bahviour for queuing behaviour at
that point. Dangerous, as you said.

(and a similar argument doesn't work for UDP, or indeed other
 protocols whose behavior is not specified as TCP's is.)

> If I interpreted the draft correctly, congestion control is still used

So how much modification do you demand before you define it as 'no
longer congestion control' and demand a new protocol type?

I've given a number of examples of modified timing where the protocol
type/identity/bits on the wire remain the same, and given the general
slackness of TCP system timers and their specification in general I
think it's a moot point.

Especially in an Internet where uncontrolled UDP traffic can run amok,
and where the same intermediate fairness/limiting/queuing mechanisms
to control such traffic can also be applied to TCP traffic. Every UDP
application behaves differently with the UDP packets it sends; every
UDP application should get its own protocol type!

L.

---

From: David Carek <[email-masked]>
Date: Mon, 17 Jun 2002 11:04:20 -0400

> David: what problems are you trying to solve, and why?
...
> And in what operational configurations are you trying to solve them?

I'm trying to identify available options for an IP compliant LEO science 
satellite, including susbsystem communications on-board as well as 
command, control, and telemetry to/from ground.  Two communications 
paths would exist: One direct LEO to ground; and one to ground via 
TDRSS(GEO).

A collegue and I have been tasked to write a communications architecute 
paper for such a system, that uses only Internet protocols end to end. 
Obviously, mission requirements and budget would ultimately define what 
is used on a real mission, but this is just a cut at a generic mission.

The problem is, that I keep coming up with more reasons not to use 
Internet protols, than reasons to use them.  Having worked on flight 
software I know the value in minimizing the SLOC count and complexity of 
flight code.  I supposed if a "flight qualified" stack were available, 
it would be much more readily accepted. I personally like the SCPS 
specifications, but I've been asked to try to identify options using 
only current Internet standards.  This creates a problem, in that some 
application level protocol will be necessary ... so I'm kind of back in 
the non-standards realm.  That's why I wanted to see if anybody has 
already done this, and to what extent.

---

From: Colin Paul Gloster <[email-masked]>
Date: Mon, 17 Jun 2002 16:47:22 +0100 (IST)

On Mon, 17 Jun 2002, David Carek wrote:
"[..]

The problem is, that I keep coming up with more reasons not to use 
Internet protols, than reasons to use them. [..]"

David,
Could you please indicate what some of these reasons would
be?
Regards,
Colin Paul Gloster

---

From: David Carek <[email-masked]>
Date: Mon, 17 Jun 2002 13:36:01 -0400

> Could you please indicate what some of these reasons would

Sure

False Perception of Standards - There is a perception that using 
Internet standards is actually a single standard, when in fact it is a 
collage interpretations and implementations of RFC's.  I doubt any two 
TCP/IP stacks implement the standards the same way.  The standard is 
actually the least common demoninator of the various implemtations.

Flight Qualification (Increased Potential for Software Faults) - Adding 
15000 lines of code that someone else wrote to your satellite creates a 
black box of software that is extremely difficult if not impossible to 
thouroghly test.  I have had a bad experience with one stack we used on 
a shuttle experiment that would hang the system when it recieved any 
non-tcp packets.  This was a older real-time embedded system (that shall 
remain nameless).  It should have been impossible for the TCP/IP module 
to completely hang the system ... but it did.
Increased software = increased complexity = increased chance for errors

Other potential problems include:

Technology Lag/Obsolescence (satellite technology generally 5-10 years 
behind terestrial)
RTOS support
Deterministic Timing Requirements (onboard systems)
Performance Limitations of Rad Hard processors
Reliability (TCP reliability might not be good enough)

I've got others ... but that's a start.

This isn't to say these issues can't be overcome.  They are just 
engineering problems and entirely workable. And certianly a system that 
is compatible with Internet systems is definitely beneficial to the 
overall communications architecture ... especially when integrating into 
the  ground systems.