<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>RE: [Sis-csi] Green book thoughts</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>> Lloyd,<BR>
><BR>
> You left out the salient point ...<BR>
><BR>
>> Best thing to do is to document and describe it as some other <BR>
>> protocol and feed it into the RFC (or CCSDS) mix for evaluation.<BR>
><BR>
> They did that for HTTP, and SMTP, and ...<BR>
<BR>
... and they didn't do it for Real or Skype or Bittorrent, which have millions of users.<BR>
<BR>
The IESG is concerned with how protocols affect the terrestrial Internet, under the congestion/contention-oriented assumptions that I described in my first mail. A protocol that is deliberately intended for use internal to a private network for a specific purpose for a small group of users, under operating assumptions somewhat different from the terrestrial Internet (scheduling/dedicated use), rather than for use seen across the public Internet with competing traffic, would not be of particular interest to the IESG or to many other terrestrial users.<BR>
<BR>
So why trouble the IESG by attempting to describe a minority-interest protocol, when protocols with millions of users (as opposed to none) sending traffic across the public Internet with more years of operational experience have not gone the standards route?<BR>
<BR>
> That's how layered protocols in the standards world are described, as a set of separate, <BR>
> formal, openly accessible specifications.<BR>
><BR>
> It's essential to know <BR>
> that some XYZ protocol is layered upon TCP or UDP, but saying it's <BR>
> UDP-based without providing a complete formal specification is no <BR>
> more meaningful than saying that every other Internet protocol is "IP-<BR>
> based".<BR>
<BR>
It remains a completely accurate description. The description indicates that Internet technology is being reused without being reinvented, and at what point the reuse ends and the custom protocol design begins.<BR>
<BR>
L.<BR>
<BR>
Do you have a complete formal specification for your toaster? Do you eat the toast?<BR>
<BR>
On Apr 18, 2006, at 4:33 PM, <L.Wood@surrey.ac.uk> wrote:<BR>
<BR>
> > UDP with NACks is NOT UDP, it's some other protocol.<BR>
><BR>
> It's a protocol using UDP. Using layering.<BR>
><BR>
> > Making believe that this protocol is UDP just because you use the<BR>
> > UDP PDU structure is false advertising.<BR>
><BR>
> The UDP structure, like the IP structure, is designed to be built <BR>
> on, with applications implementing what they need over UDP. That's <BR>
> what UDP is designed *for*. That's how engineers build protocols -- <BR>
> like CFDP -- that use UDP. That's why I said the protocol was UDP-<BR>
> based -- which it is.<BR>
><BR>
> Presumably you'd also object to me describing the HTTP transfer <BR>
> protocol as TCP-based. ("It's TCP with added semantics! It's not <BR>
> TCP! You can't claim your web browser is using TCP or sending TCP <BR>
> traffic!" Even though, obviously, the web browser is.)<BR>
><BR>
> You can use IP -- and UDP -- and be enhanced. That's what clean <BR>
> protocol layering and not reinventing the wheel is all about. <BR>
> That's what UDP is intended for. It works for Real. For Skype. And <BR>
> for many other UDP-based protocols.<BR>
><BR>
> L.<BR>
><BR>
> > Peter<BR>
><BR>
><BR>
><BR>
> On Apr 18, 2006, at 11:15 AM, <L.Wood@surrey.ac.uk> wrote:<BR>
><BR>
> > Resending the below, now that I've subscribed as<BR>
> > L.Wood@surrey.ac.uk rather than L.Wood@eim.surrey.ac.uk, so admin<BR>
> > approval of all my messages should no longer be required.<BR>
> ><BR>
> > -----Original Message-----<BR>
> > From: Wood L Dr (Electronic Eng)<BR>
> > Sent: Tue 2006-04-18 18:58<BR>
> > To: Scott, Keith L.; Keith Hogie; sis-csi@mailman.ccsds.org<BR>
> > Subject: RE: [Sis-csi] Green book thoughts<BR>
> ><BR>
> > My take:<BR>
> ><BR>
> > It's not a question of space link capacities being relatively<BR>
> > speaking too low (though those will always lag terrestrial link<BR>
> > capacities).<BR>
> ><BR>
> > High-rate UDP-based flows from space have the ability to cause<BR>
> > congestion, but won't congest the (permanently-connected,<BR>
> > terrestrial) network because they'll always be deliberately set to<BR>
> > deliver to the edges of that network. This is a sensible design<BR>
> > choice.<BR>
> ><BR>
> > Example: SSTL's Saratoga rate-based UDP-based transfer protocol<BR>
> > with NACKs, which fills an 8.1Mbps downlink from the five DMC<BR>
> > satellites, and delivers the flow to a host in the groundstation on<BR>
> > the edge of the Internet. Because that's sensible engineering;<BR>
> > congestion is not a problem on links you own (and want to get the<BR>
> > most from), while congestion on the internetwork is avoided through<BR>
> > deliberate selection of endhost locations.<BR>
> ><BR>
> > (Described in our 'Using Internet nodes and routers onboard<BR>
> > satellites' paper at:<BR>
> > <A HREF="ftp://ftp-eng.cisco.com/lwood/cleo/README.html">ftp://ftp-eng.cisco.com/lwood/cleo/README.html</A><BR>
> > which we recently updated thanks to another six months of in-orbit<BR>
> > use. I'd like to give another example as well, but the DMC<BR>
> > satellites are the only ones I know that generate large amounts of<BR>
> > data and move it at high rates using IP.)<BR>
> ><BR>
> > Your point 2) - real-time data with loss, reliable data with no<BR>
> > loss -- we've done both of these using UDP streams. I'd want to<BR>
> > carefully word discussion to avoid the 'it has to be reliable so we<BR>
> > must use TCP or SCTP' mindset.<BR>
> ><BR>
> > There's nothing stopping you from filling your own links or your<BR>
> > own network; given sensible engineering choices, it's only where<BR>
> > you're peering traffic across the terrestrial Internet and crossing<BR>
> > different use models that congestion comes into play on the path.<BR>
> ><BR>
> > It's likely that any use of shared space links will be based on a<BR>
> > coarse-grained scheduling model where payloads get given<BR>
> > coordinated access to the links for efficiency reasons -- still<BR>
> > based on IP, but the congestion models and contention assumptions<BR>
> > of the terrestrial Internet won't be immediately applicable. And<BR>
> > the main reason they're not applicable is that, for a long time to<BR>
> > come, agencies won't be ISPs with competing users contending in<BR>
> > real-time for shared link capacity; any contention will be for<BR>
> > slots in a coarse scheduling model, likely well in advance.<BR>
> ><BR>
> > You can run IP across a single link too. If you're running IP from<BR>
> > a payload across a single point-to-point link to an endhost on the<BR>
> > other end of that link (and you own the lot), internetwork<BR>
> > congestion is not your problem.<BR>
> ><BR>
> > When you talk about 'affecting the network' you need to state what<BR>
> > that network *is*. You're really worried about affecting the<BR>
> > Internet as a whole, right? I think we need to state that the<BR>
> > Internet is both protocols and conventional assumptions of use<BR>
> > (congestion, peering sharing) and that we can reuse many of the<BR>
> > protocols without also having to reuse the assumptions. We have our<BR>
> > own use models. TCP is built around a number of assumptions that<BR>
> > don't fit our use (congestion, backoff, slow start presuming a<BR>
> > shared path), so we avoid those limiting assumptions by building<BR>
> > upon UDP for the space-based Internet.<BR>
> ><BR>
> > L.<BR>
> ><BR>
> > UDP forever.<BR>
> ><BR>
> > -----Original Message-----<BR>
> > From: sis-csi-bounces@mailman.ccsds.org on behalf of Scott, Keith L.<BR>
> > Sent: Tue 2006-04-18 18:10<BR>
> > To: Keith Hogie; sis-csi@mailman.ccsds.org<BR>
> > Subject: RE: [Sis-csi] Green book thoughts<BR>
> ><BR>
> > It seems to me that the points of contention here center on <BR>
> whether or<BR>
> > not an application using UDP might cause network congestion and <BR>
> hence<BR>
> > lose packets, and whether/how building reliability on top of UDP <BR>
> is a<BR>
> > Good Idea. The arguments seem to oscillate between high-bandwidth<BR>
> > downlinks where we want to use all of the available capacity and the<BR>
> > assertion that UDP flows from space (there's a B-movie title in <BR>
> there<BR>
> > somewhere...) simply can't congest the "network" because the space<BR>
> > link<BR>
> > bandwidth is too low.<BR>
> ><BR>
> > I would assert that for some (possibly many?) future missions,<BR>
> > bandwidths will be such that pure rate-controlled streams coming <BR>
> from<BR>
> > some space applications would have the ability to congest shared<BR>
> > (space<BR>
> > and/or ground). A single HDTV stream competing with any other<BR>
> > appreciable flows in the ground or space portions of the network <BR>
> could<BR>
> > do this, e.g. I also don't think we can assert that streams will <BR>
> not<BR>
> > cross some portion of shared network, especially if there is<BR>
> > inter-agency cross-support. One must consider the possibility of<BR>
> > commercial ground stations, and also the possibility of shared in-<BR>
> > space<BR>
> > crosslinks.<BR>
> ><BR>
> ><BR>
> ><BR>
> > That said, do we all agree (at least among ourselves -- the case <BR>
> will<BR>
> > need to be made to external audiences) that:<BR>
> > 1) Moving to IP provides a large benefit to missions in that:<BR>
> > o it decouples applications from the data links<BR>
> > o it facilitates multi-hop routing over heterogeneous data<BR>
> > links<BR>
> > o it provides an efficient multiplexing mechanism for <BR>
> numerous<BR>
> > data types<BR>
> > o traffic can be directly routed from ground stations over<BR>
> > closed networks<BR>
> > or the Internet to its destination(s) on the ground with<BR>
> > commercial<BR>
> > network equipment<BR>
> ><BR>
> > 2) We don't really know how operators will want to use a networked<BR>
> > capability,<BR>
> > except that they will probably want some mix of real-time data<BR>
> > that can<BR>
> > take loss and reliable data that wants no loss. These are<BR>
> > supportable<BR>
> > in continuously connected environments by TCP, UDP, and NORM <BR>
> (the<BR>
> > latter<BR>
> > two supporting simplex environments, to some extent); and in<BR>
> > disconnected<BR>
> > environments by overlays like CFDP, and DTN.<BR>
> ><BR>
> > 3) Building application-specific reliability mechanisms on top of<BR>
> > UDP<BR>
> > is<BR>
> > an option, but *in general*, new applications should first<BR>
> > look to<BR>
> > standard<BR>
> > transport mechanisms (exact list TBD from Red Books from <BR>
> this WG)<BR>
> > to<BR>
> > fulfill their needs. Non-congestion controlled flows that <BR>
> might<BR>
> > cause<BR>
> > significant network congestion are discouraged, but not<BR>
> > prohibited<BR>
> > if<BR>
> > circumstances require their use and they can be designed to<BR>
> > 'not-too-<BR>
> > adversely' affect the network. Note that 'not-too-adversely'<BR>
> > here<BR>
> > is<BR>
> > an overall system design trade -- a particular application <BR>
> might<BR>
> > need to<BR>
> > simply blast bits without regard to the rest of the network.<BR>
> > Note<BR>
> > also<BR>
> > that the overlays mentioned above may be part of the <BR>
> recommended<BR>
> > set of<BR>
> > standard transports.<BR>
> ><BR>
> ><BR>
> > --keith<BR>
> ><BR>
> ><BR>
> ><BR>
> ><BR>
> ><BR>
> ><BR>
> > >-----Original Message-----<BR>
> > >From: sis-csi-bounces@mailman.ccsds.org<BR>
> > >[<A HREF="mailto:sis-csi-bounces@mailman.ccsds.org">mailto:sis-csi-bounces@mailman.ccsds.org</A>] On Behalf Of Keith Hogie<BR>
> > >Sent: Tuesday, April 18, 2006 2:33 AM<BR>
> > >To: sis-csi@mailman.ccsds.org<BR>
> > >Subject: Re: [Sis-csi] Green book thoughts<BR>
> > ><BR>
> > >More thoughts about Keith Scott, and Scott Burleigh's comments<BR>
> > >inline below.<BR>
> > ><BR>
> > >Scott Burleigh wrote:<BR>
> > >> Scott, Keith L. wrote:<BR>
> > >><BR>
> > >>>Keith,<BR>
> > >>><BR>
> > >>>I've integrated most of this into the document, but I have a<BR>
> > >few issues<BR>
> > >>>inline.<BR>
> > >>><BR>
> > >>><BR>
> > >>>>-----Original Message-----<BR>
> > >>>>From: sis-csi-bounces@mailman.ccsds.org<BR>
> > >>>>[<A HREF="mailto:sis-csi-bounces@mailman.ccsds.org">mailto:sis-csi-bounces@mailman.ccsds.org</A>] On Behalf Of Keith<BR>
> > Hogie<BR>
> > >>>>Sent: Thursday, March 30, 2006 12:48 PM<BR>
> > >>>>To: sis-csi@mailman.ccsds.org<BR>
> > >>>>Subject: [Sis-csi] Green book thoughts<BR>
> > >>>><BR>
> > >>>>All,<BR>
> > >>>><BR>
> > >>>> Sorry for the late input but here are a few thoughts<BR>
> > >>>>and inputs for this afternoon's telecon. I couldn't see<BR>
> > >>>>shipping the whole 6 MB around to convey<BR>
> > >>>>this little bit of info.<BR>
> > >>>><BR>
> > >>>> These are based on Draft_15.doc<BR>
> > >>>><BR>
> > >>>>2.2.2 Telepresence/Telescience<BR>
> > >>>><BR>
> > >>>>.... At Cislunar (and Cismartian) distances there will be<BR>
> > >>>>significant degradation of such capabilities (telepresence) ...<BR>
> > >>>><BR>
> > >>>> This is true at the outer limits of these environments,<BR>
> > >but Cislunar<BR>
> > >>>><BR>
> > >>>><BR>
> > >>>>also includes everything from low-earth orbit out to beyond<BR>
> > >the moon.<BR>
> > >>>>I think we often focus on Cislunar being only lunar missions and<BR>
> > >>>>forget about all of the other missions like all of the current<BR>
> > >>>>"Cislunar satellites" already in orbit around the Earth.<BR>
> > >>>><BR>
> > >>>> Section 2.1 just got done mentioning that Cislunar covers<BR>
> > >>>>everything from LEO to L2. Somehow we need to be careful about<BR>
> > >>>>making broad statements about Cislunar. Do we need to break<BR>
> > >>>>down Cislunar into short, medium, and long or something like <BR>
> that.<BR>
> > >>>><BR>
> > >>>><BR>
> > >>>I'm trying to work this in conjunction with your comment on<BR>
> > scenarios<BR>
> > >>>below.<BR>
> > >>><BR>
> > >>><BR>
> > >> I'll insert a brief plea for conservation of language here.<BR>
> > >"cislunar"<BR>
> > >> means "lying between the earth and the moon or the moon's orbit"<BR>
> > >> (Webster's 9th New Collegiate Dictionary, 1991). If L2 is not in<BR>
> > >> cislunar space, but we specifically want this architecture<BR>
> > >to extend to<BR>
> > >> L2, then we should adopt a different name.<BR>
> > >><BR>
> > >> Alternatively, I think it would be reasonable to say that this<BR>
> > >> architecture is being *designed* for communications in<BR>
> > >cislunar space<BR>
> > >> but that in practice it might also be usable in other <BR>
> environments:<BR>
> > >> cis-L2 space, for example, or the space between Mars and its <BR>
> moons.<BR>
> > ><BR>
> > >True, L2 is beyond Cislunar. The main thought was to not<BR>
> > >sound like only Lunar but make it speak to a wider range of <BR>
> missions<BR>
> > >including LEO out to L2. There are still lots of missions coming<BR>
> > >up in those domains that have nothing to do with Exploration<BR>
> > >Initiative. Also this is a CCSDS document so it needs to address<BR>
> > >non-NASA missions in all environments.<BR>
> > ><BR>
> > >><BR>
> > >>>>4.4 Automated Data Forwarding<BR>
> > >>>><BR>
> > >>>> Not sure if the SLE reference really fits here. That is a<BR>
> > >>>>reference to the old circuit switch concept and not routing<BR>
> > >>>>based on addresses in packets. SLE doesn't do IP packet<BR>
> > >>>>forwarding and doesn't apply in an end-to-end IP architecture<BR>
> > >>>>does it<BR>
> > >>>><BR>
> > >>>><BR>
> > >>>I think the data forwarding part of SLE here (as opposed to<BR>
> > >the service<BR>
> > >>>management part) is just a tunneling mechanism like GRE.<BR>
> > >Its inclusion<BR>
> > >>>allows the space (data) link protocol to be terminated somewhere<BR>
> > else<BR>
> > >>>besides the ground station. That's how many agencies are set <BR>
> up to<BR>
> > >>>operate now, and they'll probably continue with it until they can<BR>
> > get<BR>
> > >>>equipment at the ground stations to terminate the space data<BR>
> > >links AND<BR>
> > >>>something to provide reliability, or ate least comprehensive data<BR>
> > >>>accounting.<BR>
> > >>><BR>
> > >>><BR>
> > ><BR>
> > >SLE is not really like GRE. GRE operates at the network layer<BR>
> > >as part of the packet routing process and simply forwards packets<BR>
> > >one-by-one. SLE is a tunnel operating above the transport layer<BR>
> > >and has TCP acknowledgments. It also is related to the legacy<BR>
> > >"circuit" concept where there is only one hop beyond the ground<BR>
> > >station. At the last SCAWG there was a discussion about being<BR>
> > >able to forward data received with errors. You can do that with<BR>
> > >SLE but it only applies to the first hop from the ground station.<BR>
> > >If packets are forwarding across multiple space links based on<BR>
> > >IP addresses, you cannot forward errored data. At some point we<BR>
> > >need to decide if we are moving to packet forwarding or staying <BR>
> with<BR>
> > >the circuit model.<BR>
> > ><BR>
> > >There are already many stations that forward IP packets directly<BR>
> > >and things like "reliability" and "data accounting" are not a<BR>
> > >problem. The concept of "networking" in space means that some<BR>
> > >of the legacy notions of moving data over a single link from<BR>
> > >the control center to a spacecraft need to change. A packet<BR>
> > >forwarding model has some significant differences from the<BR>
> > >current circuit model.<BR>
> ><BR>
> > Exactly. We want to move to the state where the space link is<BR>
> > terminated at the ground station and packets are forwarded over <BR>
> an IP<BR>
> > network from there. But we're not there yet, and SLE is part of the<BR>
> > existing infrastructure. Hopefully missions will see benefits from<BR>
> > going to a more fully routed infrastructure and move away from <BR>
> SLE as<BR>
> > time passes, butmentioning that it's supported under this <BR>
> architecture<BR>
> > so as to provide a smooth transition path will help get us over the<BR>
> > (probably inevitable) initial resistance to 'new stuff'.<BR>
> ><BR>
> > >> Yes. I think the best way to think of SLE is simply as an<BR>
> > >extension of<BR>
> > >> the space link, as the name suggests. SLE doesn't do packet<BR>
> > >forwarding<BR>
> > >> any more than AOS or TM does; the SLE engine at the ground<BR>
> > >station is a<BR>
> > >> repeater, not a router. It's underneath the end-to-end IP<BR>
> > >architecture<BR>
> > >> in exactly the same way that AOS or TM or Prox-1 is underneath <BR>
> the<BR>
> > >> end-to-end IP architecture, forming what is functionally a single<BR>
> > >> point-to-point link between the spacecraft and the mission<BR>
> > >operations<BR>
> > >> center where IP is terminated.<BR>
> > >><BR>
> > >>>>Should this mention things like standard automated routing<BR>
> > >>>>protocols like RIP, OSPF, Mobile IP, MANET stuff, etc. along<BR>
> > >>>>with static routing.<BR>
> > >>>><BR>
> > >>>>4.4.1 Forwarding, Routing<BR>
> > >>>><BR>
> > >>>> This mentions that "This will allow mission operations<BR>
> > >>>>personnel to maintain absolute control over the forwarding<BR>
> > >>>>process..." They don't really have that control today and<BR>
> > >>>>won't have it in the future. Today they may indicate that<BR>
> > >>>>they want their commands sent to a particular antenna but<BR>
> > >>>>they don't control the exact path from their control center,<BR>
> > >>>>across all links, to the antenna.<BR>
> > >>>><BR>
> > >>>> I don't think we want to give them the impression that<BR>
> > >>>>they can control all routers in NASA's operational networks.<BR>
> > >>>><BR>
> > >>>><BR>
> > >>>Right, this was referring mainly to the space portion of the<BR>
> > network.<BR>
> > >>><BR>
> > >>><BR>
> > >> I'm uneasy about this too. It may be something we've got to say<BR>
> > for<BR>
> ><BR>
> > >> political reasons in the near term, but if we've got mission<BR>
> > >operations<BR>
> > >> personnel acting in the capacity of IP packet routers in the<BR>
> > >> interplanetary network of the future then I think we are<BR>
> > >going to look<BR>
> > >> pretty silly. Not quite as bad as using avian carriers to<BR>
> > >convey the<BR>
> > >> packets, but close.<BR>
> > >><BR>
> > >>>>4.6 Transport layer<BR>
> > >>>><BR>
> > >>>> --- insert after first paragraph ---<BR>
> > >>>><BR>
> > >>>> UDP provides a data delivery very similar to standard<BR>
> > >>>>TDM and CCSDS packet delivery systems that are currently<BR>
> > >>>>used for space communication. It's unreliable delivery<BR>
> > >>>>attribute means that it does not utilize any process,<BR>
> > >>>>such as acknowledgments, for determining if the data<BR>
> > >>>>gets to its destination. Reliable delivery can be<BR>
> > >>>>implemented over UDP in the application layer if desired<BR>
> > >>>>with applications such as CFDP.<BR>
> > >>>><BR>
> > >>>><BR>
> > >>>This is true, but I don't want to give mission software people <BR>
> the<BR>
> > >>>impression that they can just hack up reliability on a<BR>
> > >per-application<BR>
> > >>>basis.<BR>
> > >>><BR>
> > ><BR>
> > >But mission people can do whatever reliability they want on<BR>
> > >a per-application basis. That is one of the great features<BR>
> > >of layers and the Internet. The only people that need to agree<BR>
> > >on an end-to-end reliable transfer protocol are the two end systems<BR>
> > >(e.g. satellite and control center). On the current Internet there<BR>
> > >are all sorts of different reliable data delivery options that<BR>
> > >co-exist. They are both TCP and UDP based.<BR>
> ><BR>
> > Yes, however, if every mission spends all its time redesigning<BR>
> > retransmission schemes, it will:<BR>
> ><BR>
> > 1) lose any benefit of standardization obove IP (increased <BR>
> development<BR>
> > time/cost)<BR>
> > 2) possibly cause those flows to be penalized (classified as<BR>
> > nonresponsive under RED, e.g.)<BR>
> ><BR>
> > 2) is very dangerous, IMHO, as it would cause the system to behave<BR>
> > poorly, interacts adversely with existing deployed Internet<BR>
> > infrastructure, and would cause the missions to simply blame <BR>
> 'that new<BR>
> > networking stuff'.<BR>
> ><BR>
> > >> Absolutely. That would be a serious blow to interoperability and<BR>
> > >> low-cost mission software development, just as abandoning TCP in<BR>
> > the<BR>
> ><BR>
> > >> terrestrial Internet would be. A huge step backward.<BR>
> > >><BR>
> > ><BR>
> > >The big interoperability comes from using IP everywhere and does<BR>
> > >not require TCP at all. The Internet has both TCP and UDP<BR>
> > >traffic flowing over it all the time. Things like voice and video<BR>
> > >and my son's Game Boy use UDP for all sorts of streaming <BR>
> operations.<BR>
> > >TCP is the wrong answer for many data flows. We don't want to<BR>
> > >abandon TCP but we also cannot mandate only TCP. All current<BR>
> > >space missions operate in a UDP-like mode and there are many good<BR>
> > >reasons for that.<BR>
> > ><BR>
> ><BR>
> > 75% of Internet flows are TCP-based; 95% of the bytes are. I'm not<BR>
> > advocating for using TCP if you don't need reliability; by all means<BR>
> > use UDP. But for applications that want 100% data return and may<BR>
> > traverse a large shared network like the Internet, I think there <BR>
> needs<BR>
> > to be a Really Good Reason (TM) before a mission ditches TCP and<BR>
> > writes<BR>
> > their own. I would soften my position somewhat for missions <BR>
> existing<BR>
> > widely-deployed tools that do "CFDP-like" things and that coexist<BR>
> > peacefully in the Internet at large.<BR>
> ><BR>
> > ><BR>
> > >>> CFDP is sort of a special case and I'm not sure how well even<BR>
> > >>>it would play in a mixed envrionment (that is, I'm not sure if <BR>
> CFDP<BR>
> > >>>implements TCP-friendly congestion control).<BR>
> > >>><BR>
> > >> It does not. There is no congestion control in the CFDP design.<BR>
> > >><BR>
> > ><BR>
> > >I don't see CFDP as a special case. That is exactly the mode that<BR>
> > >lots of missions want to use and will continue to use. It works<BR>
> > >very well for space communications across a dedicated RF link. I<BR>
> > >realize that UDP file transfer mechanisms have potential for<BR>
> > >flooding a network and that CFDP does not specify any flow control.<BR>
> > >But missions do have a very strong flow control in that they<BR>
> > >have a fixed upper limit on their RF transmission rate.<BR>
> > ><BR>
> > >When a satellite turns on its power hungry transmitter,<BR>
> > >it wants to be able to fill the RF link with data and does not<BR>
> > >want to worry about flow control by any protocol. Especially<BR>
> > >any protocol that might require a two-way link. The bandwidth<BR>
> > >of the link has been set during mission design and the software<BR>
> > >wants to allocate it among things like housekeeping data and<BR>
> > >science data. Satellites do not operate in a highly interactive<BR>
> > >or whimsical nature like people surfing the Internet. They<BR>
> > >have much more highly planned and predictable data transfers.<BR>
> > ><BR>
> > >Also, as propagation delays get longer, it becomes even more<BR>
> > >important to use UDP based protocols because you cannot get<BR>
> > >any interactive flow control information. Also with the current<BR>
> > >high downlink rates and very low uplink rates UDP works much<BR>
> > >better to allow missions to shove data down and not need to<BR>
> > >have ACKs coming back up. Things like TDRSS demand access are<BR>
> > >another reason for using UDP. DAS only gives you a one-way<BR>
> > >link so you have to use something like CFDP over UDP.<BR>
> ><BR>
> > Wouldn't this lead to each mission simply blasting at the maximum<BR>
> > downlink rate and losing a bunch of packets at some bottleneck along<BR>
> > the path (especially if that path traverses the Internet). TDRSS<BR>
> > demand access or other paths with simplex links will require UDP and<BR>
> > (hopefully) some notion of buffering, rate-limiting, or otherwise<BR>
> > protecting the data once it makes it to the ground and before it is<BR>
> > released into a network where it may get lost.<BR>
> ><BR>
> > >For the next 10 to 15 years I see UDP as the primary means<BR>
> > >of data delivery for space missions. There are some areas<BR>
> > >where TCP is OK but the majority of data will be delivered<BR>
> > >using UDP based techniques. We won't have any large mesh<BR>
> > >network in space for quite awhile and issues of multiple<BR>
> > >missions data merging over shared links will not be an<BR>
> > >issue anytime soon. Right now we need to get basic<BR>
> > >IP packet routing available so missions can benefit from<BR>
> > >using standard communication techniques with widely<BR>
> > >available hardware and software support.<BR>
> ><BR>
> > The problem isn't the space network, it's once the flow hits the<BR>
> > ground<BR>
> > network (Internet or closed multi-agency data distribution network).<BR>
> ><BR>
> > >>>Think about the<BR>
> > >>>conditions under which TCP underperforms a UDP-based scheme<BR>
> > >-- the win<BR>
> > >>>seems to be in those cases where you have enough loss to build an<BR>
> > >>>out-of-sequence queue at the receiver and then can't fill it<BR>
> > >until the<BR>
> > >>>end of the communications session. In such cases a UDP-based<BR>
> > >>>application could get immediate access to the 'out-of-sequence'<BR>
> > data,<BR>
> > >>>but presumably would still have the same set of holes. Given the<BR>
> > low<BR>
> > >>>(relative to interplanetary) distances, power levels, and data<BR>
> > rates<BR>
> > >>>people talk about for crewed lunar exploration, is this<BR>
> > >really going to<BR>
> > >>>be a problem?<BR>
> > >>><BR>
> > ><BR>
> > >Any data where timely delivery is more important that complete<BR>
> > >delivery must use UDP. This is things like voice, video, and<BR>
> > >realtime telemetry. For the last 30 years that I have been<BR>
> > >processing satellite data, we have always lived without<BR>
> > >hardly any retransmission protocols. You get the data that<BR>
> > >you get and you deal with it. Moving to files onboard is<BR>
> > >a major change and then doing reliable delivery is another<BR>
> > >change. Using files onboard a spacecraft and then some sort<BR>
> > >of UDP based file transfer with NACKs is the mode that missions<BR>
> > >relate to and will be using for many years. I think TCP based<BR>
> > >operations will only have limited usage.<BR>
> > >>><BR>
> > >>>> One advantage of UDP is that since it does not require<BR>
> > >>>>any acknowledgments, its operation is not affected by<BR>
> > >>>>propagation delay and it can also function over one-way<BR>
> > >>>>links. UDP provides an alternative to TCP in scenarios<BR>
> > >>>>where TCP performance suffers due to delays and errors.<BR>
> > >>>>Since UDP doesn't require acknowledgments, it allows<BR>
> > >>>>end-system application implementors to design their<BR>
> > >>>>own retransmission schemes to meet their particular<BR>
> > >>>>environment.<BR>
> > >>>><BR>
> > >>>><BR>
> > >>>Again true, but I think this needs to be said very carefully, <BR>
> lest<BR>
> > >>>everyone decide that it would be more fun to design their own<BR>
> > >>>retransmission schemes than to work the application <BR>
> protocols. The<BR>
> > >>>hidden assumption here is that if TCP performance suffers<BR>
> > >due to delays<BR>
> > >>>and errors, I can do a better job with my retransmission<BR>
> > >protocol over<BR>
> > >>>UDP. While there are alternate congestion control schemes<BR>
> > >(e.g. Steven<BR>
> > >>>Low's FAST TCP, maybe some aspects of SCTP) that we could end up<BR>
> > >>>recommending, I doubt most flight software programs ability to<BR>
> > >>>correctly design and implement something with wide applicability.<BR>
> > >>>That's not meant as a knock on the flight software people -- the<BR>
> > task<BR>
> > >>>of writing a new transport layer that works well under the full<BR>
> > range<BR>
> > >>>of conditions is huge - much bigger than a single mission -<BR>
> > >and they've<BR>
> > >>>got N other things to do that are mission-specific and<BR>
> > >higher priority.<BR>
> > >>><BR>
> > >>><BR>
> > >> And a way better use of taxpayer money.<BR>
> > ><BR>
> > >Flow control is implemented by the limited RF bandwidth of<BR>
> > >spacecraft and that is not going to change anytime soon.<BR>
> > >What is the problem with one mission using CFDP, while others<BR>
> > >use MDP, NORM, Digital Fountain, NFS, or any other file delivery<BR>
> > >mechanism they want. The "network" is there to forward packets<BR>
> > >and support whatever the users want to do.<BR>
> ><BR>
> > The only issue is how these various protocols intereact with each<BR>
> > other<BR>
> > and other traffic on the same network. One of the main points of<BR>
> > moving to an IP-based infrastructure is to allow a standard network<BR>
> > service to applications and to provide efficient and flexible<BR>
> > multiplexing of multiple traffic types onto (constrained) links.<BR>
> ><BR>
> > >><BR>
> > >>>> UDP is also commonly used for data delivery<BR>
> > >>>>scenarios where timeliness of delivery is more important<BR>
> > >>>>than completeness. Common uses include streaming data<BR>
> > >>>>such as voice and video. It is also used for multicast<BR>
> > >>>>delivery where the same data is sent to multiple<BR>
> > >>>>destinations and it is not desirable to have<BR>
> > >>>>multiple acknowledgments returning from all the<BR>
> > >>>>destinations.<BR>
> > >>>><BR>
> > >>>><BR>
> > >> Sure, UDP is wholly appropriate where there's no need for<BR>
> > >fine-grained<BR>
> > >> retransmission.<BR>
> > >><BR>
> > >>>>4.8 Store-and Forward for Disrupted Environments<BR>
> > >>>><BR>
> > >>>>Seems to jump to DTN rather quickly. We have survived<BR>
> > >>>>for many years doing store-and-forward based on files<BR>
> > >>>>or big chunks of data and that will still work fine for<BR>
> > >>>>many future missions. We don't need to tell them that<BR>
> > >>>>they need to completely change what they are used to<BR>
> > >>>>just because we are putting in IP.<BR>
> > >>>><BR>
> > >>>><BR>
> > >>>I moved the DTN section to after TCP transport, which I think <BR>
> flows<BR>
> > >>>pretty well. I like your idea of tying the file-based<BR>
> > >>>store-and-forward to current mission operations procedures.<BR>
> > >>><BR>
> > >>><BR>
> > >>>>How about something like<BR>
> > >>>><BR>
> > >>>>A critical component of the cislunar architecture for dealing<BR>
> > >>>>with cases<BR>
> > >>>>where there is not an end-to-end path between source and<BR>
> > >>>>destination is<BR>
> > >>>>the use of store-and forward mechanisms. The store-and-forward<BR>
> > >>>>function can occur at either the packet level or file level.<BR>
> > >>>>Traditional store-and-forward space communication occur at<BR>
> > >the file or<BR>
> > >>>><BR>
> > >>>><BR>
> > >>>>mass-storage partition level with files being stored at<BR>
> > >each hop and<BR>
> > >>>>forwarded later. Another option is to do store-and-forward <BR>
> at the<BR>
> > >>>>packet level with approaches such as Delay/Disruption Tolerant<BR>
> > >>>>Networking (DTN).<BR>
> > >>>><BR>
> > >>>Mostly correct, except that DTN is in fact store-and-forward <BR>
> at the<BR>
> > >>>file level. One could think of DTN as the refactoring of CFDP's<BR>
> > >>>multi-hop transport mechanisms (as distinct from its file system<BR>
> > >>>manipulation capabilities) married to a general-purpose API.<BR>
> > >>><BR>
> > >>><BR>
> > >> I completely agree with the second sentence, but not with<BR>
> > >the first.<BR>
> > >> DTN is store-and-forward at the file level if CFDP packages<BR>
> > >each file in<BR>
> > >> a single bundle; I personally don't see that happening, though.<BR>
> > The<BR>
> ><BR>
> > >> understanding I've been working under is that scientists are<BR>
> > >perfectly<BR>
> > >> happy with the out-of-order and incremental arrival of the<BR>
> > >individual<BR>
> > >> records of files as in CFDP, so waiting for the entire file<BR>
> > >to arrive<BR>
> > >> before delivering it would be a retreat from the CFDP<BR>
> > >design. What's<BR>
> > >> more, the scenarios for using multiple ground stations in<BR>
> > >parallel to<BR>
> > >> transmit a single file rely on individual records being <BR>
> separately<BR>
> > >> routable over multiple parallel reliable links (nominally<BR>
> > >LTP-enabled).<BR>
> > >> Both concepts amount to fine-grained transmission of file<BR>
> > >data, which I<BR>
> > >> think means packaging each record (or PDU, with maybe some<BR>
> > >aggregation<BR>
> > >> to optimize performance) in single bundle.<BR>
> > ><BR>
> > >I think we need to have more discussions on relevant satellite<BR>
> > >operations scenarios. Scientists have always wanted some data<BR>
> > >in realtime and then wait for processed data. 30 years ago it<BR>
> > >would often take anywhere from 9 months to 2 years for scientists<BR>
> > >to get their processed data. Now it gets there quicker but there<BR>
> > >are still delays. A common mode is for a level-zero processing<BR>
> > >system to gather realtime science data and playback data, merge<BR>
> > >it all together in a timewise sequence to get the most complete<BR>
> > >set of data, and then create data products consisting of 24 hours<BR>
> > >of data from midnight to midnight.<BR>
> > ><BR>
> > >Some of the DTN scenarios I have seen don't seem to relate to<BR>
> > >spacecraft data transfer needs. Things like HTTP GET requests<BR>
> > >and web page caching make lots of sense in a DoD environment but<BR>
> > >I don't see them in satellite operations. If we are going to <BR>
> mention<BR>
> > >DTN, we need a much better description on what it is and how it<BR>
> > >fits into unmanned, science satellite operations. Web page<BR>
> > >caching may have some application 15 years from now in a manned<BR>
> > >environment but we have lots more unmanned missions coming up<BR>
> > >now and they have much different data transfer needs.<BR>
> > ><BR>
> > ><BR>
> > >><BR>
> > >> Which is why I've been pounding so hard on bandwidth<BR>
> > >efficiency in the<BR>
> > >> bundle protocol. I'm expecting DTN in space to *not* be all <BR>
> about<BR>
> > >> multi-megabyte bundles where blowing 460 bytes on a header is a<BR>
> > >> non-issue. I'm expecting it to be about fairly small<BR>
> > >bundles, on the<BR>
> > >> order of 64KB, which can't tolerate big headers.<BR>
> > >><BR>
> > >> Scott<BR>
> > >><BR>
> > >><BR>
> > >><BR>
> > >---------------------------------------------------------------<BR>
> > >---------<BR>
> > >><BR>
> > >> _______________________________________________<BR>
> > >> Sis-CSI mailing list<BR>
> > >> Sis-CSI@mailman.ccsds.org<BR>
> > >> <A HREF="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</A><BR>
> > ><BR>
> > ><BR>
> > >--<BR>
> > <BR>
> >---------------------------------------------------------------------<BR>
> > -<BR>
> > > Keith Hogie e-mail: Keith.Hogie@gsfc.nasa.gov<BR>
> > > Computer Sciences Corp. office: 301-794-2999 fax:<BR>
> > >301-794-9480<BR>
> > > 7700 Hubble Dr.<BR>
> > > Lanham-Seabrook, MD 20706 USA 301-286-3203 @ NASA/<BR>
> Goddard<BR>
> > <BR>
> >---------------------------------------------------------------------<BR>
> > -<BR>
> > ><BR>
> > >_______________________________________________<BR>
> > >Sis-CSI mailing list<BR>
> > >Sis-CSI@mailman.ccsds.org<BR>
> > ><A HREF="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</A><BR>
> > ><BR>
> ><BR>
> > _______________________________________________<BR>
> > Sis-CSI mailing list<BR>
> > Sis-CSI@mailman.ccsds.org<BR>
> > <A HREF="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</A><BR>
> ><BR>
> ><BR>
> ><BR>
> > _______________________________________________<BR>
> > Sis-CSI mailing list<BR>
> > Sis-CSI@mailman.ccsds.org<BR>
> > <A HREF="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</A><BR>
><BR>
> ________________________________________________________<BR>
><BR>
> Peter Shames<BR>
> CCSDS System Engineering Area Director<BR>
><BR>
> Jet Propulsion Laboratory, MS 301-265<BR>
> California Institute of Technology<BR>
> Pasadena, CA 91109 USA<BR>
><BR>
> Telephone: +1 818 354-5740, Fax: +1 818 393-1333<BR>
><BR>
> Internet: Peter.Shames@jpl.nasa.gov<BR>
> ________________________________________________________<BR>
><BR>
> We must recognize the strong and undeniable influence that our<BR>
> language exerts on our ways of thinking and, in fact, delimits the<BR>
> abstract space in which we can formulate - give form to - our <BR>
> thoughts.<BR>
><BR>
> Niklaus Wirth<BR>
><BR>
><BR>
><BR>
><BR>
><BR>
> _______________________________________________<BR>
> Sis-CSI mailing list<BR>
> Sis-CSI@mailman.ccsds.org<BR>
> <A HREF="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</A><BR>
<BR>
________________________________________________________<BR>
<BR>
Peter Shames<BR>
CCSDS System Engineering Area Director<BR>
<BR>
Jet Propulsion Laboratory, MS 301-265<BR>
California Institute of Technology<BR>
Pasadena, CA 91109 USA<BR>
<BR>
Telephone: +1 818 354-5740, Fax: +1 818 393-1333<BR>
<BR>
Internet: Peter.Shames@jpl.nasa.gov<BR>
________________________________________________________<BR>
<BR>
We must recognize the strong and undeniable influence that our <BR>
language exerts on our ways of thinking and, in fact, delimits the <BR>
abstract space in which we can formulate - give form to - our thoughts.<BR>
<BR>
Niklaus Wirth<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>