Subject: The (perceived) requirement to be an IETF Standard

From: Eric Travis <[email-masked]>
Date: Wed, 19 Jun 2002 17:15:44 -0400

Dan,

I read your response to Adrian (below) and I'm still struggling... 
but I'm trying to learn.

While you've been a bit cryptic (possibly because you are on 
vacation) I now think that a discussion of the perceived requirement
for IETF standardization of things for niche communities is an 
appropriate discussion for this list.

While I don't imagine there is *any* viable business case 
for CISCO to divert energy or resources to supporting any 
space-based protocols/hardware in their mainstream product 
line, should I interpret your response to Adrian to indicate:

  CISCO *only* implements protocols that are IETF standards?

  CISCO will find a business case to support space-based
  protocols if they are IETF standards?

Does your work at GRC lead you to believe that there is
a large market for space-based networking? Large enough
to sustain a working community of interest within the 
IETF?

The point of the parent thread is TCP - does CISCO make many 
end-user devices that would be relevant to this discussion?  

Are you planning on building middle-boxes - in which case the 
dynamics of the discussion changes a lot and the need for IETF 
standardization of the behavior what goes over the *private* links 
and is terminated prior to the public network becomes even less 
obvious...

For this environment, I'd imagine that any business decisions 
would *not* be based on whether a frob is an IETF Standard, 
but rather there is a sufficiently large market to recover 
development and support costs while eventually turning a profit.

You keep asserting that:

  "NASA/JPL needs to approach the IETF to make it standard"
  (there is no 'it' appropriate here, a 'them' perhaps)

My sincere question to you is: Why?

I'm not the sharpest crayon in the box, so could you please
explain to me what exactly will be gained by the communities
of interest by going through the justifiably rigorous and 
lengthy process of making *these* protocol enhancements 
IETF standards? 

They are already standards (several times over)...

Also, why might the IETF care to bother standardizing what 
is running on mostly closed/private networks?

If you can make a good case, then perhaps *we* can convince
NASA to divert some research funds to support that effort.
The money is there, but it would need to be reprogrammed
to support the effort.

I'm reluctantly up for the challenge, but I need your help 
making a convincing case to the folks that matter at NASA HQ.

The topic will keep until you return to work, but if you can
convince me that it is necessary, I'd like to pursue this within 
NASA if at all possible.

Eric

> 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: 
> >At 08:25 AM 6/18/2002 -0400, Daniel Shell wrote: 
> >>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 
> > 
> 
> Dan Shell 
> Network Architect 
> CISCO Systems 
> Gobal Defense and Space Group 
> Wireless/Mobile Networking/ Satellite 
> 216 643 2422

---

From: Daniel Shell <[email-masked]>
Date: Mon, 24 Jun 2002 08:51:18 -0400

Eric

This my opinion on SCPS.

If NASA/JPL decide that this is SCPS and it family the "space standard"
then do it.  Do not expect much commercial support for a new IP protocol.

Also there are lot of options using IP that NASA has not even explored and 
should be look at
such as RTP, and other enhancements ongoing in the IETF.

Also if SCPS and its family is put on the RFC standards track if give this 
protocol some legitimacy
with every one who is going to use it.

So why not?

Dan Shell
Network Architect
CISCO Systems

---

From: Eric Travis <[email-masked]>
Date: Mon, 24 Jun 2002 09:46:38 -0400

Dan,

> then do it.  Do not expect much commercial support for a new IP protocol.

I'm afraid that you are mistaken...

There is *nobody* advocating a "new IP protocol", IPv4 and IPv6 do
nicely with
the identified space extensions - if that's what a mission eventually
chooses
to use.  

I think you will find that all the testing that Will had previously
referenced
was over IPv4.

Commercial support means different things to different "industries";
The space community is well supported by industry, it's just that it may
not be yours. Diversity is generally a good thing.

The overlap between the traditional Internet economy and the spaceborne
community is likely to be terribly small except when the data hits a
groundstation - then it is more of a traditional networking environment.

Spacecraft have been operating a long time without commercial support
from "Internet-related" companies... The ability to purchase flight
qualified hardware/software from companies such as your own would be
nice, but it is hardly a critical requirement.

So, while it is a cool idea to stitch up end-to-end connections from an
orbiting instrument to a principle investigator in Lyon, a compelling
reason
to do so (economic or technical) has yet to surface.  In time, it may still
come - until then, mission architects always have had that option.

BTW: SCPS is not a "NASA/JPL" thing;

   Please let's try and get past these attempts at marginalizing, OK?  
   You are inadvertantly insulting more people that you might imagine
   who have never been affiliated with NASA, let alone JPL.

> Also there are lot of options using IP that NASA has not even explored
> and should be look at

There is always the promise of something brighter on the horizon.

RTP is not really a suitable solution for reliable bulk data transfer.
I would have expected a reference to something like SCTP in such an
argument.
 
Surely this isn't all just a case of "Not Invented Here"...

> Also there are lot of options using IP that NASA has not even explored
> and should be look at

Well... the space community (the folks who *are* intended to use the SCPS
recommendations) has already "given them legitimacy" by standardizing them;
You may not think much of the standards organizations (plural) that
cover the community of interest - and that is your right.

> So why not?

Lack of return on investment?
  
Lack of forseeable benefit to the IETF (what motivation is there
for the an IETF area director to put this on an agenda)?

Lack of forseeable benefit to the space community?

I'm afraid that if this is as cogent the argument gets for bringing niche
community requirments (how many spacecraft get launched each year that are
not telecommunication bent-pipes?) then we're not going to get very far in
convincing those who capable of supporting an IETF effort.

I'm still faced with the question:

Why?

Based on your response, I can only conclude that there is no compelling
need/benefit for the IETF to attempt to standardize what happens in
niche communities.

Terrestrial wireless will eventually have a huge impact on the Internet,
but communications to space based entities? Not in the foreseeable future.

Eric

---

From: David Carek <[email-masked]>
Date: Mon, 24 Jun 2002 11:28:45 -0400

Daniel Shell wrote:
> Also if SCPS and its family is put on the RFC standards track if give 
> this protocol some legitimacy

My guess is that the market won't demand it.  Standards seem to benefit 
the industry when there are sufficient quantities and companies involved 
to warrant a standard. I doubt the space segment will ever have similar 
market forces that drive the terrestrial side.  Also, the needs that 
govern space qualified hardware and software are very different than the 
terrestrial market, so there may be a culture clash trying to develop 
these standards through the IETF (this is just a total guess). If the 
SCPS spec were part of the IETF standard, I doubt it would cause 
terrestrial vendors to start supporting it.

That's not to say that the IETF standards track would be a bad idea for 
the space segment, I just don't think there's a driving market force 
that will make it happen.  SCPS is a very nice specification to handle 
the limitations of space communications.  If a few flight qualified 
implementations can be developed, it could still benefit the space 
segment.  It's mostly roll your own right now.

---

From: "Adrian J. Hooke" <[email-masked]>
Date: Mon, 24 Jun 2002 08:52:24 -0700

>with every one who is going to use it.

Dan: the SCPS variant of TCP/UDP - "TCP Tranquility" -  exists as:

a) An International Standard (ISO 15893:2000) and;
b) A US Department of Defense Military Standard (MIL-STD-2045-44000).
c) A NASA Preferred Technical Standard

We are interested in hearing from other people on this list: would putting 
Tranquility through the RFC process further increase its "legitimacy" as 
far as you are concerned? Does anyone out there feel inhibited about 
experimenting with SCPS capabilities by the current status?

>So why not?

Time and money, both of which are in short supply. What would be the return 
on investment?

///adrian

[ BTW, as Eric notes, the SCPS capabilities are not a "NASA/JPL" thing. 
They exist as full NASA Technical Standards that are approved by the NASA 
Chief Engineer (http://standards.nasa.gov/ ). That means that, unlike the 
products of NASA's Research Centers, they are the preferred standards for 
use on NASA's flight missions. They are programmatically managed by the 
Office of Space Communications within the Office of Space Flight at NASA 
Headquarters in Washington DC. ]