<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [Sis-csi] Green book
thoughts</title></head><body>
<div>At 8:05 AM -0700 4/20/06, Scott Burleigh wrote:</div>
<blockquote type="cite" cite>James L. Rash wrote:<br>
<blockquote type="cite" cite>Re: [Sis-csi] Green book
thoughts</blockquote>
<blockquote type="cite" cite>At 6:06 PM -0700 4/19/06, Scott Burleigh
wrote:<br>
<blockquote type="cite" cite><a
href="mailto:Lee.Neitzel@EmersonProcess.com"
>Lee.Neitzel@EmersonProcess.com</a> wrote:<br>
<blockquote type="cite" cite>RE: [Sis-csi] Green book thoughts<br>
</blockquote>
<blockquote type="cite" cite><font face="Arial" color="#000080">As you
know, there are significant fixed and variable costs associated with
design, implementation, testing, and deployment of each layer
protocol.</font><br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>In my mind, this is the key point in this
discussion.<br>
</blockquote>
<blockquote type="cite" cite>....<br>
</blockquote>
<blockquote type="cite" cite>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.&nbsp; The architecture needs to support the
insertion of alternatives to TCP where they are needed, but the fewer
the better.&nbsp; Suppose we leave it at that?<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>Scott,</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>If I understand what you have been
saying, it boils down to the following.&nbsp; We as architects should
aim towards saving the mission community from making costly and/or
dumb choices about rolling their own re-transmission protocols.&nbsp;
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
&quot;architecting&quot;<b>.</b></blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>My apologies if I have misinterpreted
your thesis, and I am happy to be corrected.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>As Adrian points out, &quot;disallow&quot;
isn't quite the right word here.&nbsp; &quot;Discourage&quot; is
better, and more specifically I would say &quot;discourage&quot; 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.&nbsp; People will always make
poor technical decisions for arguably irrational reasons; it's not the
function of the Space Communications Architecture to prevent that.&nbsp;
The best we can do is address in advance any arguments that would
otherwise have a defensible technical basis.</blockquote>
<div><br></div>
<div>Scott,</div>
<div><br></div>
<div>Thanks -- makes sense.&nbsp; 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.&nbsp; But
success will be more likely if mission designers actually have enough
relevant information on which to base decisions.&nbsp; We can provide
such information for decision-making and produce something far more
valuable and effective than a bare list of recommendations.</div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div><br>
James L. Rash<br>
Building 23, Room E403</div>
<div>Code 588 -- Advanced Architectures and Automation Branch</div>
<div>NASA Goddard Space Flight Center<br>
Greenbelt, MD&nbsp; 20771<br>
301-286-5246 (voice)&nbsp;&nbsp;&nbsp;&nbsp; 301-286-1768 (fax)<br>
</div>
</body>
</html>