[Sis-csi] Green book thoughts

[Keith Hogie]

Scott, Keith L. wrote:

> It seems to me that the points of contention here center on whether or
> not an application using UDP might cause network congestion and hence
> lose packets, and whether/how building reliability on top of UDP is a
> Good Idea.  The arguments seem to oscillate between high-bandwidth
> downlinks where we want to use all of the available capacity and the
> assertion that UDP flows from space (there's a B-movie title in there
> somewhere...) simply can't congest the "network" because the space link
> bandwidth is too low.
> 
> I would assert that for some (possibly many?) future missions,
> bandwidths will be such that pure rate-controlled streams coming from
> some space applications would have the ability to congest shared (space
> and/or ground).  A single HDTV stream competing with any other
> appreciable flows in the ground or space portions of the network could
> do this, e.g.  I also don't think we can assert that streams will not
> cross some portion of shared network, especially if there is
> inter-agency cross-support.  One must consider the possibility of
> commercial ground stations, and also the possibility of shared in-space
> crosslinks.
> 

Yes, there will both high-rate and low-rate scenarios.  A common
scenario is low-rate telemetry and science data flowing down with
individual streams addressed to control centers and scientists.
At the same time there will probably be high-rate data coming down.
The low-rate data can be directly addressed to users while the
high-rate data can be addressed to a file store located at the
ground station.  The files can be retrieved at lower rates later.
This is the approach that has been used very successfully by
current IP based missions.  Their direct interaction with the
open Internet is minimized by design in order to avoid the
issues mentioned above.  There will probably be more link sharing
and Internet interaction 20-30 years from now but first we need
to get basic capabilities in place.  We can't have the complex
data flows and congestion until get get lots more IP nodes and
routers in space.

> 
> 
> That said, do we all agree (at least among ourselves -- the case will
> need to be made to external audiences) that:
> 1) Moving to IP provides a large benefit to missions in that:
>   o it decouples applications from the data links 
>   o it facilitates multi-hop routing over heterogeneous data links
>   o it provides an efficient multiplexing mechanism for numerous
>        data types
>   o traffic can be directly routed from ground stations over
>        closed networks or the Internet to its destination(s) on 
 >        the ground with commercial network equipment

Yes, all very good points.

> 
> 2) We don't really know how operators will want to use a networked
>    capability, except that they will probably want some mix of 
 >    real-time data that can take loss and reliable data that
>    wants no loss.  These are supportable in continuously connected 
 >    environments by TCP, UDP, and NORM (the latter two supporting
 >    simplex environments, to some extent); and in disconnected
>    environments by overlays like CFDP, and DTN.

Sort of.  Continuous connectivity is not as big an issue as simplex,
timewise separate simplex pair, and full-duplex links.  On one-way
links and links with delay so high that they basically look like
two separate one-way links, your only choice is to use UDP transport.
Then you get to figure out what application you want to run over
UDP.  Space missions have lots of these links.  All missions
MUST support UDP for various emergency modes when they don't
have a two-way link.

The only time you even consider TCP is when you have a two-way link
with reasonable round-trip time.

> 
> 3) Building application-specific reliability mechanisms on top of UDP
>    is an option, but *in general*, new applications should first 
 >    look to standard transport mechanisms (exact list TBD from
 >    Red Books from this WG) to fulfill their needs.  Non-congestion
 >    controlled flows that might cause significant network congestion
 >    are discouraged, but not prohibited if circumstances require
 >    their use and they can be designed to 'not-too-adversely'
 >    affect the network.  Note that 'not-too-adversely' here is
>    an overall system design trade -- a particular application might
>    need to simply blast bits without regard to the rest of the 
 >    network.  Note also that the overlays mentioned above may be
 >    part of the recommended set of standard transports.
> 
> 
> 	--keith

This is a bit confusing.  It mentions "standard transport mechanisms"
but the main choices are TCP and UDP.  Where the choices come in is
what applications you want to run over one or the other of those.
It you are not using TCP or UDP then you are really departing from
standard Internet technologies and start spending lots of money
building custom solutions.  Telling missions to avoid UDP is
backwards.  TCP has lots more problems in space than UDP and
*in general* UDP solutions work better for space comm than TCP.

I also don't understand all the concerns about writing "new
applications".  There are lots of existing applications like
CFDP, NORM, Digital Fountain, VoIP, etc. that all run over
UDP and seem to be very good fits for space communication.
Things like NORM, Digital Fountain, and VoIP also work with
multicast which has applications to space comm scenarios.

The goal of using Internet technologies in space is not to
try to web surf, Google, AIM, etc. across space links.  Those
may be of more interest 20-30 years from now but right now
we need to support satellite operations for commanding,
streaming data, and moving files across intermittent, one-way
and two-way space links.  We want to do this using Internet
technologies for all of the reasons mentioned in 1. above
but we have a very different environment from the open
Internet and need to focus this document on space comm for
satellite operations and not worry about web surfing in space.

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