[Sis-csi] Cislunar section 4

[Keith Hogie]

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. 

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.

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

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

  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.

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

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.

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

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

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

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

>		--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/20050901/8901bd8d/attachment.html