[Sis-csi] Green book thoughts

[Carl A Sunshine]

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.
-----Original Message-----
From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org]On Behalf Of
Lee.Neitzel at EmersonProcess.com
Sent: Thursday, April 20, 2006 9:05 AM
To: Scott.Burleigh at jpl.nasa.gov; sis-csi at mailman.ccsds.org
Subject: RE: [Sis-csi] Green book thoughts



Chris Taylor wrote in a separate response "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".

 

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:

 

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. 

 

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.

 

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. 

 

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.

 

This partitioning of the AL 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 AL protocol.

 

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.

 

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.

 

  _____  

From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Scott Burleigh
Sent: Thursday, April 20, 2006 10:05 AM
To: sis-csi at mailman.ccsds.org
Subject: Re: [Sis-csi] Green book thoughts

 

James L. Rash wrote: 

At 6:06 PM -0700 4/19/06, Scott Burleigh wrote:

Lee.Neitzel at EmersonProcess.com <mailto:Lee.Neitzel at EmersonProcess.com>
wrote:



RE: [Sis-csi] Green book thoughts

As you know, there are significant fixed and variable costs associated with
design, implementation, testing, and deployment of each layer protocol.

In my mind, this is the key point in this discussion.

....

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?

Scott,

 

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".

 

My apologies if I have misinterpreted your thesis, and I am happy to be
corrected.

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.

Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20060421/caae6357/attachment-0001.htm