Subject: [dtn-interest] 5050bis

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 16 May 2013 07:56:16 -0500

While I think DTN RFC5050 needs a redo, I don't know if funds and energy
exist to do a very good job.

I don’t think a minor change is worth the trouble. If you are just using this for research it is probably still quite useful as is.  If you have thoughts of actually making useful and deployable on a large scale, I think there are some major changes that are required – See suggestions.

It may make more sense to let ICN work some of the naming issues and issues
related to securing information prior to any major changes to RFC5050.

Suggestions if you are seeking a widely deployable solution (these are in no particular order of preference or priority):

1) I highly doubt you need any time information in the protocol.
Rather just some course priorities like expedite immediately (real-time
stuff), expedite ASAP (fades), minutes, hours, days, clear this out when you
clean the basement or refrigerator otherwise pass it on if you get a chance.
That would solve a lot of problems. When I asked the question, nobody really
knew how to set bundle lifetimes per application.

See setting bundle lifetimes:

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

2) A flat namespace will not scale and makes route aggregation impossible (I think – at least really hard.)  The naming is overloaded as is and thus is causing problems.

3) Security is a mess for a number or reasons, but basically trying to do to much and getting to cleaver.  Keep is simple (encapsulate entire bundle).  We also need BT-Tables for resource management.

4) Don’t overload the protocol like trying to do ICN with DTN.  (see #3)

5) You probably should start with a problem statement and requirements document so that you can bound the problem.

Will Ivancic

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 16 May 2013 17:30:25 +0000

I think my 5050bis shopping list overlaps with Will's, but not completely:

*         On bundle security, I agree in part.  The basic mechanisms of BSP are fine; the problems arise (I think) when security and routing become intertwined in the same protocol, and I agree that bundle-in-bundle encapsulation is the key to disentangling them.  I am hoping we'll have some time at the IETF 87 meeting to talk about concrete proposals for doing this, including one I-D that has already been posted and another that I hope will be posted soon.

*         I'm not adamant on this, but I have come to agree with Lloyd that it would be good to have some sort of bundle integrity check that doesn't require distribution of keys.  Maybe a CRC on the primary block, plus an optional payload checksum in a post-payload extension block?

*         One thing on which I am still adamant: we need to recognize nodes as first-class entities in the DTN architecture.  Endpoints are so abstract as to be useless for most bundle processing purposes: an endpoint is a set of nodes, and we've got no definition anywhere of how a set can transmit a bundle, receive a bundle, validate a bundle, etc.  Endpoints are an excellent means of characterizing the destination of a bundle, and we've defined the manner in which an endpoint can be used in the delivery of a bundle's payload to an instance of some bundle application.  But we define everything else in BP, BSP, PRoPHET, etc. in terms of nodes.  For this purpose, we obviously need node IDs, so we have them and use them, sort of: we use the identifiers of endpoints to identify nodes.  But this doesn't make sense, because endpoints are not nodes.  We try to resolve this infelicity by using as the node identifier the ID of one of the endpoints (selected somehow) of which the node is the sole member.  It's an obvious kluge that bites us again and again, in document after document.  Nodes should be identified by node IDs, not by endpoint IDs.

*         That opens the question of what the namespace of node IDs would be.  I'm fine with using URIs for endpoint IDs, but I think node IDs should simply be positive integers.

*         In light of the last two points, I would like to use extension blocks to carry EIDs as necessary.  I think that, for a very large fraction of DTN traffic, the source, destination, report-to, and current custodian are simply identifiable port-like entities on identifiable nodes, all of which could be expressed as variable-length integers (SDNVs) in the primary block, as in CBHE.  Where this isn't the case, we can simply attach extension blocks containing URIs of whatever length and syntax are best suited to the purposes of the transmission.  This lets us remove the dictionary from the primary block, simplifying custody transfer, security, implementations, and probably more.

*         I disagree about removing time from the protocol - I've not yet heard an argument refuting the original rationale for expiring data on the basis of elapsed time - but I do think we need to add "bundle age" to the BP primary block in some way (and allow creation time to be zero), to accommodate environments where nodes' clocks will not be synchronized.

*         We might want to consider moving some of the Extended Class of Service mechanisms into the primary block, but I'm not wedded to this one.

A last point: I'm not at all convinced that current ICN research has got a better handle on naming and security than DTN does; I think naming data objects introduces new problems that DTN solved a decade ago, and I think an argument can be made that DTN is in fact quite a good way to do ICN.  But that's a topic for a different thread.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Thursday, May 16, 2013 5:56 AM
To: [email-masked]
Subject: [dtn-interest] 5050bis

I don't think a minor change is worth the trouble. If you are just using this for research it is probably still quite useful as is.  If you have thoughts of actually making useful and deployable on a large scale, I think there are some major changes that are required - See suggestions.

2) A flat namespace will not scale and makes route aggregation impossible (I think - at least really hard.)  The naming is overloaded as is and thus is causing problems.

4) Don't overload the protocol like trying to do ICN with DTN.  (see #3)

Will Ivancic

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 16 May 2013 13:48:46 -0400

- on the more "deployment/apps" side of things, I think there should be a better way to identify applications from the bundle point of view. I suggested one way during the Google DTN workshop, that did have a mix a traction /support and not support. I'm happy to look at alternatives, but I haven't seen any yet. We end up discussing a pretty complex generic scheme that would never be implemented, specially in embedded systems, which are pretty an important market for DTN. I'm happy to resurrect that work during the Berlin IETF or else.

Marc. 

Le 2013-05-16 à 13:30, "Burleigh, Scott C (313B)" <[email-masked]> a écrit :

> I think my 5050bis shopping list overlaps with Will’s, but not completely:
> ·         On bundle security, I agree in part.  The basic mechanisms of BSP are fine; the problems arise (I think) when security and routing become intertwined in the same protocol, and I agree that bundle-in-bundle encapsulation is the key to disentangling them.  I am hoping we’ll have some time at the IETF 87 meeting to talk about concrete proposals for doing this, including one I-D that has already been posted and another that I hope will be posted soon.
> ·         I’m not adamant on this, but I have come to agree with Lloyd that it would be good to have some sort of bundle integrity check that doesn’t require distribution of keys.  Maybe a CRC on the primary block, plus an optional payload checksum in a post-payload extension block?
> ·         One thing on which I am still adamant: we need to recognize nodes as first-class entities in the DTN architecture.  Endpoints are so abstract as to be useless for most bundle processing purposes: an endpoint is a set of nodes, and we’ve got no definition anywhere of how a set can transmit a bundle, receive a bundle, validate a bundle, etc.  Endpoints are an excellent means of characterizing the destination of a bundle, and we’ve defined the manner in which an endpoint can be used in the delivery of a bundle’s payload to an instance of some bundle application.  But we define everything else in BP, BSP, PRoPHET, etc. in terms of nodes.  For this purpose, we obviously need node IDs, so we have them and use them, sort of: we use the identifiers of endpoints to identify nodes.  But this doesn’t make sense, because endpoints are not nodes.  We try to resolve this infelicity by using as the node identifier the ID of one of the endpoints (selected somehow) of which the node is the sole member.  It’s an obvious kluge that bites us again and again, in document after document.  Nodes should be identified by node IDs, not by endpoint IDs.
> ·         That opens the question of what the namespace of node IDs would be.  I’m fine with using URIs for endpoint IDs, but I think node IDs should simply be positive integers.
> ·         In light of the last two points, I would like to use extension blocks to carry EIDs as necessary.  I think that, for a very large fraction of DTN traffic, the source, destination, report-to, and current custodian are simply identifiable port-like entities on identifiable nodes, all of which could be expressed as variable-length integers (SDNVs) in the primary block, as in CBHE.  Where this isn’t the case, we can simply attach extension blocks containing URIs of whatever length and syntax are best suited to the purposes of the transmission.  This lets us remove the dictionary from the primary block, simplifying custody transfer, security, implementations, and probably more.
> ·         I disagree about removing time from the protocol – I’ve not yet heard an argument refuting the original rationale for expiring data on the basis of elapsed time – but I do think we need to add “bundle age” to the BP primary block in some way (and allow creation time to be zero), to accommodate environments where nodes’ clocks will not be synchronized.
> ·         We might want to consider moving some of the Extended Class of Service mechanisms into the primary block, but I’m not wedded to this one.
>  
> A last point: I’m not at all convinced that current ICN research has got a better handle on naming and security than DTN does; I think naming data objects introduces new problems that DTN solved a decade ago, and I think an argument can be made that DTN is in fact quite a good way to do ICN.  But that’s a topic for a different thread.
>  
> Scott
>  
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 16 May 2013 13:53:00 -0500

Scott, you can expire bundle on time by expedite priority (EP) for lack of a better term at the moment.  So EP-0 is forwarded immediately or dropped whereas EP-3 would be held at a node for no longer than 1 minute and EP-4 would be held for no longer that 1 hour.

Sure, that means the bundle could stick around for a while in a multi-hop system, but... That probably won’t happen much – particularly if you have a hop count.

Recommendation is to add HOP COUNT to kill bundles in routing loops.

Users really don’t know how to set the bundle lifetime for applications.  What is the bundle lifetime of streaming media over DTN (assuming a connected system).  What is the bundle lifetime of a picture or video file or voice message?

Will

••••• ••••• • I disagree about removing time from the protocol – I’ve not yet heard an argument refuting the original rationale for expiring data on the basis of elapsed time – but I do think we need to add “bundle age” to the BP primary block in some way (and allow creation time to be zero), to accommodate environments where nodes’ clocks will not be synchronized.”

---

From: "Birrane, Edward J." <[email-masked]>
Date: Thu, 16 May 2013 14:59:10 -0400

If we are collecting shopping lists for a 5050bis...

- A within-the-bundle-unique identifier for extension blocks.  In cases where we have multiple blocks of the same type in a bundle and where we have extension blocks with dependencies on other extension blocks, we really need some mechanism for this association other than relative ordering.

-Ed

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Blanchet
Sent: Thursday, May 16, 2013 1:49 PM
To: [email-masked]
Subject: Re: [dtn-interest] 5050bis

Marc.

Le 2013-05-16 à 13:30, "Burleigh, Scott C (313B)" <[email-masked]<mailto:[email-masked]>> a écrit :

Scott

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Thursday, May 16, 2013 5:56 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn-interest] 5050bis

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

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 16 May 2013 19:40:12 +0000

Will, maybe I'm missing something, but it sounds like the expedite priorities you're proposing are just time-to-live - exactly like we've got now - except with less flexibility: instead of 4 billion different time-to-live options you'd only have four or five.  That might be worthwhile in terms of bandwidth savings, but it doesn't answer the question of how to decide on the lifetime of a picture or video file or voice message.  You still have to assert the bundle lifetime: is it 1 minute?  Is it 1 hour?

As you say, the problem is knowing how to set the bundle lifetime for applications.  The intent of the BP TTL mechanism is that you set the lifetime of the bundle to the earliest moment at which the delivery of that data item is no longer more important to you than reclaiming the storage space it occupies - it's not about preventing routing loops, it's about resource management.  And I agree that we don't yet have great rules of thumb for making these decisions, but that in itself doesn't invalidate the mechanism; it just means we need to give it some more thought.

Scott

From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]]
Sent: Thursday, May 16, 2013 11:53 AM
To: Burleigh, Scott C (313B); [email-masked]
Subject: Re: [dtn-interest] 5050bis

Sure, that means the bundle could stick around for a while in a multi-hop system, but... That probably won't happen much - particularly if you have a hop count.

Users really don't know how to set the bundle lifetime for applications.  What is the bundle lifetime of streaming media over DTN (assuming a connected system).  What is the bundle lifetime of a picture or video file or voice message?

Will

***** ***** * I disagree about removing time from the protocol - I've not yet heard an argument refuting the original rationale for expiring data on the basis of elapsed time - but I do think we need to add "bundle age" to the BP primary block in some way (and allow creation time to be zero), to accommodate environments where nodes' clocks will not be synchronized."

---

From: Dilip Krishnaswamy <[email-masked]>
Date: Thu, 16 May 2013 13:17:44 -0700

Depending on the type of traffic, we could specify different types of
QoS/delay tolerance requirements. For streaming RT traffic one could
specify stream prioritization classes or real-time latency/bandwidth
requirements. For highly delay tolerant NRT traffic, bundle lifetimes are
good to keep and use. It would be good to support both variants. Thanks.

-Dilip

On Thu, May 16, 2013 at 11:53 AM, Ivancic, William D. (GRC-RHN0) <
[email-masked]> wrote:

>  Scott, you can expire bundle on time by expedite priority (EP) for lack
> of a better term at the moment.  So EP-0 is forwarded immediately or
> dropped whereas EP-3 would be held at a node for no longer than 1 minute
> and EP-4 would be held for no longer that 1 hour.
>
> Sure, that means the bundle could stick around for a while in a multi-hop
> system, but... That probably won’t happen much – particularly if you have a
> hop count.
>
> Users really don’t know how to set the bundle lifetime for applications.
>  What is the bundle lifetime of streaming media over DTN (assuming a
> connected system).  What is the bundle lifetime of a picture or video file
> or voice message?
>
> Will
>
>
> Scott Wrote ” I disagree about removing time from the protocol – I’ve not
> yet heard an argument refuting the original rationale for expiring data on
> the basis of elapsed time – but I do think we need to add “bundle age” to
> the BP primary block in some way (and allow creation time to be zero), to
> accommodate environments where nodes’ clocks will not be synchronized.”
>
>

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 16 May 2013 15:28:19 -0500

Absolute time requires time sync and that presents problems with bundles from the past or bundles for the future and a bunch of potential DOS attacks plus lots of coding for all the variations when deciding resource management.

Maybe just get rid of absolute time and have everything use relative time.

You still need hop count for routing loops or you can kill a wireless link.  Hop count is independent of time.

-- Will

________________________________
From: "Burleigh, Scott C (JPL-313B)[Jet Propulsion Laboratory]" <[email-masked]>
Date: Thu, 16 May 2013 14:40:12 -0500
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [dtn-interest] 5050bis

Will, maybe I’m missing something, but it sounds like the expedite priorities you’re proposing are just time-to-live – exactly like we’ve got now – except with less flexibility: instead of 4 billion different time-to-live options you’d only have four or five.  That might be worthwhile in terms of bandwidth savings, but it doesn’t answer the question of how to decide on the lifetime of a picture or video file or voice message.  You still have to assert the bundle lifetime: is it 1 minute?  Is it 1 hour?

As you say, the problem is knowing how to set the bundle lifetime for applications.  The intent of the BP TTL mechanism is that you set the lifetime of the bundle to the earliest moment at which the delivery of that data item is no longer more important to you than reclaiming the storage space it occupies – it’s not about preventing routing loops, it’s about resource management.  And I agree that we don’t yet have great rules of thumb for making these decisions, but that in itself doesn’t invalidate the mechanism; it just means we need to give it some more thought.

Scott

Will

---

From: Joerg Ott <[email-masked]>
Date: Fri, 17 May 2013 10:08:30 +0300

Independent of the timing discussion, I believe that hop counts are
tremendously useful for many things, especially if we don't equate
DTN to only space communications.

Jörg

On 16.05.2013 21:53, Ivancic, William D. (GRC-RHN0) wrote:
> Sure, that means the bundle could stick around for a while in a
> multi-hop system, but... That probably won’t happen much – particularly
> if you have a hop count.
>
> connected system).  What is the bundle lifetime of a picture or video
> file or voice message?
>
> Will
>
>
> Scott Wrote ” I disagree about removing time from the protocol – I’ve
> not yet heard an argument refuting the original rationale for expiring
> data on the basis of elapsed time – but I do think we need to add
> “bundle age” to the BP primary block in some way (and allow creation
> time to be zero), to accommodate environments where nodes’ clocks will
> not be synchronized.”
>
>
>

---

From: Vint Cerf <[email-masked]>
Date: Fri, 17 May 2013 06:19:45 -0400

just one observation - in the Internet, BGP eventually forced us to provide
identifiers for autonomous systems and it may well be the case that the
same general line of reasoning supports scott's comment about node
identifiers.

vint

On Thu, May 16, 2013 at 1:30 PM, Burleigh, Scott C (313B) <
[email-masked]> wrote:

>  I think my 5050bis shopping list overlaps with Will’s, but not
> completely:****
>
> **·         **On bundle security, I agree in part.  The basic mechanisms
> of BSP are fine; the problems arise (I think) when security and routing
> become intertwined in the same protocol, and I agree that bundle-in-bundle
> encapsulation is the key to disentangling them.  I am hoping we’ll have
> some time at the IETF 87 meeting to talk about concrete proposals for doing
> this, including one I-D that has already been posted and another that I
> hope will be posted soon.****
>
> **·         **I’m not adamant on this, but I have come to agree with
> Lloyd that it would be good to have some sort of bundle integrity check
> that doesn’t require distribution of keys.  Maybe a CRC on the primary
> block, plus an optional payload checksum in a post-payload extension block?
> ****
>
> **·         **One thing on which I am still adamant: we need to recognize
> nodes as first-class entities in the DTN architecture.  Endpoints are so
> abstract as to be useless for most bundle processing purposes: an endpoint
> is a set of nodes, and we’ve got no definition anywhere of how a set can
> transmit a bundle, receive a bundle, validate a bundle, etc.  Endpoints are
> an excellent means of characterizing the destination of a bundle, and we’ve
> defined the manner in which an endpoint can be used in the delivery of a
> bundle’s payload to an instance of some bundle application.  But we define
> everything else in BP, BSP, PRoPHET, etc. in terms of nodes.  For this
> purpose, we obviously need node IDs, so we have them and use them, sort of:
> we use the identifiers of endpoints to identify nodes.  But this doesn’t
> make sense, because endpoints are not nodes.  We try to resolve this
> infelicity by using as the node identifier the ID of one of the endpoints
> (selected somehow) of which the node is the sole member.  It’s an obvious
> kluge that bites us again and again, in document after document.  Nodes
> should be identified by node IDs, not by endpoint IDs.****
>
> **·         **That opens the question of what the namespace of node IDs
> would be.  I’m fine with using URIs for endpoint IDs, but I think node IDs
> should simply be positive integers.****
>
> **·         **In light of the last two points, I would like to use
> extension blocks to carry EIDs as necessary.  I think that, for a very
> large fraction of DTN traffic, the source, destination, report-to, and
> current custodian are simply identifiable port-like entities on
> identifiable nodes, all of which could be expressed as variable-length
> integers (SDNVs) in the primary block, as in CBHE.  Where this isn’t the
> case, we can simply attach extension blocks containing URIs of whatever
> length and syntax are best suited to the purposes of the transmission.
> This lets us remove the dictionary from the primary block, simplifying
> custody transfer, security, implementations, and probably more.****
>
> **·         **I disagree about removing time from the protocol – I’ve not
> accommodate environments where nodes’ clocks will not be synchronized.****
>
> **·         **We might want to consider moving some of the Extended Class
> of Service mechanisms into the primary block, but I’m not wedded to this
> one.****
>
> ** **
>
> A last point: I’m not at all convinced that current ICN research has got a
> better handle on naming and security than DTN does; I think naming data
> objects introduces new problems that DTN solved a decade ago, and I think
> an argument can be made that DTN is in fact quite a good way to do ICN.
> But that’s a topic for a different thread.****
>
> ** **
>
> Scott****
>
> ** **
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *Ivancic, William D.
> (GRC-RHN0)
> *Sent:* Thursday, May 16, 2013 5:56 AM
> *To:* [email-masked]
> *Subject:* [dtn-interest] 5050bis****
>
> ** **
>
> I don’t think a minor change is worth the trouble. If you are just using
> this for research it is probably still quite useful as is.  If you have
> thoughts of actually making useful and deployable on a large scale, I think
> there are some major changes that are required – See suggestions.
>
> Suggestions if you are seeking a widely deployable solution (these are in
> no particular order of preference or priority):
>
> *http://www.dtnrg.org/wiki/DtnBone
>
> *2) A flat namespace will not scale and makes route aggregation
> impossible (I think – at least really hard.)  The naming is overloaded as
> is and thus is causing problems.
>
> 3) Security is a mess for a number or reasons, but basically trying to do
> to much and getting to cleaver.  Keep is simple (encapsulate entire
> bundle).  We also need BT-Tables for resource management.
>
> 5) You probably should start with a problem statement and requirements
> document so that you can bound the problem.
>
> Will Ivancic ****
>

---

From: Kevin Fall <[email-masked]>
Date: Fri, 17 May 2013 11:28:03 -0400

It sounds like we are at a point to reflect on some of the various
architectural decisions.

With respect to a few points below-

I'm not really so sure all is 'fine' with BGP, but nonetheless from my
point of view its really the area where policy intersects the basic
path selection that presents special problems.  Think "here is my
algorithm which I must tweak to things the algorithm doesn't really
want to do".

We've had the checksum debate quite a bit, and in terms of the
protocol's own meta-data it seems like there is agreement to have some
sort of check.  With respect to data, a different story.  I won't
state all the tradeoffs yet again, but recall UDP-lite where the
checksum is variable (i.e., you can cover the data parts you like).
That would be the obvious compromise point.  Some applications
(including those doing their own app layer error correction) really
don't care so much about the data bit correctness.

I think the node ID merits debate-- obviously Scott has some strong
feelings :).  But a couple of thoughts on it.  I also agree that I
don't think the ICN people have solved this issue, although its
probably looking at what is up there.  In addition, URIs aren't really
a name space... they are a structure for representing something from
what could be a variety of name spaces.  Last, trying to define a
'node' might not be trivial.  In a world in which multi-tenant systems
hold VMs with multiple instances of what we would have called 'nodes'
before, there may be subtleties.

At one point we discussed having most all the naming material in a
bundle be optional.  Yes, it might seem curious to have a bundle with
no sender or receiver or anything else mentioned, but there are
certain cases (private p2p links) where I suppose that could be
useful.  Also, FWIW, at least one of the ICN approaches lacks a sender
ID.

I think I'm with Scott on his last two points.

regards,
- K

On Fri, May 17, 2013 at 6:19 AM, Vint Cerf <[email-masked]> wrote:
> identifiers for autonomous systems and it may well be the case that the same
> general line of reasoning supports scott's comment about node identifiers.
>
> vint
>
>
>
> On Thu, May 16, 2013 at 1:30 PM, Burleigh, Scott C (313B)
> <[email-masked]> wrote:
>>
>> ·         On bundle security, I agree in part.  The basic mechanisms of
>> BSP are fine; the problems arise (I think) when security and routing become
>> intertwined in the same protocol, and I agree that bundle-in-bundle
>> encapsulation is the key to disentangling them.  I am hoping we’ll have some
>> time at the IETF 87 meeting to talk about concrete proposals for doing this,
>> including one I-D that has already been posted and another that I hope will
>> be posted soon.
>>
>> ·         I’m not adamant on this, but I have come to agree with Lloyd
>> that it would be good to have some sort of bundle integrity check that
>> doesn’t require distribution of keys.  Maybe a CRC on the primary block,
>> plus an optional payload checksum in a post-payload extension block?
>>
>> ·         One thing on which I am still adamant: we need to recognize
>> should be identified by node IDs, not by endpoint IDs.
>>
>> ·         That opens the question of what the namespace of node IDs would
>> be.  I’m fine with using URIs for endpoint IDs, but I think node IDs should
>> simply be positive integers.
>>
>> ·         In light of the last two points, I would like to use extension
>> blocks to carry EIDs as necessary.  I think that, for a very large fraction
>> of DTN traffic, the source, destination, report-to, and current custodian
>> are simply identifiable port-like entities on identifiable nodes, all of
>> which could be expressed as variable-length integers (SDNVs) in the primary
>> block, as in CBHE.  Where this isn’t the case, we can simply attach
>> extension blocks containing URIs of whatever length and syntax are best
>> suited to the purposes of the transmission.  This lets us remove the
>> dictionary from the primary block, simplifying custody transfer, security,
>> implementations, and probably more.
>>
>> ·         I disagree about removing time from the protocol – I’ve not yet
>> heard an argument refuting the original rationale for expiring data on the
>> basis of elapsed time – but I do think we need to add “bundle age” to the BP
>> primary block in some way (and allow creation time to be zero), to
>> accommodate environments where nodes’ clocks will not be synchronized.
>>
>> ·         We might want to consider moving some of the Extended Class of
>> Service mechanisms into the primary block, but I’m not wedded to this one.
>>
>>
>>
>> objects introduces new problems that DTN solved a decade ago, and I think an
>> argument can be made that DTN is in fact quite a good way to do ICN.  But
>> that’s a topic for a different thread.
>>
>>
>>
>> Scott
>>
>>
>>
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Ivancic, William D. (GRC-RHN0)
>> 2) A flat namespace will not scale and makes route aggregation impossible
>> (I think – at least really hard.)  The naming is overloaded as is and thus
>> is causing problems.
>>
>> to much and getting to cleaver.  Keep is simple (encapsulate entire bundle).
>> We also need BT-Tables for resource management.
>>

---

From: Kevin Fall <[email-masked]>
Date: Fri, 17 May 2013 11:38:16 -0400

The bundle lifetime is how long the data is useful to you when it is
in transit.  If you think it doesn't really have a known lifetime, you
can make it large.  I suppose I could imagine having an "I don't
really know" value.

In terms of hop counts, it is indeed useful to know sometimes how far
a message has gone along its path [something you don't get from IP
TTLs, unfortunately].  This could conceivably be used, for example, in
deciding what to toss if you have to toss messages.  But Joerg, what
else do you have in mind?

- Kevin

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 17 May 2013 11:12:30 -0500

The hop count if for miss-configured systems of perhaps poor routing
algorithms.  Assume you  have a wireless  link and all the sudden the bundle
is bouncing back and forth between A and B.  If I give the bundle 100 years
lifetime, it should take 100 years to die. And, if this is a high priority
packet, that may lock you out for 100 years.

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

> From: Kevin Fall <[email-masked]>
> Date: Fri, 17 May 2013 10:38:16 -0500
> To: Joerg Ott <[email-masked]>
> Cc: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>,
> "[email-masked]" <[email-masked]>
>>> multi-hop system, but... That probably won¹t happen much  particularly
>>> if you have a hop count.
>>> 
>>> Users really don¹t know how to set the bundle lifetime for applications.
>>> Scott Wrote ² I disagree about removing time from the protocol  I¹ve
>>> data on the basis of elapsed time  but I do think we need to add
>>> ³bundle age² to the BP primary block in some way (and allow creation
>>> time to be zero), to accommodate environments where nodes¹ clocks will
>>> not be synchronized.²
>>> 
>>> 
>>>

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Sat, 18 May 2013 20:00:58 +0000

Kevin, just one comment here: I think we actually already have a quite solid definition of "node", in section 3.1 of RFC5050, the 4th paragraph.  ION certainly supports the concurrent operation of any number of full-fledged BP nodes on a single machine (physical or virtual) and I believe DTN2 does as well.  That part of the problem doesn't trouble me too much.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin Fall
Sent: Friday, May 17, 2013 8:28 AM
To: Vint Cerf
Cc: Burleigh, Scott C (313B); [email-masked]
Subject: Re: [dtn-interest] 5050bis

It sounds like we are at a point to reflect on some of the various architectural decisions.

I'm not really so sure all is 'fine' with BGP, but nonetheless from my point of view its really the area where policy intersects the basic path selection that presents special problems.  Think "here is my algorithm which I must tweak to things the algorithm doesn't really want to do".

We've had the checksum debate quite a bit, and in terms of the protocol's own meta-data it seems like there is agreement to have some sort of check.  With respect to data, a different story.  I won't state all the tradeoffs yet again, but recall UDP-lite where the checksum is variable (i.e., you can cover the data parts you like).
That would be the obvious compromise point.  Some applications (including those doing their own app layer error correction) really don't care so much about the data bit correctness.

I think the node ID merits debate-- obviously Scott has some strong feelings :).  But a couple of thoughts on it.  I also agree that I don't think the ICN people have solved this issue, although its probably looking at what is up there.  In addition, URIs aren't really a name space... they are a structure for representing something from what could be a variety of name spaces.  Last, trying to define a 'node' might not be trivial.  In a world in which multi-tenant systems hold VMs with multiple instances of what we would have called 'nodes'
before, there may be subtleties.

At one point we discussed having most all the naming material in a bundle be optional.  Yes, it might seem curious to have a bundle with no sender or receiver or anything else mentioned, but there are certain cases (private p2p links) where I suppose that could be useful.  Also, FWIW, at least one of the ICN approaches lacks a sender ID.

regards,
- K

On Fri, May 17, 2013 at 6:19 AM, Vint Cerf <[email-masked]> wrote:
> just one observation - in the Internet, BGP eventually forced us to 
> provide identifiers for autonomous systems and it may well be the case 
> that the same general line of reasoning supports scott's comment about node identifiers.
>
> vint
>
>
>
>> *         On bundle security, I agree in part.  The basic mechanisms of
>> BSP are fine; the problems arise (I think) when security and routing 
>> become intertwined in the same protocol, and I agree that 
>> bundle-in-bundle encapsulation is the key to disentangling them.  I 
>> am hoping we'll have some time at the IETF 87 meeting to talk about 
>> concrete proposals for doing this, including one I-D that has already 
>> been posted and another that I hope will be posted soon.
>>
>> *         I'm not adamant on this, but I have come to agree with Lloyd
>> that it would be good to have some sort of bundle integrity check 
>> that doesn't require distribution of keys.  Maybe a CRC on the 
>> primary block, plus an optional payload checksum in a post-payload extension block?
>>
>> *         One thing on which I am still adamant: we need to recognize
>> nodes as first-class entities in the DTN architecture.  Endpoints are 
>> so abstract as to be useless for most bundle processing purposes: an 
>> endpoint is a set of nodes, and we've got no definition anywhere of 
>> how a set can transmit a bundle, receive a bundle, validate a bundle, 
>> etc.  Endpoints are an excellent means of characterizing the 
>> destination of a bundle, and we've defined the manner in which an 
>> endpoint can be used in the delivery of a bundle's payload to an 
>> instance of some bundle application.  But we define everything else 
>> in BP, BSP, PRoPHET, etc. in terms of nodes.  For this purpose, we obviously need node IDs, so we have them and use them, sort of:
>> we use the identifiers of endpoints to identify nodes.  But this 
>> doesn't make sense, because endpoints are not nodes.  We try to 
>> resolve this infelicity by using as the node identifier the ID of one 
>> of the endpoints (selected somehow) of which the node is the sole 
>> member.  It's an obvious kluge that bites us again and again, in 
>> document after document.  Nodes should be identified by node IDs, not by endpoint IDs.
>>
>> *         That opens the question of what the namespace of node IDs would
>> be.  I'm fine with using URIs for endpoint IDs, but I think node IDs 
>> should simply be positive integers.
>>
>> *         In light of the last two points, I would like to use extension
>> blocks to carry EIDs as necessary.  I think that, for a very large 
>> fraction of DTN traffic, the source, destination, report-to, and 
>> identifiable nodes, all of which could be expressed as 
>> variable-length integers (SDNVs) in the primary block, as in CBHE.  
>> Where this isn't the case, we can simply attach extension blocks 
>> containing URIs of whatever length and syntax are best suited to the 
>> purposes of the transmission.  This lets us remove the dictionary 
>> from the primary block, simplifying custody transfer, security, implementations, and probably more.
>>
>> *         I disagree about removing time from the protocol - I've not yet
>> heard an argument refuting the original rationale for expiring data 
>> on the basis of elapsed time - but I do think we need to add "bundle 
>> age" to the BP primary block in some way (and allow creation time to 
>> be zero), to accommodate environments where nodes' clocks will not be synchronized.
>>
>> *         We might want to consider moving some of the Extended Class of
>> Service mechanisms into the primary block, but I'm not wedded to this one.
>>
>>
>>
>> A last point: I'm not at all convinced that current ICN research has 
>> got a better handle on naming and security than DTN does; I think 
>> naming data objects introduces new problems that DTN solved a decade 
>> ago, and I think an argument can be made that DTN is in fact quite a 
>> good way to do ICN.  But that's a topic for a different thread.
>>
>>
>>
>> Scott
>>
>>
>>
>> While I think DTN RFC5050 needs a redo, I don't know if funds and 
>> energy exist to do a very good job.
>>
>> I don't think a minor change is worth the trouble. If you are just 
>> using this for research it is probably still quite useful as is.  If 
>> you have thoughts of actually making useful and deployable on a large 
>> scale, I think there are some major changes that are required - See suggestions.
>>
>> It may make more sense to let ICN work some of the naming issues and 
>> issues related to securing information prior to any major changes to 
>> RFC5050.
>>
>> Suggestions if you are seeking a widely deployable solution (these 
>> are in no particular order of preference or priority):
>>
>> Rather just some course priorities like expedite immediately 
>> (real-time stuff), expedite ASAP (fades), minutes, hours, days, clear 
>> this out when you clean the basement or refrigerator otherwise pass 
>> it on if you get a chance.
>> That would solve a lot of problems. When I asked the question, nobody 
>> really knew how to set bundle lifetimes per application.
>>
>> 2) A flat namespace will not scale and makes route aggregation 
>> impossible (I think - at least really hard.)  The naming is 
>> overloaded as is and thus is causing problems.
>>
>> 3) Security is a mess for a number or reasons, but basically trying 
>> to do to much and getting to cleaver.  Keep is simple (encapsulate entire bundle).
>> 5) You probably should start with a problem statement and 
>> requirements document so that you can bound the problem.
>>
>> Will Ivancic
>>
>>

---

From: Joerg Ott <[email-masked]>
Date: Sun, 19 May 2013 22:15:21 +0300

I was thinking about limiting the reach of bundles when using multi-copy
routing such as epidemic or prophet.  And having inherent support for
expanding ring searches would be nice, too.

Jörg

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 May 2013 08:34:55 +0200

Le 2013-05-18 22:00, Burleigh, Scott C (313B) a écrit :
> ION certainly supports the concurrent operation of any
> number of full-fledged BP nodes on a single machine (physical or
> virtual) and I believe DTN2 does as well.

Postellation too.

> That part of the problem doesn't trouble me too much.

Me neither. And it would make things easier from an implementation point 
of view.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Scott, Keith L." <[email-masked]>
Date: Tue, 28 May 2013 14:10:05 +0000

I wonder if a 'unique identifier' (finer-grained than the current bundleID) could be used to support reliable multicast.  The notion would be that each copy of a custodially-held bundle forwarded over multiple outbound links would get a unique id (maybe added by the current custodian before forwarding).  These might be part of a revised 'current custodian' marking and could then be used to acknowledge individual copies.

                        --keith

From: [email-masked] [mailto:[email-masked]] On Behalf Of Birrane, Edward J.
Sent: Thursday, May 16, 2013 2:59 PM
To: [email-masked]
Subject: Re: [dtn-interest] 5050bis

-Ed

---
Ed Birrane

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Marc Blanchet
Sent: Thursday, May 16, 2013 1:49 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] 5050bis

Marc.

Scott

Will Ivancic