RE: [dtn] proposed DTN workgroup - what is process being followed?

["Burleigh, Scott C (312B)" <[e-mail]>]

Engaging with Lloyd on matters relating to DTN has in the past proven to be a bottomless time sink.  In this instance, though, I worry that silence might be construed as endorsement of his remarks.  This would be incorrect; they are without merit.

The DTN BoF was not told to go away and rethink the idea.  The consensus of the BoF was "that the charter should be reviewed again to make it initially simpler".  As I recall, our responsible area director concurred.  That simplified charter is what was presented to IETF.

The charter simplifications were discussed on the dtn mailing list and in a conference call on 30 September.  In the course of those discussions the BoF also considered a radically different charter proposed by Stephen Farrell.  We concluded that the ideas in that charter had appeal but that there was not sufficient support in the BoF to address them in a working group.  Taking them up in the DTN Research Group was proposed, without dissent, except for speculation that there might not be sufficient energy in the RG either.

There are no "political" issues.  National space agencies needed the DTN protocols in their current form documented as CCSDS standards in the near term so that they could be used for long-range flight mission planning.  The CCSDS Bundle Protocol (BP) Blue Book is a profile of RFC 5050; it does not modify the Bundle Protocol.  Additional protocols are indeed defined in that book as well; if IETF determines that those protocols might also be useful in Internet DTN, then they too could be standardized for the Internet, but obviously CCSDS isn't going to "force" IETF to do anything whatsoever.  And the CCSDS standardization process easily accommodates revision; if IETF chooses to standardize the DTN protocols, the future CCSDS BP standard will almost certainly be a profile of the IETF BP standard just as the current CCSDS BP standard is a profile of RFC 5050.  NASA and other space agencies will surely have an interest in making sure that revisions to BP as it is standardized for the Internet don't diminish its utility in space flight operations, but I don't know of any resistance to this consideration within IETF.

Consequently there are no "procedural" issues.  Taking Lloyd's example: the CCSDS standardization of SCPS doesn't seem to have in any way degraded the operation of TCP/IP in the Internet.  That's because the deliberations of IETF are - and will certainly remain - completely distinct from those of CCSDS.

Again, NASA and other space agencies - like any other user community - will have an interest in preserving BP's utility in space flight operations as the protocol is revised during standardization.  This interest will be expressed through space agency employees' participation in the IETF DTN WG, just as the interests of user communities have always been expressed by their employees' participation in working groups.  There is nothing new here.

Finally, regarding technical issues: Lloyd characterizes the Bundle Protocol as "problematic", a restatement of the position taken in papers that he and several colleagues have written over the years.  In the Results section of his 2011 paper on "Assessing and improving an approach to delay-tolerant networking" (http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/CRS-2011/lloyd-wood-ccsr-crs-2011-dtn.pdf), for example, Lloyd identifies exactly three deficiencies:

(1)	Security is commonly not deployed, in part because of the complexity of the Bundle Security Protocol (BSP).  There seems to be rough consensus in the BoF that BSP is indeed too complex; a simplified BSP specification has been posted as an Internet Draft and a working prototype has been developed.

(2)	No data integrity check, apart from the keyed integrity checks defined in BSP, is included in the DTN architecture.  Adding such a check has long been identified as a proposed enhancement to BP, with no dissent within the BoF that I'm aware of.

(3)	Rough clock synchronization among machines hosting BP agents is required for some functions, but this is not possible in all circumstances.  Mitigation of this problem has likewise long been recognized as a candidate DTN WG work item, with no dissent within the BoF that I'm aware of; an Internet Draft addressing it was posted four years ago.

None of these issues have been significant enough to deter NASA from deployment of BP in International Space Station operations.  BP is not "problematic".

The frequently cited "Bundle of Problems" paper (2009) concludes with these words:

"We hope that recounting those problems here will lead to them being addressed in later versions of the DTN architecture and Bundle Protocol specifications, as research into delay-tolerant networking continues and these research ideas are matured. Once these are addressed, the Bundle Protocol may one day be ready for operational use."

While BP already is clearly ready for operational use, I believe the BoF welcomes the opportunity to further realize the hope expressed here by Lloyd and his co-authors.

Scott

-----Original Message-----
From: dtn [mailto:[e-mail]] On Behalf Of Jari Arkko
Sent: Saturday, October 18, 2014 10:47 PM
To: Lloyd Wood
Cc: [e-mail]; [e-mail]
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?

Lloyd,

Good question. It is customary that working groups being proposed to be created (like DTN is) are given a slot in the schedule. If the working group creation goes through before the meeting, the slot will be a regular working group meeting. If it does not go through, depending on circumstances we'd either run the meeting as a BOF or cancel it.

That was the process part. I'll let others comment on the substance part of your comments.

Jari