[Sis-csi] Green book thoughts

[James L. Rash]

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:
>>
>>><mailto:Lee.Neitzel at EmersonProcess.com>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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20060420/0675664b/attachment-0001.html