[Sis-csi] Green book thoughts

[Scott, Keith L.]

Keith,

I've integrated most of this into the document, but I have a few issues
inline. 

>-----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, March 30, 2006 12:48 PM
>To: sis-csi at mailman.ccsds.org
>Subject: [Sis-csi] Green book thoughts
>
>All,
>
>   Sorry for the late input but here are a few thoughts
>and inputs for this afternoon's telecon.  I couldn't see
>shipping the whole 6 MB around to convey
>this little bit of info.
>
>   These are based on Draft_15.doc
>
>2.2.2  Telepresence/Telescience
>
>...  At Cislunar (and Cismartian) distances there will be
>significant degradation of such capabilities (telepresence) ...
>
>   This is true at the outer limits of these environments, but
Cislunar
>also includes everything from low-earth orbit out to beyond the moon.
>I think we often focus on Cislunar being only lunar missions and
>forget about all of the other missions like all of the current
>"Cislunar satellites" already in orbit around the Earth.
>
>   Section 2.1 just got done mentioning that Cislunar covers
>everything from LEO to L2.  Somehow we need to be careful about
>making broad statements about Cislunar.  Do we need to break
>down Cislunar into short, medium, and long or something like that.

I'm trying to work this in conjunction with your comment on scenarios
below.

>2.2.6 Services unique to the ground environment
>
>   Not sure about this section.  Some of these might apply to space 
>links too.
>
>3.3
>
>   reference to "traffic types described in section 3" should be 2
>
>4.0
>
>Routed (definition)
>
>In a packet-switched network, data packets are delivered across
>multiple hops (links) with possibly multiple paths between a source
>and destination.  Intermediate network nodes will receive a packet
>from one link and then make a routing decision on which link
>to forward the packet to the next node.  Packet routing based
>on individual packet addresses allows a data source
>to address packets to many different destinations and the packets
>will be routed to the various destinations as they traverse the
>network and its associated links.
>
>4.2.1 IP Network Packet
>
>   With respect to IPv4 vs IPv6 can we come to any conclusion on
>one or the other.  My concern is that there is no installed
>base of IPv4 or IPv6 in space right now.  If we keep offering both
>then we need to implement and support both forever.  If we can
>justify only IPv6, that could greatly simplify implementation
>and future support issues.  It also requires support for
>security which is something we need to start supporting anyway.
>
>  Also, is it worth even mentioning SCPS-NP since IP header
>compression can do about as good and there is lots of
>real support for IP compression and no real support for SCPS-NP.
>Again, the issue of if you offer options, each option will
>eventually be used by someone, and the network ends up having
>to support them all forever.

I think that we'd only recommend NP use for *extremely* constrained
links, which wouldn't include anything that might support crewed
missions.  For some LEO science missions, NP could support very low
data rate (and hence small, cheap) missions but yes, it's not generlly
routed, there are no (to my knowledge) commercial NP-to-IP gateways,
...  In short, I think that when we come to a recommended set of
protocols, we'll settle on one of v4/v6 as the way to go.

>4.4 Automated Data Forwarding
>
>   Not sure if the SLE reference really fits here.  That is a
>reference to the old circuit switch concept and not routing
>based on addresses in packets.  SLE doesn't do IP packet
>forwarding and doesn't apply in an end-to-end IP architecture
>does it

I think the data forwarding part of SLE here (as opposed to the service
management part) is just a tunneling mechanism like GRE.  Its inclusion
allows the space (data) link protocol to be terminated somewhere else
besides the ground station.  That's how many agencies are set up to
operate now, and they'll probably continue with it until they can get
equipment at the ground stations to terminate the space data links AND
something to provide reliability, or ate least comprehensive data
accounting.

>   Should this mention things like standard automated routing
>protocols like RIP, OSPF, Mobile IP, MANET stuff, etc. along
>with static routing.
>
>4.4.1 Forwarding, Routing
>
>   This mentions that "This will allow mission operations
>personnel to maintain absolute control over the forwarding
>process..."  They don't really have that control today and
>won't have it in the future.  Today they may indicate that
>they want their commands sent to a particular antenna but
>they don't control the exact path from their control center,
>across all links, to the antenna.
>
>   I don't think we want to give them the impression that
>they can control all routers in NASA's operational networks.

Right, this was referring mainly to the space portion of the network.

>
>4.4.3 Quality of Service
>
>   There are simple QOS options like priority queuing based
>on UDP, TCP, port numbers, etc. that can also be implemented
>very easily without the additional complexity of things like
>diffserv, rsvp, etc.  We need to check and see what is
>currently implemented in IONET.  I think they may currently
>just prioritize UDP over TCP.
>
>
>4.4.4 Security
>
>   With IPv6 security is no longer an option.  It is part of
>the spec.
>
>4.4.5 Additional services
>
>   Multicast has been used for the last 10 years in NASA's
>ground networks to support efficient delivery of satellite
>data to multiple destinations. The common application is
>simultaneous delivery of realtime data to multiple control
>center processing systems and level-zero processing
>facilities.
>
>4.6 Transport layer
>
>   --- insert after first paragraph ---
>
>   UDP provides a data delivery very similar to standard
>TDM and CCSDS packet delivery systems that are currently
>used for space communication.  It's unreliable delivery
>attribute means that it does not utilize any process,
>such as acknowledgments, for determining if the data
>gets to its destination.  Reliable delivery can be
>implemented over UDP in the application layer if desired
>with applications such as CFDP.

This is true, but I don't want to give mission software people the
impression that they can just hack up reliability on a per-application
basis.  CFDP is sort of a special case and I'm not sure how well even
it would play in a mixed envrionment (that is, I'm not sure if CFDP
implements TCP-friendly congestion control).  Think about the
conditions under which TCP underperforms a UDP-based scheme -- the win
seems to be in those cases where you have enough loss to build an
out-of-sequence queue at the receiver and then can't fill it until the
end of the communications session.  In such cases a UDP-based
application could get immediate access to the 'out-of-sequence' data,
but presumably would still have the same set of holes.  Given the low
(relative to interplanetary) distances, power levels, and data rates
people talk about for crewed lunar exploration, is this really going to
be a problem?

>   One advantage of UDP is that since it does not require
>any acknowledgments, its operation is not affected by
>propagation delay and it can also function over one-way
>links.  UDP provides an alternative to TCP in scenarios
>where TCP performance suffers due to delays and errors.
>Since UDP doesn't require acknowledgments, it allows
>end-system application implementors to design their
>own retransmission schemes to meet their particular
>environment.

Again true, but I think this needs to be said very carefully, lest
everyone decide that it would be more fun to design their own
retransmission schemes than to work the application protocols.  The
hidden assumption here is that if TCP performance suffers due to delays
and errors, I can do a better job with my retransmission protocol over
UDP.  While there are alternate congestion control schemes (e.g. Steven
Low's FAST TCP, maybe some aspects of SCTP) that we could end up
recommending, I doubt most flight software programs ability to
correctly design and implement something with wide applicability.
That's not meant as a knock on the flight software people -- the task
of writing a new transport layer that works well under the full range
of conditions is huge - much bigger than a single mission - and they've
got N other things to do that are mission-specific and higher priority.

>   UDP is also commonly used for data delivery
>scenarios where timeliness of delivery is more important
>than completeness.  Common uses include streaming data
>such as voice and video.  It is also used for multicast
>delivery where the same data is sent to multiple
>destinations and it is not desirable to have
>multiple acknowledgments returning from all the
>destinations.
>
>
>4.8 Store-and Forward for Disrupted Environments
>
>Seems to jump to DTN rather quickly.  We have survived
>for many years doing store-and-forward based on files
>or big chunks of data and that will still work fine for
>many future missions.  We don't need to tell them that
>they need to completely change what they are used to
>just because we are putting in IP.

I moved the DTN section to after TCP transport, which I think flows
pretty well.  I like your idea of tying the file-based
store-and-forward to current mission operations procedures.

>
>How about something like
>
>A critical component of the cislunar architecture for dealing 
>with cases 
>where there is not an end-to-end path between source and 
>destination is 
>the use of store-and forward mechanisms.   The store-and-forward 
>function can occur at either the packet level or file level. 
>Traditional store-and-forward space communication occur at the file or

>mass-storage partition level with files being stored at each hop and 
>forwarded later.  Another option is to do store-and-forward at the 
>packet level with approaches such as Delay/Disruption Tolerant 
>Networking (DTN).
>

Mostly correct, except that DTN is in fact store-and-forward at the
file level.  One could think of DTN as the refactoring of CFDP's
multi-hop transport mechanisms (as distinct from its file system
manipulation capabilities) married to a general-purpose API.

>
>5.0  Operations concepts
>
>   These are basically Lunar scenarios.  Do we need to include 
>basic LEO 
>scenarios to let people know that Cislunar is not just lunar but 
>everything from LEO to beyond the moon. Just a thought that there will

>still be lots of non-lunar missions coming up and I think we want this

>document to relate to them too.

Yeah, this ties into the earlier comment.  I added some text near the
top of the document to try to highlight LEO applications, maybe some
glue words around the figures could extend their applicability.  I'll
try to work this.

>
>
>   See you on the telecon at 3:30
>
>----------------------------------------------------------------------
>   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
>