Re: [dtn] Draft Charter Discussion

["Templin, Fred L" <[e-mail]>]

Hi Elwyn,

> -----Original Message-----
> From: Elwyn Davies [mailto:[e-mail]]
> Sent: Thursday, June 12, 2014 4:56 PM
> To: Templin, Fred L
> Cc: [e-mail]
> Subject: Re: [dtn] Draft Charter Discussion
> 
> Hi.
> 
> Looking at the milestones and timescales...
> 
> I am still not totally convinced by the timescales which I think are
> somewhat optimistic (i'll take out the 'wildly' which I used
> previously).  However before we get onto the nitty gritty of milestone
> dates, I think there are some wording
> and scheduling issues to  sort out:
> 
> There are several entries such as
>    start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a
>                 working group document [2]. To be Proposed Standard.
> 
> I think this means 'Accept "<individual draft>" [n]  as working group
> work item intended for <Proposed Standard|Informational>.  However I
> suspect that putting these in as milestones is maybe not a good idea.

Do you want me to change the language, or should we just leave
it alone?

> Presumably what we should be doing is initially making up our collective
> mind on the changes that should be done (c.f., Martin S's comment).
> 
> Certainly for the BPbis work, depending on the outcome of this
> discussion, either the prototype individual drafts may or may not be
> the right basis for the ongoing work based on the results.  I'd be
> inclined to go for a milestone at 6-9 months on getting concensus on
> changes to be implemented in the existing RFC 5050.

So, submit BPbis as a working group item from day one in parallel
with generating consensus on changes leading up to a 6-9mo milestone?
I'm OK with it if that's what you mean - just seeking clarification. 

> On the SBSP I'd
> probably go for accepting it as a WG work item on day 1 since this is
> effectively new work.  For the items that become WG work items later:
> What do we expect people to be doing with these in the interim?  Can't
> we just make them WG items immediately, assuming that we agree we want
> to do them?

That would be OK with me.
 
> This next pair doesn't seem to be practical:
>    start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or
>                  Key Mgmt into a combined draft or keep as separate drafts.
>    start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG either
>                  as a combined draft or as separate drafts.
> Prior to this point, the charter sort of assumes that there will be
> separate drafts.  Assuming that the decision alters this to a combined
> draft at this late stage in development, switching will a.s.
> take an immense amount of work in zero elapsed time and I wouldn't like
> to guarantee the quality of the result.  I *really* think we have to
> make a decision much earlier (about the time we agree what changes are
> needed) and live with it.

Change to "start+9mos" for "WG determination for merging"?

> Returning to the amount of time needed,  I am extremely sceptical that
> we can cut and polish something like six RFCs in just over 18 months
> even given the running start we have.  This is partly because I don't
> know if any of the expected participants have some dedicated person
> power at your disposal to work on the specifications.  I'd expect that
> we would need 2 years and even then I'd not bet too heavily on getting
> there in time.

Well, the charter already has milestones out to 2yrs and from what
I have seen of other IETF charters that seems like a fairly long
timeframe for a working group to run before rechartering. And, the
expectation is to recharter after 24mos.

> As regards Martin S's feedback from the IESG discussion:
> - *Please* let's not go back into the conclusions of the architecture in
> the WG.  Let's settle that before the BoF if we need to, report there
> and have an end of it.  I suspect that if we did reopen the architecture
> in a major way, quite a lot of people would walk away: Opinions?
> 
> - There are some fairly major items that are at least partially
> architectural that we do have to sort out, not least the timestamps in
> bundles and the effects on nodes.  I suggested a tactical way fowards on
> that above.  We probably ought to start a separate thread on BP changes,
> starting with a listing of what has changed in BPv7.

There is already a list in Appendix A of:

https://datatracker.ietf.org/doc/draft-burleigh-bpv7/

Should that be posted under a new thread on this list?

> - Other protocols:
>   + I already mentioned the CGR support - something like the proposed
> CPUP - and put it in the charter update.
>   + Similarly the discovery protocol.
>   + Taking LTP to Proposed Standard ... does this need much work?  Have
> those who are using it found much in the way of holes/improvements?
>   + Other IP based convergence layer protocols (update of the TCP CL
> which I think is very important).
>   + Multicast/Anycast and content distribution. Whether non-singleton
> EIDs are actually useful.
>   + Opportunistic routing scheme(s).
> 
>   Of these protocols, the first two are now in the charter and are
> fairly lightweight.  Having a standardized LTP would complete the space
> story as it is currently used.  There is a CCSDS LTP draft
> (http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%
> 207341R2/NASAUSOverview.aspx).  I believe the TCP CL needs a bit of a
> rethink (mainly to provide parallel channels and some additional
> fragmentation support) but isn't essential to the space sector unless
> they would really like it for the ground segment.  The opportunistic
> routing protocol is really a white space at the moment.

The thinking was that the advanced CLs and reliable delay tolerant
transports would come in during a recharter. That would not preclude
posting drafts with "-dtn" in their names in the near term and
listing them as documents associated with the working group. The
idea is that associated documents with community consensus would
be targeted for wg adoption during the recharter.

Thanks - Fred
[e-mail]

 
> On Thu, 2014-06-12 at 18:34 +0000, Templin, Fred L wrote:
> > Hello,
> >
> > There were some additional off-list updates to the charter
> > emerging as Martin was calling for charter discussion. Please
> > see below for the revised version (diffs attached) and use this
> > as basis for further discussion. (Sebastian and others - please
> > post any follow-ups to this thread.)
> >
> > Fred
> >
> > ---
> >
> > Draft 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 <spencerdawkins.ietf at gmail.com>,
> >                           Martin Stiemerling <mls.ietf at gmail.com>
> >
> > Responsible Area Director:
> >
> >       TBD
> >
> > Mailing list:
> >
> >       General Discussion: dtn at ietf.org
> >       To Subscribe: https://www.ietf.org/mailman/listinfo/dtn
> >       Archive: http://www.ietf.org/mail-archive/web/dtn/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 encounter problems
> >       such as reliable transport protocol handshakes timing out and routing
> >       protocols failing 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 suggested 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 (DTNRG) of the Internet Research Task Force since 2002.
> >       The DTNRG has developed the Delay-Tolerant Networking Architecture
> >       (RFC 4838) that the DTNWG uses as the basis for its work.  The key
> >       components of the this architecture are the bundle concept for
> >       encapsulating data units, the bundle transmission protocol and the
> >       underlying convergence layer architecture.
> >
> >       The experimental DTN Bundle Protocol (RFC 5050) and Licklider
> >       Transmission Protocol (RFC 5326) have been shown to address the
> >       issues identified above in substantial fielded deployments in the space
> >       sector [1].  RFC 5050 in conjunction with TCP- and UDP-based convergence
> >       layers has been used successfully in a number of experiments both in
> >       communications challenged environments around the edges of the Internet
> >       and as an Internet overlay where applications require delay- and/or
> >       disruption-tolerance [refs needed].
> >
> >       The success of the BP over convergence layer protocol stack -- the core
> >       protocols of the "DTN Architecture" described in RFC 4838 -- 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.
> >
> > 	- 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.
> >
> > 	- 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.
> >
> >       The DTNWG believes that protocols adhering to these principles offer
> >       opportunities for enhancing the functionality of the Internet, including
> >
> >         - 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;
> >
> >         - extending the Internet into communications challenged terrestrial
> >           environments where it is not possible to provide continuous, low
> >           delay Internet connections; and
> >
> >         - supporting Internet applications that need DTN capabiliies.
> >
> >       We believe that the extensive research, demonstration, and
> >       pilot operations performed to date using the DTNRG protocols 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 will derive this bundle exchange mechanism
> >         from the DTN Bundle Protocol (BP) documented in RFC 5050 by publishing
> >         a new document for which [2] is a proposed first draft (where
> >         appendix A provides a summary of the proposed changes).
> >
> >       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 will derive this security
> > 	protocol from a "streamlined" adaptation of the DTN Bundle Security
> > 	Protocol documented in RFC 6257.
> >
> >       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.
> >
> >       o A simple datagram convergence layer protocol for adaptation of the
> >         bundle protocol to underlying internetworks. We expect to derive
> >         this convergence layer protocol from the Datagram Convergence
> >         protocol documented in RFC 7122.
> >
> >       o A delay-tolerant network management protocol for management of the
> >         infrastructure in the presence of long delays and/or intermittent
> >         connectivity.
> >
> >       o A functional specification of Contact Graph Routing (CGR) specifying
> >         the inputs (global contact schedules, traffic demands, etc.) and
> >         outputs (node specific transmission and reception schedules,
> >         notifications, etc.).  CGR is a centralized, oracle-based bundle
> >         transmission and reception scheduling scheme used in space segment
> >         DTN deployments.
> >
> >       o An adjunct to the management protocol that will allow the contact
> >         schedules generated by CGR to be distributed to nodes.  This may be
> >         based on the Contact Plan Update Protocol (CPUP) proposed in
> >
> >       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 registry for DTN Service Identifiers
> >
> >     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 such as LTP and
> >     the Saratoga protocol are among the candidates for work in this phase.
> >
> > Goals and Milestones:
> >   start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a
> >                working group document [2]. To be Proposed Standard.
> >   Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a
> >                working group document [3]. To be Proposed Standard.
> >   start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working
> >                group document [4]. To be Proposed Standard.
> >   start+12mos - Submit 'CGR Functional Specification' as a working group
> >                 document. To be an informational document.
> >   start+12mos - Submit 'Delay Tolerant Networking Security Key Management' as
> >                 a working group document. To be Proposed Standard.
> >   start+15mos - Submit 'Contact Plan Update Protocol' as working group
> >                 document.  To be Proposed Standaqqrd.
> >   start+18mos - WG determination for merging RFC5050bis, SBSP, BIBE and/or
> >                 Key Mgmt into a combined draft or keep as separate drafts.
> >   start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG either
> >                 as a combined draft or as separate drafts.
> >   start+18mos - Submit Network Management [5], Registry [6] and Simple
> >                 Convergence Layer [7] as working group documents.
> >   start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging
> >                 technologies (e.g., convergence layer protocols, dynamic
> >                 routing protocols, naming and addressing services, etc.)
> >                 ready for transition into IETF DTN Working Group. Publish
> >                 draft on survey results as independent submission related
> >                 to the WG.
> >   start+24mos - Submit Network Management, Registry and Simple Convergence
> >                 Layer to IESG
> >   start+24mos - Recharter to accommodate new work items or close Working Group
> >
> >
> > [1] "BP/LTP deployment on EPOXI spacecraft" [2008],
> >     http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf
> > [2] "Proposed Revised Bundle Protocol" [2014],
> >     https://datatracker.ietf.org/doc/draft-burleigh-bpv7/
> > [3] "Streamlined Bundle Security Protocol Specification" [2014],
> >     https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/
> > [4] "Bundle-in-Bundle Encapsulation" [2013],
> >     http://tools.ietf.org/id/draft-irtf-burleigh-bibe
> > [5] "Delay Tolerant Network Management Protocol" [2013],
> >     http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp
> > [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011],
> >     https://datatracker.ietf.org/doc/rfc6255/
> > [7] "Datagram Convergence Layers ..." [2014],
> >     https://datatracker.ietf.org/doc/rfc7122/
> > [8] "Towards Flexibility and Accuracy in Space DTN Communications",
> >     Bezirgianndia et al, CHANTS 2012,
> >     http://dl.acm.org/citation.cfm?id=2505499 [2012]
> >
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn