[Sis-csi] Green book thoughts

[Scott Burleigh]

James L. Rash wrote:

> At 6:06 PM -0700 4/19/06, Scott Burleigh wrote:
>
>> Lee.Neitzel at EmersonProcess.com 
>> <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20060420/dc7db3ba/attachment.html