<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<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"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="State"/>
<!--[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";
color:black;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:Arial;
color:navy;}
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>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=white lang=EN-US link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>The answer to the question is yes.
However, software downloads and uploads are done using the request/response
model. This is not as efficient as the stream model, but simplifies the code
base that needs to be installed in a device. It was a tradeoff that could
have gone either way. In this case, cost won over performance since this
operation is rarely performed. It is the only bulk transfer mechanism that is
used. The other transfers that you mention are more like file transfers between
host machines (e.g. PCs/Workstations) and do not involve controllers or
devices. Host to host comms generally use commercially available protocols,
including the OPC protocols. Of course, OPC is based on DCOM today, but it
migrating from that to a platform independent model. <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
color=black face="Times New Roman"><span style='font-size:12.0pt;color:windowtext'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 color=black face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight:bold'>From:</span></font></b><font
size=2 color=black face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma;
color:windowtext'> sis-csi-bounces@mailman.ccsds.org
[mailto:sis-csi-bounces@mailman.ccsds.org] <b><span style='font-weight:bold'>On
Behalf Of </span></b>Carl A Sunshine<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, April 21, 2006 12:43
PM<br>
<b><span style='font-weight:bold'>To:</span></b> sis-csi@mailman.ccsds.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Sis-csi] Green book
thoughts</span></font><font color=black><span style='color:windowtext'><o:p></o:p></span></font></p>
</div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'><o:p> </o:p></span></font></p>
<div>
<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Good summary of three types of
"real-time" interaction. But doesn't the process control
industry also need reliable transfer of larger blocks of data, over many
packets? Like a software update, or design data file, or activity logs?
That is where TCP is probably most suitable.</span></font><font color=black><span
style='color:windowtext'><o:p></o:p></span></font></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 color=black
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma;color:windowtext'>-----Original
Message-----<br>
<b><span style='font-weight:bold'>From:</span></b>
sis-csi-bounces@mailman.ccsds.org [mailto:sis-csi-bounces@mailman.ccsds.org]<b><span
style='font-weight:bold'>On Behalf Of </span></b>Lee.Neitzel@EmersonProcess.com<br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, April 20, 2006
9:05 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Scott.Burleigh@jpl.nasa.gov; sis-csi@mailman.ccsds.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Sis-csi] Green book
thoughts</span></font><font color=black><span style='color:windowtext'><o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Chris Taylor wrote in a separate response
"</span></font><font size=2 color=black face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New";color:windowtext'>I guess, I
come down of the side of Scott, do not jump to the conclusion that TCP will be
necessary. Take a better look at the link characteristic to determine what
recovery may be necessary".<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=black face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New";color:windowtext'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I agree with this completely. Again,
referring to the process control industry, the assessment was made that there
are three types of communication that have to be supported, request/response,
publisher/subscriber, and event reporting. The assessment continued as follows:<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>1) Request/response would use
connectionless services (e.g. UDP) and rely on the Application Layer to provide
for flow control and recovery. The mechanisms designed were very simple. The
responder is configured with a MaxOutstanding count that specifies how many
requests it can be processing simulataneously for each requester. From the
requester's viewpoint, this is translated to mean how many the requester can
have outstanding at any point in time. Recovery is performed by the requester
when it doesn't receive a response within a given timeout period. In the
request/response model, it is not important if the loss occurred on the request
transmission, in the responder itself, or on the response transmission. All
requests are designed to be idempotent so that a reissue of a request that was
already handled by the responder would not cause the responder to
inappropriately apply a transaction twice. Discussions were held that talked
about having a transaction id that the responder could use to know if it
already processed a request, but that led to too much complexity. However,
simple sequence numbers are used in some application layer protocols to perform
this function rather than a more complicated transaction id scheme. <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>2) Publisher/subscriber is used to send
perishable data, typically measurement data (sensor data), on a cyclic basis.
No retransmission is required here because the new data obsoletes the old data.
The only requirement is that the subscriber is able to detect missed messages
or messages that were duplicated by the comms system. Simple sequence numbers
are used to detect gaps, while the cyclic nature of the transmissions allows
the subscriber to detect, within a deadband, when a message should have been
received.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>3) Event reports are used to send events
as they occur. Events must not be lost, and are therefore, "latched"
when they are sent. If they are not confirmed (acked) by the subscriber using a
request/response exchange within a specified timeout period, they are
retransmitted. <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>For application layer protocols that have
to deal with scalablity issues many of the AL-PDUs can contain multiple
requests, responses, published data, and event reports.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>This partitioning of the <st1:State w:st="on">AL</st1:State>
into these three interaction models has served the process industries quite
well, because it recognizes differences in comms patterns, and allows simple
mechanisms to be developed for each, rather than trying to wrap them all into a
single comms model and develop a single flexible <st1:place w:st="on"><st1:State
w:st="on">AL</st1:State></st1:place> protocol.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>One more note on the use of TCP. TCP is a
stream protocol that is good for transferring undelimited data. It is not as
well suited for transferring modular data, such as requests & responses,
published data, and events. For this reason, it makes using it for these
purposes more complicated.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I am not suggesting that the three models
described above are directly applicable to the space to ground environment, but
I am suggesting that the procedure of identifying the fundamental interaction
models are. I would have to believe, though, that some variation of these
models is applicable.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
color=black face="Times New Roman"><span style='font-size:12.0pt;color:windowtext'>
<hr size=2 width="100%" align=center tabIndex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 color=black face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight:bold'>From:</span></font></b><font
size=2 color=black face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma;
color:windowtext'> sis-csi-bounces@mailman.ccsds.org
[mailto:sis-csi-bounces@mailman.ccsds.org] <b><span style='font-weight:bold'>On
Behalf Of </span></b>Scott Burleigh<br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, April 20, 2006
10:05 AM<br>
<b><span style='font-weight:bold'>To:</span></b> sis-csi@mailman.ccsds.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [Sis-csi] Green book
thoughts</span></font><font color=black><span style='color:windowtext'><o:p></o:p></span></font></p>
</div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>James L. Rash wrote: <o:p></o:p></span></font></p>
<div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>At 6:06 PM -0700 4/19/06, Scott Burleigh wrote:<o:p></o:p></span></font></p>
</div>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' cite="" type=cite>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3 color=black
face="Times New Roman"><span style='font-size:12.0pt'><a
href="mailto:Lee.Neitzel@EmersonProcess.com">Lee.Neitzel@EmersonProcess.com</a>
wrote:<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>RE: [Sis-csi] Green book thoughts<o:p></o:p></span></font></p>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' cite="" type=cite>
<p class=MsoNormal><font size=3 color=navy face=Arial><span style='font-size:
12.0pt;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><o:p></o:p></p>
</blockquote>
</blockquote>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' cite="" type=cite>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>In my mind, this is the key point in this discussion.<o:p></o:p></span></font></p>
</blockquote>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' cite="" type=cite>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>....<o:p></o:p></span></font></p>
</blockquote>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' cite="" type=cite>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>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?<o:p></o:p></span></font></p>
</blockquote>
<div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>Scott,<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>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><span style='font-weight:bold'>.</span></b><o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>My apologies if I have misinterpreted your thesis, and
I am happy to be corrected.<o:p></o:p></span></font></p>
</div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>As <st1:place w:st="on"><st1:City w:st="on">Adrian</st1:City></st1:place>
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<o:p></o:p></span></font></p>
</div>
</body>
</html>