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

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 25 Apr 2014 15:33:09 +0000

Dear DTNRG,

Boeing has been actively tracking the DTNRG activities, and we believe
that the time is now at hand to develop some of the more mature technologies
in an IETF standards-track working group. Active, innovative research in DTN
continues to be vital, but for Boeing's business purposes it is becoming
important to lock the DTN protocols down in Internet standards.
 
To that end, Boeing is proposing to request a DTN BoF at the next IETF.
Please see below for a draft BoF agenda and a proposed working group charter.
Comments?  Suggestions?
 
Fred Templin
[email-masked]

---

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

2) RFC5050(bis) - 30min

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

4) Bundle-in-Bundle Encapsulation - 30 min

5) DTN Security Key Management - 30min

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

      Delay/Disruption Tolerant Networking Working Group (DTNWG)

Chair(s):

      TBD

Area and Area Director(s):

      Transport Area: ADs Spencer Dawkins <[email-masked]>,
                          Martin Stiemerling <[email-masked]>

Responsible Area Director:

      TBD

Mailing list:

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

Description of Working Group:

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

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

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

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

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

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

      Work items related to Delay/Disruption Tolerant Networking include:

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

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

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Apr 2014 18:03:09 +0100

Hi Fred,

Thanks for proposing this.

My initial comments on the proposal are:

- I'd be delighted to see this happen if there are enough
  folks interested, willing, etc. I'm not sure there are
  enough folks interested enough though.
- I think a 5050bis really has to put a far higher priority
  on being deployable based on tooling that many Internet
  developers commonly use, but at the same time a 5050bis
  protocol should be easy to gateway to a 5050 DTN in order
  to not damage all the work the space folks have done
  based on 5050
- I'd say maybe merge agenda items (2) and (3), and the
  5050bis and "SBSP" work - it  was IMO a mistake to do the
  BSP separate from and later than the BP, which was part
  of what lead to the BSP being such a complex monster
- I'm not sure that postponing all work on CLs makes
  sense, how would we get interop for a 5050bis without
  some CL? So I'd say at least one CL would have to be
  part of the initial charter. (I don't really care much
  if that's a "new" CL or not.)

But I'll definitely turn up if this BoF happens, and will
be very interested to see who else is interested.

Cheers,
S.

On 04/25/2014 04:33 PM, Templin, Fred L wrote:
>       associations cannot be coordinated w

To that end, Boeing is proposing to request a DTN BoF at the next IETF.
Please see below for a draft BoF agenda and a proposed working group
charter.
Comments?  Suggestions?

hen communicating endpoints cannot
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
> 
>

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 25 Apr 2014 13:29:52 -0400

> be very interested to see who else is interested.

- good to go into IETF. agreed.
- I'm interested in contributing.
- I would add a milestone item to the charter: Registry for service identifiers  
 (I wrote a draft on this sometime ago).

Marc.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 25 Apr 2014 17:55:05 +0000

Hi Stephen,

Thanks for the initial input, which we should be able to
accommodate. For myself, I am willing to work in whatever
capacity would best serve the activity, e.g., work on
drafts, assist in working group administration, etc.

Thanks - Fred

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, April 25, 2014 10:03 AM
> To: Templin, Fred L; [email-masked]
> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90
> 
> 
> Hi Fred,
>

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 25 Apr 2014 19:52:50 +0000

Hi Folks,

I'm interested in contributing to this work even though I'm not planning to
go to upcoming IETF. BTW, Routing protocols in DTN environment could be
interesting as well.
Here is the link to my recent work related to this :

http://www.sciencedirect.com/science/article/pii/S0140366414001212

All the best

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

On Fri, Apr 25, 2014 at 6:29 PM, Marc Blanchet <[email-masked]>wrote:

>      Archive:
> http://www.ietf.org/mail-archive/web/dtn-interest/current/maillist.html
>

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 25 Apr 2014 20:08:51 +0000

I doubt NASA will send me to the Toronto meeting.  I expect I will have to participate remotely.

One more item is Naming and Addressing.  IMHO, we still haven't gotten that quit right.  I'm not sure how you aggregate routes on a flat address space which makes scalability problematic.

Will

From: Nabil Benamar <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 25, 2014 3:52 PM
To: Marc Blanchet <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Hi Folks,

I'm interested in contributing to this work even though I'm not planning to go to upcoming IETF. BTW, Routing protocols in DTN environment could be interesting as well.
Here is the link to my recent work related to this :

All the best

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

On Fri, Apr 25, 2014 at 6:29 PM, Marc Blanchet <[email-masked]<mailto:[email-masked]>> wrote:

Le 2014-04-25 à 13:03, Stephen Farrell <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Fred,

Marc.

Cheers,
S.

Fred Templin
[email-masked]<mailto:[email-masked]>

---

2) RFC5050(bis) - 30min

Chair(s):

     TBD

     Transport Area: ADs Spencer Dawkins <[email-masked]<mailto:[email-masked]>>,
                         Martin Stiemerling <[email-masked]<mailto:[email-masked]>>

     TBD

Mailing list:

     General Discussion: [email-masked]<mailto:[email-masked]> (note: until wg formed)
     To Subscribe: https://www.ietf.org/mailman/listinfo/dtn-interest
     Archive: http://www.ietf.org/mail-archive/web/dtn-interest/current/maillist.html

Goals and Milestones:

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

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

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

---

From: Peter Lovell <[email-masked]>
Date: Fri, 25 Apr 2014 20:02:48 -0400

Amen to that !

> On Apr 25, 2014, at 1:03 PM, Stephen Farrell <[email-masked]> wrote:
> 
> was part

---

From: Daniel Ellard <[email-masked]>
Date: Fri, 25 Apr 2014 21:38:10 -0400

> Please see below for a draft BoF agenda and a proposed working group charter.

I wish you success, but unfortunately I will not be able to
participate very much.  I don't speak for others inside Raytheon BBN
Technologies who may be interested in participating and have
time/funding to do so.

That's not to say that I won't try to participate in the mailing
list when I think I have something to add.  This might be one of
those times.

I think there is a lot of DTN spec work that unfinished -- and in
some cases, unstarted, with requirements that haven't been
completely articulated.  I'm glad to see that efforts to standardize
the CLAs are making headway, but there's more work to do.  The
effort to standardize the routing protocols and how they communicate
with the BPAs doesn't seem to have made much progress, and we can't
have truly interoperable implementations of the whole stack until
this has been nailed down.  I think it is absolutely essential that
CLAs, bundle routing protocols, and the router-to-BPA protocols be
part of the charter of this working group.

Given the amount of work that needs to be done, my guess is that
your schedule is wildly optimistic, even if your intent is limited
to to cleaning up the current documents and turning them into RFCs,
rather than trying to address any of the open issues.  If you change
your units from months to IETF meetings, it's more plausible -- but
probably still optimistic.

-Dan

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

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sat, 26 Apr 2014 01:00:31 -0400

Fred,

  I think this is a Good Idea and would be happy to support both the BoF and a working group if one is created from this effort.

  I recommend that management be added to the charter. My experience being that operational deployments require both a mechanism to secure data and a mechanism for state monitoring and (where appropriate) command/control. 

-Ed

________________________________________
From: dtn-interest [[email-masked]] On Behalf Of Templin, Fred L [[email-masked]]
Sent: Friday, April 25, 2014 11:33 AM
To: [email-masked]
Subject: [dtn-interest] DTN BoF Proposal for IETF90

Dear DTNRG,

Fred Templin

---

2) RFC5050(bis) - 30min

Chair(s):

      TBD

      TBD

Mailing list:

Goals and Milestones:

---

From: <[email-masked]>
Date: Sat, 26 Apr 2014 07:07:57 +0100

Is this belief primarily technically motivated, politically motivated, or business motivated?

The drafts:
http://tools.ietf.org/html/draft-templin-dtnhiaps-00
http://tools.ietf.org/html/draft-templin-dtntsync-00
http://tools.ietf.org/html/draft-templin-dtnskmps-00

(those should probably have -templin-dtnrg- in the filename)

acknowledge recognised technical problems with the bundle protocol that work over
five years in this research group has not solved. And pretty obvious basic problems, at that.

Given these well-known problems, isn't an IETF workgroup premature?
Isn't pushing for a standard just because you want a standard the wrong reason
to push for a standard?

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn-interest [[email-masked]] On Behalf Of Templin, Fred L [[email-masked]]
Sent: 25 April 2014 16:33
To: [email-masked]
Subject: [dtn-interest] DTN BoF Proposal for IETF90

Dear DTNRG,

Fred Templin

---

2) RFC5050(bis) - 30min

Chair(s):

      TBD

      TBD

Mailing list:

Goals and Milestones:

---

From: Joerg Ott <[email-masked]>
Date: Sun, 27 Apr 2014 11:03:32 +0300

Hi Fred,

I am also supportive and share some of Stephen's concern
(particularly security).

While I see Stephen's point on the tooling, I don't agree with
this since tool fashion changes (including the praise for text-based
encoding in the IETF at some layers).  We have built commercial
products for terrestrial use based upon RFC 5050 and, really,
the tool part isn't the problem.  The security part is where
we want to be more sensible towards protocol re-use.

With this in mind, I also agree with Stephen that it would be bad
to put off CLs to a later point.  One of the major weaknesses in
the  BP framework is that we still don't have the established and
documented (other than in code) way to do neighbor discovery.
And finding your peers can be seen as part of a convergence
layer problem, at the very least it is related.

Cheers,
Jörg

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Sun, 27 Apr 2014 12:15:57 +0000

I think Jörg makes an excellent point.  I believe the "streamlined" BSP spec that Ed Birrane has been working on will address security pretty well, but I agree that contact discovery (which I think of as being the essence of neighbor discovery) has proven to be too important to defer.  I think we want to be careful not to dictate exactly what happens when a contact (and therefore a neighbor) are discovered, because that veers into implementation, but the protocol for effecting the discovery needs to be standardized.

Scott
________________________________________
From: dtn-interest [[email-masked]] on behalf of Joerg Ott [[email-masked]]
Sent: Sunday, April 27, 2014 1:03 AM
To: Stephen Farrell; Templin, Fred L; [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Hi Fred,

Cheers,
Jörg

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Apr 2014 14:00:53 +0100

Hiya,

> we want to be more sensible towards protocol re-use.

Fair point. OTOH, I think its a real fail that one can't
e.g. just install an Apache web server module to DTN enable
your web proxy or something similar. Having to build an
entirely new overlay for 5050 that doesn't re-use anything
already deployed makes it much less likely to be used IMO.
Actually, that's not just opinion, its based on our
experience trying to deploy stuff we've piloted that worked
but always seems to be too much trouble for non-subsidised
deployments.

That is not something that will change just because the
RFC is in the IETF stream. But I think we should be able to
fix that with a 5050bis while also keeping the ability to
gateway to 5050 DTNs.

To be clear, I don't want that we aim to DTN-enable the web, I
want us to consider terrestrial deployability and making that
as easy as possible as first class requirements. If the means
to get that were not related to HTTP (though HTTP/2.0 timing
might just still be fortuitous here), but say related to
some OpenWRT build for homenet, then that'd also be just
dandy.

S.

---

From: <[email-masked]>
Date: Sun, 27 Apr 2014 14:40:49 +0100

if you're  enabling a web server for DTN,
why use the bundle protocol?

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

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: dtn-interest [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: 27 April 2014 14:00
To: Joerg Ott; Templin, Fred L; [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Hiya,

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Apr 2014 18:21:46 +0100

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

Yes, starting by looking at approaches like that (though maybe
considering HTTP/2.0 now as well) is IMO well worth considering
if we want an eventual IETF PS RFC for DTN to be (able to be)
widely used. If I recall correctly though there was something
about your http-dtn stuff that I thought just didn't work for
some use-cases, but I've not re-read it today, so I think your
stuff might or might not be a viable starting point when looked
at in detail, But its defo something to look at I'd say if
we're really prioritising terrestrial deployment.

I think you and I Lloyd might agree on the above but disagree
about what to call the result - I'd like that to be done as
a revision of the BP so as to maintain easy gatewaying with
5050 implementations. I suspect you might not be so keen on
that:-) But I think that compatibility point ought also be
up for discussion if an IETF WG is being formed.

All that said, for an IETF WG, it'd matter a lot whether or not
there's a set of interested enough parties and I could imagine
that some people would like taking this kind of approach whereas
others might hate it and want far fewer changes compared to
5050, so I think that means that resolving the high level
direction for a 5050bis is something that should be done before
forming a WG, so a WG doesn't stall on not being able to get
consensus on the high level approach. (And that in turn means
that more folks weighing in on this topic could be very
helpful.)

Cheers,
S.

---

From: <[email-masked]>
Date: Mon, 28 Apr 2014 02:15:18 +0100

> If I recall correctly though there was something
> at in detail

As always, good to get a detailed technical critique from you, Stephen.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: 27 April 2014 18:21
To: Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Cheers,
S.

---

From: Joerg Ott <[email-masked]>
Date: Mon, 28 Apr 2014 10:54:12 +0300

IIRC, I remarked back then, that adding a To: and From: fields (granted,
you call them differently) to HTTP has been done before (aka SIP).
Let's not repeat this exercise (we know where this can lead to :-)
And, no, I am not suggesting you should be using SIP instead, even
though it would be closer.

It's just that adding feature to a system it wasn't designed for is
going to be as easy as it seems at the first glance (adding routing,
etc.)

Jörg

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Apr 2014 11:03:52 +0100

> As always, good to get a detailed technical critique from you, Stephen.

Nope, what I was (perhaps badly) trying to say was
just that even if a proposal isn't yet fully baked, it
could be worth a good look, if we go down the road
of making terrestrial deployment a first class goal.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Apr 2014 11:13:39 +0100

> going to be as easy as it seems at the first glance (adding routing,

That is a danger, yes. But doing minimal changes to 5050 also
has a danger - that the result is never really deployed. So I
think the question for now seems to be whether or not to make
much simpler terrestrial deployment a first class goal for the
putative WG.

I'd like the answer to be "yes," but I do agree that there's
a case that can be made for a minimal-change approach. That
latter is a lot less interesting for me though as I think there
are just very few situations that justify rolling out an entirely
different infrastructure for a DTN.

S.

>> From: dtn-interest [[email-masked]] On Behalf Of
>> Stephen Farrell [[email-masked]]

---

From: Joerg Ott <[email-masked]>
Date: Mon, 28 Apr 2014 13:25:30 +0300

> different infrastructure for a DTN.

I don't disagree with this.  But I don't want to be presumptious
on how the answer should look like either (which also implies not
ruling out options).

That aside, one of the most important application on the terrestrial
side is running without infrastructure -- which makes the deployability
(in the sense of "compatibility") question less important.

Jörg

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 28 Apr 2014 12:14:51 +0000

Regarding deployment without infrastructure.

While doing some research and asking some questions on fractionated
spacecraft, I was forwarded this paper.  Just another data point for what
it is worth - particularly if you are thinking about running DTN over
manet.

Manet is suppose to be for networking without infrastructure, but it
assumes connectivity.  DTN assumes intermittent connectivity.  That is a
very specific deployment scenario.  Google and Facebook are investigating
and investing in making the world much more connected than it is today.

http://www.ir.bbn.com/documents/articles/chants2012.pdf

Also, if we are talking large scale deployments, we really need to address
scalability.  To start with, I know some where investigating use of DTN
for thousands to tens of thousands of units.

Will 

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

On 4/28/14 6:25 AM, "Joerg Ott" <[email-masked]> wrote:

>>....one of the most important application on the terrestrial

---

From: "Kruse, Hans" <[email-masked]>
Date: Mon, 28 Apr 2014 08:15:25 -0400

Fred, I am not sure if I can make it to IETF90 in person, but I am very willing to support a WG effort in whatever capacity makes sense.

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer Science
Chief Operating Officer, GRID Lab
31 S. Court, Room 150, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Apr 2014 13:51:15 +0100

Hiya,

> on how the answer should look like either (which also implies not

Well, isn't that last more appropriate for an RG than a WG? I
mean we presumably don't want a WG that thrashes endlessly on
the amount of change vs. 5050 that's acceptable and I think
that could happen if we can't decide on this while chartering
the putative WG.

I also think it might (not 100% sure) be the case that different
folks would be more or less interested in a WG depending on
the answer to this question, so another danger for chartering a
WG could be that if the answer to this question only emerges
some months down the road, then half the WG participants
might lose interest at that point and the whole thing might
fizzle.

S.

---

From: <[email-masked]>
Date: Mon, 28 Apr 2014 14:01:05 +0100

> Well, isn't that last more appropriate for an RG than a WG?

well, yes.

but that would be an RG with energy, and an RG not committed to one solution.

which is to say, not this RG.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: 28 April 2014 13:51
To: Joerg Ott; Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Hiya,

S.

---

From: Joerg Ott <[email-masked]>
Date: Mon, 28 Apr 2014 16:22:48 +0300

Hi Stephen,

all good and valid points.  But this still doesn't have to
predetermine a solution.  Wouldn't a solution be a function of
the requirements (or use cases or whatever)?  I am fine with
sorting this out during the chartering process (and this is,
as you point out below and as we have discussed in Berlin last
year to some extent, an element a research group could contribute
to).

It appears that all of us have diverse deployment experience in
the real world and we have different perception on why things
may not have worked the way we wanted them to or were not picked
up.  Some of those may reflect reality properly, others may not.
Some may be use case dependent, other may not.  This is probably
something worth collecting as input on what we want to do.

So, I don't think we disagree, I just got the feeling that the
issue is slightly more sophisticated than "make it look like the
web and you'll be done" -- at least because you can build
deployable systems using RFC 5050 and because you can fail
building deployable and usable systems using some web-ish tool
set.

I surely agree with your assessment that people's interest may
depend on which road we want to go down in a potential WG.
I would want this discussion to happen in more depth and, as
you say, we should also have an idea of what exactly people support
when they say that they support a WG.  The charter draft does leave
this question open.

Cheers,
Jörg

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 28 Apr 2014 13:25:03 +0000

Fred,

Since Boeing is requesting the BOF, what is their (or your) perspective on
the deployment scenario?

I know NASA is working to standardize RFC5050 as a space protocol via
CCSDS (http://cwe.ccsds.org/sis/default.aspx#_SIS-DTN).  They don't appear
to be concerned with the numerous known problems.

On the International Space Station, they are interested in using DTN to
automatically buffer data and commands between Loss-of-Signal (LOS) and
Acquisition-of-Signal (AOS).  See-
http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSIG.pd
f

DTN Goals are:

€Increase reliability of payload data transfers between ISS and remote
payload control centers during AOS/LOS transitions
€Increase automation of Payload Developer (PD) requests for data transfers
€Alleviate extensive support to plan payload transfers around AOS/LOS and
operator required transfers

Today, payload operations are highly scheduled and highly manned.  But,
with dramatic increases in uplink and downlink bandwidth to the payloads,
the link utilization doesn't have to be so tightly controlled and
automation to reduce manpower costs is highly desirable.  Note, the ISS
DTN deployment is a very small scale network.

We need to understand what problem space we are addressing.  If it is the
small space community, that can probably be handled by CCSDS.  If it is
large scale terrestrial deployment, we need to understand that
environment. 

Will
******************************

---

From: <[email-masked]>
Date: Mon, 28 Apr 2014 14:21:43 +0100

> I just got the feeling that the
> web and you'll be done" 

http as a transport mechanism is not the web. it's just a simple way to
leverage and copy mimetyped files - as a hop-by-hop transport.

Lloyd Wood

hey, something new to cite instead of 'A Bundle of Problems'!
________________________________________
From: Joerg Ott [[email-masked]]
Sent: 28 April 2014 14:22
To: Stephen Farrell; Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Hi Stephen,

Cheers,
Jörg

---

From: Joerg Ott <[email-masked]>
Date: Mon, 28 Apr 2014 16:42:15 +0300

Precisely.  There are plenty of ways doing this, but just doing file
transfer is, depending on your scenario, not enough.

Jörg

---

From: <[email-masked]>
Date: Mon, 28 Apr 2014 15:57:55 +0100

And what is the bundle, if not an overcomplicated binary file format?

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Joerg Ott [[email-masked]]
Sent: 28 April 2014 14:42
To: Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Jörg

---

From: Joerg Ott <[email-masked]>
Date: Mon, 28 Apr 2014 18:12:55 +0300

I am actually not arguing "bundle protocol or not" because this isn't
the point.  So maybe put your bundle protocol allergy aside for a
moment.

I am just saying that to make asynchronous system work, depending on
your scenario, you will not _just_ need a file transfer protocol of
some sort (and I don't care if it's BP, SMTP, SIP MESSAGE, MRTP, NNTP,
HTTP, or whatever), but you will need other functions (particularly
including applications, (G)UI, etc.) that make sensible use of it.

_Transferring_ the bits is at the end of the day a solved problem
in many ways (as you probably agree).

Jörg

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Apr 2014 15:57:30 +0000

Hi, we have heard lots of opinions ranging from: "yes, there should
be a working group", to: "yes to the working group, but please add
more work items", to: "no there should not be a working group", to
many other points in between. But, let's also consider that if we
aren't able to start a working group of some form and with some
initial charter then clearly nothing will move forward in standards
track and this area of research will continue to languish.

So, why can't we have it that the DTNRG would be an "incubator" for
important new work items that would then feed into the DTNWG as the
standards-producing vehicle? The standardization process would have
to start somewhere and with a realistic schedule in order to make
progress. Regularly-scheduled re-charters then would bring in the
new work items as they are ready to progress.

So, if we can get this started with a bounded set of work items we
can prime the pump for continued progress and hopefully spawn new
business cases in the process. Thoughts?

Thanks - Fred

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 28 Apr 2014 17:40:24 +0000

Will's view here makes sense to me.  The initiative for requesting the BoF -- the first serious commercial interest in delay-tolerant networking that we've seen, I think -- is coming from Boeing.  I think it the energy behind the BoF initiative might evaporate if this conversation diverts that BoF initiative in a direction that diverges dramatically from Boeing's interests.

In particular, the HTTP-DTN concept clearly merits serious consideration as a way of addressing the well-known challenges of delay-tolerant networking, but I don't think this BoF request discussion is the right place to try to conduct that serious consideration.  What I think would make more sense would be for a couple of experimental HTTP-DTN implementations to be developed and exercised in practical deployment scenarios, just as has been done with the DTNRG's BP-based protocol suite over the past decade, so that we can all get a better sense of the architecture's demonstrated advantages and disadvantages.  The DTNRG seems to me to be the right venue for that research.

Meanwhile, though, the experience of NASA, N4C, the U.S. Defense Department, Boeing, and others seems to indicate that the Bundle Protocol and adjunct protocols can be used to operate delay- and disruption-tolerant networks successfully.  This suggests that it could be advantageous to the networking community to standardize protocols derived from the DTNRG stack (certainly adopting some of the improvements to those protocols that have been proposed over the years).  I think that's the proposition that this BoF request conversation should be contemplating.

Scott

-----Original Message-----
From: dtn-interest [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Monday, April 28, 2014 6:25 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Fred,

Since Boeing is requesting the BOF, what is their (or your) perspective on the deployment scenario?

I know NASA is working to standardize RFC5050 as a space protocol via CCSDS (http://cwe.ccsds.org/sis/default.aspx#_SIS-DTN).  They don't appear to be concerned with the numerous known problems.

On the International Space Station, they are interested in using DTN to automatically buffer data and commands between Loss-of-Signal (LOS) and Acquisition-of-Signal (AOS).  See- http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSIG.pd
f

DTN Goals are:

€Increase reliability of payload data transfers between ISS and remote payload control centers during AOS/LOS transitions €Increase automation of Payload Developer (PD) requests for data transfers €Alleviate extensive support to plan payload transfers around AOS/LOS and operator required transfers

Today, payload operations are highly scheduled and highly manned.  But, with dramatic increases in uplink and downlink bandwidth to the payloads, the link utilization doesn't have to be so tightly controlled and automation to reduce manpower costs is highly desirable.  Note, the ISS DTN deployment is a very small scale network.

We need to understand what problem space we are addressing.  If it is the small space community, that can probably be handled by CCSDS.  If it is large scale terrestrial deployment, we need to understand that environment. 

Will

On 4/28/14 8:51 AM, "Stephen Farrell" <[email-masked]> wrote:

>> I don't disagree with this.  But I don't want to be presumptious on 
>> how the answer should look like either (which also implies not ruling 
>> out options).
>
>Well, isn't that last more appropriate for an RG than a WG? I mean we 
>presumably don't want a WG that thrashes endlessly on the amount of 
>change vs. 5050 that's acceptable and I think that could happen if we 
>can't decide on this while chartering the putative WG.
>
>I also think it might (not 100% sure) be the case that different folks 
>would be more or less interested in a WG depending on the answer to 
>this question, so another danger for chartering a WG could be that if 
>the answer to this question only emerges some months down the road, 
>then half the WG participants might lose interest at that point and the 
>whole thing might fizzle.
>
>S.
>

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 28 Apr 2014 18:18:53 +0000

Two things.  

I think DOD is still evaluating as to whether DTN or something else is
better.  Scalability is a big issue  with 1000s to  10s of 1000s of units.

To date, most everything I've seen has been small bundles (with the
exception of the UK-DMC work).  I can conceive of deployments where files
are very large. So, should one treat bundles like store-and-forward
packets or more like moving packages (Amazon or Newegg or the airlines
moving luggage).  One model aggregates prior to forwarding and
deaggregates after,  the other deaggregates prior to forwarding and
reaggregates (is that a word?) after.  The latter results in LOTS of
bundle sitting in storage queues that have to be managed on a
bundle-by-bundle basis.

Will

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

>
>Meanwhile, though, the experience of NASA, N4C, the U.S. Defense
>Department, Boeing, and others seems to indicate that the Bundle Protocol
>and adjunct protocols can be used to operate delay- and
>disruption-tolerant networks successfully.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Apr 2014 19:24:35 +0100

Hi Scott,

On 28/04/14 18:40, Burleigh, Scott C (312G) wrote:
> Will's view here makes sense to me.  The initiative for requesting
> the BoF -- the first serious commercial interest in delay-tolerant
> networking that we've seen, I think -- is coming from Boeing.  I
> think it the energy behind the BoF initiative might evaporate if this
> conversation diverts that BoF initiative in a direction that diverges
> dramatically from Boeing's interests.

I agree. But its not clear to me what Boeing do envisage in
terms of minimal or more change vs. 5050. Maybe its clear to
others, but I didn't get that from the text Fred has sent
so far.

> In particular, the HTTP-DTN concept clearly merits serious
> consideration as a way of addressing the well-known challenges of
> delay-tolerant networking, but I don't think this BoF request
> discussion is the right place to try to conduct that serious
> consideration.  

I think Lloyd's http-dtn stuff is maybe one possible approach
but the issue of whether or not an IETF WG prioritises ease of
terrestrial deployment or prioritises minimal change to 5050
is basically independent of http-dtn. So we shouldn't get hung
up on a false dichotomy there.

> What I think would make more sense would be for a
> couple of experimental HTTP-DTN implementations to be developed and
> exercised in practical deployment scenarios, just as has been done
> with the DTNRG's BP-based protocol suite over the past decade, so
> that we can all get a better sense of the architecture's demonstrated
> advantages and disadvantages.  The DTNRG seems to me to be the right
> venue for that research.
> 
> Department, Boeing, and others seems to indicate that the Bundle
> Protocol and adjunct protocols can be used to operate delay- and

"Can be used" is correct. But to be fair, I'd have to say that
"can easily be used" is not correct for a bunch of use-cases,
including the N4C ones. And for others that I've investigated
since N4C finished. I'm not saying that 5050 doesn't work by
any means (modulo the known set of relatively minor things to
fix) but that its not really easy to deploy a DTN using 5050
and maybe that could be improved a lot if we do consider bigger
changes to 5050 for a 5050bis.

> This suggests that it
> could be advantageous to the networking community to standardize
> protocols derived from the DTNRG stack (certainly adopting some of
> the improvements to those protocols that have been proposed over the
> years).  I think that's the proposition that this BoF request
> conversation should be contemplating.

Personally, I think it'd be far more interesting if we did
not try to aim for minimal change to 5050, but were more ambitious
and tried for something that could get much broader deployment.
(While at the same time making sure one could easily gateway
from a 5050bis DTN to a 5050 DTN.)

But if minimal-change is what those who are proposing to do the
work want, then yes, that is what the BoF ought (clearly) propose
and what the IESG and IAB will evaluate. (And even though I'm
not fond of that plan myself, I'll be supportive of the work
being done if I think there's enough of a constituency for it
in the IETF.)

S.

> 
> Scott
> 
> -----Original Message----- From: dtn-interest
> [mailto:[email-masked]] On Behalf Of Ivancic, William
> D. (GRC-RHN0) Sent: Monday, April 28, 2014 6:25 AM To:
> [email-masked] Cc: [email-masked] Subject: Re:
> [dtn-interest] DTN BoF Proposal for IETF90
> 
> Fred,
> 
> CCSDS (http://cwe.ccsds.org/sis/default.aspx#_SIS-DTN).  They don't
> appear to be concerned with the numerous known problems.
> 
> On the International Space Station, they are interested in using DTN
> to automatically buffer data and commands between Loss-of-Signal
> (LOS) and Acquisition-of-Signal (AOS).  See-
f
> 
> DTN Goals are:
> 
> €Increase reliability of payload data transfers between ISS and
> remote payload control centers during AOS/LOS transitions €Increase
> automation of Payload Developer (PD) requests for data transfers
> €Alleviate extensive support to plan payload transfers around AOS/LOS
> and operator required transfers
> 
> Today, payload operations are highly scheduled and highly manned.
> But, with dramatic increases in uplink and downlink bandwidth to the
> payloads, the link utilization doesn't have to be so tightly
> controlled and automation to reduce manpower costs is highly
> desirable.  Note, the ISS DTN deployment is a very small scale
> network.
> 
> 
> 
> We need to understand what problem space we are addressing.  If it is
> the small space community, that can probably be handled by CCSDS.  If
> it is large scale terrestrial deployment, we need to understand that
> environment.
> 
> Will ******************************
> 
> 
> 
> 
> 
>> Well, isn't that last more appropriate for an RG than a WG? I mean
>> we presumably don't want a WG that thrashes endlessly on the amount
>> of change vs. 5050 that's acceptable and I think that could happen
>> if we can't decide on this while chartering the putative WG.
>> 
>> folks would be more or less interested in a WG depending on the
>> answer to this question, so another danger for chartering a WG
>> could be that if the answer to this question only emerges some
>> months down the road, then half the WG participants might lose
>> interest at that point and the whole thing might fizzle.
>> 
>> S.
>> 
>> _______________________________________________ dtn-interest
>> mailing list [email-masked] 
> _______________________________________________ dtn-interest mailing
> list [email-masked] 
> _______________________________________________ dtn-interest mailing
> list [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Apr 2014 19:30:03 +0100

On 28/04/14 19:18, Ivancic, William D. (GRC-RHN0) wrote:
> exception of the UK-DMC work).

We were sometimes sending ~400MB bundles as part of one of
the N4C trials. It worked. IIRC one of 'em was split into
55 fragments and still got there in the end via different
mules. It wasn't fast though:-)

Those large bundles were only needed when we wanted to
overwrite all the stored "pushed" HTTP web content so it
wasn't a daily thing but it did work when we had to do it.

S.

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 28 Apr 2014 19:03:05 +0000

Stephen,

Thanks for that information.  Like with the UK-DMC, it appears reactive
fragmentation saved you.  So, I suspect this deployment did not apply
bundle security as reactive fragmentation and bundle security don't mix
(if I recall correctly).  IMHO, this is the type of useful information
from DTNRG deployments that we can use the generate the requirements.

Will

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 28 Apr 2014 19:21:34 +0000

Stephen, speaking just for myself, I think modifications that would make BP-based networks easier to deploy should absolutely be on the table when (and if) this WG gets formed.

At the same time, we do have a lot of experience with what works -- especially in NASA pilot deployments -- and I think (a) we ought to at least consider the lessons learned from those deployments and (b) it is going to be important to be able to at least gateway between what comes out of this WG and the current specs, on which NASA is already standardizing.

In that vein, I think I would argue for changes that make it easier to do the things we now know we need to do, possibly at the expense of features that we don't seem to be getting much mileage out of.  Whether or not that set of changes ought to be considered "minimal" is a point on which opinions might differ.

A point I think is worth making: NASA's interest in DTN is not limited to data exchange among entities that are connected by space links.  Space flight operations networks extend to teams working on the ground, and there's increasing interest in enabling those teams to be mobile.  For NASA's purposes, DTN needs to encompass disruption-tolerant terrestrial networking as well as communication over long signal propagation times.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, April 28, 2014 11:25 AM
To: Burleigh, Scott C (312G); [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Hi Scott,

On 28/04/14 18:40, Burleigh, Scott C (312G) wrote:
> Will's view here makes sense to me.  The initiative for requesting the 
> BoF -- the first serious commercial interest in delay-tolerant 
> networking that we've seen, I think -- is coming from Boeing.  I think 
> it the energy behind the BoF initiative might evaporate if this 

I agree. But its not clear to me what Boeing do envisage in terms of minimal or more change vs. 5050. Maybe its clear to others, but I didn't get that from the text Fred has sent so far.

> discussion is the right place to try to conduct that serious 

I think Lloyd's http-dtn stuff is maybe one possible approach but the issue of whether or not an IETF WG prioritises ease of terrestrial deployment or prioritises minimal change to 5050 is basically independent of http-dtn. So we shouldn't get hung up on a false dichotomy there.

> What I think would make more sense would be for a couple of 
> experimental HTTP-DTN implementations to be developed and exercised in 
> practical deployment scenarios, just as has been done with the DTNRG's 
> BP-based protocol suite over the past decade, so that we can all get a 
> better sense of the architecture's demonstrated advantages and 
> disadvantages.  The DTNRG seems to me to be the right venue for that 
> research.
> 

"Can be used" is correct. But to be fair, I'd have to say that "can easily be used" is not correct for a bunch of use-cases, including the N4C ones. And for others that I've investigated since N4C finished. I'm not saying that 5050 doesn't work by any means (modulo the known set of relatively minor things to
fix) but that its not really easy to deploy a DTN using 5050 and maybe that could be improved a lot if we do consider bigger changes to 5050 for a 5050bis.

> protocols derived from the DTNRG stack (certainly adopting some of the 
> improvements to those protocols that have been proposed over the 

Personally, I think it'd be far more interesting if we did not try to aim for minimal change to 5050, but were more ambitious and tried for something that could get much broader deployment.
(While at the same time making sure one could easily gateway from a 5050bis DTN to a 5050 DTN.)

But if minimal-change is what those who are proposing to do the work want, then yes, that is what the BoF ought (clearly) propose and what the IESG and IAB will evaluate. (And even though I'm not fond of that plan myself, I'll be supportive of the work being done if I think there's enough of a constituency for it in the IETF.)

S.

f
> payload control centers during AOS/LOS transitions €Increase 
>>> how the answer should look like either (which also implies not 
>>> ruling out options).
>> 
>> answer to this question, so another danger for chartering a WG could 
>> be that if the answer to this question only emerges some months down 
>> the road, then half the WG participants might lose interest at that 
>> point and the whole thing might fizzle.
>> 
>> S.
>>

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 28 Apr 2014 19:55:12 +0000

Will, a comment along these lines: one alternative to reactive fragmentation, that is compatible with bundle authentication as currently spec'd, is "just in time" proactive fragmentation.  At the moment you de-queue a bundle for transmission you can retrieve its size, consider the data rate of your outbound link, and carve off (as a fragment) however much of the bundle you are willing to risk having to re-forward  in the event that the link is lost before transmission of the fragmentary bundle completes.

For example, if your original bundle is 400 MB and your outbound data rate is 8 Mbps, maybe you don't mind having to re-forward a bundle that takes only four seconds to transmit; in that case, you can proactively slice 4MB fragments off the outbound bundle 100 times and attach authentication to each fragment in the usual way.  Worst case on transmission failure is 4 seconds of wasted bandwidth, which normally you don't pay (because normally you don't lose the link), and the cost is an additional 99 bundle headers -- which is offset by the fact that you no longer need additional protocol overhead at the convergence layer to support reactive fragmentation.

This approach is especially handy in environments where you know in advance the time at which the link will be turned off: you can size your outbound fragment to fit into however many seconds of transmission you've got left.

Scott

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]] 
Sent: Monday, April 28, 2014 12:03 PM
To: Stephen Farrell; Burleigh, Scott C (312G); [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Stephen,

Thanks for that information.  Like with the UK-DMC, it appears reactive fragmentation saved you.  So, I suspect this deployment did not apply bundle security as reactive fragmentation and bundle security don't mix (if I recall correctly).  IMHO, this is the type of useful information from DTNRG deployments that we can use the generate the requirements.

Will

On 4/28/14 2:30 PM, "Stephen Farrell" <[email-masked]> wrote:

>We were sometimes sending ~400MB bundles as part of one of the N4C 
>trials. It worked. IIRC one of 'em was split into
>55 fragments and still got there in the end via different mules. It 
>wasn't fast though:-)
>
>Those large bundles were only needed when we wanted to overwrite all 
>the stored "pushed" HTTP web content so it wasn't a daily thing but it 
>did work when we had to do it.
>
>S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Apr 2014 20:31:52 +0000

Internet links have Maximum Transmission Units (MTUs). For IPv6, the
maximum MTU (i.e., the maximum IPv6 packet size) is 4GB (obviously,
most Internet links have considerably smaller MTUs). Then the path
MTU is the minimum of all link MTUs in the end-to-end path.

Similarly, paths between DTN nodes should have a Maximum Bundle Unit
(MBU). The MBU should be sized so that large bundles don't cause
unacceptable head-of-line blocking thus starving out smaller bundles.

So, an end-to-end DTN path may traverse many individual hops that have
diverse MBUs. But, each hop should have a well defined MBU so that
fragmentation can work correctly. Do we need text to this effect
in the specs?

Thanks - Fred

> From: dtn-interest [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312G)
> Sent: Monday, April 28, 2014 12:55 PM
> Will, a comment along these lines: one alternative to reactive fragmentation, that is compatible with
> bundle authentication as currently spec'd, is "just in time" proactive fragmentation.  At the moment
> you de-queue a bundle for transmission you can retrieve its size, consider the data rate of your
> outbound link, and carve off (as a fragment) however much of the bundle you are willing to risk having
> to re-forward  in the event that the link is lost before transmission of the fragmentary bundle
> completes.
> 
> For example, if your original bundle is 400 MB and your outbound data rate is 8 Mbps, maybe you don't
> mind having to re-forward a bundle that takes only four seconds to transmit; in that case, you can
> proactively slice 4MB fragments off the outbound bundle 100 times and attach authentication to each
> fragment in the usual way.  Worst case on transmission failure is 4 seconds of wasted bandwidth, which
> normally you don't pay (because normally you don't lose the link), and the cost is an additional 99
> bundle headers -- which is offset by the fact that you no longer need additional protocol overhead at
> the convergence layer to support reactive fragmentation.
> 
> This approach is especially handy in environments where you know in advance the time at which the link
> will be turned off: you can size your outbound fragment to fit into however many seconds of
> transmission you've got left.
> 
> Scott
> 
> Thanks for that information.  Like with the UK-DMC, it appears reactive fragmentation saved you.  So,
> I suspect this deployment did not apply bundle security as reactive fragmentation and bundle security
> don't mix (if I recall correctly).  IMHO, this is the type of useful information from DTNRG
> deployments that we can use the generate the requirements.
> 
> Will
>

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 28 Apr 2014 20:45:46 +0000

Sorry, my fault for taking us down into the weeds on this thread; I will desist.  But one quick answer off the top of my head: I think the proactive fragmentation size I was talking about would function as the MBU you propose, controlling head-of-line blocking.  Configuring nodes to apply appropriate proactive fragmentation sizes would be a network management function, I think, and therefore something that might be addressed in the context of the DTN network management specs that APL and several NASA centers are working on.  Additionally, though, QoS in BP provides a way to defeat head-of-line blocking for small important bundles -- if they've got higher priority they ought to jump the queue of bigger ones, and if they don't then maybe it's not such a big deal if they wait for bigger bundles that are ahead of them.

But let's take continuation of this discussion, if any, to a new thread.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, April 28, 2014 1:32 PM
To: Burleigh, Scott C (312G); [email-masked]
Subject: RE: [dtn-interest] DTN BoF Proposal for IETF90

Internet links have Maximum Transmission Units (MTUs). For IPv6, the maximum MTU (i.e., the maximum IPv6 packet size) is 4GB (obviously, most Internet links have considerably smaller MTUs). Then the path MTU is the minimum of all link MTUs in the end-to-end path.

Similarly, paths between DTN nodes should have a Maximum Bundle Unit (MBU). The MBU should be sized so that large bundles don't cause unacceptable head-of-line blocking thus starving out smaller bundles.

So, an end-to-end DTN path may traverse many individual hops that have diverse MBUs. But, each hop should have a well defined MBU so that fragmentation can work correctly. Do we need text to this effect in the specs?

Thanks - Fred

> Will, a comment along these lines: one alternative to reactive 
> fragmentation, that is compatible with bundle authentication as 
> currently spec'd, is "just in time" proactive fragmentation.  At the 
> moment you de-queue a bundle for transmission you can retrieve its 
> size, consider the data rate of your outbound link, and carve off (as 
> a fragment) however much of the bundle you are willing to risk having to re-forward  in the event that the link is lost before transmission of the fragmentary bundle completes.
> 
> For example, if your original bundle is 400 MB and your outbound data 
> rate is 8 Mbps, maybe you don't mind having to re-forward a bundle 
> that takes only four seconds to transmit; in that case, you can 
> proactively slice 4MB fragments off the outbound bundle 100 times and 
> attach authentication to each fragment in the usual way.  Worst case 
> on transmission failure is 4 seconds of wasted bandwidth, which 
> normally you don't pay (because normally you don't lose the link), and the cost is an additional 99 bundle headers -- which is offset by the fact that you no longer need additional protocol overhead at the convergence layer to support reactive fragmentation.
> 
> This approach is especially handy in environments where you know in 
> advance the time at which the link will be turned off: you can size 
> your outbound fragment to fit into however many seconds of transmission you've got left.
> 
> Scott
> 
> Thanks for that information.  Like with the UK-DMC, it appears 
> reactive fragmentation saved you.  So, I suspect this deployment did 
> not apply bundle security as reactive fragmentation and bundle 
> security don't mix (if I recall correctly).  IMHO, this is the type of useful information from DTNRG deployments that we can use the generate the requirements.
> 
> Will
> 
> >the stored "pushed" HTTP web content so it wasn't a daily thing but 
> >it did work when we had to do it.
> >
> >S.
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Apr 2014 22:02:52 +0000

Hi Scott,

Yes, let's keep this thread focused on the higher level discussion. In
particular, how do we set focused chartered working group items so that
the working group can make progress while still having an avenue for
bringing in new work items as they are ready. Do you see it that the
DTNRG would be the forum for advanced development, and DTNWG as the
engineering standards body?

Thanks - Fred

> From: Burleigh, Scott C (312G) [mailto:[email-masked]]
> Sent: Monday, April 28, 2014 1:46 PM
> Sorry, my fault for taking us down into the weeds on this thread; I will desist.  But one quick answer
> off the top of my head: I think the proactive fragmentation size I was talking about would function as
> the MBU you propose, controlling head-of-line blocking.  Configuring nodes to apply appropriate
> proactive fragmentation sizes would be a network management function, I think, and therefore something
> that might be addressed in the context of the DTN network management specs that APL and several NASA
> centers are working on.  Additionally, though, QoS in BP provides a way to defeat head-of-line
> blocking for small important bundles -- if they've got higher priority they ought to jump the queue of
> bigger ones, and if they don't then maybe it's not such a big deal if they wait for bigger bundles
> that are ahead of them.
> 
> Internet links have Maximum Transmission Units (MTUs). For IPv6, the maximum MTU (i.e., the maximum
> IPv6 packet size) is 4GB (obviously, most Internet links have considerably smaller MTUs). Then the
> path MTU is the minimum of all link MTUs in the end-to-end path.
> 
> Similarly, paths between DTN nodes should have a Maximum Bundle Unit (MBU). The MBU should be sized so
> that large bundles don't cause unacceptable head-of-line blocking thus starving out smaller bundles.
> 
> So, an end-to-end DTN path may traverse many individual hops that have diverse MBUs. But, each hop
> should have a well defined MBU so that fragmentation can work correctly. Do we need text to this
> effect in the specs?
> 
> Thanks - Fred
> > a fragment) however much of the bundle you are willing to risk having to re-forward  in the event
> that the link is lost before transmission of the fragmentary bundle completes.
> >
> > security don't mix (if I recall correctly).  IMHO, this is the type of useful information from DTNRG

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Apr 2014 23:07:34 +0100

Hiya,

On 28/04/14 20:21, Burleigh, Scott C (312G) wrote:
> Stephen, speaking just for myself, I think modifications that would
> make BP-based networks easier to deploy should absolutely be on the
> table when (and if) this WG gets formed.

Agreed.

> At the same time, we do have a lot of experience with what works --
> especially in NASA pilot deployments -- and I think (a) we ought to
> at least consider the lessons learned from those deployments and (b)
> it is going to be important to be able to at least gateway between
> what comes out of this WG and the current specs, on which NASA is
> already standardizing.

Again, I agree. I'd add (c) consider lessons learned in non-DTN
deployments for factors might block or enhance wide scale deployment
of DTNs.

But I'm also arguing for more than "consider" I guess - and more
for making that last a first class requirement.

> In that vein, I think I would argue for changes that make it easier
> to do the things we now know we need to do, possibly at the expense
> of features that we don't seem to be getting much mileage out of.

And more agreement.

> Whether or not that set of changes ought to be considered "minimal"
> is a point on which opinions might differ.
> 
> A point I think is worth making: NASA's interest in DTN is not
> limited to data exchange among entities that are connected by space
> links.  Space flight operations networks extend to teams working on
> the ground, and there's increasing interest in enabling those teams
> to be mobile.  For NASA's purposes, DTN needs to encompass
> disruption-tolerant terrestrial networking as well as communication
> over long signal propagation times.

Interesting.

Its a bit too detailed for now but what I've seen is that for
applications with user interfaces, DTN can provide useful
functions, but isn't worth it because mimicing the bits of
DTN function at the application layer is easier for
application developers overall.

For M2M applications, DTN has more potential, but I don't see a
good match between 5050 and the kinds of tooling and libraries
that are already present on relevant devices so again it would
probably be easier for developers to use COAP and mimic the bits
of DTN function that they need with what they already have present
esp. in limited code-footprint devices.

That kind of thing pushed DTN into even more niche territory
which is a pity. And I think both scenarios above have changed
significantly enough since we started the design of the BP that
revisiting that design taking those new factors into account
could be well worthwhile.

S.

> 
> Scott
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Monday, April 28, 2014 11:25
> AM To: Burleigh, Scott C (312G); [email-masked] Subject: Re:
>> think it the energy behind the BoF initiative might evaporate if
>> this conversation diverts that BoF initiative in a direction that
>> diverges dramatically from Boeing's interests.
> 
> I agree. But its not clear to me what Boeing do envisage in terms of
> minimal or more change vs. 5050. Maybe its clear to others, but I
> didn't get that from the text Fred has sent so far.
> 
> I think Lloyd's http-dtn stuff is maybe one possible approach but the
> issue of whether or not an IETF WG prioritises ease of terrestrial
> deployment or prioritises minimal change to 5050 is basically
> independent of http-dtn. So we shouldn't get hung up on a false
> dichotomy there.
> 
>> experimental HTTP-DTN implementations to be developed and exercised
>> in practical deployment scenarios, just as has been done with the
>> DTNRG's BP-based protocol suite over the past decade, so that we
>> can all get a better sense of the architecture's demonstrated
>> advantages and disadvantages.  The DTNRG seems to me to be the
>> right venue for that research.
>> 
> "Can be used" is correct. But to be fair, I'd have to say that "can
> easily be used" is not correct for a bunch of use-cases, including
> the N4C ones. And for others that I've investigated since N4C
> finished. I'm not saying that 5050 doesn't work by any means (modulo
> the known set of relatively minor things to fix) but that its not
> really easy to deploy a DTN using 5050 and maybe that could be
> improved a lot if we do consider bigger changes to 5050 for a
> 5050bis.
> 
>> This suggests that it could be advantageous to the networking
>> community to standardize protocols derived from the DTNRG stack
>> (certainly adopting some of the improvements to those protocols
>> that have been proposed over the years).  I think that's the
>> proposition that this BoF request conversation should be
>> contemplating.
> 
> Personally, I think it'd be far more interesting if we did not try to
> aim for minimal change to 5050, but were more ambitious and tried for
> something that could get much broader deployment. (While at the same
> time making sure one could easily gateway from a 5050bis DTN to a
> 5050 DTN.)
> 
> But if minimal-change is what those who are proposing to do the work
> want, then yes, that is what the BoF ought (clearly) propose and what
> the IESG and IAB will evaluate. (And even though I'm not fond of that
> plan myself, I'll be supportive of the work being done if I think
> there's enough of a constituency for it in the IETF.)
> 
> S.
> 
>> 
>> Scott
>> 
>> [mailto:[email-masked]] On Behalf Of Ivancic,
>> William D. (GRC-RHN0) Sent: Monday, April 28, 2014 6:25 AM To: 
>> I know NASA is working to standardize RFC5050 as a space protocol
>> via CCSDS (http://cwe.ccsds.org/sis/default.aspx#_SIS-DTN).  They
>> don't appear to be concerned with the numerous known problems.
>> 
>> On the International Space Station, they are interested in using
>> DTN to automatically buffer data and commands between
>> Loss-of-Signal (LOS) and Acquisition-of-Signal (AOS).  See- 
>> http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNS
>>
>> 
IG.pd
>> €Alleviate extensive support to plan payload transfers around
>> AOS/LOS and operator required transfers
>> 
>> But, with dramatic increases in uplink and downlink bandwidth to
>> the payloads, the link utilization doesn't have to be so tightly 
>> We need to understand what problem space we are addressing.  If it
>> is the small space community, that can probably be handled by
>> CCSDS.  If it is large scale terrestrial deployment, we need to
>> understand that environment.
>> 
>>>> I don't disagree with this.  But I don't want to be
>>>> presumptious on how the answer should look like either (which
>>>> also implies not ruling out options).
>>> 
>>> mean we presumably don't want a WG that thrashes endlessly on the
>>> amount of change vs. 5050 that's acceptable and I think that
>>> could happen if we can't decide on this while chartering the
>>> putative WG.
>>>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Apr 2014 23:12:43 +0100

Hi Fred,

> particular, how do we set focused chartered working group items so that

Is your/Boeing's preference to try to keep as close to 5050 as
possible for a 5050bis or are you also considering changes that
are less minimal, e.g. along the lines I've been discussing?

I think it will help to be very clear about that and is needed
to get to the focused charter you describe above.

> engineering standards body?

I think the topic is the BoF though, if a WG is formed the above
is pretty obvious for as long as DTNRG exists I guess.

Ta,
S.

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 28 Apr 2014 22:14:28 +0000

Certainly that makes sense to me.  It's obvious from the messages on this thread -- and from the number of papers I'm seeing submitted and published -- that DTN is still an active research field; it would be way premature to declare victory and shut down the research group.  At the same time, there seems to be an emerging need for standards that industry can begin to pick up.  I'm no expert on how IRTF and IETF work together, but using DTNRG to answer research questions and using a DTNWG in IETF to infuse those answers into operational networks seems natural.

Scott 

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, April 28, 2014 3:03 PM
To: Burleigh, Scott C (312G); [email-masked]
Subject: RE: [dtn-interest] DTN BoF Proposal for IETF90

Hi Scott,

Yes, let's keep this thread focused on the higher level discussion. In particular, how do we set focused chartered working group items so that the working group can make progress while still having an avenue for bringing in new work items as they are ready. Do you see it that the DTNRG would be the forum for advanced development, and DTNWG as the engineering standards body?

Thanks - Fred

> Sorry, my fault for taking us down into the weeds on this thread; I 
> will desist.  But one quick answer off the top of my head: I think the 
> proactive fragmentation size I was talking about would function as the 
> MBU you propose, controlling head-of-line blocking.  Configuring nodes 
> to apply appropriate proactive fragmentation sizes would be a network 
> management function, I think, and therefore something that might be 
> addressed in the context of the DTN network management specs that APL 
> and several NASA centers are working on.  Additionally, though, QoS in 
> BP provides a way to defeat head-of-line blocking for small important bundles -- if they've got higher priority they ought to jump the queue of bigger ones, and if they don't then maybe it's not such a big deal if they wait for bigger bundles that are ahead of them.
> 
> maximum MTU (i.e., the maximum
> IPv6 packet size) is 4GB (obviously, most Internet links have 
> considerably smaller MTUs). Then the path MTU is the minimum of all link MTUs in the end-to-end path.
> 
> (MBU). The MBU should be sized so that large bundles don't cause unacceptable head-of-line blocking thus starving out smaller bundles.
> 
> fragmentation can work correctly. Do we need text to this effect in the specs?
> 
> Thanks - Fred
> > size, consider the data rate of your outbound link, and carve off 
> > (as a fragment) however much of the bundle you are willing to risk 
> > having to re-forward  in the event
> > For example, if your original bundle is 400 MB and your outbound 
> > data rate is 8 Mbps, maybe you don't mind having to re-forward a 
> > bundle that takes only four seconds to transmit; in that case, you 
> > can proactively slice 4MB fragments off the outbound bundle 100 
> > times and attach authentication to each fragment in the usual way.  
> > Worst case on transmission failure is 4 seconds of wasted bandwidth, 
> > which normally you don't pay (because normally you don't lose the 
> > link), and the cost is an additional 99
> bundle headers -- which is offset by the fact that you no longer need 
> additional protocol overhead at the convergence layer to support reactive fragmentation.
> >
> > >> To date, most everything I've seen has been small bundles (with 
> > >> the exception of the UK-DMC work).
> > >
> > >Those large bundles were only needed when we wanted to overwrite 
> > >all the stored "pushed" HTTP web content so it wasn't a daily thing 
> > >but it did work when we had to do it.
> > >
> > >S.
> >
> >

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Apr 2014 22:27:46 +0000

Hi Stephen,

> Sent: Monday, April 28, 2014 3:13 PM
> To: Templin, Fred L; Burleigh, Scott C (312G); [email-masked]

I submitted some mini problem statement drafts that touch on areas
that I think would need to be addressed in a 5050bis, but my list
was not exhaustive. Scott also posted a laundry list of 5050bis
candidate items last year. In terms of Boeing's interests, security
is a high priority for us for what we think we need in the near term.
 
> is pretty obvious for as long as DTNRG exists I guess.

OK, and yes we want to stay focused on the BoF.

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Apr 2014 23:43:01 +0100

Hi Fred,

> is a high priority for us for what we think we need in the near term.

All that's fair enough and sorry to hammer on about this, but I
do think its important to get this clear for the scoping of the
BoF/WG.

You say "not exhaustive" but do you mean that from your POV
your list is all you're really interested in working on? Which
would be entirely ok IMO, nothing wrong with that, but I think
it'd mean you're not interested in a re-design of 5050 but more
of a bug-fix type approach.

(Again, to be clear: by re-design, I mean to keep the gatewaying-
to-5050 ability but to look again at how we represent bundles
to see if its possible to come up with something much more easily
deployed.)

S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Apr 2014 22:56:50 +0000

Hi Stephen,

> Sent: Monday, April 28, 2014 3:43 PM

My three drafts were all I had time for. Probably to have done it
right I should have written a single "problem statement" document
that included my three proposed work items and also with a
work-in-progress framework for adding others. But, discussing and
setting the basis for a unified problem statement is one of the
first things I would like for the BoF to accomplish.

> to see if its possible to come up with something much more easily

I have to admit that I have been thinking more along the lines
of a bug fix - as in, can we begin to address some of the issues
outline in "Bundle of Problems". But, we should have this
discussion as part of the BoF.

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Apr 2014 00:24:49 +0100

> discussion as part of the BoF.

That's fair and answers my question for now. As a BoF/RG
participant, I'll be arguing (a bit) for more-than-bug-fix.

As an IESG member, I'll be interested to see how it turns
out, but as I said even if it comes out as bug-fix only,
if there's sufficient interest etc I'd be supportive for
forming a WG.

Thanks,
S.

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 29 Apr 2014 07:33:49 +0000

Hi,

On 2014-4-28, at 17:57, Templin, Fred L <[email-masked]> wrote:
> But, let's also consider that if we
> track 

so that's not fully accurate. There is the "AD sponsored" publication path, whereby documents can be published on the IETF RFC Stream at Standards levels without needing to have come from an IETF WG.

(Yes, it requires an AD with an interest in making this happen, and it's their personal decision if they want to do so.)

So if there are one or two documents that everyone believes are ready for standards track, those could be progressed as "AD sponsored" without actually forming a WG.

> and this area of research will continue to languish.

I don't see how failing to start a WG will make the *research* languish.

Lars

PS: And chartering a WG is of course no guarantee that any standards will get published. A WG may get derailed, loose energy, or the IESG may find the work lacking in quality to let it go forwards as standards.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Apr 2014 14:46:59 +0000

Hi Lars,

> From: Eggert, Lars [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2014 12:34 AM
> To: Templin, Fred L
> so that's not fully accurate. There is the "AD sponsored" publication path, whereby documents can be
> published on the IETF RFC Stream at Standards levels without needing to have come from an IETF WG.

Yes, I have used the AD sponsored publication path in the past. My
unspoken assumption was that getting an AD to support publication
on a per-document basis would be difficult when there are really
a number of documents that we would like to progress.

Thanks - Fred

> So if there are one or two documents that everyone believes are ready for standards track, those could
> be progressed as "AD sponsored" without actually forming a WG.
> 
> PS: And chartering a WG is of course no guarantee that any standards will get published. A WG may get
> derailed, loose energy, or the IESG may find the work lacking in quality to let it go forwards as
> standards.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Apr 2014 21:48:35 +0000

Lars,

> a number of documents that we would like to progress.

So, to complete the thought, I am not seeing this as a "one or two
docs and done" prospect. We already have four work items on the draft
charter and have had a number or requests for additional work items.
IMHO, that level of interest fits the profile of a working group
moreso than one-off AD shopping.

Thanks - Fred

---

From: Eric Travis <[email-masked]>
Date: Tue, 29 Apr 2014 18:44:00 -0400

Fred,

Regardless of whether the path forward is - via a WG or via independent
submission, I believe that a 5050.Bis
(or whatever the result is called) should *bundle* - pardon the
unintentional pun - or otherwise coalesce
(the content and "fixes" to):

       o  RFC 5050 Bundle Protocol Specification
       o  Streamlined Bundle Security Protocol (SBSP)
                                        and
       o  Bundle in Bundle Encapsulation (still an I-D?)

into a SINGLE, comprehensive bundle specification document.  This will help
to ensure any tweaks/fixes to the
existing RFC-5050 will be addressed more holistically.  For sake of
completeness,  I'd add the content of RFC 6260
(Compressed Bundle Header Encoding) and the existing UDP and TCP
convergence layers to that list.

The effort starts with a melding of the existing content, and continues
with whatever tweaks/modifications that are
deemed appropriate/desirable for advancing the documented flavor of DTN.

And since I'm rudely suggesting things, may I inquire as to why this needs
to wait?

The ground-work for preparing the existing documentation can begin *now*
within the existing infrastructure of the
DTNRG.  This provides almost 3 months of lead-time and momentum (and
demonstration of energy/commitment) going
into a DTN BoF.

Apologies and Regards,

Eric
[email-masked]

-- 

*The problem with the worlld is that the intelligent people are full of
doubts, while the stupid ones are full of confidence.*

*
- Charles Bukowski*

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Apr 2014 23:46:39 +0100

> demonstration of energy/commitment) going

Excellent point

S

---

From: <[email-masked]>
Date: Tue, 29 Apr 2014 22:54:21 +0000

DTN as an area of research (which subsumed MANET as the fashionable marker term for attracting funding) is not the Bundle Protocol - and most DTN research papers are on work not using the Bundle Protocol.

The messages on this thread are debating how to reanimate a corpse. Sure, shut down the research group - but declare victory?

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn-interest <[email-masked]> on behalf of Burleigh, Scott C (312G) <[email-masked]>
Sent: Tuesday, 29 April 2014 8:14 AM
To: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]]
Sent: Monday, April 28, 2014 3:03 PM
To: Burleigh, Scott C (312G); [email-masked]
Subject: RE: [dtn-interest] DTN BoF Proposal for IETF90

Hi Scott,

Thanks - Fred

---

From: <[email-masked]>
Date: Wed, 30 Apr 2014 02:40:51 +0000

> DTN can provide useful functions, but isn't worth it because
> mimicing the bits of DTN function at the application layer is easier for

This holds for e.g. bundle protocol security. It's unneeded; apps can roll their own.

> both scenarios above have changed

The scenarios haven't changed. The bundle protocol designers have just
gained more experience with reality.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn-interest <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Tuesday, 29 April 2014 8:07 AM
To: Burleigh, Scott C (312G); [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Hiya,

Agreed.

And more agreement.

Interesting.

S.

IG.pd

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 30 Apr 2014 02:48:37 +0000

>This holds for e.g. bundle protocol security. It's unneeded; apps can

Payload can be handle by the source to destination.  That is what emails
does.

IMHO, one would want to validate the source as I might not want to store
anything from Lloyd (sorry Lloyd), 100 Mbytes from Scott and 20 Gbytes
from Stephen (since he agreed to pay half my monthly phone bill).  I'm not
about to let just anyone use my truck.

Will

---

From: Eric Travis <[email-masked]>
Date: Wed, 30 Apr 2014 00:20:53 -0400

Will,

Are you suggesting that the (originating) sender should be validated at each
transfer point (from Bob's truck to my truck to your truck)?  If this is
even possible,
it certainly won't scale.

Nor is it enforceable: What if Stephen enters into a secret side agreement
with Lloyd to encapsulate bundles?

Way back in the days of the IPN (presumably back in the time "before
gaining experience with reality" - nod to Lloyd), we used to talk about
admissions control...  The bundle sender was to be verified at the entry
bundle portal. Only authorized sources could submit bundles.   As bundle
nodes were to be "mutually suspicious" [1], the interacting bundle nodes
would
validate each other (at each contact episode) prior to exchanging bundles,
but  bundles would travel between nodes w/o requiring subsequent individual
source verifications (though there was to be a mandatory integrity check to
verify
a content of the bundle was not altered by the intermediate "sending"
node).

Once the bundle was "in the system", there was no need to validate the
source
of bundles in transit.

Rather than "not letting just anybody use your truck", you don't let just
any
other truck driver offload it's contents into your truck.  Truck drivers
are not
permitted to accept freight from unauthorized customers.

This in not to suggest that bundle nodes can't/shouldn't have policies
defining
filters for the characteristics of acceptable bundles (such as declared
[but unverified] source,
bundles smaller than 10MB, only blue or purple bundles, etc.) - mechanisms
allowing
nodes to exchange policies and coordinate regarding local resource
allocation are a missing
feature and topic for a different discussion.

I will concede that the IPN architecture was much (much) more of a walled
garden compared to that
of this DTN problem space - but that doesn't change the notion that
requiring source verification
at each bundle transfer point is not the best approach.

If you were making a different point, sorry for my misunderstanding....

[1] Bundle node "mutual suspicion" didn't make the jump between IPN -> DTN
     architecture.  One implication was the loss of an integral bundle
integrity check.

Eric

-- 

*The problem with the world is that the intelligent people are full of
doubts, while the stupid ones are full of confidence.*

*
- Charles Bukowski*

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 30 Apr 2014 12:46:18 +0000

In Line

From: Eric Travis <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 30, 2014 12:20 AM
To: William Ivancic <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Will,

Are you suggesting that the (originating) sender should be validated at each
transfer point (from Bob's truck to my truck to your truck)?

Not necessarily every transfer point, just transfer points that care.

If this is even possible,
it certainly won't scale.

Nor is it enforceable: What if Stephen enters into a secret side agreement with Lloyd to encapsulate bundles?

If they have such an agreement, I don't know that I care.

Way back in the days of the IPN (presumably back in the time "before
gaining experience with reality" - nod to Lloyd), we used to talk about
admissions control...  The bundle sender was to be verified at the entry
bundle portal. Only authorized sources could submit bundles.   As bundle
nodes were to be "mutually suspicious" [1], the interacting bundle nodes would
validate each other (at each contact episode) prior to exchanging bundles,
but  bundles would travel between nodes w/o requiring subsequent individual
source verifications (though there was to be a mandatory integrity check to verify
a content of the bundle was not altered by the intermediate "sending" node).

It seems like this assumes a closed system and thus, scaling is not all that much of a consideration relative to a global or universal deployment.
Much of Bundling has, IMHO, always been very space centric.   Understandably so, as it did start as Interplanetary Network (IPN) with origins in CFDP.
http://public.ccsds.org/publications/archive/720x1g3.pdf
http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF

But, once this hit DTRNG, I think the hope was to make this more universal, which opened up a complete new user space and expectations.  However, to date, the terrestrial users have not found the protocol, as is, very deployable.  Space is a much smaller and much simpler deployment environment.  In many ways, Space  is very small and extremely predictable.

Once the bundle was "in the system", there was no need to validate the source
of bundles in transit.

Rather than "not letting just anybody use your truck", you don't let just any
other truck driver offload it's contents into your truck.  Truck drivers are not
permitted to accept freight from unauthorized customers.

Thus, assumes a closed network.  No?

---

From: Amy Alford <[email-masked]>
Date: Wed, 30 Apr 2014 11:25:33 -0400

BSP certainly allows verification at every node, or verification at any
node that cares to go to the effort.  IIRC, SBSP does also.

One of the challenges with BSP/SBSP, is that the spec allows for phenomenal
complexity in the security policy at a node.  It seems unlikely that any
implementation is going to allow the entire scope of possibilities in the
spec.  SBSP narrowed the possibilities, but there's still a lot of policy
decisions that it's hard to communicate to users.  For example, multiple
instances of BIB or BCB are not allowed.  So, what do you do when an
incoming bundle already has one and local policy says you should add one?
 If your local policy is allowed to vary by src/dest, then what happens if
your configuration says two different BIB/BCB should be added based on the
src/dest?

On Wed, Apr 30, 2014 at 12:20 AM, Eric Travis <[email-masked]>wrote:

> doubts, while the stupid ones are full of confidence. *
>
> *
> - Charles Bukowski*
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 30 Apr 2014 16:59:14 +0000

Hi Eric,

A process point regarding the lead-time going into a DTN BoF. Although IETF90 is scheduled
for July 20-25th (the 3 months you mentioned), the time to begin organizing the BoF is now.
We will very soon need to make a formal BoF request, and my sense from these discussions
is that we at least have enough interest to initiate the request. Am I wrong?

Thanks - Fred

The ground-work for preparing the existing documentation can begin *now* within the existing infrastructure of the
DTNRG.  This provides almost 3 months of lead-time and momentum (and demonstration of energy/commitment) going
into a DTN BoF.

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 30 Apr 2014 18:35:25 +0000

Fred,

Have you talked to an AD or someone on the IESG about a BOF?  If not, I suggest you/we do.

Way back,  I was involved with organizing a BOF on multi-homed mobile platforms (aircraft, boats, etc…).  I know we talked to ADs and planned for probably six to nine months.  I know we met with ADs in 2006 in Montreal (66th IETF) to discuss what we wanted to do and strategize for the BOF.  In fact, cannot remember if we did a BOF.  I think we may have then presented to nemo and monami at IEFT 67.

>From the discussions on the list, I would say, we are not ready to have a BOF.   It is my understanding that  BOF can be held: 1) to conduct a single, brief discussion or 2) to ascertain interest and establish goals for a working group.  I believe #2 is you goal.

Generally, you get one chance, so you want to know exactly what you want out of the BOF and you need to be well organized to convince the community that there is ample reason to form a working group and ample energy to get the work done.

Stephen can probably provide some advice here.

>From the activity on this list lately, I think you may be hard pressed to get the workers.  Most of the big funding for this has dried up.  Previously you had DARPA, NASA and the N4C investing significant funds.  Many of those who use to be active on this list have moved to Information Centric Networking.

Will

From: <Templin>, Fred L <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 30, 2014 12:59 PM
To: Eric Travis <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Hi Eric,

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 30 Apr 2014 20:03:09 +0000

Hi Will,

Your experience is appreciated and noted. By my read of RFC5434 we are not too late
in the game to hold a BoF at IETF90, but we need to keep moving along. Also, my
understanding is that a second BoF can be held if the first is inconclusive.  That said,
I agree that it would be good to talk to an AD soon.

Thanks - Fred

From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]]
Sent: Wednesday, April 30, 2014 11:35 AM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Fred,

Way back,  I was involved with organizing a BOF on multi-homed mobile platforms (aircraft, boats, etc...).  I know we talked to ADs and planned for probably six to nine months.  I know we met with ADs in 2006 in Montreal (66th IETF) to discuss what we wanted to do and strategize for the BOF.  In fact, cannot remember if we did a BOF.  I think we may have then presented to nemo and monami at IEFT 67.

Will

Hi Eric,

Thanks - Fred

---

From: Eric Travis <[email-masked]>
Date: Wed, 30 Apr 2014 22:41:31 -0400

Hi Fred,

Based on the draft Charter, I had assumed that you had already initiated
discussions with an Area Director...

The schedule in the draft Charter is, in my opinion, enthusiastic.  The
higher the level of actual participation,
the longer the timelines are likely to be (again, just my opinion).  What I
was suggesting is that assuming there
is a BoF *and* it leads to a DTN WG, doing  the actual work can be started
now, getting a 3 month jump on the
BoF and probably 8+ month jump on the earliest possible meeting of a DTN WG.

My impression is there has been sufficient interest in a 5050.Bis since the
possibility was raised close to 3 years ago.

So - no, I don't think you are wrong, either regarding your process point
or in the estimate of apparent level of interest.

Regards,

Eric

On Wed, Apr 30, 2014 at 12:59 PM, Templin, Fred L <[email-masked]
> wrote:

-- 

*
- Charles Bukowski*