Subject: Re: Satellites running IP

From: Eric Travis <[email-masked]>
Date: Fri, 14 Jun 2002 17:08:26 -0400

Will, 

>On Thur, 13 June 2002, William Ivancic wrote:

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

Ah - there is just so much of your old baggage here...

You responded:

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

Outside of shuttle/station, the number of platforms that have
flown a SCPS stack for onboard use is the same as those that 
have flown a native Internet protocol stack. Actually, the 
number of "SCPS compliant missions" is double that because 
the native Internet protocol stacks are SCPS compliant 
(This is no accident, as we were the *original* proponents of 
IP deployment on space vehicles - when it made sense to do so)

If your intent was to argue to be that this makes "SCPS"
(again, which includes TCP, UDP, ICMP, etc. and IP) impractical 
for space deployment, please do proceed down this path. The rope 
is approximately the right length...

But none of this is not what Lloyd asked is it?

The answer to Lloyd's question is : 

               Yes

CCSDS's did the pioneering work into onboard IP based networking 
(a free clue - this was the SCPS effort), a stack was flown over 
6 years ago and it did splendidly. Despite these now ancient 
accomplishments, no missions care then, and even now missions just 
don't need IP and wouldn't benefit from it. Maybe someday...

Since spacecraft, link and ground infrastructure are certainly 
capable of supporting IP (as I said, we did it 6 years ago without 
disturbing a thing)... just maybe there are reasons for the dearth 
IP deployment on spacecraft to date?  

Therefore for everyone's benefit, would you please:
   
   Name one mission that failed because of the lack of an 
   IP protocol stack across the spacelink?

   Name one mission that returned less science because
   it wasn't "IP enabled"?

IP on the ground distribution network seems to be satisfying
all the needs so far - when it makes sense to extend it over
the spacelink, it'll happen. 

Spacecraft designers are notoriously conservation folks,
and I don't believe it is difficult to understand why.

I would actually love to see an large IP-based science mission 
flown as we'd learn some interesting things about the communications
problems. I've been waiting about a decade for this. You new-age 
"IP zealots" are latecomers :o)

Please just get over it and let's advocate the spending 
of NASA's funds on actual scientific pursuits rather than 
'kewl things to do with Internet stuff'.

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

Ummm... Why would you think that an application *needs* to call 
socket options just because they exist?  I think you would lots
of commercial applications that don't call TCP options. This 
proves what?

I'd be surprised if most "commercial applications" need to call the 
SCPS specific TCP options. If it would be beneficial to the hosted 
applications, chances are the system would be configured to use them 
by default.

Just to set you straight, every "commercial" TCP application that 
you would ever want to use works just fine over "SCPS-TP" (read: TCP), 
I do it all the time - but I don't expect it really matters or
that anybody really cares.

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

This is certainly new information to me.

Exactly which TCP behavior enhancements *require* SCPS-NP and 
this can not be provided over IP?

> We performed high-speed testing those SCPS options we could test 
> and found no significant performance improvements.

Depending on the conditions under which you tested, that probably
wouldn't surprise me at all. Of course, you aren't claiming that 
your (yet undocumented) tests are conclusive - are you?

Do you have any non-Powerpoint versions of your results?
I'd love to see your results - but more so I'd love to read
the technical paper that generated them.

Often when running my traffic over the Internet, I also see no 
performance increase when I'm running a TCP with the SCPS defined 
enhancements - I see no performance degradation either.

However, when I run across more challenged paths (say those that
include satellite hops), then I certainly do see 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

Hmmm... hopefully the paper will be finished before you present the 
results again. I'm looking forward to reading, commenting on the actual
report. 

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

Well, if someone is foolish enough to stick metal pots into a microwave 
oven, guess who loses? Obviously this makes metal cookware terrible for 
deployment in any kitchen environment.

IMO, you are a bit confused here. Exactly what are you expressing a concern
about here - that it is possible for people to make stupid configuration 
choices?

There are certain configuration options that only make sense if you 
*know* the characteristics of your entire end-to-end path. Isn't it 
obvious to you that choosing pure rate-based transmission obviously 
fits into this category?

The rule is darned simple:
   
     If you do not have an end-to-end bandwidth reservation,
     you are foolish (if not just evil) to configuring 
     flows to run with only rate-pacing.

The reason that an intelligent person would even consider running 
in a purely paced manner is when they have arranged to have reserved 
capacity for the flow *over the entire end-to-end path*.

If it is unreasonable for you to have this guarantee, then it is
unreasonable to be running without any other congestion mechansims
active. 

Given that you have to actually do work to force this configuration
one would guess that a clueful network administrator and end-user 
would make sure that this makes sense with whatever else was going
on in the end-to-end path. 

If you are upset that you can't make queuing decisions based on a 
simple check of a protocol ID rather than observed flow behavior, 
then be happy to have learned something useful outside the parameters
of the satellite universe.

Not all TCP flavors/implementations have the exact same mechanisms - and 
the evolution and divergence in behavior is likely to grow over time. 
Even subtle differences in behavior might want to influence your queuing 
decisions. Further, there is nothing preventing anybody from hacking a 
TCP implementation to exhibit antisocial/greedy behavior. 

Making decisions on *assumed* behavior is ultimately going to be the 
wrong choice and not going to yield the desired results. Police flows
on actual - not assumed - behavior.

A robust network can't "trust" its users to be nice, honest and never
attempt to consume more resources than they are due. Making such decisions
based on a label generated by the end-user entity (even a protocol ID)
is just a bad idea.

Having managed capacity down to the granularity of individual flows 
is quite reasonable in a space mission environment. This is the 
intended use of purely rate limited TCP streams. If someone chooses
to misuse this capability, hopefully the flow will be suitably punished 
for it's non-TCP friendly behavior over shared paths (just as should
any purely rate-paced UDP traffic).

If you are trying to express a desire to be able to transparently 
multiplex returned mission science data with traffic like e-mail 
over a common IP backbone... You would run the very real risk having 
to retransmit the science data over the spacelink because of terrestrial 
congestion... that would be an excellent example of a silly configuration 
decision.

Eric

---

From: Daniel Shell <[email-masked]>
Date: Tue, 18 Jun 2002 08:25:34 -0400

Is SCPS an IETF RFC on a standards track yet?

>congestion... that would be an excellent example of a silly configuration

Dan Shell
Network Architect
CISCO Systems
Gobal Defense and Space Group
Wireless/Mobile Networking/ Satellite
216 643 2422

---

From: Eric Travis <[email-masked]>
Date: Tue, 18 Jun 2002 11:58:55 -0400

> Wireless/Mobile Networking/ Satellite

Hi Dan,

How are things going at Glenn?

I'm confused by what you are asking but you've been 
affiliated with NASA/Glenn and familiarity with SCPS 
goes back long enough for me to remind you (sadly, not 
for the first time):

  SCPS is NOT a protocol, but it is a set of 
  recommendations covering four protocol layers 
  (or 3.5 if you consider security a sublayer).

Lots of things in the SCPS recommendations are 
covered by IETF RFCs that are standards or standards 
track - those things include such obscure things as 
IP, TCP, UDP, ICMP, etc.

You knew all that, however.

If you are specifically asking whether the enhancements 
that contribute to TCP Tranquility are covered by an IETF 
RFC (Standard, Standards Track, Experimental, etc.) - then 
the answer is:

   Nope - nobody every claimed they were, and 
   nobody in known space loses any sleep over it.

But:

  The SCPS options have valid IANA assignments
  (Options 20-23) and the protocol 106 covers
  operation when using the SCPS compressed TCP 
  headers.

  As an aside:
    I happen to pass lots of traffic onto the Internet     
    using TCP-Tranquility and I'm at least as nice as 
    every other TCP flow that I observe.

Had NASA (or any other Space agency) expressed
a non niche interest (backed with the commitment
of necessary resources) in deploying any Internet
derived technologies over the space link and
beyond, the TCP modifications probably would have
been submitted as IDs with the desirement/goal of 
having them someday make Experimental RFCs[*]; 

[*] If I remember correctly, you folks at GRC
    stated several times that you were going to
    take elements of the SCPS recommendations 
    into IETF as part of the ACTS 118X (or Next?)
    activities - maybe I should be asking you
    your question - eh? :o)

As it stands, the question needs to be answered:

Why waste the IETF's time and meeting space on such 
a insignificant problem space (no pun desired) that 
even the mission folk at the space agencies don't 
realm consider more than research?

Does everything need to be covered by an IETF Standard?

As I've said many time before (to you and others):
for a terrestrial environment, the elements of the 
TCP-Tranquility feature set are experimental and tailored 
primarily for the space environment (but work well in any 
lossy tetherless network):

  Pure Rate Pacing is only useful for reserved paths

  Selective Negative Acknowledgements are best for
  environments far more lossy than should be on any
  end-to-end path going over the Internet backbone.

  The Vegas modifications seem to work well in general
  but there still *may* be some nasty edge conditions 
  in networks that would not be typical to the space 
  environment. 

     Any bandwidth estimation techniques are 
     likely to be burdened by the same concerns.

  Separating congestion signaling from loss:
    We've never advocated running a default loss assumption
    other than congestion for anything sharing an end-to-end
    path with a public network (that may have different 
    assumptions and not the necessary machinery to explicitly 
    signal congestion)

  Explicit signaling of loss (trends)
    I seem to remember some traffic polling for interest
    on this topic (this mailing list or end-to-end); 
    This is somewhat of a localized issue and maybe not
    something that needs an IETF standard.

  Link outages are a local problem and probably not something
    that requires an IETF standard.

There is more, need I continue down the list or have I made
the point?

We've never been looking to push these concepts on a wired 
infrastructure, but rather have always advocated using them
in networks which interface to a wired infrastructure.

The most valuable thing that the space community (and anyone else) 
gets from protocol standards are standard *interfaces* - which 
include important things like header formats; 

Further, standardized state machines seem to track across diverse 
environments, but the behaviors not covered by those state machines 
may not.

It is not clear to many of us that the protocol behaviors which are 
best for operating over a diverse terrestrial network are necessarily 
the best behaviors for operation over a resource constrained, time 
bounded delivery infrastructure that is prevalent in most space 
environments (and more than a few tetherless environments)

You've probably been dealing in networking for long enough that you 
probably remember the stupid/evil days of GOSIP - right?

Please don't depress me and claim that everything used in a space 
environment needs to be blessed as an IETF Standard (or Standards 
track) RFC?

Do you think the behavior of all the traffic that you are seeing on 
your networks is strictly covered by (and conforming to) IETF Standards?

Faith in guiding principles *can* lead to many wonderful things,
Dogma *always* leads to disaster, grief and collateral damage...

Now - what was your question again?

Eric

---

From: "Adrian J. Hooke" <[email-masked]>
Date: Tue, 18 Jun 2002 10:04:40 -0700

>Is SCPS an IETF RFC on a standards track yet?

Dan:

Could you perhaps ask your question a bit more precisely? Which of the four 
SCPS protocols would you suggest should be launched on an IETF standards track?

If you are talking about the SCPS flavor of TCP (TCP Tranquility), in what 
context do you ask the question? TCP running between two ground end systems 
over a satellite link, or TCP running from a ground end system to an end 
system onboard a satellite?

If the latter, what would be the benefit to you of IETF standardization of 
TCP Tranquility? If it was on a standards track, would CISCO Systems Gobal 
[sic] Defense and Space Group then be interested in investing corporate 
funds to build a bunch of COTS products to support space missions?

Best regards

Adrian J. Hooke
Manager, DOD-NASA Space Communications Protocol Standards (SCPS) Project
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.scps.org

---

From: Daniel Shell <[email-masked]>
Date: Wed, 19 Jun 2002 08:46:45 -0400

Eric

So the answer is no.

Sorry for the short reply but I am on vacation will get you a more detailed
answer later

Dan Shell
Network Architect
CISCO Systems

---

From: Daniel Shell <[email-masked]>
Date: Wed, 19 Jun 2002 08:48:33 -0400

Adrian

CISCO is not interested in SCPS at this time.
NASA/JPL needs to approach the IETF to make it standard.
So far that has not happened.

At 01:04 PM 6/18/2002, Adrian J. Hooke wrote:
>Could you perhaps ask your question a bit more precisely? Which of the 
>four SCPS protocols would you suggest should be launched on an IETF 
>standards track?
>
>context do you ask the question? TCP running between two ground end 
>systems over a satellite link, or TCP running from a ground end system to 
>an end system onboard a satellite?
>

Dan Shell
Network Architect
CISCO Systems

---

From: Eric Travis <[email-masked]>
Date: Wed, 19 Jun 2002 10:12:41 -0400

Dan,

I need to better understand your question...

   An onboard stack using (any flavor of)
   TCP and IP (version 4 or 6) is part of
   the SCPS recommendations.

   CISCO manufactures equipment that could
   be labeled "SCPS Compliant" if there were
   such a classification.

Based on this, the answer to your question is: Yes

If only there were a market for onboard networking
equipment, CISCO marketing folks could add that to
the marketing brochures :o)

Now, when one asks a rhetorical question, there is
generally a reason - I honestly want to understand
your motivation was for asking a question (in this
forum) where you know the answer.

Please understand that missions will adopt whatever
satisifies their goals (which are not limited to
reducing risk from unfamiliar code-bases, increasing
efficiency and maximizing the amount of science they
can get down per unit of time and radiated power);

These requirements may not mesh with the goals of
the larger IETF, and hence may not justify attempting
to standardize differentiated behaviors for use in
the Internet (where they probably will never be used);

When you have sufficent time, *please* reread my responses
and then let's take this off list.

It is not apparent to me that the discussion that
you want to have is really relevant to the to the
rest of the list...

Enjoy the remainder of your vacation.

Eric