<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
James L. Rash wrote:
<blockquote cite="mida05200f5dc06d42c40274@%5B128.183.223.239%5D"
type="cite">
<style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style>
<title>Re: [Sis-csi] Green book
thoughts</title>
<div>At 6:06 PM -0700 4/19/06, Scott Burleigh wrote:</div>
<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 color="#000080" face="Arial">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="">....</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?</blockquote>
<div>Scott,</div>
<div><br>
</div>
<div>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></div>
<div><br>
</div>
<div>My apologies if I have misinterpreted your thesis, and I am
happy
to be corrected.</div>
</blockquote>
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.<br>
<br>
Scott<br>
</body>
</html>