Subject: [dtn] Draft Charter Discussion

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jun 2014 18:34:23 +0000

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]

---

From: Sebastian Schildt <[email-masked]>
Date: Thu, 12 Jun 2014 20:49:00 +0200

Hi

> post any follow-ups to this thread.)

Ok. So far so good. Referring to the previous thread I would just take you up on the offer to replace this 
> 	the integrity of the infrastructure.

with that 

On 12 Jun 2014, at 20:25, Templin, Fred L <[email-masked]> wrote:

> 
> I don't mind taking a slightly revised version of your proposed bullet:
> 
>  o A delay-tolerant security key management scheme that can protect
>    the integrity of a DTN network.

>        infrastructure in the presence of long delays and/or intermittent

DT-SNMP?  Maybe the stakeholders in this could add/suggest a sentence to clarify what „network management“ means in this case?

MfG

Sebastian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jun 2014 19:46:31 +0000

Hi Sebastian,

> -----Original Message-----
> From: Sebastian Schildt [mailto:[email-masked]]
> Sent: Thursday, June 12, 2014 11:49 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [dtn] Draft Charter Discussion
> 
> Hi
> 

OK - this will be fixed in the next update.

> DT-SNMP?  Maybe the stakeholders in this could add/suggest a sentence to clarify what "network
> management" means in this case?

Can someone with interest in DTN network management address this point?

Thanks - Fred
[email-masked]

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 13 Jun 2014 00:55:40 +0100

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

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.

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.

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.

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

On Thu, 2014-06-12 at 18:34 +0000, Templin, Fred L wrote:
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: <[email-masked]>
Date: Fri, 13 Jun 2014 00:56:33 +0000

> in a major way, quite a lot of people would walk away: Opinions?

The architecture question is valid. It's valid and reasonable to question
why an obviously failed design is being pushed through so heavily,
particularly when it has so little relevance to the rest of IETF work,
and any putative IETF workgroup should consider things other than the
bundle protocol.

The IESG made the correct call there imo - though I don't think it made
the right one in allowing the BOF.

I see scope has already opened up on routing etc. Why not on
base protocol?

(Oh, you should also certainly push for a revision of RFC6256 to go
standards track, since everything else is being revised for standards
track as well.)

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Jun 2014 15:44:33 +0000

Hi Elwyn,

> From: Elwyn Davies [mailto:[email-masked]]
> Sent: Thursday, June 12, 2014 4:56 PM
> To: Templin, Fred L
> Cc: [email-masked]

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

> 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

That would be OK with me.
 
> needed) and live with it.

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

> we would need 2 years and even then I'd not bet too heavily on getting

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.

> starting with a listing of what has changed in BPv7.

There is already a list in Appendix A of:

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

> 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

---

From: "Ramachandran, Vignesh R. (Vinny)" <[email-masked]>
Date: Fri, 13 Jun 2014 15:15:53 -0400

Hi all,

>Can someone with interest in DTN network management address this point?

Ed Birrane and I published the DTNMP experimental internet draft document
back in October, so perhaps I can shed some light...

I believe the intent here may be clarified with "A protocol for remote
status monitoring, configuration, and administration of network nodes in
the presence of long delays and/or intermittent connectivity."

Conceptually, this is in line with SNMP offerings, without the overhead
and bidirectionality requirements of a request/response conversation.  I
believe the DING protocol proposal also offers similar features, so DTNMP
is by no means the only answer.

Apologies for jumping in mid-stream on this quite long discussion.

>[email-masked]

Best, 
Vinny Ramachandran

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Jun 2014 17:40:42 +0000

Please see below for an updated version of the draft charter based
on list discussions, and post any further comments in follow-up.
(See also attached for diffs relative to the previous version.)

Thanks - Fred

---

Draft BoF Agenda (2.5hrs):
**************************
1) Problem statement (IETF wg motivation) - 30min

2) RFC5050(bis) - 15min

3) Streamlined Bundle Security Protocol (SBSP) - 15min

4) Security Key Management - 10min

5) Network Management - 10min

6) Contact Graph Routing and Contact Plan Update Protocol - 10min

7) Bundle-in-Bundle Encapsulation - 5min

8) Registry for Service Identifiers - 5min

9) Open Discussion - 50min

Chair(s):

      TBD

      TBD

Mailing list:

      

      o A protocol for remote status monitoring, configuration, and
        administration of network nodes in the presence of long delays
        and/or intermittent connectivity.

  
    
Goals and Milestones:
  start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] as
               a working group work item intended for Proposed Standard.
  Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3] as
               a working group work item intended for Proposed Standard.
  start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a
               working work item intended for Proposed Standard.
  start+6mos - Working group getting concensus on changes to be implemented
               in RFC 5050(bis).
  start+9mos - Working group getting consensus on merging RFC5050bis, SBSP,
               BIBE etc. into a combined draft or keep as separate drafts.
  start+12mos - Accept 'CGR Functional Specification' as a working group 
                working group work item intended for Informational.
  start+12mos - Accept 'Delay Tolerant Networking Security Key Management'
                as a working group work item intended for Proposed Standard.
  start+15mos - Accept 'Contact Plan Update Protocol' as working group work
                item intended for Proposed Standard.
  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

---

From: William Ivancic <[email-masked]>
Date: Tue, 17 Jun 2014 11:24:36 -0700

Some thoughts:

I think we need some deep philosophical discussion at the BOF on what we are trying to do with DTN.  Most (actually ALL) deployments I am aware of have been in the order of probably tens or less nodes - certainly less than 100.  Are we developing a standard for space systems or looking at hundreds of thousands or millions of nodes? 

I think the last time IETF worked a specific problem it was TCPSAT and, I believe, the IETF decided that we would not do work on a specific deployment area.  (Fortunately, the TCP over Satellite actually had a more generic problem which was time/bandwidth.)  If the end result is deploying over 100 nodes (10 nodes in 10 deployments) in the next 5 years, I doubt we should be considering a standard at this time.

There has never been a "problem statement" written, so we don't really know what problem we are trying to solve.  Is Scalability an issue?  I think so.

There is currently  no document of which I am aware of that states what the default operation of a forwarding agent is.  For example, if you have no route, do you drop a bundle even if it has not expired or do you hold it in anticipation of perhaps having a route later?  

I do know that some groups want to run DTN (RFC5050) at extremely high rates (Gbps and higher).  The current structure, while nice for research with all the flexibility, is not very well suited for high-speed deployments - particularly if you are considering space-based hardware and processors.  Do we address this?

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

Quite honestly, I cannot agree with this statement.  I have seen very little with regards to scalability, a mix of traffic, a mix of bundle lifetimes, a mix of bundle sizes, complex networks, etc.  If you do a PING, you can, with high degree of confidence, conclude that you have connectivity, but not much else.  To date, IMHO, we haven't done much more that the equivalent of a PING with regard to DTN RFC5050 (and nearly everyone I've talked to has realized that there system wasn't synced to the 30 second default in DTNPING.).

I was attracted to this research group because there are so many areas ripe for research.  That hasn't changed in over 7 years or more. All categories are still wide open for research.

Will Ivancic
Syzygy Engineering 

________________________________

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Jun 2014 19:50:17 +0000

Hi Will,

I may address some of your individual points later, but for now I have to say that I don't
understand the concern about scalability. The Internet started with a few nodes with
static routing and address provisioning as well as static host tables maintained in a central
repository (SRI-NIC). The IETF also got its start from the early days beginning with the IEN
documents and then transitioning into the RFC document series where the core Internet
protocols were standardized. That model stood for many years while the Internet grew to
larger scale, and not until much later did dynamic routing protocols, the Domain Name
System and DHCP come online. I don't see why a similar model would not hold for DTN,
independent of specific use cases.

I think another fallacy in the scaling concern is the notion that there would be "one DTN" in
the beginning in the same way that we have "one Internet" today. Instead, I can imagine
there would be many independent DTNs established for many diverse use cases. Some
of these purpose-built DTNs might be joined together at some point in the future to form
larger DTNs, and to accommodate seamless interoperability we needs interoperable IETF
standards from the very beginning - sort of like how the Internet got started.

Thanks - Fred

From: William Ivancic [mailto:[email-masked]]
Sent: Tuesday, June 17, 2014 11:25 AM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Some thoughts:

Will Ivancic
Syzygy Engineering

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jun 2014 21:04:49 +0100

Fred and others,

I think I've asked this before so apologies if I just forget
the good answer;-)

We have the space use-case and some fairly well known niche
terrestrial use-cases, which are fine. But we've known these
for years and the DTNRG didn't want to move to the standards
track until now.

I think it'd help the IESG to decide whether to approve a
WG if there were more information available about what has
changed to motivate moving to the standards track.

If (say for Boeing) those are such that you can't say and
there aren't any others who can, then that's a pity, since
it does make it harder to get why a 5050bis on the standards
track is attractive.

I'm just noting this again because I think many recent
successful BoFs have tended to have this topic as part of
the agenda, but it seems missing in yours, which just
assumes that the room knows that RFC5050 needs a bit of
work. (I'm exaggerating a bit there, but I hope you get
what I mean.)

S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Jun 2014 20:12:14 +0000

Hi Stephen,

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Tuesday, June 17, 2014 1:05 PM

Yes, a diverse set of use cases and not a single use case. That
means that in the early days there may be many purpose-built DTNs
that may at a later time be joined together to form larger DTNs.
A "DTN-of-DTNs" in the same way that the Internet is a "network-
of-networks".

The whole reason the Internet was able to join together smaller
networks to form larger networks is that the Internet had
interoperable standards from the very beginning. It is now
time for us to do that for DTN.

Thanks - Fred

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Tue, 17 Jun 2014 20:19:14 +0000

Stephen, I'm confused: the first 30 minutes of the agenda Fred has proposed are reserved for "Problem statement (IETF wg motivation)".  Are you saying that's not as much time as recent successful BoFs have spent on this part of the agenda?  How much more time do you think will be needed?

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, June 17, 2014 1:05 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Fred and others,

I think I've asked this before so apologies if I just forget the good answer;-)

We have the space use-case and some fairly well known niche terrestrial use-cases, which are fine. But we've known these for years and the DTNRG didn't want to move to the standards track until now.

I think it'd help the IESG to decide whether to approve a WG if there were more information available about what has changed to motivate moving to the standards track.

If (say for Boeing) those are such that you can't say and there aren't any others who can, then that's a pity, since it does make it harder to get why a 5050bis on the standards track is attractive.

I'm just noting this again because I think many recent successful BoFs have tended to have this topic as part of the agenda, but it seems missing in yours, which just assumes that the room knows that RFC5050 needs a bit of work. (I'm exaggerating a bit there, but I hope you get what I mean.)

S.

On 17/06/14 18:40, Templin, Fred L wrote:
> Please see below for an updated version of the draft charter based on 
> list discussions, and post any further comments in follow-up.
>       Archive: 
> http://www.ietf.org/mail-archive/web/dtn/current/maillist.html
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jun 2014 21:31:52 +0100

Hi Fred,

> time for us to do that for DTN.

I'm familiar with DTN. But I find the above a pretty
complete non-answer to the question asked (in that it
answers no part of my question:-) So I'll try again,
in a more direct fashion...

I do not know why specifically Boeing want a standards
track RFC5050bis, nor why you want it now.

And I'm wondering and would like to know. I have not heard
your use-case (or business case, whatever) explained so far.
Nor have I heard someone say "can't/won't tell, sorry."
So I'm curious.

And I'll note once again that successful BoFs tend to
involve explaining why this, now, specifically. As an
IESG member it makes it much easier for me to evaluate
proposals for forming a WG.

(BTW, any answer that asks me to think like an acorn
won't really work for this question, sorry:-)

If someone else has a new answer to this question that
would also be interesting. By new, I mean a use-case
or business-case that hasn't previously been discussed
in the DTNRG.

Cheers,
S.

PS: In case there's confusion. My question is very much
not the same as Will's, despite your answer being very
similar.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Jun 2014 21:12:55 +0000

Hi Stephen,

> Sent: Tuesday, June 17, 2014 1:32 PM

I am sorry you didn't find my answer helpful, but I am somewhat
puzzled by that. The Internet was enabled by the bedrock standards
(IP, TCP, etc.) that allowed for joining smaller networks together
into larger ones without the need for complex gateway mechanisms
at the borders. The same should be true for DTN.

> Nor have I heard someone say "can't/won't tell, sorry."

I am not permitted to discuss my company's business plans on
a public forum (i.e., "can't tell - sorry").

> proposals for forming a WG.

I know you didn't like the answer, but let's say we had two
DTNs - one for space based applications, and one for tracking
the wildebeest migration across the plains of Africa - and we
wanted to join the two DTNs together. It is easy if both DTNs
are using the same protocols, and much harder if each DTN uses
its own custom protocol (which Gnu would you put the complex
border gateway function on?).

> or business-case that hasn't previously been discussed

My company for one is large and with diverse business interests,
as I'm sure many others are. Where those business interests
intersect, we may wish to join multiple DTNs together seamlessly
and without having to stand up complex gateways. That is why
we need standard protocols.

Thanks - Fred

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 17 Jun 2014 17:24:08 -0400

Stephen,

  I certainly can't answer those questions for Boeing or for Fred, but I have my own answer that I'm willing to share. Having never been an acorn, I am not certain if I am thinking like one, but here goes.

  For years, there have been sample deployments and experiments that show the feasibility and functionality of DTN, specifically BP. There have also been a smaller set of experiments that identified limitations with BP.  From speaking with government, university, and small businesses my accumulated opinions are as follows.

So, why DTN in non-space cases?

- Some like the protocol bits (blocks, custody xfer, queuing, reporting structure) as a consolidated standard and not a layered set of standards and best practices.
- Some like the automation for delay/disrupted and scaled deployments - it cuts down on their one-off app point solutions.
- Some feel that their analyses indicate DTN overlays can simplify complex architectures such as TCP PEPs, including how to integrate differing networks using different queuing models.
- Some sensor networks behave quite similarly to space networks regarding disruption. Underwater scenarios also look similar in terms of delay.

Not an exhaustive list, but the highlights from why people are interested in a standard that pulls these bits together.

Separately, the line between space providers and space users is blurring. LEO constellations that want to interact seamlessly with terrestrial infrastructure as first-class nodes in a network should not be lumped as "space" in the sense of deep space missions or older, sparser near-earth deployments.

So, why no scaled DTN deployments yet outside of NASA baselines?

- The security mechanism looked overly complex and hard to verify.
- There was no progress on management, especially in access-denied and open-loop areas.
- The protocol specs are described in experimental RFCs, with discussion of a bis.

So, why now?

- There has been progress on simplifying the security implementations based on lessons learned.
- There is some promising progress (yes, through NASA, but not NASA centric) on disruption-scaling management concepts.
- There is a set of lessons learned informing  5050bis/BPv7. To Fred's schedule, this can be resolved in relatively short order.

I know of a few companies and some non-commercial entities that have no issue with BP and are not worried about building a BPA.  But an operational deployment needs a non-experimental spec, security, and management. There is much more it needs in the general case, but these seem to be driving requirements.

I am unsure of what is sufficient proof for your question. Does it have to be 10 companies interested and not 8? 25 nodes instead of 18? 100? Is the deployment horizon 1 year and not 3?

So, I naively ask the opposite question: why not standardize this work in the IETF?

You have the community of people who are willing to do the work, with backing from industry and government. The charter, as I see it, addresses clear needs for operational deployment, and to Will's points, the DTNRG persists to continue inspection of the fundamental research issues surrounding more exotic deployments.

-Ed

---
Ed Birrane
Principal Professional Staff, Space Department
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> Sent: Tuesday, June 17, 2014 4:32 PM
> >> terrestrial use-cases, which are fine. But we've known these for
> >> years and the DTNRG didn't want to move to the standards track until
> >> now.
> >
> > Yes, a diverse set of use cases and not a single use case. That means
> > that in the early days there may be many purpose-built DTNs that may
> > at a later time be joined together to form larger DTNs.
> > interoperable standards from the very beginning. It is now time for us
> > to do that for DTN.
>
> I'm familiar with DTN. But I find the above a pretty complete non-answer to
> the question asked (in that it answers no part of my question:-) So I'll try
> again, in a more direct fashion...
>
> I do not know why specifically Boeing want a standards track RFC5050bis, nor
> why you want it now.
>
> And I'm wondering and would like to know. I have not heard your use-case
> (or business case, whatever) explained so far.
> And I'll note once again that successful BoFs tend to involve explaining why
> this, now, specifically. As an IESG member it makes it much easier for me to
> evaluate proposals for forming a WG.
>
> (BTW, any answer that asks me to think like an acorn won't really work for
> this question, sorry:-)
>
> If someone else has a new answer to this question that would also be
> interesting. By new, I mean a use-case or business-case that hasn't
> previously been discussed in the DTNRG.
>
> Cheers,
> S.
>
> PS: In case there's confusion. My question is very much not the same as
> Will's, despite your answer being very similar.
>
> >
> > Thanks - Fred
> >> I think it'd help the IESG to decide whether to approve a WG if there
> >> were more information available about what has changed to motivate
> >> moving to the standards track.
> >>
> >> If (say for Boeing) those are such that you can't say and there
> >> aren't any others who can, then that's a pity, since it does make it
> >> harder to get why a 5050bis on the standards track is attractive.
> >>
> >> I'm just noting this again because I think many recent successful
> >> BoFs have tended to have this topic as part of the agenda, but it
> >> seems missing in yours, which just assumes that the room knows that
> >> RFC5050 needs a bit of work. (I'm exaggerating a bit there, but I
> >> hope you get what I mean.)
> >>
> >> S.
> >>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jun 2014 22:29:16 +0100

Hiya,

> a public forum (i.e., "can't tell - sorry").

Thanks for the clear answer.

I figured it might be that. And there's nothing weird with
a business taking that approach, or with having it imposed
on them by some customers.

However, it does mean that there's essentially no new
information for the IESG in answer to the "why this, and
why now" question, except for the assertion that you'd
like it to happen. As I say, sometimes we might have to
live with that, but it doesn't make things easier to
understand.

For example, if we take the issue I raised where I believe
I'm probably in the rough, the list/BoF/IETF can't use your
use-case to figure out if a "minimal" 5050bis or a re-design
is more reasonable. (I don't want to re-do that discussion
on the list now, its just an example.) You of course can
do that and tell us all what you've concluded but others
on the list cannot, which is a pity since presumably your
use-case is one that motivates a large industrial player
into spending effort on this, so may well be more compelling
that e.g. TCD running about after reindeer herders.

But it is what it is I guess.

Cheers,
S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Jun 2014 21:42:54 +0000

Hi Stephen,

> Sent: Tuesday, June 17, 2014 2:29 PM

OK, but please understand that questions about my company's business
interests will always cause me to clam up rather than open up since
business interests are competition-sensitive. But, I can say that I
am here during working hours exerting energy in these discussions
because my company finds it in their interest for me to do so.

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jun 2014 22:58:09 +0100

Hi Ed,

> - The protocol specs are described in experimental RFCs, with discussion of a bis.

The above is all well and good, but is mostly the kind of argument
we've made over the years in the DTNRG. Not that its wrong or bad,
but its not new. (You're very positive though, so not complete:-)

> - There is a set of lessons learned informing  5050bis/BPv7. To Fred's schedule, this can be resolved in relatively short order.

Sure. But nothing in the above provides a strong argument
for a WG that I can see.

> I know of a few companies and some non-commercial entities that have no issue with BP and are not worried about building a BPA.  But an operational deployment needs a non-experimental spec, securit…

That would be more interesting.

> I am unsure of what is sufficient proof for your question. Does it have to be 10 companies interested and not 8? 25 nodes instead of 18? 100? Is the deployment horizon 1 year and not 3?

Proof is the wrong word. From my POV the only new thing I've
seen here so far is Fred saying Boeing would like this to
happen (but not quite why). That they want it is a good thing.
More folks and more detail would be better of course as
that would give more confidence we're solving the right
problem and our solution might get widely deployed.

There are no hard and fast numbers but I don't believe we've
seen new participants turning up saying that they want this
and why. (I.e. not a bare "+1" mail, but something real.)
We have seen known DTNRG participants saying that which is
also good, but also not really new.

And don't get me wrong, even though I would write a quite
different charter, I'm still supportive of this one if we
end up with it. But folks will be asking these questions.

> So, I naively ask the opposite question: why not standardize this work in the IETF?

The generic arguments are about costs and capacity and keeping
to the knitting. Everything has a cost, and a WG imposes costs
on others (e.g. the IESG, directorates, meetings etc.) not
only on the direct participants.

In this case, one might add a lack of clarity as to "why
this, now" to the generic list.

Then there's Lloyd's objections, with which I mostly do not
agree. But I think he and I do have some common concerns
as to whether this 5050bis is the right target, vs. e.g.
exploring a more web like approach. There is after all only
so much participant effort available and one WG of any
sort will consume all of that. As I've said, I suspect
I'm in the rough on that.

> 
> You have the community of people who are willing to do the work, with backing from industry and government. 

So did OSI:-)

> The charter, as I see it, addresses clear needs for operational
deployment, and to Will's points, the DTNRG persists to continue
inspection of the fundamental research issues surrounding more exotic
deployments.

Actually I don't buy that last. If the WG gets going it is
my belief that the RG will (or should) go dormant, but that's
for discussion elsewhere/when.

S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Jun 2014 22:04:09 +0000

Hi Stephen,

> > You have the community of people who are willing to do the work, with backing from industry and

But remember that OSI did not come from the IETF. We would like
to see something that comes from the IETF.

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jun 2014 23:06:00 +0100

> to see something that comes from the IETF.

Fair enough. BEEP then:-) BTW, only kidding we don't need
to descend further down this rathole.

S.

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Tue, 17 Jun 2014 22:23:58 +0000

Okay, taking another crack at this.

I think there are two levels of question here, one implying the other, and it might be helpful to address them separately.

First the proximate question: given that DTN exists, why standardize it?  Why not just use it as it is?  What has changed?

I think the answer there, to which Fred and Ed have alluded, is that there are business entities that would now like to use DTN to solve some communication problems (or exploit some opportunities) but won't risk doing so while the protocols are not standards.  I know Ed works with such entities on a regular basis, and the fact that Boeing is willing to invest some time and money in this BoF seems to suggest that they at least are another such entity.

So then the underlying question: what are those problems and opportunities for which a standardized DTN would be used?

As Fred has pointed out, organizations that hope to make money from these ideas are not likely to disclose them here or in the BoF.  But, just from my own reading of the news, let me suggest a couple of potential DTN use cases that go beyond the ISS and Saami deployments we're all familiar with.

1.  The UAV industry is exploding.  Nobody has any idea where the limits on applications of UAVs are, but what we do know is that the information that controls them is conveyed by radio, which is occasionally subject to disruption.  Technology that could improve the safety and reliability of UAVs, while reducing cost, could find a large market.

2.  The speed of sound underwater is 1.5 km/sec, so the round-trip time between two underwater entities communicating by acoustic modem and separated by a distance of 7.5 km is about equal to the round-trip time between Earth and the Earth/Sun L2 Lagrange point.  Since the data rates of acoustic modems are low, efficient delay-tolerant networking is a pretty good way to establish underwater communication.  The market for underwater sensors and instrumentation is already in the billions of dollars; revenue in the autonomous underwater vehicle manufacturing industry is growing at nearly 14% per year.

3.  The "space" use case is arguably still small if you restrict it to the vehicles that are in orbit.  If you extend the space communication use case to users on Earth who will need to communicate with spacecraft over the next two decades, as Earth orbit becomes increasingly industrialized, then you find yourself talking about a very large user community.

And I am pretty sure there are more that I'm not aware of.  The basic proposition is that the Internet is an outstanding communications solution for all parts of Earth's surface that are relatively easy to get to, but there are business opportunities that are beyond its current reach.  DTN can help extend that outstanding communications solution to currently Internet-inhospitable parts of the Earth and near-Earth, benefiting a lot of people.  Standardizing it will help make that happen.  As Vint remarked in one of our conversations on this topic (I paraphrase freely), the Internet didn't get created because somebody thought of a killer app; people thought of killer apps because there was an Internet.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, June 17, 2014 1:32 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Hi Fred,

> interoperable standards from the very beginning. It is now time for us 

I'm familiar with DTN. But I find the above a pretty complete non-answer to the question asked (in that it answers no part of my question:-) So I'll try again, in a more direct fashion...

I do not know why specifically Boeing want a standards track RFC5050bis, nor why you want it now.

And I'm wondering and would like to know. I have not heard your use-case (or business case, whatever) explained so far.
Nor have I heard someone say "can't/won't tell, sorry."
So I'm curious.

And I'll note once again that successful BoFs tend to involve explaining why this, now, specifically. As an IESG member it makes it much easier for me to evaluate proposals for forming a WG.

(BTW, any answer that asks me to think like an acorn won't really work for this question, sorry:-)

If someone else has a new answer to this question that would also be interesting. By new, I mean a use-case or business-case that hasn't previously been discussed in the DTNRG.

Cheers,
S.

PS: In case there's confusion. My question is very much not the same as Will's, despite your answer being very similar.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jun 2014 23:37:45 +0100

On 17/06/14 23:23, Burleigh, Scott C (312G) wrote:
> 1.  The UAV industry is exploding.  Nobody has any idea where the
> limits on applications of UAVs are, but what we do know is that the
> information that controls them is conveyed by radio, which is
> occasionally subject to disruption.  Technology that could improve
> the safety and reliability of UAVs, while reducing cost, could find a
> large market.

Excellent example. Now if we knew that that was a focus of interest
that'd be cool and we could discuss timing and contact requirements,
development environments, tooling etc. and how DTN protocols might
fit with e.g. telemetry/control. (Elwyn could even have fun with
routing - we have an old unfunded proposal along those lines;-)

I'm not saying its a fatal problem that we only have the already
known use-cases, but new information such as a confirmation that
your good example was real (and were we to have folks who work
in that space involved), could make for a much more compelling
BoF and likely successful WG.

S.

---

From: Sebastian Schildt <[email-masked]>
Date: Wed, 18 Jun 2014 00:47:50 +0200

Hello *,

I think this raises some interesting points, and from my standpoint I’d like to add something regarding scalabiliy and design targets.

> I think we need some deep philosophical discussion at the BOF on what we are trying to do with DTN.  Most (actually ALL) deployments I am aware of have been in the order of probably tens or less no…
Millions. At least.

I think this is an important point, but as has been mentioned by other replies, maybe scalability is not such a big problem: We can start small and grow. Like IP currently there is nothing in the BP itself that limits scalability. The main challenges wrt. scalability are 
1. Routing. While I have lots of opinions on that, I will not open that discussion again, and it is nothing in the „core“-protocol. 
2. Storage: What to do, when there are millions of bundles around? Who will store what and for how long? But a significant part of these may also be implementation issues.

So trusting, that there are no fundamental problems with scaling up,  when working with DTNs/BP I usually have large-scale systems in mind. I have always seen  DTN/BP as a - for a lack of a better word - "future internet" approach. Not like the dream that many of the "real" future internet  project have: Switch off the old system, and the new one takes over. I rather imagine some slow, organic growth, where more and more applications, for which it makes sense, transition to  DTN (which can be transported over existing  internet transports just fine). An obvious appication area for which the transtion to DTN makes sense are Apps that extend from the internet into fringe networks (internet-based services focussed on mobile users).

More importantly, I see the space and terrestrial use cases converging: The original reason to have DTNs for IPNs are delays and disruptions. Now, in the short term the applications that are deployed might be control traffic for space craft and such things.  But if we are thinking about the middle-term we might have couple of (ten) thousand people living on Mars or elsewhere in the neighbourhood, where we will have communication delays. However, as far as I have followed developments, we WILL have quite a bit of bandwidth(*1). Definitely we do not want to have Mars-Intranet and Earth-Intranet. Or millions of application-specific synchronization solutions (Facebook-Sync, Twitter-Sync,...). Instead, I imagine applications that they are already built in an asynchronous DTN using DTN protocols and thus will just work. Granted, this might all only become relevant, after I have long been recylced, but at least it is one of the images that guide me, when I work on DTN problems.  Think big!

> I do know that some groups want to run DTN (RFC5050) at extremely high rates (Gbps and higher).  The current structure, while nice for research with all the flexibility, is not very well suited for…

In principle, store-carry-and forward as implemented by the BP needs more ressources then lets say TCP/IP. While some research software might not be optimized for performance, this is largely an enigneering problem. Over the last years we put some effort into improving the performance of our own IBR-DTN implementation, and today it _can_ saturate a GBit ethernet link using a normal PC (*2). When we started optimizing, we were far from it. Now it is possible, and I am sure there is much more potential for implementations focussing on this point.
Regarding slower hardware, we built a BP implementation for an 8 Bit microcontroller(*3). While this can not saturate a GBit link :), throughput-wise it was in the same league as an IP implementation on the same plattform.  So I would say the current structure, while being more complex than classical non-DTN protocols,  does not necessarily limits performance

MfG

Sebastian

*1 http://arstechnica.com/science/2014/05/wireless-broadband-can-reach-the-moon-and-maybe-mars/

*2 Wolf-Bastian Pöttner, Johannes Morgenroth, Sebastian Schildt and Lars Wolf: An Empirical Performance Comparison of DTN Bundle Protocol Implementations, Technische Universität Braunschweig, Informatikbericht 2011-08, https://www.ibr.cs.tu-bs.de/papers/poettner-tr201108.pdf
Current tests: http://jenkins.ibr.cs.tu-bs.de/dtnperf/

*3 The µDTN project https://www.ibr.cs.tu-bs.de/projects/mudtn/
Wolf-Bastian Pöttner, Felix Büsching, Georg von Zengen and Lars Wolf: Data Elevators: Applying the Bundle Protocol in Delay Tolerant Wireless Sensor Networks, in The Ninth IEEE International Conference on Mobile Ad-hoc and Sensor Systems (IEEE MASS 2012)

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Wed, 18 Jun 2014 00:19:13 +0000

A perfectly reasonable perspective, Will.  Let me offer a different one.

I don't know how it's possible to say that we don't really know what problem we are trying to solve with DTN, when that problem statement is laid out in detail in section 2 of RFC 4838 and in the papers referenced in that text.  Let's set that aside.

I agree, all deployments that I am aware of have encompassed fewer than 100 nodes.  But this in itself doesn't suggest to me that DTN is structurally unable to support a deployment of millions of nodes.  It suggests to me that nobody has yet chosen to deploy a larger DTN-based network.

So, is the scalability of DTN an issue?  I can think of two good ways to answer that question.  One is to attempt to deploy a very large DTN-based network.  If the attempt fails due to some structural defect in the DTN architecture then yes, it's an issue; if not, then it apparently isn't.  If someone has the resources to take this on as an experiment, that would be great.  But it seems unlikely.

The other would be by inspection: are there elements of required DTN functionality that we know a priori cannot be accomplished if the network comprises a million nodes?

If there are, then we should be able to enumerate them, yes?  Do you have any candidates?

I'll agree that none of the routing systems deployed to date will scale up to a million nodes; a system for federating routing "regions" (something a bit like autonomous systems in the Internet) will very likely be needed.  But that's just development that hasn't happened yet, because nobody has required it.  It's not a structural defect, any more than the need to develop BGP in order to enable the Internet to scale up to millions of nodes was a structural defect.

So what else?

How to deal with a bundle for which you have no route is certainly a question, and different implementations of DTN answer that question in different ways.  Is that a problem?  If it is (and I am by no means convinced that it is) then aren't we talking about writing two lines of specification to deal with it?  That doesn't seem like a significant structural defect to me.

Nor is high-rate operation an issue.  As Sebastian notes, IBR DTN on a PC can already saturate a Gigabit Ethernet.  ION runs a bit slower, in part because the implementation is designed to be able to survive an unplanned power reset at any moment without losing state or compromising the integrity of bundles at rest.  Even so, ION's built-in benchmark tests show BP/LTP between two nodes on the Linux box in my office running at about 390 Mbps for 1-Megabyte bundles. (BP/TCP is faster, close to 3 Gbps for 10-Megabyte bundles.)

Finally, to say that all of the DTN operations experience on ISS since 2009, the METERON experiments in DTN-based telerobotics, the N4C experiments in Slovenia and Sweden from 2008 to 2011, and the month-long DINET operations on EPOXI over 10 million miles from Earth, with multi-day round trip times, all amount to little more than a ping is simply false.

So sure, there's still plenty of room for research on DTN.  People still do research on Internet issues, I believe.  I don't think there's a problem here.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of William Ivancic
Sent: Tuesday, June 17, 2014 11:25 AM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Some thoughts:

Will Ivancic
Syzygy Engineering

---

From: <[email-masked]>
Date: Wed, 18 Jun 2014 12:55:45 +0000

> 1.  The UAV industry is exploding.

Q. What's the difference between an Al Qaeda convoy and a bus full of schoolchildren?

A. I don't know, I only fly the drones.

Exploding? Really, Scott? Wouldn't 'growing' have been enough?

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

that there was no obvious reason for reindeer herders to talk to deep space probes.
There is no shared killer app.
So there's no obvious or compelling reason to build a bundle overlay
connecting them. The separate communities do need to connect to the Internet - 
but for entirely different purposes.

However, I'm surprised that some sort of DTN herders-talk-to-schoolchildren-talk-to
astronauts-on-the-ISS-using-the-Bundle-Protocol effort has not been manufactured.
Perhaps for the next ExtremeCom?

A key point here is that TCP/IP was in widespread use _before_ it was a standard.
The standards track was retrofitted (RFC1310 is later than RFC761/768 et al.) to
apply to specifications that have not changed substantially since.

Here, the Bundle Protocol is not in widespread use, and it seems that some
are hoping that pushing it onto the standards track will fix that. While
grudgingly acknowledging that, yes, it also needs reworking in rather
significant ways, while not acknowledging the drain on IETF resources
and attention that this will be. 

This sounds a lot like the OSI committee work - write the standard, and once it's a
standard they will be forced to come, success assured. That consumed a 
_lot_ of standards body resources.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn <[email-masked]> on behalf of Burleigh, Scott C (312G) <[email-masked]>
Sent: Wednesday, 18 June 2014 8:23 AM
To: [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, June 17, 2014 1:32 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Hi Fred,

Cheers,
S.

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 18 Jun 2014 13:00:28 +0000

UAV applications sound good initially, but when you look at the
regulations, it is a not starter.  You must be in control of the aircraft
at all times.  There is not a pilot IN the aircraft, but there is one
flying it!  Air Traffic Control is all about Safety of Flight and Safety
of Life.

NASA Glenn Research Center is working the communications issues and
technologies for integrating Unmanned Air Vehicles (UAVs) in the National
Airspace System (NAS).

DTN for UAVs - only after you have gained complete confidence in
autonomous control for air craft avoidance.  That isn't even being worked
now.  Maybe 50 years from now, but not for a long time.

Will

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 18 Jun 2014 15:02:57 +0100

One of the best worked out proposals for DTN routing that I know of is
in the UAV space [1].  The proposal is intended for passing
reconnaissance sensor data back through a swarm and is a geographic
system that piggy backs on the expected GPS system in a UAV (clearly
realistic unlike many other proposals where GPS is a must have).  My
instinct was that this system had actually been implemented and trialled
- based entirely on gut feel and the way in which the expected
practicalities were addressed.

Using it directly for control is obviously another matter, but for data
recovery it looked good. 

Regards,
Elwyn

[1] A framework for performance analysis of geographic delay-tolerant
routing
Erik Kuiper, Simin Nadjm-Tehrani, Di Yuan (2012) 
EURASIP Journal on Wireless Communications and Networking 2012 (1) p.
184 
http://jwcn.eurasipjournals.com/content/2012/1/184

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Jun 2014 15:04:26 +0000

Hi Will,

> From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
> Sent: Wednesday, June 18, 2014 6:00 AM
> To: Stephen Farrell; Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; [email-masked]

A recent NASA solicitation is asking for proposals for supporting
single-pilot operations on commercial airplanes. If a single pilot
becomes incapacitated, and if there is no ground controller, the
plane becomes zero-pilot and needs to rely fully on automation.

Remote UAV mission scenarios will eventually rely fully on automation.
The US government has also posted the FAA Modernization and Reform Act
of 2012 which calls for integration of UAVs into the national air space
within this decade. Plus, we already have the google driverless car on
the road today.

Fully autonomous operation is coming. Technology will continue to move
forward and regulations will change.

Thanks - Fred

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Wed, 18 Jun 2014 15:32:54 +0000

Will, Fred is way more knowledgeable about UAVs than I am, so I'm happy to go with his assessment.  But in any case I don't think I said anything about DTN being great only for pilot-less UAV operations.  UAV operations, piloted or not, rely on communications.  Technology that can improve communications with UAVs makes them safer and more reliable.  As I understand it, if communication with a remotely piloted UAV is interrupted for any reason, the vehicle has to go into some sort of safe autonomous operational mode until communication is restored; the more quickly and reliably that can happen -- that is, the better the disruption can be handled -- the sooner the aircraft can resume normal operations.

Scott

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]] 
Sent: Wednesday, June 18, 2014 6:00 AM
To: Stephen Farrell; Burleigh, Scott C (312G); [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

UAV applications sound good initially, but when you look at the regulations, it is a not starter.  You must be in control of the aircraft at all times.  There is not a pilot IN the aircraft, but there is one flying it!  Air Traffic Control is all about Safety of Flight and Safety of Life.

NASA Glenn Research Center is working the communications issues and technologies for integrating Unmanned Air Vehicles (UAVs) in the National Airspace System (NAS).

DTN for UAVs - only after you have gained complete confidence in autonomous control for air craft avoidance.  That isn't even being worked now.  Maybe 50 years from now, but not for a long time.

Will

On 6/17/14 6:37 PM, "Stephen Farrell" <[email-masked]> wrote:

>development environments, tooling etc. and how DTN protocols might fit 
>with e.g. telemetry/control. (Elwyn could even have fun with routing - 
>we have an old unfunded proposal along those lines;-)
>
>I'm not saying its a fatal problem that we only have the already known 
>use-cases, but new information such as a confirmation that your good 
>example was real (and were we to have folks who work in that space 
>involved), could make for a much more compelling BoF and likely 
>successful WG.
>
>S.
>

---

From: ccaini <[email-masked]>
Date: Wed, 18 Jun 2014 19:10:51 +0200

Dear All,
  I am not a UAV expert, but I have read some papers about DTN application
to them and I am also aware of some research on this field. 
UAVs may, or may not, need a continous channel to be remotely controlled.
In fact they can also fly in a completely autonomous way (I have seen some
small UAVs flying this way) with the flight route precharged before
launching. Of course, present regulations may or may not allow this,
depending on countries. Anyway, the communication channel used to pilot
them, if any, as well as being subject to possible disruption, as stated by
Scott, does not need to be the same used for downloading data (e.g.
pictures). The former can be a continous channel with scarce bandwidth but
large coverage (e.g. that provided by a GEO satellite, or by a global LEO
constallation, as Iridium), the latter can be a short range high bandwith
link, characterized by an intermittent connectivity. For this link DTN
seems of course the ideal choice. Moreover, communication can be integrated
with flying control, and a UAV during the download of pictures to an earth
station can keep hoovering or flying around until the reception of a BP
custody acceptance from the node on the ground. Only after this reception
the UAV is allowed to restart is normal flight. The same of course can be
done with whatever DTN mule, not just UAVs. Not sure but maybe it was done
with helicopters working as data mule in N4C. Maybe Stephen Farrell can
confirm.
Yours,
  Carlo Caini

On Wed, 18 Jun 2014 15:32:54 +0000, "Burleigh, Scott C (312G)"
<[email-masked]> wrote:
> Will, Fred is way more knowledgeable about UAVs than I am, so I'm happy
to
> go with his assessment.  But in any case I don't think I said anything
> about DTN being great only for pilot-less UAV operations.  UAV
operations,
> piloted or not, rely on communications.  Technology that can improve
> communications with UAVs makes them safer and more reliable.  As I
> understand it, if communication with a remotely piloted UAV is
interrupted
> for any reason, the vehicle has to go into some sort of safe autonomous
> operational mode until communication is restored; the more quickly and
> reliably that can happen -- that is, the better the disruption can be
> handled -- the sooner the aircraft can resume normal operations.
> 
> Scott
> 

> flying it!  Air Traffic Control is all about Safety of Flight and Safety
of
> Life.

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 18 Jun 2014 17:39:21 +0000

Yes for payload data one could use DTN if it fit the deployment scenario.
I say understand the deployment scenario because we looked at DTN and
mobile-ip for the NASA Global Hawk flying over the poles.  DTN provide no
value because you were connect up to the 70+ degrees latitude, then
disconnected until the return at which point you were connected again.
The network was single-hop.  LEO spacecraft have similar.  Yes, you can
use DTN, but there are other solutions that may be simpler.

The group should beware of what we state the use cases are.  At this point
in time, if one were to indicate, without specifying payload data, that
DTN could be used for UAVs, people working these policy programs and
trying to integrate UAVs into the National and Global Airspace will
probably not be happy.  They have enough issues and hurdles without
someone thinking large cargo UAVs are going to fly into San Diego with
disrupted communications (FYI, one can literally walk from San Diego
airport to the center of downtown San Diego in 20 to 30 minutes.  That is
how close those large aircraft fly to downtown.)

Will

******************************

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Wed, 18 Jun 2014 18:00:22 +0000

Hi, Stephen.  I figure you're not saying that Boeing (or anybody else) has got to disclose proprietary information or forego business opportunities in order to make the BoF more compelling and the WG more successful.  What you're really telling us is that it would be advantageous if the WG were simply able to focus on some use case that is not an insignificant niche or a purely academic problem, correct?  Not necessarily the specific use case(s) that interest Boeing, that Fred can't discuss, but at least something with potentially significant impact.

In that context, maybe it would be helpful to look at a project I've been noodling with for the past few years.  "Ring Road" would be a DTN-based communication satellite network aimed (originally) at provided extremely low-cost -- but high-latency -- network communication service to communities that lack Internet access, typically because they're geographically isolated, economically disadvantaged, and/or temporarily devastated by natural or political disaster.  There's a summary presentation at http://ipnsig.org/wp-content/uploads/2014/02/Ring-Road-applicationsRev1.pdf which I would be more than happy to discuss on this list or privately, with whoever is interested.

I think that project constitutes the sort of focus we might be looking for, as it's not a niche use case or a purely academic problem.  Potential users would be in the hundreds of thousands, perhaps millions, so it's a sort of forcing function for scalability.  It's an open architecture, so standardization is necessary.  It's entirely deployable using DTN implementation software that can be downloaded off the Internet, with very little additional development.  A lot of the configuration details have already been worked out, at least to the level of back-of-the-envelope numbers.

And deployment of this sort of capability is entirely plausible.  We've been in conversations with the Media Development Investment Fund about infusing this architecture into a second stage of their Outernet project, which initially is aiming only at downloading content to subscribers but which may want to expand into bidirectional networking once their constellation is deployed.  Beyond this, though, it would constitute an inexpensive way for any large multinational entity -- a business, a group of collaborating NGOs -- to construct its own entirely private worldwide communication network. It could easily interconnect autonomous undersea vehicles in mid-ocean with operators in Tennessee or Latvia, using BP end-to-end.  Alternatively, by somewhat increasing the size (and cost) of the satellites and using more powerful radios we could evolve it into a very low-cost, high-latency bulk data transfer infrastructure, which would be quite good for large-scale multimedia distribution.  Lots of possibilities, I think.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2014 3:38 PM
To: Burleigh, Scott C (312G); [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

On 17/06/14 23:23, Burleigh, Scott C (312G) wrote:
> occasionally subject to disruption.  Technology that could improve the 
> safety and reliability of UAVs, while reducing cost, could find a 
> large market.

Excellent example. Now if we knew that that was a focus of interest that'd be cool and we could discuss timing and contact requirements, development environments, tooling etc. and how DTN protocols might fit with e.g. telemetry/control. (Elwyn could even have fun with routing - we have an old unfunded proposal along those lines;-)

I'm not saying its a fatal problem that we only have the already known use-cases, but new information such as a confirmation that your good example was real (and were we to have folks who work in that space involved), could make for a much more compelling BoF and likely successful WG.

S.

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Wed, 18 Jun 2014 18:22:09 +0000

Sorry, I should have noted before that Ed Birrane, Aaron Rogers, and Chris Krupiarz of the Johns Hopkins University Applied Physics Laboratory made major contributions to the "Ring Road" concept.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312G)
Sent: Wednesday, June 18, 2014 11:00 AM
To: [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

And deployment of this sort of capability is entirely plausible.  We've been in conversations with the Media Development Investment Fund about infusing this architecture into a second stage of their Outernet project, which initially is aiming only at downloading content to subscribers but which may want to expand into bidirectional networking once their constellation is deployed.  Beyond this, though, it would constitute an inexpensive way for any large multinational entity -- a business, a group of collaborating NGOs -- to construct its own entirely private worldwide communication network. It could easily interconnect autonomous undersea vehicles in mid-ocean with operators in Tennessee or Latvia, using BP end-to-end.  Alternatively, by somewhat increasing the size (and cost) of the satellites and using more powerful radios we could evolve it into a very low-cost, high-latency bulk data transfer infrastructure, which would be quite good for large-scale multimedia distribution.  Lots
  of possibilities, I think.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tuesday, June 17, 2014 3:38 PM
To: Burleigh, Scott C (312G); [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Jun 2014 20:04:59 +0000

Hi Will,

> Sent: Wednesday, June 18, 2014 10:39 AM
> To: ccaini; [email-masked]

No one is going to be flying a zero-pilot freighter into San Diego
anytime soon, but you seem to be coming at this from a perspective
of extremes. As in: "If the extremes (e.g., large-scale deployment,
full UAV autonomy, etc.) aren't addressed in the first iteration
then let's just forget the whole thing". But, that's not the way
things work in real life. With that sort of thinking, the Internet
(with its start-small grass-roots upbringing) never would have
come into existence.

Start with lots of limited-scale DTNs, then join them together to
form larger DTNs - all of it supported by standard protocols. That
is how the world works.

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Jun 2014 21:38:58 +0100

Hi Scott,

On 18/06/14 19:00, Burleigh, Scott C (312G) wrote:
> Hi, Stephen.  I figure you're not saying that Boeing (or anybody
> else) has got to disclose proprietary information or forego business
> opportunities in order to make the BoF more compelling and the WG
> more successful.  

Clearly. We can't force anyone to do anything.

However, its pretty common that vendors do manage to say
something about what it is they'd like to do with the IETF
standard they want created. I can't think of any other case of
"can't tell" from the main BoF proponent to be honest. (I do
recall cases where what that proponent said wasn't very easy
to believe, so Fred's doing better than that for sure:-)

I also need to look at Kip's mail to see if there's more
in that - its doesn't have to be Fred who offers use-cases.

> What you're really telling us is that it would be
> advantageous if the WG were simply able to focus on some use case
> that is not an insignificant niche or a purely academic problem,
> correct?  Not necessarily the specific use case(s) that interest
> Boeing, that Fred can't discuss, but at least something with
> potentially significant impact.

Not quite. Reality is what I'm after rather than plausible
speculation - we've done quite a lot of the latter over the
years in the RG and while that's well and good, its less good
than reality.

Cheers,
S.

PS: Didn't get into your reasonable scenario below on the
basis of my argument above. Interesting stuff though.

> 
> In that context, maybe it would be helpful to look at a project I've
> been noodling with for the past few years.  "Ring Road" would be a
> DTN-based communication satellite network aimed (originally) at
> provided extremely low-cost -- but high-latency -- network
> communication service to communities that lack Internet access,
> typically because they're geographically isolated, economically
> disadvantaged, and/or temporarily devastated by natural or political
> disaster.  There's a summary presentation at
> http://ipnsig.org/wp-content/uploads/2014/02/Ring-Road-applicationsRev1.pdf
> which I would be more than happy to discuss on this list or
> privately, with whoever is interested.
> 
> I think that project constitutes the sort of focus we might be
> looking for, as it's not a niche use case or a purely academic
> problem.  Potential users would be in the hundreds of thousands,
> perhaps millions, so it's a sort of forcing function for scalability.
> It's an open architecture, so standardization is necessary.  It's
> entirely deployable using DTN implementation software that can be
> downloaded off the Internet, with very little additional development.
> A lot of the configuration details have already been worked out, at
> least to the level of back-of-the-envelope numbers.
> 
> And deployment of this sort of capability is entirely plausible.
> We've been in conversations with the Media Development Investment
> Fund about infusing this architecture into a second stage of their
> Outernet project, which initially is aiming only at downloading
> content to subscribers but which may want to expand into
> bidirectional networking once their constellation is deployed.
> Beyond this, though, it would constitute an inexpensive way for any
> large multinational entity -- a business, a group of collaborating
> NGOs -- to construct its own entirely private worldwide communication
> network. It could easily interconnect autonomous undersea vehicles in
> mid-ocean with operators in Tennessee or Latvia, using BP end-to-end.
> Alternatively, by somewhat increasing the size (and cost) of the
> satellites and using more powerful radios we could evolve it into a
> very low-cost, high-latency bulk data transfer infrastructure, which
> would be quite good for large-scale multimedia distribution.  Lots of
> possibilities, I think.
> 
> Scott
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Tuesday, June 17, 2014 3:38
> PM To: Burleigh, Scott C (312G); [email-masked] Subject: Re: [dtn]
> Draft Charter Discussion
> 
>> the safety and reliability of UAVs, while reducing cost, could find
>> a large market.
> 
> known use-cases, but new information such as a confirmation that your
> good example was real (and were we to have folks who work in that
> space involved), could make for a much more compelling BoF and likely
> successful WG.
> 
> S.
> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Jun 2014 20:47:55 +0000

Hi Stephen,

> Sent: Friday, June 20, 2014 1:39 PM

If you follow up on the thread Kip was posting to, you'll
see that I gave it a +i (for some value of i between 0 an 1).

Thanks - Fred

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 20 Jun 2014 21:01:42 -0400

Hi Stephen,

Sorry for pruning, my web mail client is acting up...

> but its not new. (You're very positive though, so not complete:-)

Agreed that the above benefits of the technology to potential deployments are not new. But we haven't attached a TTL on good ideas or desirable properties. 

> Sure. But nothing in the above provides a strong argument
 
We have a clever protocol to handle sticky connectivity situations. We have a decade of experience with that protocol and other standards/protocols around it. We have entities wanting to implement these things as non-experimental standards in operational networks. We have activity in areas necessary to cover operational deployments, such as security and NM. We have identified an important set of updates to the experimental standard and a community of funded people willing to do the standards work.

IMO, those are all true statements and, together, are a fine argument for doing the work.

> end up with it. But folks will be asking these questions.

I do understand this.  I have had many more conversations (sadly off list) that have removed from my mind the question of commercial interest, participation, and deployment. However, so much of it surrounds new deployment strategies, products, services, etc... that DTN considerations get pulled too quickly behind the business proprietary curtain. 

Besides Boeing and NASA, I know of at least 2 other companies that have funded activity related to DTN deployed in their products. I am aware of 3 or 4 others that have either addressed or advertised DTN in their proposals and marketing literature. I have been asked quite a few times "when will the DTN protocols be ready for us to adopt", the implied question being "when will the standard stop being experimental". I freely admit that is a bunch of hearsay, but it is what I can offer right now.

-Ed

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 20 Jun 2014 21:15:56 -0400

We really can't stress point 3 enough.  The industrialization of near-earth space is growing.  In doing so, it is also transitioning away from space agencies and large aerospace. The companies I have talked with want their ground infrastructure, space infrastructure, and peers integrated in a single end-to-end overlay.

Ultimately, I have seen a commercial desire to make the Internet of Things into the Internet of Moving Things. DTN is not a magical cure for that, but it is seen as a reasonable part of the puzzle.

-Ed

________________________________________
From: dtn [[email-masked]] On Behalf Of Burleigh, Scott C (312G) [[email-masked]]
Sent: Tuesday, June 17, 2014 6:23 PM
To: [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, June 17, 2014 1:32 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Hi Fred,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Jun 2014 02:16:14 +0100

Hiya,

On 21/06/14 02:01, Birrane, Edward J. wrote:
> I do understand this.  I have had many more conversations (sadly off
> list) that have removed from my mind the question of commercial
> interest, participation, and deployment. However, so much of it
> surrounds new deployment strategies, products, services, etc... that
> DTN considerations get pulled too quickly behind the business
> proprietary curtain.

So one reason I'm going on about this is that my experience
with DTN projects (and failed proposals;-) has been that
there are often ways to get enough DTN-like functionality for
some specific purpose without the BP, and that those other
ways will be chosen in preference to the BP in various cases.

For example, based on lack of OS support, or if most code is
UI code then the benefits from the BP are less and can be
overwhelmed by the availability of a library, or if the
delay/disruption on almost all paths is only experienced
on one link, in which case e2e DTN isn't quite needed. Its
not a knock-out argument by any means, but is real.

If all that offlist discussion stays offlist then I am
less confident that a WG will be able to have discussions
based on what people really need and would be in danger
of deciding based on the loudest voice on the list (which
could be mine sometimes, and that'd be just as wrong or
even more wrong than usual:-).

And such bad decisions, if made, would be more likely to
lead to a 5050bis that ends up not being used much, which
would be a waste of all our efforts.

That's my concern. Its not alleviated by plausible
scenarios at all, nor by offlist discussions.

S.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 20 Jun 2014 23:26:25 -0400

Stephen, 

  Yes, it would be an interesting data point if a company said something like "we are deploying a DTN of purpose X and need a WG to help us with Y."  But that can't be the only way to assess the value of an IETF WG, right? 

> ways will be chosen in preference to the BP in various cases.

Projects use what is available because the focus of the project is... to do whatever the project should be doing rather than developing telecom protocols. If there was a non-experimental DTN implementation of a lessons-learned BPv7 with security and management, projects would integrate that - even if they just wanted 70% of the stack. This is what NASA, Boeing, Harris (Kip), Outernet, and other companies seem to be asserting here.

Getting to the point where it is cheaper to adopt the DTN stack rather than assemble an alternative is an implementation matter, is necessary, and (IMO) requires non-experimental specs.

> even more wrong than usual:-).

DTN has a long history of experimentation, investment, and an interest list with 1000+ people on it. ;) I would not discount the value of the existing body of evidence - correcting for loudness - to successfully inform the WG.

Besides, needs can be discussed without delving into business practices. Fred's charter certainly gives what I presume is Boeing's focus. I've focused on the following for things like Outernet (which is a suitable stand in for a variety of off-list efforts because in this way they are all roughly the same...)

- Clever protocol bits about extension blocks, custody transfers, and standardized queuing models consolidated in one spec.
- An end-to-end overlay protocol to reduce gateways, proxies, and the complexities of configuration.
- Automation enough to get the human-out-of-the-loop, either due to signal propagation delays, link disruptions, or operator disruptions.
- Interoperability over multiple existing transports without needing to redo everything when integrating another network.

IMO, the work Fred has outlined in the charter pretty much encompasses the above. 

-Ed

---

From: William Ivancic <[email-masked]>
Date: Mon, 23 Jun 2014 06:07:51 -0700

Low Earth Orbiting (LEO) satellite networks tend to be  single hop before you hit the connected Internet.  So, you need efficient transport protocols if you have highly asymmetric links, but you do not really need the features of RFC5050.  Unless you have a multi-hop disconnected network, RFC5050 doesn't buy you much and adds complexity and the routing protocols are not necessarily there.

Skybox and Planet Lab were at AIAA SpaceOps 2014 this May.  I talked to both groups.  Neither mentioned DTN.  Skybox said they simple consider their satellites as a server in the sky.  One of them, I think Skybox, is using 9P to communicate to there satellites.  RTT to a LEO is under 10 msec.  

Will

________________________________
 From: "Birrane, Edward J." <[email-masked]>
To: "Burleigh, Scott C (312G)" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, June 20, 2014 9:15 PM
Subject: Re: [dtn] Draft Charter Discussion

-Ed

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, June 17, 2014 1:32 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Hi Fred,

Cheers,
S.