ietf
[Top] [All Lists]

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

2014-10-20 10:37:03
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:dtn-bounces(_at_)ietf(_dot_)org] On Behalf Of Jari Arkko
Sent: Saturday, October 18, 2014 10:47 PM
To: Lloyd Wood
Cc: ietf(_at_)ietf(_dot_)org; dtn(_at_)ietf(_dot_)org
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


<Prev in Thread] Current Thread [Next in Thread>