<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2722" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=234512814-02092005>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.</SPAN></FONT></DIV>
<DIV> </DIV>
<DIV><SPAN class=234512814-02092005></SPAN><FONT face=Arial><FONT
color=#0000ff>I<SPAN class=234512814-02092005> think there are two (related)
main points here:</SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><SPAN
class=234512814-02092005></SPAN></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><SPAN class=234512814-02092005>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.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><SPAN
class=234512814-02092005></SPAN></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><SPAN class=234512814-02092005>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?</SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><SPAN
class=234512814-02092005></SPAN></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><SPAN
class=234512814-02092005>
--keith</SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff></FONT><BR></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sis-csi-bounces@mailman.ccsds.org
[mailto:sis-csi-bounces@mailman.ccsds.org] <B>On Behalf Of </B>Keith
Hogie<BR><B>Sent:</B> Thursday, September 01, 2005 1:03 AM<BR><B>Cc:</B>
sis-csi@mailman.ccsds.org<BR><B>Subject:</B> Re: [Sis-csi] Cislunar section
4<BR></FONT><BR></DIV>
<DIV></DIV>Keith,<BR><BR> 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.<BR><BR>Keith Hogie<BR><BR><BR>Scott,Keith L. wrote:
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap="">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. </PRE></BLOCKQUOTE>
<DIV>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. <BR><SPAN
class=234512814-02092005><FONT face=Arial
color=#0000ff> </FONT></SPAN></DIV>
<DIV><SPAN class=234512814-02092005><FONT face=Arial color=#0000ff>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.</FONT></SPAN></DIV>
<DIV><SPAN class=234512814-02092005> </SPAN><BR>I started with the
network layer to try to move away from circuit concepts and get into network
packet forwarding concepts.<BR></DIV>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap="">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. </PRE></BLOCKQUOTE>
<DIV>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.<SPAN class=234512814-02092005><FONT
face=Arial color=#0000ff> </FONT></SPAN></DIV>
<DIV><SPAN class=234512814-02092005></SPAN> </DIV>
<DIV><SPAN class=234512814-02092005><FONT face=Arial color=#0000ff>Sure, we
need to accommodate cases where there are simplex paths, but not let it
drive the architecture.</FONT> </SPAN><BR></DIV>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap="">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, ...) </PRE></BLOCKQUOTE>
<DIV>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.<BR><BR>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. <SPAN class=234512814-02092005><FONT face=Arial
color=#0000ff> </FONT></SPAN></DIV>
<DIV><SPAN class=234512814-02092005></SPAN> </DIV>
<DIV><SPAN class=234512814-02092005><FONT face=Arial
color=#0000ff>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.</FONT></SPAN><BR></DIV>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap="">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. </PRE></BLOCKQUOTE>
<DIV>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.<BR><SPAN class=234512814-02092005><FONT face=Arial
color=#0000ff> </FONT></SPAN></DIV>
<DIV><SPAN class=234512814-02092005><FONT face=Arial color=#0000ff>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?</FONT></SPAN></DIV>
<DIV><SPAN class=234512814-02092005> </SPAN><BR> 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. <BR><BR> 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.<BR><BR><SPAN class=234512814-02092005><FONT face=Arial
color=#0000ff>Without QoS, IP makes no claim whatsoever as
to packet latency. This is one of the reasons to implement
QoS.</FONT></SPAN></DIV>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap="">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?
</PRE></BLOCKQUOTE>
<DIV>The requirement is that the option must be available for one-way blind
commanding which is<BR>a requirement for all spacecraft. Normal
commanding may use a two-way, reliable <BR>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. <SPAN class=234512814-02092005><FONT face=Arial
color=#0000ff> </FONT></SPAN></DIV>
<DIV><SPAN class=234512814-02092005></SPAN> </DIV>
<DIV><SPAN class=234512814-02092005><FONT face=Arial
color=#0000ff>Agreed.</FONT> </SPAN><BR><BR>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.<BR><SPAN
class=234512814-02092005><FONT face=Arial
color=#0000ff> </FONT></SPAN></DIV>
<DIV><SPAN class=234512814-02092005><FONT face=Arial color=#0000ff>Yes, CFDP,
NORM, and DTN would all work in such
environments.</FONT> </SPAN></DIV>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap="">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
</PRE></BLOCKQUOTE>
<DIV>I have mixed feeling about messing around with too much QoS complexity at
the network layer. See comments below on diffserv.<FONT face=Arial><FONT
color=#0000ff><SPAN class=234512814-02092005> </SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><SPAN
class=234512814-02092005></SPAN></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><SPAN class=234512814-02092005>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. </SPAN><SPAN class=234512814-02092005> DTN can help there if
there's a storage point closer to the drop (or at
it).</SPAN></FONT></FONT></DIV>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap=""><SPAN class=234512814-02092005> </SPAN>Security (note: may be 'TLS-like where only application data is
</PRE></BLOCKQUOTE>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap="">authenticated / encrypted) -- not really a requirement for us; could be
pushed to the application but may be good to provide as an
infrastructure mechanism)
</PRE></BLOCKQUOTE>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.<BR><BR>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap="">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'? </PRE></BLOCKQUOTE>
<DIV>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.<SPAN class=234512814-02092005><FONT face=Arial
color=#0000ff> </FONT></SPAN></DIV>
<DIV><SPAN class=234512814-02092005></SPAN> </DIV>
<DIV><SPAN class=234512814-02092005><FONT face=Arial color=#0000ff>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.</FONT></SPAN></DIV>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap="">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?
</PRE></BLOCKQUOTE>
<DIV>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.<SPAN class=234512814-02092005><FONT face=Arial
color=#0000ff> </FONT></SPAN></DIV>
<DIV><SPAN class=234512814-02092005></SPAN> </DIV>
<DIV><SPAN class=234512814-02092005><FONT face=Arial color=#0000ff>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.</FONT></SPAN></DIV>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap="">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)).
</PRE></BLOCKQUOTE>
<DIV>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?<BR><SPAN class=234512814-02092005><FONT face=Arial
color=#0000ff> </FONT></SPAN></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><SPAN class=234512814-02092005>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. </SPAN><SPAN
class=234512814-02092005> </SPAN></FONT></FONT><BR></DIV>
<BLOCKQUOTE cite=midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG
type="cite"><PRE wrap=""> --keith
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">-----Original Message-----
From: <A class=moz-txt-link-abbreviated href="mailto:sis-csi-bounces@mailman.ccsds.org">sis-csi-bounces@mailman.ccsds.org</A>
[<A class=moz-txt-link-freetext href="mailto:sis-csi-bounces@mailman.ccsds.org">mailto:sis-csi-bounces@mailman.ccsds.org</A>] On Behalf Of Keith Hogie
Sent: Thursday, August 18, 2005 3:25 AM
To: <A class=moz-txt-link-abbreviated href="mailto:sis-csi@mailman.ccsds.org">sis-csi@mailman.ccsds.org</A>
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
</PRE></BLOCKQUOTE><PRE wrap=""><!---->section.
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">See what you think of the general structure and contents and we can
discuss it at this week's telecon.
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE class=moz-signature cols="72">----------------------------------------------------------------------
Keith Hogie e-mail: <A class=moz-txt-link-abbreviated href="mailto:Keith.Hogie@gsfc.nasa.gov">Keith.Hogie@gsfc.nasa.gov</A>
Computer Sciences Corp. office: 301-794-2999 fax: 301-794-9480
7700 Hubble Dr.
Lanham-Seabrook, MD 20706 USA 301-286-3203 @ NASA/Goddard
---------------------------------------------------------------------- </PRE></BLOCKQUOTE></BODY></HTML>