<!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. 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?<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. 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"<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, "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.</blockquote>
<div><br></div>
<div>Scott,</div>
<div><br></div>
<div>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.</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 20771<br>
301-286-5246 (voice) 301-286-1768 (fax)<br>
</div>
</body>
</html>