[Sis-csi] Cislunar section 4

Fri Sep 2 11:23:26 EDT 2005

Replies inline.  Yes, it took me until I got out of the network section
to figure out exactly what your scope was there.  I did go back and
redo my responses based on that.

I think there are two (related) main points here:

1) I think QoS is a requirement.  You mention that we want to ensure
that users who want low-latency get it.  Without QoS, IP makes no claim
as to packet latency.  Even diffserv doesn't necessarily address
latency cleanly; there can still be queueing within a given traffic
class.  Integrated services lets you reserve bandwidth per flow, which
might work for NASA (relatively small number of flows, even in the
'core'), but is more complicated.

2) My model has always been a single network for voice, video, and data
(including C2).  Having a single infrastructure lets us make efficient
use of the bandwidth by statistically multiplexing lots of users onto
it.  You talk about an 'astronaut' RF link and a 'mission' RF link: are
you thinking of separate networks?

        --keith

________________________________

	From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Keith Hogie
	Sent: Thursday, September 01, 2005 1:03 AM
	Cc: sis-csi at mailman.ccsds.org
	Subject: Re: [Sis-csi] Cislunar section 4

	Keith,

	  See comments below.  I think some of these comments resulted
from the way I led into the section and didn't clearly separate the
overall network from a discussion focused on just the network layer.
I'll be working more on the section in the next few days.

	Keith Hogie

	Scott,Keith L. wrote: 

		Keith:
		I like a lot of your section 4 but some issues with
your network layer
		requirements for cislunar comms.  The requirements seem
entirely
		centered around the need to handle simplex paths.  

	The network part was meant to be about just the network layer.
That could use some clarification.  The thought was that at the network
layer you just want packet forwarding.  There is not reliable ACK/NACK
operation at the network layer.  It just receives packets, looks at the
destination address, and forwards the packet.  Any "reliable" delivery
options come in at the transport layer.  

	Yes, but why is this a requirement for cislunar comms?  I agree
that in the OSI model, the responsibility for reliable delivery is in
the transport layer, but I don't think it explicitly states that the
network layer can't do it.  I'm not really arguing against you here,
just that this might not be a requirement, and if we say that it is,
somebody else is going to ask why and we'll need a good answer.

	I started with the network layer to try to move away from
circuit concepts and get into network packet forwarding concepts.

		While I think we
		have to be able to handle simplex paths, I don't think
we want to count
		on them as the norm.  

	Yes, missions will not necessarily use simplex as the norm but
at the network layer I was thinking more about basic packet forwarding
and then building on that with the upper layers. 

	Sure, we need to accommodate cases where there are simplex
paths, but not let it drive the architecture. 

		There are lots of things in IP that won't work
		right over pure simplex paths (you'd have to pre-load
your ARP table,
		you're not going to get ICMP messages, ...)  

	When using IP over a point-to-point serial link you don't need
ARP.  ARP is needed in shared media LANs where you need to associate a
MAC address with an IP address.  When running IP over serial links you
just have a routing table that tells you what serial interface to use
to forward the packet.  The route needs to be set up somehow and on a
simplex link that might require manual route setup.  But during a
spacecraft emergency, you need to do whatever needed to try to send a
packet over a simplex link.

	I was trying to emphasize that IP (network layer) doesn't
require two-way links to function.  It is really just about packet
forwarding.  Another point is that IP is not sensitive to propagation
delay.  Routing entries need to be in place, but once they are, IP
packets simply forward and don't care how long it takes to get to their
destination because IP does not have any sort of handshake required.   

	Right.  But this argument starts with IP as the answer and
states that IP's characteristics are requirements.  I agree that IP is
a good answer for a network layer, but I'm not sure that all of its
characteristics are then requirements.

		Things like network layer
		QoS are, I believe, essential to getting missions to
buy into the rest
		of the cislunar stack.  We need to convince missions
that during a
		critical maneuver, their important data isn't going to
get lost because
		some astronaut is surfing the web.  

	Missions have been running without any QoS for years.  IONET
has been running all NASA operational traffic over UDP/IP for years and
control centers and LZP facilities routinely receive passes with
hundreds of thousands of blocks without any loss.  There are also TCP
transfers running on the same ground network.  There are simple
approaches like prioritizing UDP traffic over TCP to take care of mixed
traffic problems.  These are much easier to implement than requiring
all network nodes to participate in more complex QoS mechanisms.

	I suspect that IONET has way more bandwidth than the
space-to-ground links.  If we are successful in moving to a networked
space architecture, there will be times when multiple independent data
sources converge on a single link (downlink or crosslink) that can't
accommodate the sum of the sources.  If this condition is transient,
buffering in the router will suffice.  If it persists, QoS is concerned
with answering the question: which data to I send, and which do I drop?

	  As far as an astronaut surfing the web and congesting a link,
wouldn't the astronaut's RF link and the mission RF link be two
separate links so there would not be any common low-rate RF link shared
by them.  If their traffic merged somewhere, it would be on a larger
link and the UDP traffic can be prioritized to avoid problems.  

	  I guess I'm not sure the network layer has to provide QoS for
everyone and we need to make sure that it doesn't add any additional
delay for users who want low latency packet delivery.

	Without QoS, IP makes no claim whatsoever as to packet latency.
This is one of the reasons to implement QoS.

		Also, is it really a requirement to
		NOT provide guaranteed delivery, or just that
guaranteed delivery can
		be met universally given the need to function over
simplex paths?

	The requirement is that the option must be available for
one-way blind commanding which is
	a requirement for all spacecraft.  Normal commanding may use a
two-way, reliable 
	protocol but the "network" must support a simplex mode for
spacecraft emergencies.   We need to make sure there is always an
option to run in simplex mode at the network layer.   

	Agreed. 

	Also some missions are planning on using things like TDRSS
demand access with only a one-way data flow.  They would run lots of
data over one-way links and then might have a few two-way contacts
every day for any retransmissions needed.

	Yes, CFDP, NORM, and DTN would all work in such environments. 

		I'd propose the following list of networking
requirements (heavily
		borrowing from yours):

		End-to-end networking layer that can function over a
set of
		heterogeneous environment-specific link layers.
		Support for gateways to connect legacy and future
networks
		Quality of Service mechanisms to protect important data
from congestion
		loss

	I have mixed feeling about messing around with too much QoS
complexity at the network layer.  See comments below on diffserv. 

	As above, if you don't have QoS at the network layer, you don't
have QoS period unless you segregate a chunk of bandwidth for
'high-prioirity' traffic.  The whole point of packet-switching is to
get away from apriori dicing of the links and to allow statistical
multiplexing to allow more traffic.  Another benefit of QoS is that it
allows you to specify a 'bulk' class of traffic that gets dropped
first.  This lets you send a lot of the bulk class (maybe CFDP dumps of
low-priority data) and keep links full.  There is a rather nasty
problem that if data is lost non-proximate to the source,
retransmissions will come from the source and consume bandwidth again
between the source and the drop point.  DTN can help there if there's a
storage point closer to the drop (or at it).

		 Security (note: may be 'TLS-like where only
application data is

		authenticated / encrypted) -- not really a requirement
for us; could be
		pushed to the application but may be good to provide as
an
		infrastructure mechanism)

	I left all the security stuff in the next section that is still
getting filled in.  I wanted to focus on basic network concepts first
and then we can confuse people with all the security stuff in the next
section.  That will mention things like IPSec at the network layer.

		Ability to transmit over simplex paths for emergencies
		Ability to support short command sequences for
emergency commanding.
		Ability to function over a range of end-to-end delays,
starting with
		~2.5s (lunar) and growing to minutes or tens of minutes
over the next
		20 years.
		Capable of efficiently supporting voice, video, and
data traffic

		I think I agree with the data link requirements, but
don't understand
		'Resume/continue operation after link errors'?  

	I'm not quite sure what that one means.  It was just a thought
that any link protocol has to be prepared for intermittent links.  Also
that data should not stop flowing in one direction on the link just
because there was and interruption on the link on one direction or the
other.  Not sure how we want to state that. 

	I guess it is a requirement, since to NOT resume would mean
that the link stopped after the first error...  Still, it reads sort of
odd.

		The requirement to
		support variable length frames at the data link layer
(as a universal
		requirement) is also problematic, I think.  If one uses
Reed-Solomon
		error correction, it's possible to support variable
length data link
		PDUs, it's just that the physical (underneath coding)
frames have
		discrete step sizes, right?

	Yes, exactly.  R/S, or Turbo, or LPDC, often require fixed size
codeblocks.  We need to make sure those sizes don't restrict the
network packet size. 

	I don't think any of the above mechanisms places any
restriction on data link PDU sizes, do they?  The problem is that the
block code imposes a minimum length on what goes out over they physical
link.  For those emergency commanding situations, it's going to be
important for us to know just what the smallest thing we can send is.
So, for example, if we say that astronaut suits use 802.11, we're
requiring bi-directional RF and the smallest thing we can send (over
the link) is probably a SNAP packet with a few bytes of data (need to
figure out the length here).  The smallest thing we can send over the
network is probably UDP unless we tried to get a new IPPROTO for
emergency commanding to save 8 bytes.

		In your requirements for transport layers, you include
QoS, which I
		agree with (though I'd put at least a piece of it in
network (e.g.
		diffserv)).

	I'm not sure what to say about diffserv.  I did a bit of web
searching to see what's up with diffserv and didn't find much current
work.  Most of it was from 1998-2002.  I'm not sure how popular it is
yet and how feasible it is to implement in our environment.  Does
anyone have any updates on how and where diffserv is being
used/deployed?

	Most IP stacks can treat traffic differently based on the
diffserv codepoint (DSCP), it's just a matter of setting it up.
Expedited forwarding for emergency commands would seem like a good
idea.  

				--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, August 18, 2005 3:25 AM
			To: sis-csi at mailman.ccsds.org
			Subject: [Sis-csi] Cislunar section 4

			All,

			   Here is the current version of section 4 of
the Cislunar Green
			Book.  I chopped out all of the other sections
to keep the file
			smaller.  It is not complete but is has some
thoughts in each

		section.

			See what you think of the general structure and
contents and we can
			discuss it at this week's telecon.

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

---------------------------------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20050902/69c7b361/attachment.htm