Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

From: Nabil Benamar <[email-masked]>
Date: Thu, 1 May 2014 18:53:55 +0100

Hi Fred,

I am supporting the idea of a WG dedicated to DTN. I would like to draw
your attention that DTN architecture and bundle protocol is not limited to
deep space and/or ocean communication.
Among the other opportunities of DTN is the vehicular environment. Indeed,
in order to guarantee the feasibility of many applications through
vehicular networks, it is imperative to design networking protocols
that can overcome relevant problems that arise from vehicular environments.
In this case, we talk about VDTN protocols.

In an attempt to address the problem of disconnected networks in vehicular
environment, vehicular networks may deliver data using the
store-carry-and-forward (SCF) paradigm of DTNs rather than a simple
carry-and-forward method. Consequently, asynchronous, long and variable
length messages, (bundles) can be opportunistically routed towards the
destinations through intermittent connections, assuming that end-to-end
network path is not necessarily currently available, but rather that such a
path exists over time.

*Best wishes*
*نبيل بنعمرو*
*Nabil Benamar*
*Moulay Ismail University.*
*Meknes. Morocco*
*nabilbenamar.com <http://nabilbenamar.com>*

On Thu, May 1, 2014 at 3:41 AM, Eric Travis <[email-masked]>wrote:

> Hi Fred,
>
> Based on the draft Charter, I had assumed that you had already initiated
> discussions with an Area Director...
>
> The schedule in the draft Charter is, in my opinion, enthusiastic.  The
> higher the level of actual participation,
> the longer the timelines are likely to be (again, just my opinion).  What
> I was suggesting is that assuming there
> is a BoF *and* it leads to a DTN WG, doing  the actual work can be started
> now, getting a 3 month jump on the
> BoF and probably 8+ month jump on the earliest possible meeting of a DTN
> WG.
>
> My impression is there has been sufficient interest in a 5050.Bis since
> the possibility was raised close to 3 years ago.
>
> So - no, I don't think you are wrong, either regarding your process point
> or in the estimate of apparent level of interest.
>
>
> Regards,
>
> Eric
> [email-masked]
>
>
>
>
> On Wed, Apr 30, 2014 at 12:59 PM, Templin, Fred L <
> [email-masked]> wrote:
>
>>  Hi Eric,
>>
>>
>>
>> A process point regarding the lead-time going into a DTN BoF. Although
>> IETF90 is scheduled
>>
>> for July 20-25th (the 3 months you mentioned), the time to begin
>> organizing the BoF is now.
>>
>> We will very soon need to make a formal BoF request, and my sense from
>> these discussions
>>
>> is that we at least have enough interest to initiate the request. Am I
>> wrong?
>>
>>
>>
>> Thanks - Fred
>>
>>
>>
>> The ground-work for preparing the existing documentation can begin *now*
>> within the existing infrastructure of the
>> DTNRG.  This provides almost 3 months of lead-time and momentum (and
>> demonstration of energy/commitment) going
>> into a DTN BoF.
>>
>>
>
>
> --
> *The problem with the world is that the intelligent people are full of
> doubts, *
>
> *while the stupid ones are full of confidence.*
> *
>                                                       - Charles Bukowski*
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> <[email-masked]>
> https://www.irtf.org/mailman/listinfo/dtn-interest
> <https://www.irtf.org/mailman/listinfo/dtn-interest>
>
>

---

From: Elwyn Davies <[email-masked]>
Date: Sat, 03 May 2014 00:05:41 +0100

Hi.

It would be good to get some standards track DTN work under way and I
would be willing to contribute.

Were I trying to decide whether to approve this BOF I would be
interested to check that we have answers to various technical questions:

- The bundle protocol or whatever is probably useless without a
practical, scalable routing protocol applicable to the use cases we
propose to address.  How would we propose to complete this part of the
picture? I suspect we might encounter pushback if we, instead, looked
like we were going down the MANET route which has more routing protocol
proposals than I have had hot dinners.  However, we probably need to
consider two cases.  For the space case and similar, contact graph
routing (CGR) seems to be the right answer.  There are implementations
but no formal specification of CGR: Would it be sensible to either
include doing a specification in the milestones or say that we would
seek a recharter to address this when the basics are done?
Opportunistic routing is a different can of worms.  As I have discovered
there are probably about 300 academic papers describing DTN routing
protocols for various types of DTN scenarios.  AFAICS essentially none
of them actually represents a truly practical solution.  There are about
five protocols implemented in various degrees of completeness and
interoperability.  As the SNC, N4C and SAIL projects have discovered,
none of these is really satisfactory in a real world deployment for
various reasons.  I am looking into whether we can improve the
practicality of DTN routing for opportunistic networks but I am not
ready to write a specification although I would hope I might have some
better ideas by the time the basic specs are done.

- Management.  How would we manage a DTN network?  The monitoring aspect
has been addressed somewhat and there are MIB drafts.  We probably ought
to propose some continuation of this work.  Control and configuration is
a completely different matter.  I believe this is tied in to the ability
to do transactional applications in a DTN environment.  This seems to be
a deep dark hole.  Consideration of this side of things might be
relevant when doing the security protocol updates.  

- Privacy.  How would we try to handle privacy?  Does the security work
cover this adequately?  Obviously a hot topic at the moment.

- Assuming we stick with the convergence layer model: What CL's will we
specify?  I agrre with various posts that we need to progress this -
from my experience and the comments on head of the line blocking, it
might be interesting to consider a multichannel or block oriented (TCP)
CL that could interleave chunks of bundles on a TCP connection.

Joerg's point about neighbor discovery is also well taken.  My view of
this is that there is a relatively simple high level problem that allows
nodes to signal their capabilities etc., and a much deeper and not
really DTN problem that solves what I call the 'symmetric discovery'
problem, i.e., two unsynchronized mostly sleeping nodes with no common
infrastructure passing each other and being able to discover each other
before they have gone out of radio range again without running their
batteries flat in less than several days; once this is solved,
persuading equipment manufacturers that they should install the solution
in smartphones and similar devices, and then devote time and effort to
making the solution properly interoperable (i.e., not like ad-hoc
wi-fi).  Unfortunately all the deployed solutions to low battery drain
discovery are asymmetric, i.e., they rely on one party being mostly
awake.  This is true for all cell phone schemes (handsets are time
synched to the base station and wake up for a tiny fraction of the duty
cycle) and LE Bluetooth which is only really LE for one end of the
pairing. 
 
There are also political and administrative questions: 

- Attitude of CCSDS and the space community. CCSDS has a standard
(assuming I understand their process correctly) that references RFC
5050: How will the space community react if we start modifying the BP?
I haven't gathered from the various posts from those involved in space
usage exactly what the likely attitude would be.  CCSDS did (does) have
a work item to develop a CGR protocol specification but this seems to be
stalled according to what I have heard.  I guess getting an IETF spec
would be helpful and combining effort could speed things up.

- Who will chair the proposed WG? 

I also feel that the timescales are overoptimistic, although we
obviously mustn't drag the process out.

Regards,
Elwyn

On Fri, 2014-04-25 at 15:33 +0000, Templin, Fred L wrote:
> Dear DTNRG,
> 
> Boeing has been actively tracking the DTNRG activities, and we believe
> that the time is now at hand to develop some of the more mature technologies
> in an IETF standards-track working group. Active, innovative research in DTN
> continues to be vital, but for Boeing's business purposes it is becoming
> important to lock the DTN protocols down in Internet standards.
>  
> To that end, Boeing is proposing to request a DTN BoF at the next IETF.
> Please see below for a draft BoF agenda and a proposed working group charter.
> Comments?  Suggestions?
>  
> Fred Templin
> [email-masked]
> 
> ---
> 
> Draft BoF Agenda (2.5hrs):
> **************************
> 1) Problem statement (IETF wg motivation) - 30min
> 
> 2) RFC5050(bis) - 30min
> 
> 3) Streamlined Bundle Security Protocol (SBSP) - 30min
> 
> 4) Bundle-in-Bundle Encapsulation - 30 min
> 
> 5) DTN Security Key Management - 30min
> 
> 
> Proposed working group charter:
> *******************************
> Working group name: 
> 
>       Delay/Disruption Tolerant Networking Working Group (DTNWG)
> 
> Chair(s):
> 
>       TBD
> 
> Area and Area Director(s):
> 
>       Transport Area: ADs Spencer Dawkins <[email-masked]>,
>                           Martin Stiemerling <[email-masked]>
> 
> Responsible Area Director:
> 
>       TBD
> 
> Mailing list:
> 
>       General Discussion: [email-masked] (note: until wg formed)
>       To Subscribe: https://www.ietf.org/mailman/listinfo/dtn-interest
>       Archive: http://www.ietf.org/mail-archive/web/dtn-interest/current/maillist.html
> 
> Description of Working Group:
> 
>       The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies
>       mechanisms for data communications in the presence of long delays
>       and/or intermittent connectivity. The work is motivated by well known
>       limitations of standard Internet protocols that expect end-to-end
>       connectivity between communicating endpoints, sub-second transmission
>       delays and robust packet delivery ratios. In environments where these
>       favorable conditions do not apply, existing mechanisms such as reliable
>       transport protocols and routing protocols can fail to converge resulting
>       in communication failures. Furthermore, classical end-to-end security
>       associations cannot be coordinated when communicating endpoints cannot
>       conduct multi-message keying exchanges in a timely fashion. These
>       limitations suggest the need for a new approach. 
>       
>       Delay-Tolerant Networking (DTN) protocols have been the subject of
>       extensive research and development in the Delay-Tolerant Networking
>       Research Group of the Internet Research Task Force since 2002.  In
>       particular, the DTN Bundle Protocol (RFC 5050) and Licklider
>       Transmission Protocol (RFC 5326) have been shown to address the
>       issues identified above.  In 2008, BP/LTP was deployed on the EPOXI
>       spacecraft in deep space and was used to conduct reliable, automated
>       communication for four weeks over a network of 10 nodes in which the
>       bottleneck router in the network (the spacecraft) was up to 100 light
>       seconds from all other nodes and connectivity with the router was
>       subject to periods of disconnection lasting several days.
> 
>       The success of the BP/LTP protocol stack -- the core protocols of the
>       "DTN Architecture" originally described in RFC 4838 -- in this
>       demonstration may be attributed to the following fundamental design
>       principles:
> 
> 	- There is never any expectation of contemporaneous end-to-end
>        connectivity between any two network nodes.  Where such connectivity
>        is sustained, the protocols leverage it to optimize performance,
>        but the possibility of transient but sustained disconnection at
>        any time, anywhere in the network, is always recognized.
> 
> 	- Because end-to-end connectivity can never be assumed, each node
> 	  on the path between source and destination must be prepared to
> 	  handle incoming "bundles" of data that cannot immediately be
> 	  forwarded.  Such bundles must either be stored for future trans-
> 	  mission or discarded; in the latter case, the network must
> 	  be informed of this data loss so that an alternative path may
> 	  be selected, to avoid impairing the usability of the network.
> 
> 	- Again because end-to-end connectivity can never be assumed,
> 	  end-to-end conversational data exchange can never be assumed to
> 	  complete in a timely manner; protocol features that rely on
> 	  timely conversational data exchange must be excluded from the
> 	  architecture.  This principle makes the DTN architecture
> 	  suitable not only for network environments characterized by
> 	  lengthy disconnection but also for those that are characterized
> 	  by long signal propagation delays (such as underwater communication
> 	  by acoustic signals or, worse, interplanetary communication) even
> 	  when connectivity is continuous.
> 
>       The DTNWG believes that protocols adhering to these principles offer
>       opportunities for enhancing the functionality of the Internet - in
>       particular, for facilitating the extension of the Internet into
>       environments such as the ocean floor and deep space in which the core
>       Internet protocols operate sub-optimally for the reasons discussed
>       earlier.  We believe that the extensive research, demonstration, and
>       pilot operations performed to date using the DTNRG protocols, both
>       before and after the EPOXI experiment, provides a firm basis for
>       publishing Internet standards derived from that work.
> 
>       Work items related to Delay/Disruption Tolerant Networking include:
> 
>       o A mechanism for the exchange of protocol data units, termed
> 	"bundles", that are designed to obviate conversational communications
> 	by containing values for all potentially relevant configuration
> 	parameters.  These protocol data units are typically larger than
> 	network-layer packets.  We expect to derive this bundle exchange
> 	mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050.
> 
>       o A security protocol for ensuring that the network in which bundles
> 	are exchanged is secured against unauthorized access and denial of
> 	service attacks, and to ensure data integrity and confidentiality
> 	in that network where necessary.  We expect to derive this security
> 	protocol from a "streamlined" adaptation of the DTN Bundle Security
> 	Protocol documented in RFC 6257.
> 
>       o An encapsulation protocol for "tunneling" BP traffic within bundles
> 	that are secured and/or routed in different way from the encapsulated
> 	bundles.
> 
>       o A delay-tolerant security key management scheme for ensuring that
> 	public keys are certified by a globally trusted authority to protect
> 	the integrity of the infrastructure.
>   
>     The working group will consider extending the current milestones based on
>     new information and knowledge gained while working on the initial charter,
>     as well as to accommodate new work items beyond the scope of the initial
>     phase.  For example, we expect that transport protocols uniquely suited
>     to the various communication environments that may need to be traversed
>     by a single DTN end-to-end path (operating under BP, at what is termed
>     the DTN "convergence layer") will need to be standardized in a second
>     phase of the working group's charter; LTP and the Saratoga protocol are
>     among the candidates for work in this phase.  These adjustments will be
>     accommodated in a working group recharter, assuming the initial
>     chartered activities meet their delivery milestones. Possible new work
>     items must then still fit into the (rechartered) DTNWG charter scope.
>     
> Goals and Milestones:
>   start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a
>                       working group document. To be Proposed Standard.
>   Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a
>                        working group document. To be Proposed Standard.
>   start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working
>                       group document. To be Proposed Standard.
>   start+9mos - Submit 'Delay Tolerant Networking Security Key Management' as
>                       a working group document. To be Proposed Standard.
>   start+9mos - Submit 'Bundle Protocol Specification (RFC5050bis)' to the
>                       IESG. To be Proposed Standard.
>   start+9mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' to the
>                       IESG. To be Proposed Standard.
>   start+10mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' to the IESG.
>                        To be Proposed Standard.
>   start+11mos - Submit 'Delay Tolerant Networking Security Key Management' to
>                        the IESG. To be Proposed Standard.
>   start+12mos - Recharter to accommodate new work items or close Working Group
>

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Sat, 3 May 2014 19:44:43 +0000

Excellent questions, Elwyn.  I will try to offer a few answers in-line below, speaking just for myself.

Scott

-----Original Message-----
From: dtn-interest [mailto:[email-masked]] On Behalf Of Elwyn Davies
Sent: Friday, May 02, 2014 4:06 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Hi.

It would be good to get some standards track DTN work under way and I would be willing to contribute.

Were I trying to decide whether to approve this BOF I would be interested to check that we have answers to various technical questions:

- The bundle protocol or whatever is probably useless without a practical, scalable routing protocol applicable to the use cases we propose to address.  How would we propose to complete this part of the picture? I suspect we might encounter pushback if we, instead, looked like we were going down the MANET route which has more routing protocol proposals than I have had hot dinners.  However, we probably need to consider two cases.  For the space case and similar, contact graph routing (CGR) seems to be the right answer.  There are implementations but no formal specification of CGR: Would it be sensible to either include doing a specification in the milestones or say that we would seek a recharter to address this when the basics are done?
Opportunistic routing is a different can of worms.  As I have discovered there are probably about 300 academic papers describing DTN routing protocols for various types of DTN scenarios.  AFAICS essentially none of them actually represents a truly practical solution.  There are about five protocols implemented in various degrees of completeness and interoperability.  As the SNC, N4C and SAIL projects have discovered, none of these is really satisfactory in a real world deployment for various reasons.  I am looking into whether we can improve the practicality of DTN routing for opportunistic networks but I am not ready to write a specification although I would hope I might have some better ideas by the time the basic specs are done.

>>>	I agree that a formal specification for CGR is important.  My inclination is to go with Fred's initial instinct, that committing to standardize only the core protocols in the first phase of the WG -- prior to the first re-charter -- would help to make the initial charter task list more doable with available resources.  In that context, deferring specification of routing protocols including CGR -- all of which are applicable to specific types of topologies -- until after the re-charter makes sense to me.  But certainly there are valid arguments on the other side.

- Management.  How would we manage a DTN network?  The monitoring aspect has been addressed somewhat and there are MIB drafts.  We probably ought to propose some continuation of this work.  Control and configuration is a completely different matter.  I believe this is tied in to the ability to do transactional applications in a DTN environment.  This seems to be a deep dark hole.  Consideration of this side of things might be relevant when doing the security protocol updates.

>>>	NASA has been funding a lot of work on DTN network management over the past couple of years, mainly because NASA has got an imminent need for it (deployment on ISS in 2015) and there hadn't seemed to be a lot of interest in DTNRG.  This absolutely would need to be taken up by a DTN WG, but again maybe a formal standard isn't needed in the first phase of work.  The NASA work could be taken up by the WG after re-charter, at least as a starting point.  

- Privacy.  How would we try to handle privacy?  Does the security work cover this adequately?  Obviously a hot topic at the moment.

>>>	I think the "streamlined BSP" I-D that Ed Birrane posted will answer these questions really well.  And my feeling is that this protocol truly is core and would need to be addressed in the first phase of WG deliberations.

- Assuming we stick with the convergence layer model: What CL's will we specify?  I agrre with various posts that we need to progress this - from my experience and the comments on head of the line blocking, it might be interesting to consider a multichannel or block oriented (TCP) CL that could interleave chunks of bundles on a TCP connection.

>>>	Because the list of potentially useful CLs is open-ended, I would again propose slipping this activity until after the first re-charter.  At the same time, it's true having at least one CL adapter spec is a precondition to testing bundle protocol implementations.  I would suggest that we include a dead-simple UDP CL adapter spec in the first phase of the WG and later on decide which CLs need to be supported in phase 2.

Joerg's point about neighbor discovery is also well taken.  My view of this is that there is a relatively simple high level problem that allows nodes to signal their capabilities etc., and a much deeper and not really DTN problem that solves what I call the 'symmetric discovery'
problem, i.e., two unsynchronized mostly sleeping nodes with no common infrastructure passing each other and being able to discover each other before they have gone out of radio range again without running their batteries flat in less than several days; once this is solved, persuading equipment manufacturers that they should install the solution in smartphones and similar devices, and then devote time and effort to making the solution properly interoperable (i.e., not like ad-hoc wi-fi).  Unfortunately all the deployed solutions to low battery drain discovery are asymmetric, i.e., they rely on one party being mostly awake.  This is true for all cell phone schemes (handsets are time synched to the base station and wake up for a tiny fraction of the duty
cycle) and LE Bluetooth which is only really LE for one end of the pairing.

>>>	Here I would suggest that the proposed WG limit phase-1 work to a standard for the sort of neighbor discovery we've already got working, while asking the Research Group to dig into the deeper problem you have identified.

- Attitude of CCSDS and the space community. CCSDS has a standard (assuming I understand their process correctly) that references RFC
5050: How will the space community react if we start modifying the BP?
I haven't gathered from the various posts from those involved in space usage exactly what the likely attitude would be.  CCSDS did (does) have a work item to develop a CGR protocol specification but this seems to be stalled according to what I have heard.  I guess getting an IETF spec would be helpful and combining effort could speed things up.

>>>	I can't speak for CCSDS or the space flight community, but I can relay my understanding of the conversations we've had on this topic within the NASA DTN project.  CCSDS standardization of the current DTN RFCs (particularly 5050 and 5326) is pretty far advanced and would not be derailed by establishment of a DTN WG in IETF; the space agencies (especially NASA) need these books as soon as possible.  However, CCSDS standards can be revised.  So long as it remains fairly straightforward to "gateway" between the current protocols and whatever "bis" protocols are defined by the WG, so that interoperation remains possible where necessary, I think CCSDS will welcome the improvements and will over time revise the CCSDS DTN standards to track them.  My sense is that absolute backward compatibility is not considered necessary.

>>>	Good question.  I don't know how this sort of decision gets made.  If it counts for anything, I nominate Fred.

I also feel that the timescales are overoptimistic, although we obviously mustn't drag the process out.

Regards,
Elwyn

On Fri, 2014-04-25 at 15:33 +0000, Templin, Fred L wrote:
> that the time is now at hand to develop some of the more mature 
> technologies in an IETF standards-track working group. Active, 
> innovative research in DTN continues to be vital, but for Boeing's 
> business purposes it is becoming important to lock the DTN protocols down in Internet standards.
>  
>       Archive: 
> http://www.ietf.org/mail-archive/web/dtn-interest/current/maillist.htm
> l
>

---

From: <[email-masked]>
Date: Sun, 4 May 2014 08:19:34 +0000

"At the same time, it's true having at least one CL adapter spec is a precondition to testing bundle protocol implementations.  I would suggest that we include a dead-simple UDP CL adapter spec in the first phase of the WG and later on decide which CLs need to be supported in phase 2."

Kruse et al., Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP), RFC7122, March 2014.

Is the basic premise of this putative IETF workgroup to redo everything done in this IRTF research group, because it wasn't done well enough? That does not strike me as a useful charter for a workgroup.

It's May the Fourth, and I have a bad feeling about this.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: dtn-interest <[email-masked]> on behalf of Burleigh, Scott C (312G) <[email-masked]>
Sent: Sunday, 4 May 2014 5:44 AM
To: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Scott

-----Original Message-----
From: dtn-interest [mailto:[email-masked]] On Behalf Of Elwyn Davies
Sent: Friday, May 02, 2014 4:06 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Hi.

Regards,
Elwyn

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 04 May 2014 16:46:30 +0100

Lloyd,

On 04/05/14 09:19, [email-masked] wrote:
> I have a bad feeling about this.

FWIW, my impression is that you'd have a bad feeling about
anything related to rfc5050 regardless. IMO, it'd be quite
reasonable for people to disregard quite a bit of what you
say on that basis, i.e. that you appear to be interested
in being destructively critical. That's a pity, since there
are things to be improved/fixed for which you have argued,
and with which others agree.

Its even more a pity as it somewhat poisons the discussion,
so I'd ask that if you can, please you try to put aside your
distaste for rfc5050 and your annoyance at dtnrg history and
try constructively discuss the proposed IETF wg.

S.

---

From: <[email-masked]>
Date: Mon, 5 May 2014 07:12:40 +0000

Stephen,

I would discourage others from using or building on
RFC5050, based on our experience in testing the Bundle
Protocol in space [1], analysing the protocol's failings
[2], and a variety of previously suggested fixes and drafts
in this RG that never went anywhere, which aren't published.

That's our engineering judgement on RFC5050 as it stands,
and many long-time readers will be familiar with our arguments.
But, as far as discussing the proposed WG and a modified
RFC5050bis goes:

Any protocol is simply an artefact that is an outcome of a process by people.
It's reasonable to have doubts about the same pool of people producing anything
better in a similar process. If there's a new crowd from Boeing et al with
relevant expertise and funding/resources/time, that may help.
(Or not, depending on the learning curve.)

Will the putative IETF WG be as wholly focused on, say, security?
I don't see how having a set of milestones magically fixes things
that years in this research group, with discussion between the interested,
did not. I don't see how an RG with failing output and limited adoption
can be transformed into a WG with successful output and widespread (even
terrestrial?) adoption, and I have never seen that done.
(RGs have transformed and mutated into other RGs, with rather
varying success.)

How can a WG with the mandate 'fix the bundle protocol' succeed?
Is it just being set up to fail? Should it therefore not be set up at all?

[1] Will Ivancic, Wesley M. Eddy, Dave Stewart, Lloyd Wood, James Northam
and Chris Jackson, 'Experience with delay-tolerant networking from orbit',
peer-reviewed journal paper, International Journal of Satellite
Communications and Networking, special issue for best papers of the Fourth
Advanced Satellite Mobile Systems Conference (ASMS 2008), vol. 28,
issues 5-6, pp. 335-351, September-December 2010.
http://dx.doi.org/10.1002/sat.966
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/ijscn-asms-bundle-paper-submitted.pdf

[2] Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems',
peer-reviewed conference paper, IEEE Aerospace Conference, Big Sky,
Montana, March 2009.  16 pages.  http://dx.doi.org/10.1109/AERO.2009.4839384
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf

Lloyd Wood
http://sat-net.com/L.Wood/dtn

that was a Star Wars reference, btw. May the 4th: may the force...
________________________________________
From: Stephen Farrell <[email-masked]>
Sent: Monday, 5 May 2014 1:46 AM
To: Wood L  Dr (Electronic Eng); [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Lloyd,

S.

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 05 May 2014 09:37:27 -0400

Independent of the RG/WG question, I think it might be useful to
have more face-to-face meetings, or at least regular telecons. 
Maybe having WG meetings at the IETF meetings would help, but I
don't think it's a prerequisite.

In my experience, email threads often devolve into discussions of
all the ways we don't agree, while realtime or face-to-face
discussions are more productive in building consensus for things on
which we do agree (or at least agree to disagree and move on).

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
Raytheon BBN Technologies
[email-masked]
617-873-8004

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 May 2014 14:41:49 +0000

Hi Elwyn,

These are all great points - I am printing your message for further
consideration as we speak. As to who will chair the working group,
I believe that will be part of the WG formation process but I can
volunteer if it would be helpful.

About timing, we still have time to get the ball rolling ahead of
IETF90 and I have initiated discussions with the IETF Transport
Area ADs. I think this is strategically important because IETF91
will be held in Honolulu and how many here could convince their
employers to send them to Hawaii "on business" in November?

Thanks - Fred

> From: Elwyn Davies [mailto:[email-masked]]

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 5 May 2014 14:44:13 +0000

I would certainly agree. And, that probably would be a good measure of the
true ability to commit to do work.  I know, I currently have no funding to
travel.  If such meetings do occur, it would sure be nice to be able to
participate remotely via some type of web meeting application.

One of the questions that keeps crossing my mind the past week or two
while watching the discussion / arguments and whatever is: "Why hasn't
this issue been resolved in the research group?"

Things like head-of-line blocking, scalable routing, reactive
fragmentation,  what should be secure, etc....  There are a lot of open
issues.  And that doesn't include route loops and the ability to have a
bundle stuck in a route loop terminate.  Bundle lifetime will not
adequately handle this.

If I were an AD or IESG, this would certainly play into my decision to
allow a working group to form.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 May 2014 14:54:20 +0000

Hi Scott,

Correct that we need to start with a bounded set of work items to
get the ball rolling. Ideally, this would then lead to a snowball
effect to bring in additional work items after the initial charter
is executed. But, you have to start somewhere.

I will also say that having a bounded initial charter does not
preclude candidate new work items with the working group. Drafts
titled: "draft-dtnwg-*" will be tracked as being associated with
the working group and implicitly candidates for inclusion in a
recharter. Such drafts could also be presented at DTNWG face to
face meetings (given agenda time slots) even if they are not yet
on the charter.

Thanks - Fred

> From: dtn-interest [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312G)
> Sent: Saturday, May 03, 2014 12:45 PM
> - The bundle protocol or whatever is probably useless without a practical, scalable routing protocol
> applicable to the use cases we propose to address.  How would we propose to complete this part of the
> picture? I suspect we might encounter pushback if we, instead, looked like we were going down the
> MANET route which has more routing protocol proposals than I have had hot dinners.  However, we
> probably need to consider two cases.  For the space case and similar, contact graph routing (CGR)
> seems to be the right answer.  There are implementations but no formal specification of CGR: Would it
> be sensible to either include doing a specification in the milestones or say that we would seek a
> recharter to address this when the basics are done?
> Opportunistic routing is a different can of worms.  As I have discovered there are probably about 300
> academic papers describing DTN routing protocols for various types of DTN scenarios.  AFAICS
> essentially none of them actually represents a truly practical solution.  There are about five
> protocols implemented in various degrees of completeness and interoperability.  As the SNC, N4C and
> SAIL projects have discovered, none of these is really satisfactory in a real world deployment for
> various reasons.  I am looking into whether we can improve the practicality of DTN routing for
> opportunistic networks but I am not ready to write a specification although I would hope I might have
> some better ideas by the time the basic specs are done.
> 
> >>>	I agree that a formal specification for CGR is important.  My inclination is to go with Fred's
> initial instinct, that committing to standardize only the core protocols in the first phase of the WG
> -- prior to the first re-charter -- would help to make the initial charter task list more doable with
> available resources.  In that context, deferring specification of routing protocols including CGR --
> all of which are applicable to specific types of topologies -- until after the re-charter makes sense
> to me.  But certainly there are valid arguments on the other side.
> 
> - Management.  How would we manage a DTN network?  The monitoring aspect has been addressed somewhat
> and there are MIB drafts.  We probably ought to propose some continuation of this work.  Control and
> configuration is a completely different matter.  I believe this is tied in to the ability to do
> transactional applications in a DTN environment.  This seems to be a deep dark hole.  Consideration of
> this side of things might be relevant when doing the security protocol updates.
> 
> >>>	NASA has been funding a lot of work on DTN network management over the past couple of years,
> mainly because NASA has got an imminent need for it (deployment on ISS in 2015) and there hadn't
> seemed to be a lot of interest in DTNRG.  This absolutely would need to be taken up by a DTN WG, but
> again maybe a formal standard isn't needed in the first phase of work.  The NASA work could be taken
> up by the WG after re-charter, at least as a starting point.
> 
> >>>	I think the "streamlined BSP" I-D that Ed Birrane posted will answer these questions really
> well.  And my feeling is that this protocol truly is core and would need to be addressed in the first
> phase of WG deliberations.
> 
> - Assuming we stick with the convergence layer model: What CL's will we specify?  I agrre with various
> posts that we need to progress this - from my experience and the comments on head of the line
> blocking, it might be interesting to consider a multichannel or block oriented (TCP) CL that could
> interleave chunks of bundles on a TCP connection.
> 
> >>>	Because the list of potentially useful CLs is open-ended, I would again propose slipping this
> activity until after the first re-charter.  At the same time, it's true having at least one CL adapter
> spec is a precondition to testing bundle protocol implementations.  I would suggest that we include a
> dead-simple UDP CL adapter spec in the first phase of the WG and later on decide which CLs need to be
> supported in phase 2.
> 
> Joerg's point about neighbor discovery is also well taken.  My view of this is that there is a
> relatively simple high level problem that allows nodes to signal their capabilities etc., and a much
> deeper and not really DTN problem that solves what I call the 'symmetric discovery'
> problem, i.e., two unsynchronized mostly sleeping nodes with no common infrastructure passing each
> other and being able to discover each other before they have gone out of radio range again without
> running their batteries flat in less than several days; once this is solved, persuading equipment
> manufacturers that they should install the solution in smartphones and similar devices, and then
> devote time and effort to making the solution properly interoperable (i.e., not like ad-hoc wi-fi).
> Unfortunately all the deployed solutions to low battery drain discovery are asymmetric, i.e., they
> rely on one party being mostly awake.  This is true for all cell phone schemes (handsets are time
> >>>	Here I would suggest that the proposed WG limit phase-1 work to a standard for the sort of
> neighbor discovery we've already got working, while asking the Research Group to dig into the deeper
> problem you have identified.
> 
> I haven't gathered from the various posts from those involved in space usage exactly what the likely
> attitude would be.  CCSDS did (does) have a work item to develop a CGR protocol specification but this
> seems to be stalled according to what I have heard.  I guess getting an IETF spec would be helpful and
> combining effort could speed things up.
> 
> >>>	I can't speak for CCSDS or the space flight community, but I can relay my understanding of the
> conversations we've had on this topic within the NASA DTN project.  CCSDS standardization of the
> current DTN RFCs (particularly 5050 and 5326) is pretty far advanced and would not be derailed by
> establishment of a DTN WG in IETF; the space agencies (especially NASA) need these books as soon as
> possible.  However, CCSDS standards can be revised.  So long as it remains fairly straightforward to
> "gateway" between the current protocols and whatever "bis" protocols are defined by the WG, so that
> interoperation remains possible where necessary, I think CCSDS will welcome the improvements and will
> over time revise the CCSDS DTN standards to track them.  My sense is that absolute backward
> compatibility is not considered necessary.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 May 2014 15:02:15 +0000

Hi Lloyd,

I have to say that I mostly agree with Stephen. IMHO, "Bundle of Problems"
is a very useful document and still applies today, but I see it as an
actionable problem statement and not an end-of-the-road pronouncement.
I believe most of the BoP problems can be addressed in an RFC5050(bis)
and we would tackle this in the initial working group work items.

Thanks - Fred

> From: dtn-interest [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, May 05, 2014 12:13 AM
> To: [email-masked]; [email-masked]

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 1 May 2014 19:08:40 +0100

This is a good point made by Joerg ! Indeed, deployment of DTN terrestrial
applications without the use of the infrastructure is one of the most
important aspects especially when it comes to vehicular environment.

*Best wishes*
*نبيل بنعمرو*
*Nabil Benamar*

On Mon, Apr 28, 2014 at 11:25 AM, Joerg Ott <[email-masked]> wrote:

> On 28.04.2014 13:13, Stephen Farrell wrote:
>
>>
>> On 28/04/14 08:54, Joerg Ott wrote:
>>
>>> IIRC, I remarked back then, that adding a To: and From: fields (granted,
>>> you call them differently) to HTTP has been done before (aka SIP).
>>> Let's not repeat this exercise (we know where this can lead to :-)
>>> And, no, I am not suggesting you should be using SIP instead, even
>>> though it would be closer.
>>>
>>> It's just that adding feature to a system it wasn't designed for is
>>> going to be as easy as it seems at the first glance (adding routing,
>>> etc.)
>>>
>>
>> That is a danger, yes. But doing minimal changes to 5050 also
>> has a danger - that the result is never really deployed. So I
>> think the question for now seems to be whether or not to make
>> much simpler terrestrial deployment a first class goal for the
>> putative WG.
>>
>> I'd like the answer to be "yes," but I do agree that there's
>> a case that can be made for a minimal-change approach. That
>> latter is a lot less interesting for me though as I think there
>> are just very few situations that justify rolling out an entirely
>> different infrastructure for a DTN.
>>
>
> I don't disagree with this.  But I don't want to be presumptious
> on how the answer should look like either (which also implies not
> ruling out options).
>
> That aside, one of the most important application on the terrestrial
> side is running without infrastructure -- which makes the deployability
> (in the sense of "compatibility") question less important.
>
> Jörg
>
>

---

From: William Immerman <[email-masked]>
Date: Mon, 5 May 2014 11:04:38 -0400

Lloyd--

I don't have the basis or history that most on this list do to address the specific technical limitations of BP, so I won't, but I do have some recent first-hand experience trying to get disruption-tolerant networking more attention as a concept/technology with people with repeated operational needs, and I can say that the limited adoption you refer to doesn't seem based on technical flaws in the slightest:

On May 5, 2014, at 3:12 AM, <[email-masked]> <[email-masked]> wrote:

> .. I don't see how an RG with failing output and limited adoption

If  I can distill the problem getting adoption, it would have two main parts:
1) Potential users really don't understand (wide area/inter-) networking. Their questions and comments would apply equally to TCP/IP if it were being presented new to them today.
2) Despite (1), they buy in completely to the value of Internet technology, but they don't understand that there are many cases of practical value where just buying more network bandwidth is not the answer and will never be, and don't get why "disruption-tolerance" is needed

Ironically, for all the contentiousness in this community, it appears to me that these are the two things that are almost universally agreed upon by people with expertise and experience, i.e., the value of true networking and the need to handle disruptions for which IP end-to-end alone is poorly suited.

The first part of your comment, that the output of the RG is diminishing, is certainly not unrelated to the issue of adoption. Independent of what individuals may think is the suitability of prior work, there are limited resources available to anyone for further research (whether to mature existing technologies or to develop alternatives) until there's a demonstrated utility for what's already been done. There's a catch-22 with regard to the potential adopters/funders recognizing the need prior to this demonstration. In the meantime, more and more specific instances are being handled with repeated, not always great, deployment-specific applications, and the time is passing to do something smarter that encompasses a broader range of needs. This may be part of the reason that Stephen is asking for everyone regardless of technical specifics to collaborate.

Bill Immerman

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 May 2014 15:07:13 +0000

Hi Will,

Technologies for remote participation have become quite good, and are
being used more and more in IETF working group meetings. I don't see
why we couldn't accommodate remote participation in an initial BoF,
for example.

About your other points, additional work items can be tracked by
the working group and brought in during a recharter. But, without
an initial charter, that ball will never get rolling.

Thanks - Fred

> From: dtn-interest [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
> Sent: Monday, May 05, 2014 7:44 AM
> To: Daniel Ellard; [email-masked]

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 5 May 2014 16:10:01 +0000

If we start talking vehicle related disruption tolerant networking (delay does not appear to be an issue here), the scalability is a very important issue as is routing.

A Concept of Operations for vehicle disruption tolerant networking (VDTN) would be very useful to understand the issues and scale.

Will

From: Nabil Benamar <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 1, 2014 2:08 PM
To: Joerg Ott <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

This is a good point made by Joerg ! Indeed, deployment of DTN terrestrial applications without the use of the infrastructure is one of the most important aspects especially when it comes to vehicular environment.

Best wishes
نبيل بنعمرو
Nabil Benamar
Moulay Ismail University.
Meknes. Morocco
nabilbenamar.com<http://nabilbenamar.com>

On Mon, Apr 28, 2014 at 11:25 AM, Joerg Ott <[email-masked]<mailto:[email-masked]>> wrote:
On 28.04.2014 13:13, Stephen Farrell wrote:

Jörg

_______________________________________________
dtn-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Kevin Fall <[email-masked]>
Date: Mon, 5 May 2014 15:02:33 -0400

I can see a couple of ways you might go forward.  If you start off as
a "fix 5050/BP" you will encounter disagreement as to what are
problems and what are not.  This is evident from the various exchanges
over the years.  Alternatively, you can start somewhat higher level
with the notion that the area of challenged/DTN/DIL networks is to be
addressed with a standard protocol (set), that there is now sufficient
insight and knowledge thanks to DTNRG, and the field is open.  There
may be different design goals potentially (e.g., some web
compatibility or whatnot) which was/were not a particular driving goal
for DTNRG or BP.

- Kevin

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 5 May 2014 19:52:08 +0000

How about doing both?

My understanding of Boeing's interest is that they are looking for standards to support fairly near-term commercialization of the RFC 5050-based technology that we've all gotten a good deal of experience with over the past few years.  In that context, "fix 5050/BP" seems like a good fit for the proposed working group.

At the same time, taking up the last decade's worth of insight and knowledge and starting over again from a blank sheet of paper seems like exactly the right sort of thing for the DTN Research Group to take on.

Scott 

-----Original Message-----
From: dtn-interest [mailto:[email-masked]] On Behalf Of Kevin Fall
Sent: Monday, May 05, 2014 12:03 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

I can see a couple of ways you might go forward.  If you start off as a "fix 5050/BP" you will encounter disagreement as to what are problems and what are not.  This is evident from the various exchanges over the years.  Alternatively, you can start somewhat higher level with the notion that the area of challenged/DTN/DIL networks is to be addressed with a standard protocol (set), that there is now sufficient insight and knowledge thanks to DTNRG, and the field is open.  There may be different design goals potentially (e.g., some web compatibility or whatnot) which was/were not a particular driving goal for DTNRG or BP.

- Kevin

On Mon, May 5, 2014 at 11:02 AM, Templin, Fred L <[email-masked]> wrote:
>> I would discourage others from using or building on RFC5050, based on 
>> our experience in testing the Bundle Protocol in space [1], analysing 
>> the protocol's failings [2], and a variety of previously suggested 
>> fixes and drafts in this RG that never went anywhere, which aren't 
>> published.
>>
>> That's our engineering judgement on RFC5050 as it stands, and many 
>> long-time readers will be familiar with our arguments.
>> But, as far as discussing the proposed WG and a modified RFC5050bis 
>> goes:
>>
>> It's reasonable to have doubts about the same pool of people 
>> producing anything better in a similar process. If there's a new 
>> crowd from Boeing et al with relevant expertise and funding/resources/time, that may help.
>> that years in this research group, with discussion between the 
>> interested, did not. I don't see how an RG with failing output and 
>> limited adoption can be transformed into a WG with successful output 
>> and widespread (even
>> (RGs have transformed and mutated into other RGs, with rather varying 
>> success.)
>>
>> [1] Will Ivancic, Wesley M. Eddy, Dave Stewart, Lloyd Wood, James 
>> Northam and Chris Jackson, 'Experience with delay-tolerant networking 
>> from orbit', peer-reviewed journal paper, International Journal of 
>> Satellite Communications and Networking, special issue for best 
>> papers of the Fourth Advanced Satellite Mobile Systems Conference 
>> (ASMS 2008), vol. 28, issues 5-6, pp. 335-351, September-December 2010.
>> [2] Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of 
>> Problems', peer-reviewed conference paper, IEEE Aerospace Conference, 
>> Big Sky, Montana, March 2009.  16 pages.  
>> http://dx.doi.org/10.1109/AERO.2009.4839384
>> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-iee
>> e-aerospace-2009-bundle-
>> problems.pdf
>>
>> Lloyd Wood
>> FWIW, my impression is that you'd have a bad feeling about anything 
>> related to rfc5050 regardless. IMO, it'd be quite reasonable for 
>> people to disregard quite a bit of what you say on that basis, i.e. 
>> that you appear to be interested in being destructively critical. 
>> That's a pity, since there are things to be improved/fixed for which 
>> you have argued, and with which others agree.
>>
>> Its even more a pity as it somewhat poisons the discussion, so I'd 
>> ask that if you can, please you try to put aside your distaste for 
>> rfc5050 and your annoyance at dtnrg history and try constructively 
>> discuss the proposed IETF wg.
>>
>> S.
>>
>>

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 5 May 2014 13:16:31 -0700

> At the same time, taking up the last decade's worth of insight and knowledge and starting over again from a blank sheet of paper seems like exactly the right sort of thing for the DTN Research Grou…

on "paper", I agree. But I have concerns on people bandwidth to work in two working groups. Even the current one has not met for quite some time. So instead of starting 2, we may want to try to just (re-)start one...

Marc.

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Tue, 6 May 2014 00:00:14 +0000

Marc, certainly you are correct that taking both paths concurrently would amount to twice as much work, more or less.  But we are all individuals, all free agents (modulo the interests of our funding sources, for those of us whose participation is funded).  It's not as if there is a common pool of people bandwidth that we can direct to work on one project or another: those of us who are interested in one of these projects will work on it, and those who are not probably won't.  I don't think excluding one of them would much improve the effort that gets devoted to the other; rather, I think including both could accomplish more in total.

Scott

-----Original Message-----
From: Marc Blanchet [mailto:[email-masked]] 
Sent: Monday, May 05, 2014 1:17 PM
To: Burleigh, Scott C (312G)
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Marc.

>> I believe most of the BoP problems can be addressed in an 
>> RFC5050(bis) and we would tackle this in the initial working group work items.
>> 
>> Thanks - Fred
>>> I would discourage others from using or building on RFC5050, based 
>>> on our experience in testing the Bundle Protocol in space [1], 
>>> analysing the protocol's failings [2], and a variety of previously 
>>> suggested fixes and drafts in this RG that never went anywhere, 
>>> which aren't published.
>>> 
>>> varying
>>> Northam and Chris Jackson, 'Experience with delay-tolerant 
>>> networking from orbit', peer-reviewed journal paper, International 
>>> Journal of Satellite Communications and Networking, special issue 
>>> for best papers of the Fourth Advanced Satellite Mobile Systems 
>>> Conference (ASMS 2008), vol. 28, issues 5-6, pp. 335-351, September-December 2010.
>>> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/ijscn-a
>>> s
>>> ms-bundle-paper-submitted.pdf
>>> 
>>> Problems', peer-reviewed conference paper, IEEE Aerospace 
>>> Conference, Big Sky, Montana, March 2009.  16 pages.

---

From: "Mehta, Devanshu - 0665 - MITLL" <[email-masked]>
Date: Tue, 6 May 2014 15:30:00 +0000

In fact, a "blank sheet" dtnrg may reinvigorate some of the more silent members of the group.

Devanshu

----- Original Message -----
From: Burleigh, Scott C (312G) [mailto:[email-masked]]
Sent: Monday, May 05, 2014 08:00 PM Eastern Standard Time
To: Marc Blanchet <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Scott

-----Original Message-----
From: Marc Blanchet [mailto:[email-masked]] 
Sent: Monday, May 05, 2014 1:17 PM
To: Burleigh, Scott C (312G)
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Marc.

---

From: ccaini <[email-masked]>
Date: Tue, 06 May 2014 21:18:36 +0200

Dear Fred,
      if the vitality of a research group is denoted by the number of mail
exchanges on the group mailing list, I would say that your proposal has
really brought new life to it!
I am grateful for this.
In my opinion, it was high time that somebody proposed to move DTN BP from
pure research to engineering standardization also for non Interplanetary
applications.
I say this not because I think that BP is perfect and there is no need to
further research, or just to include some of the features that at present
are lacking in future RFCs (e.g. I am in favor of end-to-end CRC check,
which is one of Wood's favorite arguments, with good reasons), but because
without true applications in mind, without the active participation  of big
companies, like Boeing, the DTN appealing outside of Interplanetary
applications seems to me destined to slowly fade out.
I suppose that the prospect of having a DTN standardized protocol
supported by a big company can help in sustaining and rising the interest
of Industry on DTN, which is essential to develop applications that are not
just mere demos; applications that can show all the potential of the DTN
concept and that can make the difference with present ones. This would also
help in keeping alive and possibly reinvigorating DTN more open research
too.
Of course, IETF standardizations should be coordinated with CCSDS
standardization for space applications, in order to maintain a unique DTN
umbrella for both (i.e. some form of close interoperability).
 
Yours,
    Carlo Caini 

(University of Bologna)

On Tue, 6 May 2014 15:30:00 +0000, "Mehta, Devanshu - 0665 - MITLL"
<[email-masked]> wrote:
> Marc, certainly you are correct that taking both paths concurrently
would
> amount to twice as much work, more or less.  But we are all individuals,
> all free agents (modulo the interests of our funding sources, for those
of
> us whose participation is funded).  It's not as if there is a common
pool
> of people bandwidth that we can direct to work on one project or
another:
> those of us who are interested in one of these projects will work on it,
> and those who are not probably won't.  I don't think excluding one of
them
> would much improve the effort that gets devoted to the other; rather, I
> think including both could accomplish more in total.
> 
> Scott
> 
> Le 2014-05-05 à 12:52, Burleigh, Scott C (312G)
> <[email-masked]> a écrit :
> 
>> How about doing both?
>> 
>> My understanding of Boeing's interest is that they are looking for
>> standards to support fairly near-term commercialization of the RFC
>> 5050-based technology that we've all gotten a good deal of experience
>> with over the past few years.  In that context, "fix 5050/BP" seems
like
>> a good fit for the proposed working group.
>> 
>> At the same time, taking up the last decade's worth of insight and
>> knowledge and starting over again from a blank sheet of paper seems
like
>> exactly the right sort of thing for the DTN Research Group to take on.
> 
> on "paper", I agree. But I have concerns on people bandwidth to work in
> two working groups. Even the current one has not met for quite some
time.
> So instead of starting 2, we may want to try to just (re-)start one...
> 
> Marc.
> 
>> 
>> Scott
>> 
>> I can see a couple of ways you might go forward.  If you start off as a
>> "fix 5050/BP" you will encounter disagreement as to what are problems
and
>> what are not.  This is evident from the various exchanges over the
years.
>> Alternatively, you can start somewhat higher level with the notion that
>> the area of challenged/DTN/DIL networks is to be addressed with a
>> standard protocol (set), that there is now sufficient insight and
>> knowledge thanks to DTNRG, and the field is open.  There may be
different
>> design goals potentially (e.g., some web compatibility or whatnot)
which
>> was/were not a particular driving goal for DTNRG or BP.
>> 
>> - Kevin
>> 
>>> RFC5050(bis) and we would tackle this in the initial working group
work
>>> items.

---

From: Vassilios Tsaoussidis <[email-masked]>
Date: Wed, 07 May 2014 09:47:44 +0800

I am also in favor of Fred's proposal. Although DTN has clearly research
issues to be addressed, the level of maturity of BP along with the
community's clear direction towards internet for everywhere, everything
and everyone calls for IETF standardization actions. I am also in favor
of forming a single group - to which I intend to participate;
dichotomies typically cause more problems than they solve. Also,
optimizing DTN for terrestrial or space environment only may cancel the
original concept of interoperability of diverse environments. 

Vassilis Tsaoussidis 

Στις 2014-05-07 03:18, ccaini έγραψε: 

>> In fact, a "blank sheet" dtnrg may reinvigorate some of the more silent members of the group. Devanshu ----- Original Message ----- From: Burleigh, Scott C (312G) [mailto:[email-masked]] Sent: Monday, May 05, 2014 08:00 PM Eastern Standard Time To: Marc Blanchet <[email-masked]> Cc: [email-masked] <[email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Marc, certainly you are correct that taking both paths concurrently
> 
> would
> 
>> amount to twice as much work, more or less. But we are all individuals, all free agents (modulo the interests of our funding sources, for those
> 
> of
> 
>> those of us who are interested in one of these projects will work on it, and those who are not probably won't. I don't think excluding one of
> 
> them
> would much improve the effort that gets devoted to the other; rather, I think including both could accomplish more in total. Scott -----Original Message----- From: Marc Blanchet [mailto:[email-masked]] Sent: Monday, May 05, 2014 1:17 PM To: Burleigh, Scott C (312G) Cc: [email-masked] Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Le 2014-05-05 à 12:52, Burleigh, Scott C (312G) <[email-masked]> a écrit : How about doing both? My understanding of Boeing's interest is that they are looking for standards to support fairly near-term commercialization of the RFC 5050-based technology that we've all gotten a good deal of experience with over the past few years. In that context, "fix 5050/BP" seems

like

>> a good fit for the proposed working group. At the same time, taking up the last decade's worth of insight and knowledge and starting over again from a blank sheet of paper seems

like

> on "paper", I agree. But I have concerns on people bandwidth to work in two working groups. Even the current one has not met for quite some

time.

> So instead of starting 2, we may want to try to just (re-)start one... Marc. 
> 
>> Scott -----Original Message----- From: dtn-interest [mailto:[email-masked]] On Behalf Of Kevin Fall Sent: Monday, May 05, 2014 12:03 PM To: Templin, Fred L Cc: [email-masked] Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 I can see a couple of ways you might go forward. If you start off as a "fix 5050/BP" you will encounter disagreement as to what are problems

and

years.

>> Alternatively, you can start somewhat higher level with the notion that the area of challenged/DTN/DIL networks is to be addressed with a standard protocol (set), that there is now sufficient insight and knowledge thanks to DTNRG, and the field is open. There may be

different

which

> was/were not a particular driving goal for DTNRG or BP. - Kevin On Mon, May 5, 2014 at 11:02 AM, Templin, Fred L <[email-masked]> wrote: Hi Lloyd, I have to say that I mostly agree with Stephen. IMHO, "Bundle of Problems" is a very useful document and still applies today, but I see it as an actionable problem statement and not an end-of-the-road pronouncement. I believe most of the BoP problems can be addressed in an RFC5050(bis) and we would tackle this in the initial working group

work

> items. Thanks - Fred [email-masked] -----Original Message----- From: dtn-interest [mailto:[email-masked]] On Behalf Of [email-masked] Sent: Monday, May 05, 2014 12:13 AM To: [email-masked]; [email-masked] Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Stephen, I would discourage others from using or building on RFC5050, based on our experience in testing the Bundle Protocol in space [1], analysing the protocol's failings [2], and a variety of previously suggested fixes and drafts in this RG that never went anywhere, which aren't published. That's our engineering judgement on RFC5050 as it stands, and many long-time readers will be familiar with our arguments. But, as far as discussing the proposed WG and a modified RFC5050bis goes: Any protocol is simply an artefact that is an outcome of a process by people. It's reasonable to have doubts about the same pool of people producing anything better in a similar process. If
there's a new crowd from Boeing et al with relevant expertise and funding/resources/time, that may help. (Or not, depending on the learning curve.) Will the putative IETF WG be as wholly focused on, say, security? I don't see how having a set of milestones magically fixes things that years in this research group, with discussion between the interested, did not. I don't see how an RG with failing output and limited adoption can be transformed into a WG with successful output and widespread (even terrestrial?) adoption, and I have never seen that done. (RGs have transformed and mutated into other RGs, with rather varying success.) How can a WG with the mandate 'fix the bundle protocol' succeed? Is it just being set up to fail? Should it therefore not be set up at all? [1] Will Ivancic, Wesley M. Eddy, Dave Stewart, Lloyd Wood, James Northam and Chris Jackson, 'Experience with delay-tolerant networking from orbit', peer-reviewed journal paper, International Journal of Satellite
Communications and Networking, special issue for best papers of the Fourth Advanced Satellite Mobile Systems Conference (ASMS 2008), vol. 28, issues 5-6, pp. 335-351, September-December 2010. http://dx.doi.org/10.1002/sat.966 [1] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/ijscn-a [2] s ms-bundle-paper-submitted.pdf [2] Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems', peer-reviewed conference paper, IEEE Aerospace Conference, Big Sky, Montana, March 2009. 16 pages. http://dx.doi.org/10.1109/AERO.2009.4839384 [3] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-ie [4] e e-aerospace-2009-bundle- problems.pdf Lloyd Wood http://sat-net.com/L.Wood/dtn [5] that was a Star Wars reference, btw. May the 4th: may the force... ________________________________________ From: Stephen Farrell <[email-masked]> Sent: Monday, 5 May 2014 1:46 AM To: Wood L Dr (Electronic Eng); [email-masked] Subject: Re: [dtn-interest] DTN BoF
Proposal for IETF90 Lloyd, On 04/05/14 09:19, [email-masked]: I have a bad feeling about this. FWIW, my impression is that you'd have a bad feeling about anything related to rfc5050 regardless. IMO, it'd be quite reasonable for people to disregard quite a bit of what you say on that basis, i.e. that you appear to be interested in being destructively critical. That's a pity, since there are things to be improved/fixed for which you have argued, and with which others agree. Its even more a pity as it somewhat poisons the discussion, so I'd ask that if you can, please you try to put aside your distaste for rfc5050 and your annoyance at dtnrg history and try constructively discuss the proposed IETF wg. S. _______________________________________________ dtn-interest mailing list [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest [6]
 _______________________________________________ dtn-interest mailing
list [email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest [6]
_______________________________________________ dtn-interest mailing
list [email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest [6]
_______________________________________________ dtn-interest mailing
list [email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest [6]
_______________________________________________ dtn-interest mailing
list [email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest [6]
_______________________________________________ dtn-interest mailing
list [email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest [6] 

_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest [6]

Links:
------
[1] http://dx.doi.org/10.1002/sat.966
[2] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/ijscn-a
[3] http://dx.doi.org/10.1109/AERO.2009.4839384
[4] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-ie
[5] http://sat-net.com/L.Wood/dtn
[6] https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: <[email-masked]>
Date: Wed, 7 May 2014 03:55:35 +0000

"Although DTN has clearly research issues to be addressed"

I wouldn't describe these as research issues, but as basic engineering issues. Rediscovering the ramifications of the end-to-end principle cannot really be considered research at this point.

"optimizing DTN for terrestrial or space environment only may cancel the original concept of interoperability of diverse environments."

We have previously asked whether interoperability of diverse environments is warranted and worthwhile:

Lloyd Wood, Peter Holliday, Daniel Floreani and Wesley M. Eddy,
'Sharing the dream: The consensual networking hallucination offered
by the Bundle Protocol', peer-reviewed conference paper, Workshop on
the Emergence of Delay-/Disruption-Tolerant Networks (E-DTN),
part of the International Conference on Ultra Modern Telecommunication
(ICUMT), St. Petersburg, Russia, 14 October 2009.  2 pages.
http://dx.doi.org/10.1109/ICUMT.2009.5345655

http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#e-dtn-position

figure 1 is particularly helpful in thinking about this dichotomy of environments.

Lloyd Wood
http://about.me/lloydwood
________________________________
From: dtn-interest <[email-masked]> on behalf of Vassilios Tsaoussidis <[email-masked]>
Sent: Wednesday, 7 May 2014 11:47 AM
To: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

I am also in favor of Fred's proposal. Although DTN has clearly research issues to be addressed, the level of maturity of BP along with the community's clear direction towards internet for everywhere, everything and everyone calls for IETF standardization actions. I am also in favor of forming a single group - to which I intend to participate; dichotomies typically cause more problems than they solve. Also, optimizing DTN for terrestrial or space environment only may cancel the original concept of interoperability of diverse environments.

Vassilis Tsaoussidis

Dear Fred,

Yours,
    Carlo Caini

(University of Bologna)

On Tue, 6 May 2014 15:30:00 +0000, "Mehta, Devanshu - 0665 - MITLL"
<[email-masked]<mailto:[email-masked]>> wrote:

In fact, a "blank sheet" dtnrg may reinvigorate some of the more silent members of the group. Devanshu ----- Original Message ----- From: Burleigh, Scott C (312G) [mailto:[email-masked]<mailto:[email-masked]>] Sent: Monday, May 05, 2014 08:00 PM Eastern Standard Time To: Marc Blanchet <[email-masked]<mailto:[email-masked]>> Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Marc, certainly you are correct that taking both paths concurrently

would

of

pool

another:

them

would much improve the effort that gets devoted to the other; rather, I think including both could accomplish more in total. Scott -----Original Message----- From: Marc Blanchet [mailto:[email-masked]<mailto:[email-masked]>] Sent: Monday, May 05, 2014 1:17 PM To: Burleigh, Scott C (312G) Cc: [email-masked]<mailto:[email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Le 2014-05-05 à 12:52, Burleigh, Scott C (312G) <[email-masked]<mailto:[email-masked]>> a écrit :
How about doing both? My understanding of Boeing's interest is that they are looking for standards to support fairly near-term commercialization of the RFC 5050-based technology that we've all gotten a good deal of experience with over the past few years. In that context, "fix 5050/BP" seems

like

like

time.

So instead of starting 2, we may want to try to just (re-)start one... Marc.
Scott -----Original Message----- From: dtn-interest [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kevin Fall Sent: Monday, May 05, 2014 12:03 PM To: Templin, Fred L Cc: [email-masked]<mailto:[email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 I can see a couple of ways you might go forward. If you start off as a "fix 5050/BP" you will encounter disagreement as to what are problems

and

years.

different

which

was/were not a particular driving goal for DTNRG or BP. - Kevin On Mon, May 5, 2014 at 11:02 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lloyd, I have to say that I mostly agree with Stephen. IMHO, "Bundle of Problems" is a very useful document and still applies today, but I see it as an actionable problem statement and not an end-of-the-road pronouncement. I believe most of the BoP problems can be addressed in an RFC5050(bis) and we would tackle this in the initial working group

work

items. Thanks - Fred [email-masked]<mailto:[email-masked]>
-----Original Message----- From: dtn-interest [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]> Sent: Monday, May 05, 2014 12:13 AM To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Stephen, I would discourage others from using or building on RFC5050, based on our experience in testing the Bundle Protocol in space [1], analysing the protocol's failings [2], and a variety of previously suggested fixes and drafts in this RG that never went anywhere, which aren't published. That's our engineering judgement on RFC5050 as it stands, and many long-time readers will be familiar with our arguments. But, as far as discussing the proposed WG and a modified RFC5050bis goes: Any protocol is simply an artefact that is an outcome of a process by people. It's reasonable to have doubts about the same pool of people producing anything better in a similar process. If there's a new crowd from Boeing et al with relevant expertise and funding/resources/time, that may help. (Or not, depending on the learning curve.) Will the putative IETF WG be as wholly focused on, say, security? I don't see how having a set of milestones magically fixes things that years in this research group, with discussion between the interested, did not. I don't see how an RG with failing output and limited adoption can be transformed into a WG with successful output and widespread (even terrestrial?) adoption, and I have never seen that done. (RGs have transformed and mutated into other RGs, with rather varying success.) How can a WG with the mandate 'fix the bundle protocol' succeed? Is it just being set up to fail? Should it therefore not be set up at all? [1] Will Ivancic, Wesley M. Eddy, Dave Stewart, Lloyd Wood, James Northam and Chris Jackson, 'Experience with delay-tolerant networking from orbit', peer-reviewed journal paper, International Journal of Satellite Communications and Networking, special issue for best papers of the Fourth Advanced Satellite Mobile Systems Conference (ASMS 2008), vol. 28, issues 5-6, pp. 335-351, September-December 2010. http://dx.doi.org/10.1002/sat.966 http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/ijscn-a s ms-bundle-paper-submitted.pdf [2] Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems', peer-reviewed conference paper, IEEE Aerospace Conference, Big Sky, Montana, March 2009. 16 pages. http://dx.doi.org/10.1109/AERO.2009.4839384 http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-ie e e-aerospace-2009-bundle- problems.pdf Lloyd Wood http://sat-net.com/L.Wood/dtn that was a Star Wars reference, btw. May the 4th: may the force... ________________________________________ From: Stephen Farrell <[email-masked]<mailto:[email-masked]>> Sent: Monday, 5 May 2014 1:46 AM To: Wood L Dr (Electronic Eng); [email-masked]<mailto:[email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Lloyd, On 04/05/14 09:19, [email-masked]<mailto:[email-masked]>wrote:
I have a bad feeling about this.
FWIW, my impression is that you'd have a bad feeling about anything related to rfc5050 regardless. IMO, it'd be quite reasonable for people to disregard quite a bit of what you say on that basis, i.e. that you appear to be interested in being destructively critical. That's a pity, since there are things to be improved/fixed for which you have argued, and with which others agree. Its even more a pity as it somewhat poisons the discussion, so I'd ask that if you can, please you try to put aside your distaste for rfc5050 and your annoyance at dtnrg history and try constructively discuss the proposed IETF wg. S. _______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest
_______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest
_______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest _______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest
_______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest _______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Gelard Patrick <[email-masked]>
Date: Wed, 7 May 2014 08:29:03 +0000

Dear all,

>> Rediscovering the ramifications of the end-to-end principle cannot really be considered research at this point
Is it a rediscovering of end-to-end principle variant or the need of new definition of end-to-end concept to take in account new Delay and  Disruption constraint ?

Is that Delay-  and  Disruption-Tolerant  Networking can continue to be base on the principle of « Intelligence is at the end » : Network architecture must be as simple as possible – don’t bring in infrastructure specific optimizations for any particular purpose ? A "dumb" network with "smart" terminals ?

Modern physic try to build « A theory of everything » to take in account major unsolved problems in physics<http://en.wikipedia.org/wiki/Unsolved_problems_in_physics>. What are the major unsolved problem in Networking ?

Bests regard
Patrick
end-to-end principle http://en.wikipedia.org/wiki/End-to-end_principle

De : dtn-interest [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 7 mai 2014 05:56
À : [email-masked]; [email-masked]
Objet : Re: [dtn-interest] DTN BoF Proposal for IETF90

figure 1 is particularly helpful in thinking about this dichotomy of environments.
Lloyd Wood
http://about.me/lloydwood
________________________________
From: dtn-interest <[email-masked]<mailto:[email-masked]>> on behalf of Vassilios Tsaoussidis <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 7 May 2014 11:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Vassilis Tsaoussidis

Dear Fred,

I am grateful for this.

applications.

too.

Yours,

    Carlo Caini

(University of Bologna)

would

of

pool

another:

them

like

like

time.

and

years.

different

which

work

---

From: <[email-masked]>
Date: Tue, 27 May 2014 03:38:56 +0000

> Yes, starting by looking at approaches like that (though maybe
> considering HTTP/2.0 now as well) is IMO well worth considering
> if we want an eventual IETF PS RFC for DTN to be (able to be)
> widely used.

I think people are starting to realise that a higher version number 
doesn't necessarily mean better.

http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0815.html

I think HTTP/1.1 has a lot of mileage in it.

Lloyd Wood
http://sat-net.com/L.Wood/dtn/http-dtn.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 May 2014 07:57:14 +0100

> http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0815.html

You may or may not be correct. It could equally be that some of
those people are regrinding the same axe one more time.

S.

---

From: Joerg Ott <[email-masked]>
Date: Wed, 28 May 2014 09:27:59 +0300

> those people are regrinding the same axe one more time.

Sure.  But one could also easily sense some second system syndrome...

Jörg