<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Scott, Keith L. wrote:
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535935B99@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">Keith,
I've integrated most of this into the document, but I have a few issues
inline.
</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, March 30, 2006 12:48 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:sis-csi@mailman.ccsds.org">sis-csi@mailman.ccsds.org</a>
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
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->I'm trying to work this in conjunction with your comment on scenarios
below.
</pre>
</blockquote>
I'll insert a brief plea for conservation of language here. "cislunar"
means "lying between the earth and the moon or the moon's orbit"
(Webster's 9th New Collegiate Dictionary, 1991). If L2 is not in
cislunar space, but we specifically want this architecture to extend to
L2, then we should adopt a different name.<br>
<br>
Alternatively, I think it would be reasonable to say that this
architecture is being *designed* for communications in cislunar space
but that in practice it might also be usable in other environments:
cis-L2 space, for example, or the space between Mars and its moons.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535935B99@IMCSRV1.MITRE.ORG"
type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
</blockquote>
Yes. I think the best way to think of SLE is simply as an extension of
the space link, as the name suggests. SLE doesn't do packet forwarding
any more than AOS or TM does; the SLE engine at the ground station is a
repeater, not a router. It's underneath the end-to-end IP architecture
in exactly the same way that AOS or TM or Prox-1 is underneath the
end-to-end IP architecture, forming what is functionally a single
point-to-point link between the spacecraft and the mission operations
center where IP is terminated.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535935B99@IMCSRV1.MITRE.ORG"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->Right, this was referring mainly to the space portion of the network.
</pre>
</blockquote>
I'm uneasy about this too. It may be something we've got to say for
political reasons in the near term, but if we've got mission operations
personnel acting in the capacity of IP packet routers in the
interplanetary network of the future then I think we are going to look
pretty silly. Not quite as bad as using avian carriers to convey the
packets, but close.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535935B99@IMCSRV1.MITRE.ORG"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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.</pre>
</blockquote>
Absolutely. That would be a serious blow to interoperability and
low-cost mission software development, just as abandoning TCP in the
terrestrial Internet would be. A huge step backward.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535935B99@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap=""> 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).</pre>
</blockquote>
It does not. There is no congestion control in the CFDP design.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535935B99@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">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?
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
</blockquote>
And a way better use of taxpayer money.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535935B99@IMCSRV1.MITRE.ORG"
type="cite">
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
</blockquote>
Sure, UDP is wholly appropriate where there's no need for fine-grained
retransmission.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535935B99@IMCSRV1.MITRE.ORG"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">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).</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
</blockquote>
I completely agree with the second sentence, but not with the first.
DTN is store-and-forward at the file level if CFDP packages each file
in a single bundle; I personally don't see that happening, though. The
understanding I've been working under is that scientists are perfectly
happy with the out-of-order and incremental arrival of the individual
records of files as in CFDP, so waiting for the entire file to arrive
before delivering it would be a retreat from the CFDP design. What's
more, the scenarios for using multiple ground stations in parallel to
transmit a single file rely on individual records being separately
routable over multiple parallel reliable links (nominally
LTP-enabled). Both concepts amount to fine-grained transmission of
file data, which I think means packaging each record (or PDU, with
maybe some aggregation to optimize performance) in single bundle.<br>
<br>
Which is why I've been pounding so hard on bandwidth efficiency in the
bundle protocol. I'm expecting DTN in space to *not* be all about
multi-megabyte bundles where blowing 460 bytes on a header is a
non-issue. I'm expecting it to be about fairly small bundles, on the
order of 64KB, which can't tolerate big headers.<br>
<br>
Scott<br>
</body>
</html>