Subject: [dtn] DTN BoF Proposal for IETF90 - Consensus Check

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

Hello, and welcome to the [email-masked] mailing list. As many of you may
recall, on April 25th I posted on [email-masked] to propose a BoF
meeting at IETF90 for the purpose of discussing the formation of a DTN
working group in the IETF:

http://www.ietf.org/mail-archive/web/dtn-interest/current/msg05080.html

A great deal of discussion ensued, with many suggestions and insights
that were captured in the archives. It is now time to check whether
there is consensus to go forward with the BoF through discussion on
this new list.

While there were many suggestions on changes and additional work items
to add to the proposed BoF agenda and working group charter, I will
begin by reposting the original proposal below. We can work on revising
these as we move closer to the actual BoF, but for now let's focus the
discussion on whether there is consensus to move forward. Comments?

Fred
[email-masked] 

---

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

2) RFC5050(bis) - 30min

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

4) Bundle-in-Bundle Encapsulation - 30 min

5) DTN Security Key Management - 30min

Proposed working group charter:
*******************************
Working group name: 

      Delay/Disruption Tolerant Networking Working Group (DTNWG)

Chair(s):

      TBD

Area and Area Director(s):

      Transport Area: ADs Spencer Dawkins <spencerdawkins.ietf at gmail.com>,
                          Martin Stiemerling <mls.ietf at gmail.com>

Responsible Area Director:

      TBD

Mailing list:

      General Discussion: dtn-interest at irtf.org (note: until wg formed)
      To Subscribe: https://www.ietf.org/mailman/listinfo/dtn-interest
      Archive: http://www.ietf.org/mail-archive/web/dtn-interest/current/maillist.html

Description of Working Group:

      The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies
      mechanisms for data communications in the presence of long delays
      and/or intermittent connectivity. The work is motivated by well known
      limitations of standard Internet protocols that expect end-to-end
      connectivity between communicating endpoints, sub-second transmission
      delays and robust packet delivery ratios. In environments where these
      favorable conditions do not apply, existing mechanisms such as reliable
      transport protocols and routing protocols can fail to converge resulting
      in communication failures. Furthermore, classical end-to-end security
      associations cannot be coordinated when communicating endpoints cannot
      conduct multi-message keying exchanges in a timely fashion. These
      limitations suggest the need for a new approach. 
      
      Delay-Tolerant Networking (DTN) protocols have been the subject of
      extensive research and development in the Delay-Tolerant Networking
      Research Group of the Internet Research Task Force since 2002.  In
      particular, the DTN Bundle Protocol (RFC 5050) and Licklider
      Transmission Protocol (RFC 5326) have been shown to address the
      issues identified above.  In 2008, BP/LTP was deployed on the EPOXI
      spacecraft in deep space and was used to conduct reliable, automated
      communication for four weeks over a network of 10 nodes in which the
      bottleneck router in the network (the spacecraft) was up to 100 light
      seconds from all other nodes and connectivity with the router was
      subject to periods of disconnection lasting several days.

      The success of the BP/LTP protocol stack -- the core protocols of the
      "DTN Architecture" originally described in RFC 4838 -- in this
      demonstration may be attributed to the following fundamental design
      principles:

	- There is never any expectation of contemporaneous end-to-end
       connectivity between any two network nodes.  Where such connectivity
       is sustained, the protocols leverage it to optimize performance,
       but the possibility of transient but sustained disconnection at
       any time, anywhere in the network, is always recognized.

	- Because end-to-end connectivity can never be assumed, each node
	  on the path between source and destination must be prepared to
	  handle incoming "bundles" of data that cannot immediately be
	  forwarded.  Such bundles must either be stored for future trans-
	  mission or discarded; in the latter case, the network must
	  be informed of this data loss so that an alternative path may
	  be selected, to avoid impairing the usability of the network.

	- Again because end-to-end connectivity can never be assumed,
	  end-to-end conversational data exchange can never be assumed to
	  complete in a timely manner; protocol features that rely on
	  timely conversational data exchange must be excluded from the
	  architecture.  This principle makes the DTN architecture
	  suitable not only for network environments characterized by
	  lengthy disconnection but also for those that are characterized
	  by long signal propagation delays (such as underwater communication
	  by acoustic signals or, worse, interplanetary communication) even
	  when connectivity is continuous.

      The DTNWG believes that protocols adhering to these principles offer
      opportunities for enhancing the functionality of the Internet - in
      particular, for facilitating the extension of the Internet into
      environments such as the ocean floor and deep space in which the core
      Internet protocols operate sub-optimally for the reasons discussed
      earlier.  We believe that the extensive research, demonstration, and
      pilot operations performed to date using the DTNRG protocols, both
      before and after the EPOXI experiment, provides a firm basis for
      publishing Internet standards derived from that work.

      Work items related to Delay/Disruption Tolerant Networking include:

      o A mechanism for the exchange of protocol data units, termed
	"bundles", that are designed to obviate conversational communications
	by containing values for all potentially relevant configuration
	parameters.  These protocol data units are typically larger than
	network-layer packets.  We expect to derive this bundle exchange
	mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050.

      o A security protocol for ensuring that the network in which bundles
	are exchanged is secured against unauthorized access and denial of
	service attacks, and to ensure data integrity and confidentiality
	in that network where necessary.  We expect to derive this security
	protocol from a "streamlined" adaptation of the DTN Bundle Security
	Protocol documented in RFC 6257.

      o An encapsulation protocol for "tunneling" BP traffic within bundles
	that are secured and/or routed in different way from the encapsulated
	bundles.

      o A delay-tolerant security key management scheme for ensuring that
	public keys are certified by a globally trusted authority to protect
	the integrity of the infrastructure.
  
    The working group will consider extending the current milestones based on
    new information and knowledge gained while working on the initial charter,
    as well as to accommodate new work items beyond the scope of the initial
    phase.  For example, we expect that transport protocols uniquely suited
    to the various communication environments that may need to be traversed
    by a single DTN end-to-end path (operating under BP, at what is termed
    the DTN "convergence layer") will need to be standardized in a second
    phase of the working group's charter; LTP and the Saratoga protocol are
    among the candidates for work in this phase.  These adjustments will be
    accommodated in a working group recharter, assuming the initial
    chartered activities meet their delivery milestones. Possible new work
    items must then still fit into the (rechartered) DTNWG charter scope.
    
Goals and Milestones:
  start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a
                      working group document. To be Proposed Standard.
  Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a
                       working group document. To be Proposed Standard.
  start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working
                      group document. To be Proposed Standard.
  start+9mos - Submit 'Delay Tolerant Networking Security Key Management' as
                      a working group document. To be Proposed Standard.
  start+9mos - Submit 'Bundle Protocol Specification (RFC5050bis)' to the
                      IESG. To be Proposed Standard.
  start+9mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' to the
                      IESG. To be Proposed Standard.
  start+10mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' to the IESG.
                       To be Proposed Standard.
  start+11mos - Submit 'Delay Tolerant Networking Security Key Management' to
                       the IESG. To be Proposed Standard.
  start+12mos - Recharter to accommodate new work items or close Working Group

---

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

> begin by reposting the original proposal below.

Based on my read of the archives, there were many suggestions for the
proposed working group charter. I know I am not capturing everything,
but at least the following items were proposed for consideration:

  - Consider merging SBSP, Bundle-in-Bundle Encapsulation and
    RFC5050(bis) into a single document
  - Convergence Layer(s)
  - Contact discovery
  - Routing protocols
  - Registry for service identifiers
  - Compressed Bundle Header Encoding
  - Network management

Please let me know what I may be missing or mis-representing.

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Jun 2014 21:54:14 +0100

Hi Fred,

>   - Compressed Bundle Header Encoding

I'd be interested in a version of the charter text that includes
whatever are the changes related to the above that you (as the
BoF proponents) think are reasonable.

> Please let me know what I may be missing or mis-representing.

We had a longish discussion of whether or not the proposed WG
would be much more of a "5050bis with minimal change" or would
attempt to more broadly revisit the BP as an instance of the
DTN architecture described in RFC 4838.

While I would be in favour of the latter, I don't think the list
discussion landed there, (so far anyway) and it seems clear that
the BoF proponents are more in favour of the former, i.e. minimal
changes to 5050.

That still needs to be much more clearly stated in the proposed
charter text IMO, as it significantly impacts on the scope
of the proposed WG.

S.

> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 3 Jun 2014 17:03:22 -0400

> charter text IMO, as it significantly impacts on the scope

I agree that the scope needs to be well defined.

We could do this in two steps:
1.1 Minimal changes (5050bis, registry, convergence layer, ...) that does not change the architecture.
1.2 write a problem statement for the "revisit BP and the architecture" 

then after completing 1.1 and 1.2, either close the wg, move it to the rg, or recharter, all based on 1.2 outcome

Marc.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Jun 2014 22:08:38 +0100

On 03/06/14 22:03, Marc Blanchet wrote:

> We could do this in two steps: 1.1 Minimal changes (5050bis,
> registry, convergence layer, ...) that does not change the
> architecture. 1.2 write a problem statement for the "revisit BP and
> the architecture"
> 
> then after completing 1.1 and 1.2, either close the wg, move it to
> the rg, or recharter, all based on 1.2 outcome

I'd argue myself that there's no need for a problem statement
and that a bigger change than envisaged would likely still
conform to the DTN architecture. So I'd not find that plan
attractive tbh. I also doubt that there'd be energy for such
a plan. Once a 5050bis is done, it'd be sensible to wait a
while and see how its deployment goes.

S.

> 
> Marc.
> 
>> 
>> S.
>> 
>> 
>>> 
>>> Thanks - Fred [email-masked]
>>> 
>>> _______________________________________________ dtn mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>>> 
>> 
>> _______________________________________________ dtn mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
> 
> 
> 
> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>

---

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

Hi Stephen,

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Tuesday, June 03, 2014 1:54 PM
> To: Templin, Fred L; [email-masked]
> Subject: Re: [dtn] Proposed Working Group Charter Suggestions
> 
> 
> Hi Fred,
> 

I think a large part of this process will be to refine the proposed
working group charter, and it will be an iterative process. It may
not be fully resolved before the actual BoF is held, but to my
understanding having the charter agreed to and approved is not a
pre-condition for conducting the BoF.

However, it seems that you would like to see a first iteration of
the revised proposed charter based on the discussions of the past
couple of months on the dtnrg list - is that what you are asking?

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Jun 2014 22:23:03 +0100

> couple of months on the dtnrg list - is that what you are asking?

I think that'd be great,
Thanks,
S.

---

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

Hi, Stephen.  In my mind those are not necessarily the only two options.  I definitely would not be in favor of starting from a blank sheet of paper.  A number of changes to BP have been proposed, at one time or another, most of which I think have merit, and some of which might be considered substantial.  If those changes were made, would the result be considered "5050 with minimal change"?  The term "minimal" is slippery here and, I think, generally not helpful.

Maybe the charter clarification you're looking for could simply take the form of a strawman list of proposed changes?

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, June 03, 2014 1:54 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Proposed Working Group Charter Suggestions

> Please let me know what I may be missing or mis-representing.

We had a longish discussion of whether or not the proposed WG would be much more of a "5050bis with minimal change" or would attempt to more broadly revisit the BP as an instance of the DTN architecture described in RFC 4838.

While I would be in favour of the latter, I don't think the list discussion landed there, (so far anyway) and it seems clear that the BoF proponents are more in favour of the former, i.e. minimal changes to 5050.

That still needs to be much more clearly stated in the proposed charter text IMO, as it significantly impacts on the scope of the proposed WG.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Jun 2014 23:04:12 +0100

On 03/06/14 22:41, Burleigh, Scott C (312G) wrote:
> Hi, Stephen.  In my mind those are not necessarily the only two
> options.  

Sure. Could be the only two feasible options though:-)

> I definitely would not be in favor of starting from a blank
> sheet of paper.  A number of changes to BP have been proposed, at one
> time or another, most of which I think have merit, and some of which
> might be considered substantial.  If those changes were made, would
> the result be considered "5050 with minimal change"?  The term
> "minimal" is slippery here and, I think, generally not helpful.

Sorry, didn't mean it as a derogatory term, but I do think it
seems to accurately capture the intent as I understand it. And
"minimal" is a valid goal, just one with which I'd disagree.
To be clear, and as I've said before, if there's enough support
for that "minimal" goal, then I'm ok to be in the rough and still
want to see the work going ahead. Before and during the BoF is
the time for that scoping discussion though.

> Maybe the charter clarification you're looking for could simply take
> the form of a strawman list of proposed changes?

Actually, for me at least, the general characterisation is
more useful as a guideline for which of the other fairly well
known kinds of change will likely get done. That may be different
for others of course, so you're probably right that a TBD
list of changes will be useful, maybe in an update to Fred's
draft?

S.

> 
> Scott
> 
> -----Original Message----- From: dtn [mailto:[email-masked]] On
> Behalf Of Stephen Farrell Sent: Tuesday, June 03, 2014 1:54 PM To:
> Templin, Fred L; [email-masked] Subject: Re: [dtn] Proposed Working
> Group Charter Suggestions
> 
> 
>> 
> We had a longish discussion of whether or not the proposed WG would
> be much more of a "5050bis with minimal change" or would attempt to
> more broadly revisit the BP as an instance of the DTN architecture
> described in RFC 4838.
> 
> discussion landed there, (so far anyway) and it seems clear that the
> BoF proponents are more in favour of the former, i.e. minimal changes
> to 5050.
> 
> charter text IMO, as it significantly impacts on the scope of the
> proposed WG.
> 
> S.
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 04 Jun 2014 11:37:55 -0400

One clear, objective criteria that I think we should agree on is that 
5050bis does not need to be backward compatible with 5050.

Simon

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 4 Jun 2014 16:29:01 +0000

I wouldn't even call it 5050bis as the changes would probably have to be
significant.  

* Need for reliability check at least in the header.
* Need for hop count to eliminate routing loops.
* Really no need for time.  Nobody is using it or knows how to set it.

My question is "Who is deploying RFC5050 in any significant way to justify
a working group?" I think we have to be able to answer this question if we
really expect to proceed. Boeing hasn't indicated any scaled deployment. I
think DOD may have dropped it.  I've only seen very simple deployments of
a few nodes.  Epoxy and N4C may be the largest with 10 to perhaps 20?  I
think early work with DieselNet and others may have been much larger
deployments of store, carry and forward technologies. NASA/DARPA SPHERES
uses DTN Tunneling and is really a one-hop DTN network.  It works because
SHPERES uses a publish/subscribe architecture so the application doesn't
really care/know if messages are missed or can re-request during
acquisition of signal.

Here are the latest in NASA's plans that I know of.
http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSIG.pd
f
http://www.docstoc.com/docs/158373645/CU-Boulder-ISS-Updatepptx

Note, these are very simple deployments with only a few nodes and probably
can be accommodated with the current protocol

Will
******************************
William D. Ivancic
Phone 216-433-3494
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

On 6/4/14 11:37 AM, "Simon Perreault" <[email-masked]> wrote:

>>options.  I definitely would not be in favor of starting from a blank
>>might be considered substantial.  If those changes were made, would the
>>result be considered "5050 with minimal change"?  The term "minimal" is
>>slippery here and, I think, generally not helpful.
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 4 Jun 2014 17:33:05 +0000

Hi Will,

> Boeing hasn't indicated any scaled deployment

I don't believe that an indication of scaled deployment is a
necessary precondition for holding a BoF.

Thanks - Fred

---

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

Hi Fred,

Maybe so, Maybe not. But, many planned deployments and scaled deployments
are likely to be necessary to establish a working group.  If the best we
can come up with is NASA putting DTN on a three node DTN backbone on ISS
and a small deployment in a cave in Slovenia, the I think the people in
the IESG might not consider this worthy of their time.

I'M asking the questions now, because someone is going to ask them later
and we better be able to answer if we want to really establish a DTN
working group in the IETF and develop a meaningful, widely deployable
protocol that can scale.

Consider this:  Why haven't these topics been adequately addressed in
DTNRG?  If there is still needed work here and it hasn't been done, why
would we consider a better result from an IETF working group?  We have to
anticipate this question and if we cannot adequately answer it, the chance
of establishing an IETF working group on DTN is probably not very good.

- Contact discovery
  - Routing protocols

Will

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 4 Jun 2014 19:32:10 +0000

Hi Will,

To me, "at scale" implies dynamic routing protocols, distributed
naming services, etc. But, consider that the Internet itself began
with static configurations (remember SRI-NIC?) and scalable dynamic
services did not come online until much later. That did not stop
the Internet from growing up out of nothingness, nor did it stop
the IETF from forming.

About the other items on your list, I already have many of those
on my revised draft wg charter that I will be publishing very soon
(should be later today). So, please bear with me while I get that
done.

Thanks - Fred

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Wed, 4 Jun 2014 20:55:47 +0000

Will, FWIW, the word we're hearing from our NASA sponsors is that DTN will be baselined for everything that the Advanced Exploration Systems program fields.  I think this may be a case of not everybody necessarily advertising everything they've got in the pipeline.

As an aside, I have to point out that your observation that "Nobody is using [time] or knows how to set it" is simply, categorically wrong.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Wednesday, June 04, 2014 9:29 AM
To: Simon Perreault; [email-masked]
Subject: Re: [dtn] Proposed Working Group Charter Suggestions

I wouldn't even call it 5050bis as the changes would probably have to be significant.  

My question is "Who is deploying RFC5050 in any significant way to justify a working group?" I think we have to be able to answer this question if we really expect to proceed. Boeing hasn't indicated any scaled deployment. I think DOD may have dropped it.  I've only seen very simple deployments of a few nodes.  Epoxy and N4C may be the largest with 10 to perhaps 20?  I think early work with DieselNet and others may have been much larger deployments of store, carry and forward technologies. NASA/DARPA SPHERES uses DTN Tunneling and is really a one-hop DTN network.  It works because SHPERES uses a publish/subscribe architecture so the application doesn't really care/know if messages are missed or can re-request during acquisition of signal.

Note, these are very simple deployments with only a few nodes and probably can be accommodated with the current protocol

Will

---

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

Scott,

I heard the same regarding AES
http://www.nasa.gov/directorates/heo/aes/#.U4-NpSS8LhU

But that is not many systems.  Really, whatever is done on ISS and maybe
an Asteroid Retrieval via Orion (single space craft) around a lunar orbit.
 And not until 2020 or later  will maybe a few node network at best.

IMHO, you'll need more than that to justify a IETF working group.  There
is already a CCSDS working group for space that is doing DTN. If we are
only considering small space deployments, perhaps CCSDS is the place to
handle this.  

Regarding time:  I had a group in yesterday demonstrating a simple 3 node
DTN network using the Soldier Radio Waveform.  The first thing required
was to manually synchronize the LAN portions of the radio.  IMHO, the Time
sync requirement (even loose time sync) makes DTN RFC5050 extremely
fragile.  Yes, time is used to expire bundles, but that could be done via
priorities.  Response to my question a few years ago about what do people
set bundle lifetimes to indicated that generally it is the lifetime of the
demonstration or something equivalent like 24 hours if your mining.  The
DINET deployment is a prime example.

http://www.dtnrg.org/wiki/DtnBone

Also, if you check the mail list archives, I believe nobody is using
bundle lifetimes to make bundle forwarding decisions. Since so many
deployments have been a sting of pearls with single source and all bundles
set to the same lifetime, it wouldn't have mattered.  In this instance,
you will end up with a first-in, first-out queue regardless.

Will

On 6/4/14 4:55 PM, "Burleigh, Scott C (312G)"
<[email-masked]> wrote:

>Will, FWIW, the word we're hearing from our NASA sponsors is that DTN
>will be baselined for everything that the Advanced Exploration Systems
>program fields.  I think this may be a case of not everybody necessarily
>advertising everything they've got in the pipeline.
>
>As an aside, I have to point out that your observation that "Nobody is
>using [time] or knows how to set it" is simply, categorically wrong.
>
>Scott
>
>My question is "Who is deploying RFC5050 in any significant way to
>justify a working group?" I think we have to be able to answer this
>question if we really expect to proceed. Boeing hasn't indicated any
>scaled deployment. I think DOD may have dropped it.  I've only seen very
>simple deployments of a few nodes.  Epoxy and N4C may be the largest with
>10 to perhaps 20?  I think early work with DieselNet and others may have
>been much larger deployments of store, carry and forward technologies.
>NASA/DARPA SPHERES uses DTN Tunneling and is really a one-hop DTN
>network.  It works because SHPERES uses a publish/subscribe architecture
>so the application doesn't really care/know if messages are missed or can
>re-request during acquisition of signal.
>
>Note, these are very simple deployments with only a few nodes and
>probably can be accommodated with the current protocol
>
>Will

---

From: ccaini <[email-masked]>
Date: Wed, 04 Jun 2014 20:28:07 +0200

Dear Stephen and Scott,
     In my opinion to start from scratch would be a wrong choice, as the
present code seems mature enough for writing applications (not just demos),
although of course many improvements can and should be added.
We must go on, and in my opinion we must go on with an evolutionary path,
being the alternative a disruptive path (legitimate as well, of course). 
I am  not in a position, as I am not an English mother tongue speaker, as
both of you, to suggest anything.  However, "5050 with minimal changes"
sounds to me as the proponents are a bit lazy, while "5050 evolution"
sounds more suitable. "5050 evo" even better. You can then "decline" the
term evolution as you prefer; from almost anything, i.e. the "minimal
changes", to something more substantial, as intended by Scott. In both
cases it is clear that "evolution" is something different from the
disruptive alternative. 
Yours,
   Carlo

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Jun 2014 23:27:25 +0100

> necessary precondition for holding a BoF.

Fred is correct here. What Will is asking about isn't even
needed for a proposed standard. But the more real interest
there is for a BoF topic, the better, clearly.

And in response to Carlo and Scott - "minimal" is *not* a
bad thing - the idea that an IETF WG will make minimal
changes to an experimental track RFC to produce a proposed
standard is quite positive actually. From one reasonable
perspective, the kind of more extensive change I'd personally
like is more risky. (Not that I'm wrong though:-)

S.

---

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

Thanks, Stephen, and in that context I am perfectly comfortable with calling this work plan approach "minimal".  I just don't want us to be trapped into thinking we can't consider a given modification because it would exceed some sort of minimal-ness limit.

Also, just to clarify, I've got no objection at all to taking a clean-sheet-of-paper look at the whole DTN problem statement; I think that could be interesting and productive.  I just think the DTNRG is a better venue for that than the proposed Working Group would be, and I'm happy for us to agree to disagree on that point.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Wednesday, June 04, 2014 3:27 PM
To: Templin, Fred L; Ivancic, William D. (GRC-RHN0); Simon Perreault; [email-masked]
Subject: Re: [dtn] Proposed Working Group Charter Suggestions

On 04/06/14 18:33, Templin, Fred L wrote:
> I don't believe that an indication of scaled deployment is a necessary 
> precondition for holding a BoF.

Fred is correct here. What Will is asking about isn't even needed for a proposed standard. But the more real interest there is for a BoF topic, the better, clearly.

And in response to Carlo and Scott - "minimal" is *not* a bad thing - the idea that an IETF WG will make minimal changes to an experimental track RFC to produce a proposed standard is quite positive actually. From one reasonable perspective, the kind of more extensive change I'd personally like is more risky. (Not that I'm wrong though:-)

S.

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Wed, 4 Jun 2014 23:28:53 +0000

You're right, Will, AES alone certainly doesn't constitute a user community that's large enough to justify forming an IETF working group.  But I think it is large enough to demonstrate that informed interest in operational use of technology based on the DTNRG protocols exists, suggesting that the interest we're hearing about from Boeing deserves to be taken seriously.  Sometimes most of the growth in the user base comes only after the standards have been nailed down.

And you are quite wrong about nobody using bundle lifetimes to make bundle forwarding decisions: bundle expiration time is a critical parameter in contact graph routing.  Of course, CGR is not used in most DTN research studies, because CGR currently can't be driven by opportunistic contacts.  That will be changing over the next few months.

Scott

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]] 
Sent: Wednesday, June 04, 2014 2:46 PM
To: Burleigh, Scott C (312G); Simon Perreault; [email-masked]
Subject: Re: [dtn] Proposed Working Group Charter Suggestions

Scott,

But that is not many systems.  Really, whatever is done on ISS and maybe an Asteroid Retrieval via Orion (single space craft) around a lunar orbit.
 And not until 2020 or later  will maybe a few node network at best.

IMHO, you'll need more than that to justify a IETF working group.  There is already a CCSDS working group for space that is doing DTN. If we are only considering small space deployments, perhaps CCSDS is the place to handle this.  

Regarding time:  I had a group in yesterday demonstrating a simple 3 node DTN network using the Soldier Radio Waveform.  The first thing required was to manually synchronize the LAN portions of the radio.  IMHO, the Time sync requirement (even loose time sync) makes DTN RFC5050 extremely fragile.  Yes, time is used to expire bundles, but that could be done via priorities.  Response to my question a few years ago about what do people set bundle lifetimes to indicated that generally it is the lifetime of the demonstration or something equivalent like 24 hours if your mining.  The DINET deployment is a prime example.

Also, if you check the mail list archives, I believe nobody is using bundle lifetimes to make bundle forwarding decisions. Since so many deployments have been a sting of pearls with single source and all bundles set to the same lifetime, it wouldn't have mattered.  In this instance, you will end up with a first-in, first-out queue regardless.

Will

On 6/4/14 4:55 PM, "Burleigh, Scott C (312G)"
<[email-masked]> wrote:

>program fields.  I think this may be a case of not everybody 
>necessarily advertising everything they've got in the pipeline.
>
>scaled deployment. I think DOD may have dropped it.  I've only seen 
>very simple deployments of a few nodes.  Epoxy and N4C may be the 
>largest with
>10 to perhaps 20?  I think early work with DieselNet and others may 
>have been much larger deployments of store, carry and forward technologies.
>network.  It works because SHPERES uses a publish/subscribe 
>architecture so the application doesn't really care/know if messages 
>are missed or can re-request during acquisition of signal.
>
>http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSI
>G.p
>d
>f

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 05 Jun 2014 00:32:56 -0400

On 6/4/2014 7:28 PM, Burleigh, Scott C (312G) wrote:
> And you are quite wrong about nobody using bundle lifetimes to make
> bundle forwarding decisions: bundle expiration time is a critical
> parameter in contact graph routing.

I think the point is not that routing algorithms can't use it
appropriately, but rather than sending applications so far
haven't generally been able to set it with any meaningful
granularity so that it would then cause the routing system to
be able to do intelligent things.

I.e. if all bundles coming through have the same very long
lifetime, it will not impact the routing decisions, even if
there happens to be logic that incorporates the lifetime.

This doesn't exclude the possibility that there's a system
somewhere in which the applications can really make use of a
whole spectrum of lifetime values, but it doesn't look like
the general case so far.

-- 
Wes Eddy
MTI Systems

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Thu, 5 Jun 2014 15:53:45 +0000

Wes, thanks!  You have brought up an issue that I think has never received enough research attention.

The purpose of the lifetime field in bundles is, essentially, congestion control: a way is needed to flush data out of the network that most likely will never get delivered, so as to resources needed for other traffic.  In the Internet we can do this with a hop count, because the packets are always in motion and signal propagation delays are small; any hop count limit will map to a packet lifetime limit with a small, fairly predictable upper bound.  In a DTN-based network this is no good: a bundle could make one hop to a router node that (unknown to it) will never have a path forward to the destination.  Without an explicit lifetime limit the bundle could occupy storage on that node forever, waiting for a forwarding opportunity that will never come.

But you're right, there aren't a lot of guidelines for selecting that lifetime limit.  Somebody should come up with some.

Considering this just in terms of ION (the DTN software that I've got most experience with), I think one approach might be to pick some lifetime value at random, do a simulation of CGR-based traffic, and see what percentage of bundles are abandoned at the source because CGR discovers that they can't possibly be delivered prior to bundle expiration time.  Then increase or decrease that standard lifetime and repeat until that percentage is low enough to be tolerable.

Another approach might be to look at some sample contact plans, compute the expected delivery times for bundles sent from every node to every other node at some given moment, and look for a relationship between the maximum expected delivery times and some characteristics of the corresponding contact plans.

Again, for now this could only be done for flight mission scenarios because the contact plans used by CGR include only scheduled, relatively certain contacts.  Over the next few months we hope to be adding opportunistic and probabilistic contacts to those contact plans, which should open CGR up for use in terrestrial DTN scenarios.

Scott

-----Original Message-----
From: Wesley Eddy [mailto:[email-masked]] 
Sent: Wednesday, June 04, 2014 9:33 PM
To: Burleigh, Scott C (312G); Ivancic, William D. (GRC-RHN0); [email-masked]
Subject: Re: [dtn] Proposed Working Group Charter Suggestions

> parameter in contact graph routing.

I think the point is not that routing algorithms can't use it appropriately, but rather than sending applications so far haven't generally been able to set it with any meaningful granularity so that it would then cause the routing system to be able to do intelligent things.

I.e. if all bundles coming through have the same very long lifetime, it will not impact the routing decisions, even if there happens to be logic that incorporates the lifetime.

This doesn't exclude the possibility that there's a system somewhere in which the applications can really make use of a whole spectrum of lifetime values, but it doesn't look like the general case so far.

--
Wes Eddy
MTI Systems

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 5 Jun 2014 16:11:59 +0000

Hmmm.  It appears that maybe there should be a document on what lifetime
is used for.  I never thought of it as congestion control.  I always
thought of it a how long the information in the bundle is useful for -
analogous to expiration dates on the food in your refrigerator. For
example:

Help, I'M drownding!  = 1 minute (assuming I have decent lung capacity)
Happy Birthday (and your birthday is tomorrow) = 24 hours
Happy New Year 2015 = whatever the math is that works out to that number
of days.

I think BBN sort of did this the best they could with two code points.

Which is why I always thought one would want to consider how much longer a
bundle is valid for when making forwarding decisions.

I always consider hop count a mechanism to kill traffic stuck in a routing
loop and the reason I proposed hop count in the base header of bundling or
whatever Store, Carry and Forward mechanism one implements.

Will

On 6/5/14 11:53 AM, "Burleigh, Scott C (312G)"
<[email-masked]> wrote:

>The purpose of the lifetime field in bundles is, essentially, congestion
>control: a way is needed to flush data out of the network that most
>likely will never get delivered, so as to resources needed for other
>traffic.  In the Internet we can do this with a hop count, because the
>packets are always in motion and signal propagation delays are small; any
>hop count limit will map to a packet lifetime limit with a small, fairly
>predictable upper bound.  In a DTN-based network this is no good: a
>bundle could make one hop to a router node that (unknown to it) will
>never have a path forward to the destination.  Without an explicit
>lifetime limit the bundle could occupy storage on that node forever,
>waiting for a forwarding opportunity that will never come.
>
>But you're right, there aren't a lot of guidelines for selecting that
>lifetime limit.  Somebody should come up with some......
>

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Thu, 5 Jun 2014 16:29:50 +0000

Will, sure, hop counts are a great way to break routing loops, but (a) it has been suggested that routing loops are not always a bad thing in DTN (I haven't yet heard the fully-worked out argument for this, so I can't engage on this point), and (b) I think routing loops are the least of your problems in a DTN -- there are plenty of simpler ways to screw up performance in these weird environments.

The original argument for the bundle lifetime is lost in the mists of time (though I think it shows up in some of the emails I've got archived from fifteen years ago); I think it eventually just became taken for granted.  It's still sort of implicit in the design, though.  Really, why would you bother to delete a bundle whose lifetime had expired?  Certainly you don't want to waste any more bandwidth on forwarding it, but you could omit it from forwarding without deleting it.  The only reason to go to that trouble is that you want the storage back.

Scott

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]] 
Sent: Thursday, June 05, 2014 9:12 AM
To: Burleigh, Scott C (312G); [email-masked]
Subject: Re: [dtn] Proposed Working Group Charter Suggestions

Hmmm.  It appears that maybe there should be a document on what lifetime is used for.  I never thought of it as congestion control.  I always thought of it a how long the information in the bundle is useful for - analogous to expiration dates on the food in your refrigerator. For
example:

Help, I'M drownding!  = 1 minute (assuming I have decent lung capacity) Happy Birthday (and your birthday is tomorrow) = 24 hours Happy New Year 2015 = whatever the math is that works out to that number of days.

Which is why I always thought one would want to consider how much longer a bundle is valid for when making forwarding decisions.

I always consider hop count a mechanism to kill traffic stuck in a routing loop and the reason I proposed hop count in the base header of bundling or whatever Store, Carry and Forward mechanism one implements.

Will

On 6/5/14 11:53 AM, "Burleigh, Scott C (312G)"
<[email-masked]> wrote:

>packets are always in motion and signal propagation delays are small; 
>any hop count limit will map to a packet lifetime limit with a small, 
>fairly predictable upper bound.  In a DTN-based network this is no 
>good: a bundle could make one hop to a router node that (unknown to it) 
>will never have a path forward to the destination.  Without an explicit

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 05 Jun 2014 18:05:24 +0100

Hi.

I don't think that it's true that there hasn't been much research into
this.  Just about every opportunistic routing scheme proposal (and there
are lots) assumes that the ultimate backstop for storage occupancy is
bundle expiry and quite a few of them link some of their parameters to
bundle lifetime.  This is indeed all about avoiding congestion (or
perhaps more accurately storage overload).

The difficulty is, as Scott says, that deciding what is a good value for
lifetime is mobility model dependent and is not trivial to do.  It is
(or should be) tied to the expected delay distribution in a network and
(in an opportunistic network) what proportion of bundles you are
prepared to see undelivered (i.e., where you put the limit on the delay
distribution).  There is some useful discussion and mathematical
analysis in
Spyropoulos, T., Psounis, K., and
Raghavendra, C. S. Spray and wait: an efficient
routing scheme for intermittently connected mobile
networks. In Proceedings of the 2005 SIGCOMM
Workshops (2005), p. 8.
for a simple case, but the general case is non-trivial.  It is possible
to estimate what is a good value from encounter histories but we haven't
done enough practical trials (as opposed to simulations) to see how
useful these values might be.

Karvo, J., and Ott, J. Time scales and
delay-tolerant routing protocols. Proceedings of the
third ACM workshop on Challenged networks
CHANTS 08 (2008), 33–40.
discusses how timescales affect routing protocol parameters - this is
another aspect of the same problem but doesn't explicitly consider
bundle lifetimes.

In the space case with contact graph routing I would have thought that
the contact graph tells you what the expected delivery deadline will be
which should enable you to set a lifetime using some safety factor on
top of the deadline.  But I'm not an expert on CGR.

Regards,
Elwyn

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Thu, 5 Jun 2014 17:15:03 +0000

Elwyn, there has indeed been some work on computing expected delivery time from a contact plan (http://www.spice-center.org/files/publications/TR-Delivery_Time_Estimation_for_Space_Bundles.pdf), so what you propose might be a very good solution.  The computation is somewhat time-consuming, though, so having a handy constant that results in statistically good performance could still be worthwhile.

Scott

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Thursday, June 05, 2014 10:05 AM
To: Burleigh, Scott C (312G)
Cc: [email-masked]
Subject: Re: [dtn] Proposed Working Group Charter Suggestions

Hi.

I don't think that it's true that there hasn't been much research into this.  Just about every opportunistic routing scheme proposal (and there are lots) assumes that the ultimate backstop for storage occupancy is bundle expiry and quite a few of them link some of their parameters to bundle lifetime.  This is indeed all about avoiding congestion (or perhaps more accurately storage overload).

The difficulty is, as Scott says, that deciding what is a good value for lifetime is mobility model dependent and is not trivial to do.  It is (or should be) tied to the expected delay distribution in a network and (in an opportunistic network) what proportion of bundles you are prepared to see undelivered (i.e., where you put the limit on the delay distribution).  There is some useful discussion and mathematical analysis in Spyropoulos, T., Psounis, K., and Raghavendra, C. S. Spray and wait: an efficient routing scheme for intermittently connected mobile networks. In Proceedings of the 2005 SIGCOMM Workshops (2005), p. 8.
for a simple case, but the general case is non-trivial.  It is possible to estimate what is a good value from encounter histories but we haven't done enough practical trials (as opposed to simulations) to see how useful these values might be.

Karvo, J., and Ott, J. Time scales and
delay-tolerant routing protocols. Proceedings of the third ACM workshop on Challenged networks CHANTS 08 (2008), 33-40.
discusses how timescales affect routing protocol parameters - this is another aspect of the same problem but doesn't explicitly consider bundle lifetimes.

In the space case with contact graph routing I would have thought that the contact graph tells you what the expected delivery deadline will be which should enable you to set a lifetime using some safety factor on top of the deadline.  But I'm not an expert on CGR.

Regards,
Elwyn

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 5 Jun 2014 17:33:56 +0000

In Line

>Will, sure, hop counts are a great way to break routing loops, but (a) it
>has been suggested that routing loops are not always a bad thing in DTN
>(I haven't yet heard the fully-worked out argument for this, so I can't
>engage on this point),

I've heard that, but it was more of an intentional route back once because
you may now have a better path or as a temporary storage environment.

> and (b) I think routing loops are the least of your problems in a DTN

Not really.  It is the unintentional misconfiguration that I worry about.
CGR is certainly a candidate if the entire system doesn't get updated
correctly.  But, just plain static routes is the easiest place to
demonstrate this.  Create a DTN static route between two systems where the
both think the next hop route is the other system.  A wants to forward
bundles for C to B and B wants to forward bundles for C to A.  Now create
a bundle destined to C with a lifetime of 300 years and leave a note for
three generations from now to see if it is still bouncing between systems.
 This is really bad for wireless systems.  You may lock yourself out.
And, depending on how the code is implemented, this may happen for a
bundle with a 30 second lifetime depending on when and where the
implementation checks for expired bundles.

Believe me.  I've seen similar with static security tunnels and such.
Fortunately IP hop count will kill the packet.

I've been very careful and triple checked systems and then still screwed
up.  Hop count is a relief valve for when something unintentionally  gets
misconfigured.

>-- there are plenty of simpler ways to screw up performance in these
>weird environments.

I'm sure you are correct.  Some things are difficult to anticipate and
foresee.  Others are obvious.  The ability for a bundle stuck in a route
loop  to self-terminate should be one.

Will

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Thu, 5 Jun 2014 17:42:43 +0000

Okay, fair enough; in a properly configured network it shouldn't be needed, but providing a defense against network misconfiguration is a good idea.  I'm fine with adding a hop count block.

Scott

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]] 
Sent: Thursday, June 05, 2014 10:34 AM
To: Burleigh, Scott C (312G); [email-masked]
Subject: Re: [dtn] Proposed Working Group Charter Suggestions

In Line

>Will, sure, hop counts are a great way to break routing loops, but (a) 
>it has been suggested that routing loops are not always a bad thing in 
>DTN (I haven't yet heard the fully-worked out argument for this, so I 
>can't engage on this point),

I've heard that, but it was more of an intentional route back once because you may now have a better path or as a temporary storage environment.

Not really.  It is the unintentional misconfiguration that I worry about.
CGR is certainly a candidate if the entire system doesn't get updated correctly.  But, just plain static routes is the easiest place to demonstrate this.  Create a DTN static route between two systems where the both think the next hop route is the other system.  A wants to forward bundles for C to B and B wants to forward bundles for C to A.  Now create a bundle destined to C with a lifetime of 300 years and leave a note for three generations from now to see if it is still bouncing between systems.
 This is really bad for wireless systems.  You may lock yourself out.
And, depending on how the code is implemented, this may happen for a bundle with a 30 second lifetime depending on when and where the implementation checks for expired bundles.

I've been very careful and triple checked systems and then still screwed up.  Hop count is a relief valve for when something unintentionally  gets misconfigured.

>-- there are plenty of simpler ways to screw up performance in these 

I'm sure you are correct.  Some things are difficult to anticipate and foresee.  Others are obvious.  The ability for a bundle stuck in a route loop  to self-terminate should be one.

Will