[Sis-csi] Green book thoughts

Lee.Neitzel at EmersonProcess.com Lee.Neitzel at EmersonProcess.com
Wed Apr 19 10:20:37 EDT 2006


I've been watching these emails go back and forth and it sounds to me
like the discussions we have previously had in the process industries
(refineries, petro-chem, food and beverage, pharmaceuticals, etc),.

 

In the process industries we use UDP as the base commerical protocol for
our control networks, and some of them go across satellite links. We use
UDP for one primary reason - cost and availability. We don't use TCP
very often because of the overhead, the fact that it is stream-oriented,
and the lack of determinism caused by variations of implementations.  

 

In addition, UDP is simple, doing very little except for maintaining
message boundaries (message in/message out).  We rarely, if ever, use
checksums since we run over ethernet, which has proven over the years to
be reliable when it comes to data transmission. Of course, there are
always the arguments that there could be missed messages that aren't
covered by the DLL checksum, but those haven't been seen in the field. 

 

In addition, where we need to ensure a higher level of reliability, the
application layer protocols detect missed messages and provide for
necessary retransmissions.  Generally, these protocols are proprietary
to one of the major process control companies. This is because there was
no existing standard protocol that would meet the needs of a given
control system when the control system was initially designed.

 

The process industry protocols above UDP always convert the UDP PDU (the
message) into some data structure with semantics (a Read Request or
Response, and Event Notification, etc). They generally do not create new
layers for missed message detection and retransmission. Instead these
functions are integrated into the protocols that runs on top of UDP.
The reason for this is implementation and configuration simplicity,
which ultimately leads to cost management. We, in the process control
industries, do not make our money on protocols. They are a cost to us.
Therefore, they are carefully crafted to be simple and bundled to keep
costs low.  As you know, there are significant fixed and variable costs
associated with design, implementation, testing, and deployment of each
layer protocol.

 

________________________________

From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Scott, Keith L.
Sent: Wednesday, April 19, 2006 8:44 AM
To: L.Wood at surrey.ac.uk; adrian.j.hooke at jpl.nasa.gov
Cc: sis-csi at mailman.ccsds.org
Subject: RE: [Sis-csi] Green book thoughts

 

High utilization of limited contacts is definitely a consideration.  For
reliable communications in that environment, one could build reliability
on top of UDP, or use TCP PEPs at either end of the space link, or use
DTN.  Using PEPs allows the end systems to use a standard model for
reliable communications while still enabling full use of the space link.
DTN is attractive in that the end systems don't have to be cognizant of
the contact schedule.

 

Your points about CFDP are well taken, and I believe Scott agreed that
CFDP over UDP doesn't do congestion control.  As such I think it would
fall into the category of 'use with caution so as not to melt the
network.'  One benefit of CFDP is that it's designed to be a standard
service for applications, so at least every app wouldn't have to
re-implement it.  I think it shares this with Saratoga.

 

For right now I would like to settle on an architecture which is
encompassing in what it allows and not get too involved in guidance to
mission designers.  We WILL have to provide that guidance soon, but I
would prefer to make progress with the current document, since we're not
going to get to the degree of specificity for mission design in the
architecture document anyway.  When it comes time to pick the
recommended set of protocols / services for cislunar (starting with the
next set of meetings?) we can figure out how to come to consensus on the
set of recommended protocols / services.

 

        --keith

	 

	
________________________________


	From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of
L.Wood at surrey.ac.uk
	Sent: Wednesday, April 19, 2006 6:16 AM
	To: adrian.j.hooke at jpl.nasa.gov
	Cc: sis-csi at mailman.ccsds.org
	Subject: RE: [Sis-csi] Green book thoughts

	>At 04:33 PM 4/18/2006, Lloyd wrote:
	>> You can use IP -- and UDP -- and be enhanced.
	>
	> Enhanced? Seems like you've got a custom, non-standard
application running
	> over UDP (which doesn't *do* anything, so presumably that
custom
	> application has its own custom reliability built into it?)
running over IP
	> which "routes" you from a single processor on the spacecraft
over a single
	> link to a single processor located directly in the ground
station.
	
	UDP provides per-packet checksums, multiplexing and
identification via ports, and a standard widespread sockets interface
convention for building on top of.
	
	That's why many custom non-IETF-standard applications, including
Skype, Real, and CFDP, use UDP. I presume CFDP also implements its own
custom reliability? Is that somehow a bad thing? (No.)
	
	The choice of path from one of a network of scheduled processors
on the DMC spacecraft to one of a network of computers in the ground
station LAN is dictated solely by pass utilization and wanting to get
the most from the space/ground link while it's active, rather than
introduce a bottleneck elsewhere with a longer path. That applies no
matter what UDP-based protocol you use; a CFDP implementation was used
in exactly the same way (until it was replaced to increase performance
and link utilization).
	
	ftp://ftp-eng.cisco.com/lwood/cleo/README.html
	
	L.
	
	
<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20060419/7195dda6/attachment-0001.html


More information about the Sis-CSI mailing list