[Sis-dtn] [dtn] Re: [EXT] recharter to include deepspace

[Keith Scott]

On Thu, Aug 8, 2024 at 10:09 AM lloyd.wood at yahoo.co.uk <
lloyd.wood at yahoo.co.uk> wrote:

> Keith,
>
>
> 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.)
>
>
> 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.
>
>
> 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.
>
>
> 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.
>

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.

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.


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

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.


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




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.

Best Regards,

  --keith



> best
>
>
> Lloyd Wood
> lloyd.wood at yahoo.co.uk
>
>
> ...remains manifestly not useful to CCSDS. Fittingly, battleships are
> obsolete.
>
>
>
>
>
>
> On Wednesday 7 August 2024 at 20:42:19 GMT+10, Keith Scott <
> keithlscott at gmail.com> wrote:
>
>
>
>
>
> 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.
>
> 1. The space community is extremely conservative
>     * 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.
>     * 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).
>     * 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.
>     *
>     * 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.
> 2. The people participating in the 'deepspace' work don't seem to have a
> good idea of the requirements for deep space
>     * 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.
>     * 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.
>     * 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):
>         * 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.
>         * 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.
>         * 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.
> 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.
>     * 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.
>     * Updating the ipn scheme has taken 2 years, hopefully nearly there
> but still counting
>     * 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).
>     * 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.
>
> 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.
>
>
> v/r,
>
>     --keith
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240808/8d170b63/attachment.htm>