<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" 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"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Re: [Sis-csi] Green book thoughts</TITLE>
<META content="MSHTML 6.00.2800.1543" name=GENERATOR><!--[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]--><o:SmartTagType name="City"
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType
name="State"
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType
name="place"
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: black; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: black; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: black; FONT-FAMILY: "Times New Roman"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
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 lang=EN-US vLink=blue link=blue bgColor=white>
<DIV><SPAN class=810573517-21042006><FONT face=Arial color=#0000ff size=2>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<SPAN
class=342573717-21042006>, or activity logs</SPAN>? That is where TCP is
probably most suitable.</FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B>
sis-csi-bounces@mailman.ccsds.org
[mailto:sis-csi-bounces@mailman.ccsds.org]<B>On Behalf Of
</B>Lee.Neitzel@EmersonProcess.com<BR><B>Sent:</B> Thursday, April 20, 2006 9:05
AM<BR><B>To:</B> Scott.Burleigh@jpl.nasa.gov;
sis-csi@mailman.ccsds.org<BR><B>Subject:</B> RE: [Sis-csi] Green book
thoughts<BR><BR></FONT></DIV>
<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Chris Taylor wrote in a
separate response "</SPAN></FONT><FONT face="Courier New" color=black
size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: 'Courier New'">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 face="Courier New" color=black size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: 'Courier New'"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">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 face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">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 face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">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 face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">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 face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">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 face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">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:State w:st="on"><st1:place w:st="on">AL</st1:place></st1:State>
protocol.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">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 face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">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 face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<DIV>
<DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT
face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt; COLOR: windowtext">
<HR tabIndex=-1 align=center width="100%" SIZE=2>
</SPAN></FONT></DIV>
<P class=MsoNormal><B><FONT face=Tahoma color=black size=2><SPAN
style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT
face=Tahoma color=black size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Tahoma">
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 face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt">James L. Rash wrote: <o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt">At 6:06 PM -0700 4/19/06, Scott Burleigh
wrote:<o:p></o:p></SPAN></FONT></P></DIV>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" cite="" type="cite">
<P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt"><A
href="mailto:Lee.Neitzel@EmersonProcess.com">Lee.Neitzel@EmersonProcess.com</A>
wrote:<BR><BR><o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt">RE: [Sis-csi] Green book
thoughts<o:p></o:p></SPAN></FONT></P>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" cite="" type="cite">
<P class=MsoNormal><FONT face=Arial color=navy size=3><SPAN
style="FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Arial">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: 5pt; MARGIN-BOTTOM: 5pt" cite="" type="cite">
<P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt">In my mind, this is the key point in this
discussion.<o:p></o:p></SPAN></FONT></P></BLOCKQUOTE>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" cite="" type="cite">
<P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt">....<o:p></o:p></SPAN></FONT></P></BLOCKQUOTE>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" cite="" type="cite">
<P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt">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 face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt">Scott,<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt">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 face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt">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 face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt">As <st1:City w:st="on"><st1:place
w:st="on">Adrian</st1:place></st1:City> 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>