Subject: [dtn-interest] RFC 5050 revision?

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 May 2012 21:01:24 +0100

Hi all,

As Joerg noted we're interested in whether or not,
and if so how, folks would like to do some work on an
update or revision for RFC 5050, or ideas for
alternatives to the BP or additional DTN protocols.

Things we're interested in hearing about, are:

- Should we rev 5050? why? why not?
- What do you not like about 5050? how'd you fix that?
- What is missing from 5050? how'd you add that?
- What's great about 5050? why'd you keep that?
- What 2119 MUST/SHOULD/MAY would you change and why?
- What DTN research questions would you like to tackle
  where RFC 5050 (or implementations thereof) are
  a barrier?

In addition, we'd be interested in hearing whether
folks would like to explore doing DTN based not on
a straight revision of the BP, but maybe e.g. based
on CoAP, SPDY, websockets, or other protocols.

Or, if you've something else to say/suggest, fo
ahead and do that too.

At this point the goal is to gather and discuss
ideas on the list, with a view to seeing what's of
interest to RG participants.

If we get a bunch of ideas, then we'll try to
organise those a bit and start separate threads.
For now, if you can respond to this mail, that'll
help us track the discussion later.

Later on, the question of who's actually willing to
do stuff will get more interesting, since that's how
things get done - just saying that it "must be so"
is frequently trumped by the fact that someone else
has the energy to actually do something.

Lastly, none of this means that there's anything
wrong with RFC 5050 which has been great for both
doing DTN experiments and for the CCSDS folks who're
building on it for their work. (And in case CCSDS
people get process-scared, no, nothing will ever
change the existing RFCs, so documents referring
to them are unaffected.)

Cheers,
Stephen, Kevin, Joerg.

---

From: William Immerman <[email-masked]>
Date: Wed, 16 May 2012 11:22:58 -0400

I'd like to comment on one aspect of these questions from the point of view of a newbie to DTN, and one who is more focussed on use of DTN than on research into the protocol(s).

I've visited with a number of people who I believe (should) see DTN as a solution to their common set of problems, and many believe that their existing one-off implementations are solutions. One of my observations to them that seems to be opening doors is the potential that DTN will permit their devices/subsystems to interoperate with others. I've also observed without contradiction that these won't be the last systems they build that face these issues, and that no one would adopt their stovepipe solution as THE basis for a common solution, but that the DTN community's work may serve that purpose. Finally, I've had to field a bunch of questions about the maturity of DTN, and I've had a difficult enough time explaining to would-be sponsors that a lot of the less mature aspects are in implementations and ancillary components/protocols (e.g., routing, naming), but that the DTN community has at least converged largely on BP as a core protocol with proven capability and which interoperates over multiple implementations. This explanation seems to have had a mildly calming effect.

I'm concerned that a substantial effort to replace 5050 might undermine some of these arguments, and that every time a leg is knocked out from under us we make it more difficult for people with needs to choose to adopt DTN.

This doesn't mean that there wouldn't be good reason to examine changes to 5050 at this time: if there are things that people have found obstruct adoption and can be fixed without negative impact on other uses, that'd be very positive. Likewise, I don't mean to say people should stop researching core problems, just expressing concerns that if a proposal is based mainly on how somebody might do it differently if starting fresh, they might want to consider the chilling effect that optimization might have on getting users on board now. There's a lot of potential utility to DTN, but it still addresses a population that is, for some observers, a niche, albeit an important and sizable niche. If we fragment that niche too much, we may end up with no critical mass of support.

Thanks,
Bill Immerman
 
On May 15, 2012, at 4:01 PM, Stephen Farrell wrote:

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

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Fri, 18 May 2012 16:50:31 +0000

I think we got a lot of things right in RFC 5050: I think it's just about open-ended enough -- I'm a big fan of the extension block mechanism -- and I think the notions of node, endpoint, forwarding, delivery, custody, etc. are generally pretty solid.

But I do think we got one major thing wrong: although we recognize the significance of nodes, we nowhere establish any concept of node ID.  All we've got are endpoint IDs.

And we need that concept.  As important as endpoints are, we define a large (and growing) number of critical DTN functions in terms of nodes, not endpoints:
	-  Custody transfer is accomplished between nodes, not endpoints.
	-  In practice, we route on the basis of nodes, not endpoints.  (Delivery predictability in PROPHET, for example, is associated with nodes.  Everything in Contact Graph Routing is implemented in terms of nodes.)
	-  All of the Bundle Security Protocol mechanisms actually operate on the basis of nodes, not endpoints.  (For example, section 1.2 of RFC 6257 defines "security source" and "security destination" as nodes.)

Since nodes have got to be identified in order to accomplish these functions, and we can't live without these functions, we identify nodes now.  We use endpoint identifiers to identify them.

But endpoint identifiers don't identify nodes.  They identify endpoints.

By convention we mutually agree that a node can always be identified by the ID of one of the singleton endpoints in which it is registered (and there always has to be at least one, per section 3.1 of RFC 5050).  This works, so long as our nodes all know which singleton endpoints other nodes are registered in, and those registrations never change without notification to all other nodes who care about them.

But there's nothing in any specification anywhere that requires this persistent registration.  A node could register in a new singleton endpoint (and unregister in all old ones) once every second, making its use as a "router" node impossible, and yet remain fully conformant with RFC 5050.  Since there is no requirement for persistent endpoint registration in any DTN specification, and therefore no assurance of persistent node identity, the foundation on which many critical DTN functions rests is really just good will and out-of-band consensus on the part of node administrators.

I will freely admit to a bias on this topic: I think the CBHE (and "ipn" scheme) notion of explicitly identifying nodes and services (i.e., demuxes) by numbers, expressing most endpoint IDs in terms of node and service numbers, and directly encoding those numeric EIDs as SDNVs in the primary block -- rather than carrying arbitrarily long ASCII strings in a dictionary array -- has been shown to work well, and I'd like to see that representation made standard in the Bundle Protocol rather than supported only as a convergence-layer adaptation.  I'm fully on board with retaining the expressive power of URIs for complex and interesting new destination EIDs (intentional naming, etc.), but the vast bulk of BP traffic now and in the foreseeable future doesn't need any of that power.  I believe we can, and should, optimize for the uninteresting, prevailing case of sending bundles directly to explicitly identified service points at explicitly identified nodes, and define one or more destination EID override extension blocks for the scenarios that need more complex endpoint IDs.

But whether or not we make that adjustment, at the very least I believe we have got to acknowledge nodes as first-class entities in the DTN architecture and decide how we're going to reference them in our protocols.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, May 15, 2012 1:01 PM
To: DTN interest
Subject: [dtn-interest] RFC 5050 revision?

Hi all,

As Joerg noted we're interested in whether or not, and if so how, folks would like to do some work on an update or revision for RFC 5050, or ideas for alternatives to the BP or additional DTN protocols.

In addition, we'd be interested in hearing whether folks would like to explore doing DTN based not on a straight revision of the BP, but maybe e.g. based on CoAP, SPDY, websockets, or other protocols.

Or, if you've something else to say/suggest, fo ahead and do that too.

At this point the goal is to gather and discuss ideas on the list, with a view to seeing what's of interest to RG participants.

If we get a bunch of ideas, then we'll try to organise those a bit and start separate threads.
For now, if you can respond to this mail, that'll help us track the discussion later.

Later on, the question of who's actually willing to do stuff will get more interesting, since that's how things get done - just saying that it "must be so"
is frequently trumped by the fact that someone else has the energy to actually do something.

Lastly, none of this means that there's anything wrong with RFC 5050 which has been great for both doing DTN experiments and for the CCSDS folks who're building on it for their work. (And in case CCSDS people get process-scared, no, nothing will ever change the existing RFCs, so documents referring to them are unaffected.)

Cheers,
Stephen, Kevin, Joerg.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 May 2012 17:56:10 +0100

Hi Scott,

Interesting that this is sort of the opposite of the ideas
that we're working on in the newly-formed ICNRG, where
we want to name data and not nodes! But I think I agree
with you here - all of the DTN trials that I can think of
involved naming the nodes.

S

On 05/18/2012 05:50 PM, Burleigh, Scott C (313B) wrote:
> I will freely admit to a bias on this topic: I think the CBHE (and "ipn" scheme) notion of explicitly identifying nodes and services (i.e., demuxes) by numbers, expressing most endpoint IDs in terms of node and service numbers, and directly encoding those numeric EIDs as SDNVs in the primary block -- rather than carrying arbitrarily long ASCII strings in a dictionary array -- has been shown to work well, and I'd like to see that representation made standard in the Bundle Protocol rather than supported only as a convergence-layer adaptation.  I'm fully on board with retaining the expressive power of URIs for complex and interesting new destination EIDs (intentional naming, etc.), but the vast bulk of BP traffic now and in the foreseeable future doesn't need any of that power.  I believe we can, and should, optimize for the uninteresting, prevailing case of sending bundles directly to explicitly identified service points at explicitly identified nodes, and define one or more 
 destinati
on EID override extension blocks for the scenarios that need more complex endpoint IDs.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 May 2012 18:04:57 +0100

So, replying to my own mail, at least in part,
and not as chair,..

I'd think I'd like to see a rev of the BP that
includes the security stuff from day 1 as a
MUST implement, that gets rid of the dictionary
in favour of some kind of generic compression
(if IPR-free) and that also loses the absolute
time requirement. I think that'd be best done
as a new BP version that didn't have to be
backwards compatible with the 5050, and we'd
want to define a way for (some?) CLs to negotiate
versions of the BP to make sure that smooth
migration was possible.

I'd also like to see some bits of current
work finished (e.g CL RFCs), and also progression
of the BPQ work we've been doing and on
key management.

I'm sure there's more but those are my main
things for now.

S

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Fri, 18 May 2012 17:13:21 +0000

I agree with at least the first part of your list, Stephen, and probably the rest as well except that I haven't been following BPQ closely enough to comment.  I think the BABs, at least, should be MUST implement (so long as they can be turned off in deployment); I'm all for getting rid of the dictionary, and I'd propose CBHE as the generic compression that takes its place; and I think we've got to support aggregated bundle age as an alternative to authoritative bundle creation time for bundle expiration purposes.  And I think this does require a new version of BP.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, May 18, 2012 10:05 AM
To: Stephen Farrell
Cc: DTN interest
Subject: Re: [dtn-interest] RFC 5050 revision?

So, replying to my own mail, at least in part, and not as chair,..

I'd think I'd like to see a rev of the BP that includes the security stuff from day 1 as a MUST implement, that gets rid of the dictionary in favour of some kind of generic compression (if IPR-free) and that also loses the absolute time requirement. I think that'd be best done as a new BP version that didn't have to be backwards compatible with the 5050, and we'd want to define a way for (some?) CLs to negotiate versions of the BP to make sure that smooth migration was possible.

I'd also like to see some bits of current work finished (e.g CL RFCs), and also progression of the BPQ work we've been doing and on key management.

I'm sure there's more but those are my main things for now.

S

On 05/15/2012 09:01 PM, Stephen Farrell wrote:
> 
> Hi all,
> 
> As Joerg noted we're interested in whether or not, and if so how, 
> folks would like to do some work on an update or revision for RFC 
> 5050, or ideas for alternatives to the BP or additional DTN protocols.
> 
> In addition, we'd be interested in hearing whether folks would like to 
> explore doing DTN based not on a straight revision of the BP, but 
> maybe e.g. based on CoAP, SPDY, websockets, or other protocols.
> 
> At this point the goal is to gather and discuss ideas on the list, 
> with a view to seeing what's of interest to RG participants.
> 
> Later on, the question of who's actually willing to do stuff will get 
> more interesting, since that's how things get done - just saying that 
> it "must be so"
> Lastly, none of this means that there's anything wrong with RFC 5050 
> which has been great for both doing DTN experiments and for the CCSDS 
> folks who're building on it for their work. (And in case CCSDS people 
> get process-scared, no, nothing will ever change the existing RFCs, so 
> documents referring to them are unaffected.)
> 
> Cheers,
> Stephen, Kevin, Joerg.
>

---

From: <[email-masked]>
Date: Sun, 20 May 2012 09:30:05 +0100

> on CoAP, SPDY, websockets, or other protocols.

Since this group was set up to push and develop only the bundle protocol, the group will probably need to be rechartered to allow this. Non-bundle protocol work has been ignored previously.

To consider CoAP or SPDY or websockets in dtns, it is necessary to consider how HTTP - which CoAP, SPDY and websockets are based on - fits into dtns. And since HTTP assumes full path connectivity between the endpoints, and dtns don't have that, it's not as easy as one might think...

Fortunately, that consideration and mapping HTTP to dtns has already been thought out, and has been previously presented to the group:
http://sat-net.com/L.Wood/dtn/http-dtn
http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery

---

From: <[email-masked]>
Date: Sun, 20 May 2012 09:49:41 +0100

> MUST implement, 

No surprises there - the chairs of this group have always been very focused on security.

But many embedded systems don't need, want, or can afford the overheads and complexity of the BP security protocols, so mandating security will make the bundle protocol even less relevant to operational dtns than it is now. 

> that gets rid of the dictionary
> time requirement. 

The absolute time requirement has indeed prevented adoption of the BP.

However, mandating the security protocol may well need absolute time anyway... I imagine that uniquely identifying a bundle (or preventing replay attacks?) becomes less straightforward without timestamps.

> work finished (e.g CL RFCs),

since the TCP convergence layer draft expired in 2008, and 99+% of bundle transfers rely on the Internet (because TCP/IP is widely available and bundling's just built on top) and use the TCP convergence layer, getting that published would seem to be essential.

http://tools.ietf.org/html/draft-irtf-dtnrg-tcp-clayer-02

(Any reliability that the bundle protocol is perceived to have is probably due to its reliance on TCP. Mandating the security protocol forces a degree of reliability, but at a performance cost.)

> and also progression

Key management and revocation without absolute time could be... interesting.

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 20 May 2012 11:47:14 +0100

> Since this group was set up to push and develop only the bundle protocol, the group will probably need to be rechartered to allow this. Non-bundle protocol work has been ignored previously.

I don't think rechartering is a must-do, but I do agree that
if enough people want to do credible DTN work not associated
with the BP then we probably should update the charter text
so the very few people who read the charter [1] don't get
confused.

   [1] http://irtf.org/dtnrg

> http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery

I agree that if we seriously discuss non-BP things then HTTP
ought be considered.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 20 May 2012 11:59:22 +0100

On 05/20/2012 09:49 AM, [email-masked] wrote:
> No surprises there - the chairs of this group have always been very focused on security

Ah. I so missed that kind of thing;-)

> But many embedded systems don't need, want, or can afford the overheads and complexity of the BP security protocols, so mandating security will make the bundle protocol even less relevant to operat…

Sure, there's a discussion to be had there. IMO the BSP stuff
is too complex, but had to be since it was designed after the
fact. I think we could do better.

> However, mandating the security protocol may well need absolute time anyway... I imagine that uniquely identifying a bundle (or preventing replay attacks?) becomes less straightforward without time…

Yep. Didn't say all these changes were easy or trivial.

> Key management and revocation without absolute time could be... interesting.

Revocation with hard-fail hasn't been deployed by most Internet
applications. Could be that in DTNs its just not worth it - might
be better to try distribute new keys at whatever frequency you
could have done CRL-equivalents. But DTN key management is an
area that needs real research, I agree.

S.

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 30 May 2012 14:04:36 -0500

> so the very few people who read the charter [1] don't get

I think a recharter is necessary to encourage additional thinking in store-carry-and-forward techniques.  The first two paragraphs are more open thinking, but the following two propose a specific solution and appears rather restrictive.

http://irtf.org/dtnrg
"The group intends to build upon the extended “bundling” architecture created originally for the Interplanetary Internet. This architecture proposes an alternative to the Internet TCP/IP end-to-end model and employs hop-by-hop storage and retransmission as a transport-layer overlay. It provides a messaging service interface conceptually similar to electronic mail, but generalized for application-independence and supported by specialized reliability and routing capabilities.

The intended work products of the DTNRG include architectural descriptions (concept documents) a bundling protocol specification, and a series of one or more network-environment-specific “profile” documents. These profile documents will include descriptions of ‘convergence layers’ intended to adapt the overlying messaging architecture for use in specialized networking environments (space, water, sensor networks), and are expected to be created by the study teams described in the Membership section below. One study team output will be an “Internet profile” document, developed in concert with the architectural and protocol specification documents, giving suggested naming conventions and protocols to use for transport within the public Internet."

- Will

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 May 2012 23:23:54 +0100

Hi Will,

> I think a recharter is necessary to encourage additional thinking in store-carry-and-forward techniques.  The first two paragraphs are more open thinking, but the following two propose a specific s…

IRTF RG charters aren't meant to be restrictive like that.

I'd rather discuss what people want to do and then decide
if we want new charter text. (Note: want, not need:-)

S