<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 8, 2024 at 10:09 AM <a href="mailto:lloyd.wood@yahoo.co.uk">lloyd.wood@yahoo.co.uk</a> <<a href="mailto:lloyd.wood@yahoo.co.uk">lloyd.wood@yahoo.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Keith,<br>
<br>
<br>
We're both well aware of the DTN and bundle efforts' origins in the "Interplanetary Internet" -- Vint and Adrian's very public effort in 1998 to get CCSDS to drag space agencies towards computing, networking, and packetisation, rising up the stack, rather than twiddling bits and tweaking waveforms at lower layers. (TCP/IP was rejected early solely because of TCP.)<br>
<br>
<br>
That's how it all started, through the ISOC IPNSIG, then the IRTF DTNRG charter to focus on the chosen bundle protocol, and then this DTN group continuing work on that bundle protocol. That's a lot of time, or inertia -- over a quarter century.<br>
<br>
<br>
The IETF serves the organisations who support sending 'individuals' to meetings and give them the time to participate on mailing lists, of course - the loudest voices and the people who keep turning up to participate get to set the agendas.<br>
<br>
<br>
The assumption underlying your post below seems to be that this dtn workgroup exists to serve CCSDS, and that CCSDS gets work done for free that it, as another standards body writing its own standards documents (red/blue books), is somehow not actually able to do itself in its own processes. (Why CCSDS is unable to do that would be an interesting discussion in itself.) You're concerned with how useful future dtn workgroup work will be to CCSDS.<br></blockquote><div> </div><div>Not at all, I think that a general IETF working group on Delay / Disruption Tolerant Networking is a great thing that will (could/should) benefit a huge community of users, not just space ones.</div><div><br></div><div>However, a cadere with the moniker 'deepspace' would seem well-advised to understand the environment and existing communities / organizations working in that area, especially since deep space exploration is still a very small community.  If / when commercialization of deep space happens that may change.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<br>
But CCSDS is not the only participant in this workgroup, and CCSDS doesn't have a lock on deep space. Who, apart from CCSDS, is attempting to use the bundle protocol? Who are the customers for and users of bundling? (Not space agencies -- yet. they're downstream from CCSDS, not yet sold on bundling, and the ramifications of CCSDS trying to sell them on the earlier CFDP are still trickling through the pipeline - visible in all those redundant CFDP-over-bundle demonstrations.)<br></blockquote><div><br></div><div>Absolutely I would love to see a larger community working with and benefiting from DTN-enabled communications, and I would be most pleased if the IETF dtn working group could accommodate their needs.  I'd LIKE (to the extent possible) for the IETF dtn wg to ALSO accommodate the needs of CCSDS (as a member of that community).  To that end, a somewhat general bundle protocol (or peer / alternative) that is well-suited to DTN environments and that can also be tailored as needed for specific communities (space, terrestrial, subterranean, oceanographic, etc.) and preferably that could interoperate among such communities, at least at some level, would seem to be useful.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<br>
Is CCSDS the sole or loudest voice here, or, if it isn't, should the IETF simply hand bundling off to CCSDS, saying "You now have real control of your own destiny. Here's a quarter-century of design and development, and we wish you well with it." and explore compelling alternatives?<br>
<br></blockquote><div><br></div><div>I don't think CCSDS is the loudest voice within the IETF dtn wg by far, as evidenced by participation / discussion, but I think it should (and the onus here falls on CCSDS, not the rest of the community) at least make their requirements / needs / concerns knowns so that the IETF can consider whether or not they should be supported in a DTN protocol (or protocols).</div><div><br></div><div><br></div><div><br></div><div><br></div><div>My main point was not that IETF should bend to CCSDS' will, it was more addressed to the deepspace folks.  If the 'deepspace' effort were just 'an alternative to BP' then I would still think they were misguided, but wouldn't be as concerned.  If they think they're going to be contributing to deepspace communications, I don't see that happening unless/until there is a large-scale shift there the likes of which SpaceX made to low-earth-orbit launches.  If we find something that's commercially viable to mine from the asteroid belt, people may start deploying infrastructure there in a heartbeat.</div><div><br></div><div>Best Regards,</div><div><br></div><div>  --keith</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
best<br>
<br>
<br>
Lloyd Wood <br>
<a href="mailto:lloyd.wood@yahoo.co.uk" target="_blank">lloyd.wood@yahoo.co.uk</a><br>
<br>
<br>
...remains manifestly not useful to CCSDS. Fittingly, battleships are obsolete.<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Wednesday 7 August 2024 at 20:42:19 GMT+10, Keith Scott <<a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a>> wrote: <br>
<br>
<br>
<br>
<br>
<br>
My concern with incorporating the 'deepspace' work into the dtn WG in the IETF will actually make the IETF dtn WG *less* useful to the folks actually pursuing (deep) space communications.<br>
<br>
1. The space community is extremely conservative<br>
    * It took about 7 years for CCSDS to do a profile of the experimental version of the Bundle Protocol (RFC5050).  That's seven years from the time the working group to do so was actually spun up; CCSDS spent 5 or 6 years prior to that socializing and advocating for the notion of networking for space communications.<br>
    * Space agencies invest a lot of time and money documenting requirements, documenting the processes used in the development of software, and designing, building and testing custom hardware for flight missions.  Changing the course of that battleship is a long, slow process that CCSDS has pursued over decades to advocate for, demonstrate, and socialize the benefits of space networking using BP.  Attempting to change course at this point would not be beneficial to those arguments (IMHO).<br>
    * There will not be two parallel architectures for deep space communications; the community and commercial market just isn't there.  There will almost certainly be a large enough community / market to support extending the Internet protocols as far as they can possibly go.  Such efforts might see Internet protocols run end-to-end to the Moon, assuming there is enough infrastructure (or people) on the moon to warrant 24/7 connectivity.<br>
    * <br>
    * The space community has spent a lot of time and effort advocating for the BP architecture supporting DTN.  An attempt to switch now to a purely Internet-based architecture would result in many space agencies / missions simply reverting to the previous 1-hop communications model and saying: "we'll wait to see how this all turns out".  The timescale for that 'wait-and-see' is measured in decades.<br>
2. The people participating in the 'deepspace' work don't seem to have a good idea of the requirements for deep space<br>
    * While space processing and operating systems have advanced greatly over the past couple of decades, they still lag behind their terrestrial counterparts by a hardware generation or so.  A number of factors contribute to this, ranging from the need for radiation hardening for some systems to the difficulties in certifying and launching even commercial hardware for the ISS.<br>
    * Just because a particular piece of hardware or software works on ISS does not mean that it will function for deep-space communications.  E.g. at one time (possibly still) there were Outlook servers on ISS running over TCP/IP.  That approach won't work (I don't think) to Mars, e.g.<br>
    * It's not just a matter of surviving long propagation times on a single (space) link; a viable deep space networking architecture needs to (IMHO):<br>
        * Handle the case where round trip times are highly variable.  For example, we may have constant connectivity on Earth TO the various antennas used to communicate with space, but the schedule for actually getting particular data onto a space link is, and will probably continue to be, highly scheduled and possibly irregular.  Thus the round trip time could vary from seconds when there is end-to-end connectivity to hours when there's not.  Alternately, if there is never end-to-end connectivity, RTTs could still vary greatly between two messages sent back-to-back if one message gets onto an earlier space link contact and the next has to wait for the next contact, e.g.<br>
        * Handle the case of 'mixed' communications where the end-to-end path crosses both a portion of the terrestrial Internet *and* space links.  So, for example, combining this with the above, when sending a gigabyte to an Earth-orbiting spacecraft via an optical terminal, you may need to route the data to the right ground terminal before the pass starts so that it can be sent at high rate once the spacecraft is available.  The transmission mechanism (transport) needs to obey Internet-like congestion control for the Internet portion, and then be able to change to blast data at full rate once the space link is available.  This seems to (though I'm open to other reasonable approces) require some sort of 'jointed / environment-aware' transport process that is not (just) end-to-end.<br>
        * Provide some mechanism to 'checkpoint' communications as they move through the network so that information that does get lost doesn't have to be detected by and retransmitted from the source.<br>
3. While the IETF can operate at the speed of rough consensus and running code, space organizations need stable documents (RFCs or the equivalent) in order to let procurements, especially in today's industry-oriented environment.  Attempting to generate and vet an alternative DTN architecture will slow the WG's progress.<br>
    * As an example, RFC9171, which started with a viable experimental RFC and strong backing from the space community, took nearly 7 years.  The primary changes to RFC5050 were to change the on-the-wire encoding and to remove functionality (data prioritization, reliability) that is required by the space community.<br>
    * Updating the ipn scheme has taken 2 years, hopefully nearly there but still counting<br>
    * In the meantime, NASA (and other space agencies') missions are progressing.  Where there are stable specifications they can use them but they are loathe to just 'make something up' (which could easily be done within the BPv6 and/or BPv7 frameworks) to work around the incomplete areas (see #1 above).<br>
    * Any alternative DTN architecture will need to be vetted against the requirements for space missions, demonstrated in flight experiments and re-litigated before the space agencies and their science communities.  For BP that process began in the early 200s with the first experimental flight in 2008; we saw our first real DTN-enabled mission (excluding ISS, the deployment of DTN onto which was a HUGE lift in itself by the folks at NASA's MSFC) in 2024.<br>
<br>
I suspect the result if the deepspace work is incorporated into the IETF dtn WG charter will be that CCSDS will continue forward with their profiles of the BPv7, BPSec, and hopefully network management specifications and then focus on defining their own extension blocks (either in CCSDS or the IETF) to address mission-specific needs.  The inevitable slowdown in the IETF dtn wg would render it less useful to any deep space efforts.<br>
<br>
<br>
v/r,<br>
<br>
    --keith<br>
<br>
<br>
</blockquote></div></div>