[Sis-csi] Green book thoughts

[Donald P Olsen]

Greetings

Let me weigh in on this one.  Any attempt to "dissallow"  alternatives 
will be ignored.  This is true because CCSDS recommendations are just 
that, recommendations, and not requirements.

Don



"James L. Rash" <James.L.Rash at nasa.gov> 
Sent by: sis-csi-bounces at mailman.ccsds.org
04/20/2006 12:23 PM

To
sis-csi at mailman.ccsds.org
cc

Subject
Re: [Sis-csi] Green book thoughts






At 8:05 AM -0700 4/20/06, Scott Burleigh wrote:
James L. Rash wrote:
Re: [Sis-csi] Green book thoughts
At 6:06 PM -0700 4/19/06, Scott Burleigh wrote:
Lee.Neitzel at EmersonProcess.com wrote:
RE: [Sis-csi] Green book thoughts
As you know, there are significant fixed and variable costs associated 
with design, implementation, testing, and deployment of each layer 
protocol.
In my mind, this is the key point in this discussion.
....
So in this architecture document I think we want *not* to encourage every 
flight software manager to look at each mission as yet another opportunity 
to demonstrate what fools the designers of TCP were.  The architecture 
needs to support the insertion of alternatives to TCP where they are 
needed, but the fewer the better.  Suppose we leave it at that?
Scott,

If I understand what you have been saying, it boils down to the following. 
 We as architects should aim towards saving the mission community from 
making costly and/or dumb choices about rolling their own re-transmission 
protocols.  We should accomplish this by (a) developing/adopting a small 
set of re-transmission protocols that will meet 
all-but-the-most-usual-mission-needs for the future and (b) disallow 
future missions from using any other re-transmission protocols over the 
infrastructure we are "architecting".

My apologies if I have misinterpreted your thesis, and I am happy to be 
corrected.
As Adrian points out, "disallow" isn't quite the right word here. 
"Discourage" is better, and more specifically I would say "discourage" in 
the sense of providing such stable and effective functionality in the 
supported protocols that missions don't have any sound technical reason to 
*want* to invent their own.  People will always make poor technical 
decisions for arguably irrational reasons; it's not the function of the 
Space Communications Architecture to prevent that.  The best we can do is 
address in advance any arguments that would otherwise have a defensible 
technical basis.

Scott,

Thanks -- makes sense.  It also implies a means for measuring success: the 
ratio of the number of missions that adopt the preferred protocols to the 
number of missions that don't.  But success will be more likely if mission 
designers actually have enough relevant information on which to base 
decisions.  We can provide such information for decision-making and 
produce something far more valuable and effective than a bare list of 
recommendations.
-- 


James L. Rash
Building 23, Room E403
Code 588 -- Advanced Architectures and Automation Branch
NASA Goddard Space Flight Center
Greenbelt, MD  20771
301-286-5246 (voice)     301-286-1768 (fax)
_______________________________________________
Sis-CSI mailing list
Sis-CSI at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20060426/504fa406/attachment.html