[Sis-csi] Telecon today

Thu Apr 20 10:34:22 EDT 2006

I don't think the real nut of contention is CFDP itself, but in what we
might recommend as a general practice for mission designers, especially
with respect to reliable data transfer.

I'm not trying to argue that there's no place for UDP -- far from it.
For applications that don't need reliability, UDP is the way to go.
There are issues in that UDP-based applications could, depending on
circumstances, cause congestion in the network.  How much traffic
constitutes 'too much' and whether the system is engineered such that
the application will always be safe are considerations.

My concern with presenting advice that could be interpreted as 'once
you have IP you're free to do completely anything above that, we're out
of it, and oh by the way TCP just won't work' is that (again, my
personal fear) it would lead to each mission crafting its own
reliability mechanisms, having to design and test each one.  When one
of those bites it (and one would, sooner or later) they'll claim that
the networking stuff is all crap and chuck it all, possibly including
IP.  'Standard' overlay protocols like CFDP, NORM, and DTN that can
provide some of the services applications need AND have some reuse and
testing/robustness go a long way towards alleviating this, and I think
their use should be encouraged for those cases where TCP is not an
acceptable reliability mechanism.

I completely agree with your last, that we can all agree on an IP-based
infrastructure and let missions sort out exactly how they want to work
over that later.

The way I see it, we will eventually have to provide some pretty
specific recommendations (it's our job -- mission designers are not
necessarily network-saavy, and we're supposed to be experts).

For THIS document, expecially since it's rationale and NOT a
recommendation, I wonder if we can simply cite some data transport
mechanisms, to include TCP, UDP, CFDP, maybe NORM? and DTN, with some
illustrative examples of their use (we have the section on Ops
Concepts) and stay relatively mute on recommended practice.  I think
it's worth pointing out *briefly* that: TCP provides congestion control
but in turn requires bidirectional end-to-end paths and can suffer from
low performance in long-rtt, high BER environments; UDP is insensitive
to RTT and works over simplex links, but doesn't provide reliability
unless the application implements it.  There are some UDP-based
overlays (e.g. CFDP, NORM) that provide reliability and have the
advantage that somebody else has done the design and hopefully some
testing.

		--keith

>-----Original Message-----
>From: sis-csi-bounces at mailman.ccsds.org 
>[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Keith Hogie
>Sent: Thursday, April 20, 2006 10:02 AM
>To: sis-csi at mailman.ccsds.org
>Subject: Re: [Sis-csi] Telecon today
>
>Scott, Keith L. wrote:
>> Let's hold the telecon today
>>  
>> 12:30 Pacific
>> 3:30 Eastern
>>  
>> 703.983.1550 passcode 55555
>>  
>>         --keith
>>  
>
>Sounds good.  We do need to figure out how to converge on words for
>the document.  As I was reviewing the current discussion I noticed
>a few possible differing views.  I'm trying to figure out if the
>following thoughts are the basis of some of our differing views.
>
>There has been lots of discussion on "transport protocols" and
>"applications".  I think I have seen things like CFDP mentioned
>in the following contexts:
>
>1 - CFDP is a "transport protocol"
>2 - CFDP provides "services"
>3 - CFDP is an "application"
>
>Here are my thoughts:
>
>1 - CFDP is NOT a transport protocol.  The transport protocols we
>have available are TCP and UDP and CFDP (as well as any other
>UDP-based, reliable file transfer techniques) live above the
>transport layer.
>
>2 - CFDP does provide services for reliable data delivery but
>those services are implemented in an application.  I think this
>gets into things like FTP which provides services in the same way
>but when we talk about FTP we normally mean the FTP application
>that implements the FTP protocol.  However, the application does
>lots more than just implement the FTP protocol.  It also provides
>access to the file system, provides some sort of user interface,
>etc.
>
>3 - CFDP in my mind is the application that implements the CFDP
>protocol.  Even though rate-control is not part of the CFDP
>specification, that does not mean the application implementing
>CFDP can't add its own rate-control, add a fancy GUI, interface
>CFDP with an email system, or do all sorts of other things.
>
>-------------------------
>
>I wonder if some of the concerns about software development
>cost, risk, and non-interoperable systems when people use
>UDP are related to these different views.  As I see it,
>reliable file transfer over UDP is just an application and
>there are already many available.  It's really quite easy
>for an end-system to support many different applications.
>We all do it all the time on our computers which can easily
>have support for Telnet, FTP, SSH, SCP, HTTP, SMTP, POP,
>IMAP, NFS, CFDP, MDP, NORM, and many others.  These normally
>all run simultaneously.  Adding or changing applications
>is really the easiest part of networking because it only
>affects the two end systems involved.  Intermediate nodes
>in the network do not need to know what protocols any
>two end systems are using.
>
>I think the big thing we need
>to focus on is getting a basic network infrastructure
>with both UDP and TCP over IP and link layer protocols
>agreed on.  The individual missions will then pick the
>application protocols that meet their needs and issues
>like congestion will get worked out between mission
>designers and network operations people.
>
>----------------------------------------------------------------------
>   Keith Hogie                   e-mail: Keith.Hogie at gsfc.nasa.gov
>   Computer Sciences Corp.       office: 301-794-2999  fax: 
>301-794-9480
>   7700 Hubble Dr.
>   Lanham-Seabrook, MD 20706  USA        301-286-3203 @ NASA/Goddard
>----------------------------------------------------------------------
>
>_______________________________________________
>Sis-CSI mailing list
>Sis-CSI at mailman.ccsds.org
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
>