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

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

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:[e-mail]] On Behalf Of Elwyn Davies
Sent: Friday, May 02, 2014 4:06 PM
To: Templin, Fred L
Cc: [e-mail]
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.
 
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.

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

- Who will chair the proposed WG? 

>>>	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:
> 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
> [e-mail]
> 
> ---
> 
> 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 <[e-mail]>,
>                           Martin Stiemerling <[e-mail]>
> 
> Responsible Area Director:
> 
>       TBD
> 
> Mailing list:
> 
>       General Discussion: [e-mail] (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.htm
> l
> 
> 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
> 
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest

_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest