<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<a class="moz-txt-link-abbreviated" href="mailto:Lee.Neitzel@EmersonProcess.com">Lee.Neitzel@EmersonProcess.com</a> wrote:
<blockquote
cite="midD7D5E451660C3342AFB97611174B775004B17CB0@usaus-exm01.na.emersonprocess.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [Sis-csi] Green book thoughts</title>
<o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City">
<o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style></o:SmartTagType></o:SmartTagType>
<div class="Section1">
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;">As
you know, there are significant fixed and variable costs associated
with design,
implementation, testing, and deployment of each layer protocol.</span></font></p>
</div>
</blockquote>
In my mind, this is the key point in this discussion.<br>
<br>
Keith H. is clearly right that UDP is entirely entirely appropriate for
applications where data completeness is not important. He's also
clearly right that UDP and UDP-like transmission has historically been
used for operations of nearly all spacecraft mission (that I can think
of), where all communications have been between The Spacecraft and The
Ground. I agree with him and with David that the simplicity of that
model in that environment has proven to be very valuable, even though
it means that -- if you care about data completeness -- you need some
sort of manual command procedure to effect the retransmission of data
that got lost or corrupted in transmission from the spacecraft to the
ground.<br>
<br>
The question, I think, is whether or not that model is appropriate for
communications among the elements of a cislunar network, such as the
fleet of Constellation vehicles. The topology we're contemplating in
that environment would not be pairwise communication between The
Spacecraft and The Ground, but rather multi-hop communication through
relays (e.g., relay satellites) functioning as IP routers.<br>
<br>
Again, if data completeness is not important then UDP is perfectly
adequate for conveying data throughout that network. But if data
completeness is important some of the time, then one or more
retransmission mechanisms are needed in the protocols; I haven't yet
heard anyone suggest that manually commanded retransmission would be a
cost-effective way of assuring completeness of data exchange among
multiple surface rovers and orbiters at the moon.<br>
<br>
As Lloyd points out, UDP is a terrific platform for building new
protocols on: it imposes little overhead, it does message delimitation,
it provides port numbers for multiplexing of higher-layer protocols, it
provides checksums (if you want them), and the standard socket library
makes implementation very straightforward. But there are significant
fixed and variable costs associated with the design, implementation,
testing, and deployment of each layer of protocol. I would say that's
particularly true of protocols that do retransmission, which if done
well is not as easy as it sounds. This suggests that if an existing,
proven transport protocol provides retransmission then you should use
it rather than reinvent retransmission yourself, unless you've got a
good reason not to.<br>
<br>
I think we all agree that there are some good reasons not to use TCP in
all cases where you need a retransmitting protocol, so there are
clearly cases where it makes more sense to use something else -- very
likely something built on top of UDP, because UDP is such a fine
platform for building new protocols on. But it remains true that each
such new protocol costs money. If retransmission were reinvented in
every application-layer protocol flown on every spacecraft:<br>
<br>
a. Each one would impose significant additional mission cost.<br>
<br>
b. Some of them would have bugs that wouldn't be found in testing
prior to flight, imposing significant additional mission risk.<br>
<br>
c. None of them would be interoperable. In order to interoperate,
spacecraft would have to fly multiple protocols at this layer of the
stack, further increasing mission cost and complexity (and therefore
risk).<br>
<br>
d. Each one would pose a potential congestion threat to the network
since, as experience in the Internet has shown us, retransmission
procedures that aren't carefully designed with congestion in mind will
increase it. And congestion will indeed be possible, because this is a
network, with routers and "trunk lines", and not just a set of pairwise
communication links.<br>
<br>
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>
<br>
Scott<br>
</body>
</html>