Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Fri, 7 Dec 2012 01:50:27 +0000

We may diverge a little bit on this, John.  I am a big fan of the layer-free extension of BP (and, to a lesser extent, LTP) that we can do in DTN, but I think there's still a place for layering.  In my earlier email I suggested that anything that has to do with operating the BP network itself belongs in extension blocks rather than in additional layers -- but that there are still application protocols that shouldn't be made part of BP, so they're at a different layer, and there are still underlying transport protocols that shouldn't be made part of BP, so they're also at a different layer.  The new application services we're looking at in DTPC seem to me to belong at an application layer above BP, not within BP itself.

The analogy with TCP/IP is actually pretty close, I believe.  BP's functions need to be invoked at every forwarding agent along the end-to-end path, just like the IP functions.  But DTPC's functions are end-to-end only; they need to be invoked at the source and destination and nowhere else, just like the functions of TCP.

That is, there's a sort of topological isomorphism that I find myself using in thinking about when it makes sense to layer and when it doesn't.

Suppose we've got a chain of four nodes, A->B->C->D and we're sending a bundle from A to D.  Bundle protocol itself needs to operate at all four nodes: receiving the bundle, storing it, computing the route to forward it on, and forwarding it to the next node along that route.  We also want operator-specified class of service to be honored at every forwarding point, so something like ECOS belongs inside BP as an extension.  The metadata that describes the bundle might be consulted in route computation, so it too operates at every node and therefore belongs inside BP as an extension.  And so on.

But the link between A and B is a space link, reinforced by LTP, while the B->C link is DCCP/UDP and the C->D link is TCP.  Since LTP runs only between nodes A and B it shouldn't be a BP extension; it belongs at the underlying convergence layer.  And other functionality that applies only in pairwise fashion between two neighboring nodes in the network belongs at that layer too, such as retransmission timeout interval computation that needs to be done in entirely different ways on different segments of the end-to-end path.

The functions that are included in DTPC are things like end-to-end acknowledgment, end-to-end retransmission, resequencing received data into transmission order, that can only be done at the source and the destination.  They're not functions that need to operate at all four nodes, so they don't belong inside BP as extensions.  These are functions that operate on a common topology, but it's not the topology that functions like route computation and class of service operate at -- it's the A<->D topology, not the A->B->C->D topology.  They belong at a different layer.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Zinky
Sent: Thursday, December 06, 2012 2:30 PM
To: [email-masked]
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

Scott,
I hope that your new application services will put their headers as extension blocks and not layer them inside the bundle payload. I was really encouraged by your previous posts about non-layered protocols!

On Dec 6, 2012, at 3:46 PM, "Burleigh, Scott C (313B)" <[email-masked]> wrote:

> It would be a standardized application service layer -- similar to a transport layer -- running immediately above BP.

On Dec 5, 2012, at 1:53 PM, "Burleigh, Scott C (313B)" <[email-masked]> wrote:

> Which it already has, to some extent, because additional features such as QoS are added in extension blocks (e.g., BSP and Extended Class of Service) rather than in additional layers.

> The only DTN extension blocks that can be said to nest are the BSP extensions, and I there's a strong argument for removing that nesting as well.
_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: <[email-masked]>
Date: Fri, 7 Dec 2012 06:32:51 +0000

Good to see the BP's lack of recognition of end-to-end considderation being addressed - even if it takes a higher layer to do it.

"functionality that applies only in pairwise fashion between two neighboring nodes in the network belongs at that layer too"

Question: with adding a higher layer, why bother with security in the bundle protocol? Implement end-to-end payload encryption in DTCP, you're done. That would greatly simplify bundling implementations across the network.

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

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Burleigh, Scott C (313B) [[email-masked]]
Sent: 07 December 2012 01:50
To: John Zinky; [email-masked]
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Zinky
Sent: Thursday, December 06, 2012 2:30 PM
To: [email-masked]
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

Scott,

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 7 Dec 2012 08:53:21 -0600

IMHO, protecting the content is not the responsibility of the Bundle Agent
but rather the user or application.  Think of email.  Email is encrypted by
the user, not the IP layer.

On the other hand, I would like to authenticate the source of the bundle,
because I am not going to let just anyone use my resources (battery,
storage, bandwidth, etc...).  IMHO, this is the major issue in deploying
Store, Carry, and Forwarding distributed applications across domains owned
and operated by various entities.  It is not an issue if you own the entire
network (Military, US Space).  But, if you want to move across domains, the
agreement to share some amount of resource is of major importance.

- Will

On 12/7/12 1:32 AM, "[email-masked]" <[email-masked]> wrote:

> Good to see the BP's lack of recognition of end-to-end considderation being
> addressed - even if it takes a higher layer to do it.
> 
> "functionality that applies only in pairwise fashion between two neighboring
> nodes in the network belongs at that layer too"
> 
> Question: with adding a higher layer, why bother with security in the bundle
> protocol? Implement end-to-end payload encryption in DTCP, you're done. That
> would greatly simplify bundling implementations across the network.
> 
> Lloyd Wood
> From: [email-masked] [[email-masked]] On Behalf
> Of Burleigh, Scott C (313B) [[email-masked]]
> We may diverge a little bit on this, John.  I am a big fan of the layer-free
> extension of BP (and, to a lesser extent, LTP) that we can do in DTN, but I
> think there's still a place for layering.  In my earlier email I suggested
> that anything that has to do with operating the BP network itself belongs in
> extension blocks rather than in additional layers -- but that there are still
> application protocols that shouldn't be made part of BP, so they're at a
> different layer, and there are still underlying transport protocols that
> shouldn't be made part of BP, so they're also at a different layer.  The new
> application services we're looking at in DTPC seem to me to belong at an
> application layer above BP, not within BP itself.
> 
> The analogy with TCP/IP is actually pretty close, I believe.  BP's functions
> need to be invoked at every forwarding agent along the end-to-end path, just
> like the IP functions.  But DTPC's functions are end-to-end only; they need to
> be invoked at the source and destination and nowhere else, just like the
> functions of TCP.
> 
> That is, there's a sort of topological isomorphism that I find myself using in
> thinking about when it makes sense to layer and when it doesn't.
> 
> Suppose we've got a chain of four nodes, A->B->C->D and we're sending a bundle
> from A to D.  Bundle protocol itself needs to operate at all four nodes:
> receiving the bundle, storing it, computing the route to forward it on, and
> forwarding it to the next node along that route.  We also want
> operator-specified class of service to be honored at every forwarding point,
> so something like ECOS belongs inside BP as an extension.  The metadata that
> describes the bundle might be consulted in route computation, so it too
> operates at every node and therefore belongs inside BP as an extension.  And
> so on.
> 
> But the link between A and B is a space link, reinforced by LTP, while the
> B->C link is DCCP/UDP and the C->D link is TCP.  Since LTP runs only between
> nodes A and B it shouldn't be a BP extension; it belongs at the underlying
> convergence layer.  And other functionality that applies only in pairwise
> fashion between two neighboring nodes in the network belongs at that layer
> too, such as retransmission timeout interval computation that needs to be done
> in entirely different ways on different segments of the end-to-end path.
> 
> The functions that are included in DTPC are things like end-to-end
> acknowledgment, end-to-end retransmission, resequencing received data into
> transmission order, that can only be done at the source and the destination.
> They're not functions that need to operate at all four nodes, so they don't
> belong inside BP as extensions.  These are functions that operate on a common
> topology, but it's not the topology that functions like route computation and
> class of service operate at -- it's the A<->D topology, not the A->B->C->D
> topology.  They belong at a different layer.
> 
> Scott
> 
> I hope that your new application services will put their headers as extension
> blocks and not layer them inside the bundle payload. I was really encouraged
> by your previous posts about non-layered protocols!
> 
>> It would be a standardized application service layer -- similar to a
>> transport layer -- running immediately above BP.
> 
>> Which it already has, to some extent, because additional features such as QoS
>> are added in extension blocks (e.g., BSP and Extended Class of Service)
>> rather than in additional layers.
> 
>> The only DTN extension blocks that can be said to nest are the BSP
>> extensions, and I there's a strong argument for removing that nesting as
>> well.

******************************
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: Stephen Farrell <[email-masked]>
Date: Fri, 07 Dec 2012 14:58:50 +0000

> the user, not the IP layer.

S/MIME and PGP do that for email. DKIM adds and verifies signatures
at MTAs, though for different reasons.

But I agree that BSP has some value, is not a panacea, and
ought be re-designed if/when we do a 5050 bis.

S.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Fri, 7 Dec 2012 17:23:22 +0000

It's a fair question, Lloyd.  As I was writing that email I was thinking to myself that bundle authentication really belonged at the convergence layer rather than in BP, because it likewise applies only in pairwise fashion between neighboring nodes.

Strictly speaking, I think one could argue that all of the BSP mechanisms belong either at a "common application service" layer above BP (PCB, PIB, ESB) or at the convergence layer below BP (BAB).  Carrying them in BP is what we might have called a "layer violation" in olden days.

At the same time, I think a strong case can be made that BP is the right place for the BSP machinery after all, despite what I might claim to be a topological dissonance.  End-to-end payload security is very likely to be required for a broad range of applications; neighbor authentication is very likely to be required for all possible convergence-layer protocols.  Using BP extension blocks to carry the information needed for these services saves us the trouble of implementing these mechanisms individually, over and over again, for every application and every underlying protocol.

That is, the stability and economy of abstracting this stuff and carrying it in just one place trumps the "correctness" of leaving it to the layers where it theoretically belongs.  Sure, we could provide a common application service layer -- DTPC, for example -- that does end-to-end payload security for all applications, and maybe a common convergence-layer wrapper layer that does neighbor authentication for all underlying transport protocols.  But that would force all applications to use DTPC even if they didn't need payload security (or else be configured to select different APIs depending on whether payload security was needed or not), and it would require extra complexity in BP to deal with configurations where the convergence-layer wrapper either would or wouldn't be used.  There would be no simplification of code and no increase in efficiency -- if anything, the reverse -- all with no substantial benefit to show for it, that I can think of.

So the general principle of extending BP rather than adding layers even when it's a "layer violation" does seem to me to make sense in at least this one case.  And it might make sense in other cases too.  I'm not yet convinced that end-to-end erasure coding is a capability that will be so essential to delay-tolerant networking that it needs to be a BP extension, but that seems like a reasonable conversation to have.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 06, 2012 10:33 PM
To: Burleigh, Scott C (313B); [email-masked]; [email-masked]
Subject: RE: [dtn-interest] DTN architecture issues for handling Huge Content Objects

Lloyd Wood

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Zinky
Sent: Thursday, December 06, 2012 2:30 PM
To: [email-masked]
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

Scott,

---

From: Eric Travis <[email-masked]>
Date: Fri, 7 Dec 2012 16:33:28 -0500

Will,

If you could clarify - where do you believe the responsibility (and more
importantly, the mechanisms) reside to authenticate the source of the
bundle? (And by "source", do you mean what is in the bundle header or the
node that is currently attempting to hand-off the bundle to you?)

The protection of the local *resources* supporting bundle operation is
*not* the responsibility of the bundle protocol.  Replace "bundle protocol"
with another comparable DTN protocol and it still applies.

The issue of resource allocation is a separate area (and to me), far more
complex one.  Peering agreements between mythical bundle operators would
likely be interesting...  Even within a single operational network, the
service policies are likely to vary on a node-by-node basis - the well
connected bundle nodes having a differing demands on local resources than
the more sparsely connected nodes.

Eric

> agreement to share some amount of resource is of major importance.

On Fri, Dec 7, 2012 at 9:53 AM, Ivancic, William D. (GRC-RHN0) <
[email-masked]> wrote:

> > Subject: Re: [dtn-interest] DTN architecture issues for handling Huge
> Content
> > Objects
> >
> > From: [email-masked] [mailto:
> [email-masked]] On
> > Behalf Of John Zinky
> > Subject: Re: [dtn-interest] DTN architecture issues for handling Huge
> Content
> > Objects
> >
> > Scott,

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 7 Dec 2012 16:16:59 -0600

From: Eric Travis <[email-masked]>
Date: Fri, 7 Dec 2012 15:33:28 -0600
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

Will,

If you could clarify - where do you believe the responsibility (and more importantly, the mechanisms) reside to authenticate the source of the bundle? (And by "source", do you mean what is in the bundle header or the node that is currently attempting to hand-off the bundle to you?)

What is in the Bundle Header, What entity sourced the data?  That is why something like BBNs idea of adding FEC in the middle will likely not work in resource protected system.  Multi-hop  store and forward systems are different than connected systems.  One should have the capability to protect your resources.

The protection of the local *resources* supporting bundle operation is *not* the responsibility of the bundle protocol.  Replace "bundle protocol" with another comparable DTN protocol and it still applies.

It is the responsibility of the policy engine that resides that must make a determination on what resources are allocated and how.  Failure to do so opens up the system for very simple and effective DOS attacks.  I simply deplete your resources.

The issue of resource allocation is a separate area (and to me), far more complex one.  Peering agreements between mythical bundle operators would likely be interesting...  Even within a single operational network, the service policies are likely to vary on a node-by-node basis - the well connected bundle nodes having a differing demands on local resources than the more sparsely connected nodes.

Yes indeed. But not really a separate issue.  Failure to recognize and address this up front is the same old story.  Adding security as an afterthought tends to no work very well.  Lots of things break.

Think of this as a firewall.  Storage systems on wireless platforms are a much different beast than a router in a connected network.  The latter has short-term storage for buffering.  The former can store information for a long long time and also has to receive and transmit, both which use power.

- Will

> agreement to share some amount of resource is of major importance.

On Fri, Dec 7, 2012 at 9:53 AM, Ivancic, William D. (GRC-RHN0) <[email-masked]> wrote:
IMHO, protecting the content is not the responsibility of the Bundle Agent
but rather the user or application.  Think of email.  Email is encrypted by
the user, not the IP layer.

- Will

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

---

From: Eric Travis <[email-masked]>
Date: Sat, 8 Dec 2012 01:44:09 -0500

Will,

I think you might have misinterpreted my query as "why" rather than the
intended "how"...

> * If you could clarify - where do you believe the responsibility (and
> more importantly, the mechanisms) reside to authenticate the source of the
> *
> What is in the Bundle Header, What entity sourced the data?  That is why
> something like BBNs idea of adding FEC in the middle will likely not work
> in resource protected system.  Multi-hop  store and forward systems are
> different than connected systems.  One should have the capability to
> protect your resources.
>

My intent was not to question the need/value of protecting the resources, I
was merely wondering *how* you wanted to achieve that in a bundle-protocol
based DTN.  I'm not seeing how to authenticate the bundle source in a
timely manner within environments that do necessarily provide timely
communications.

The "timely" is important because you will be storing the bundle at least
as long as it takes to authenticate the bundle source...

My understanding was/is that the intent is to the authenticate at every
intermediate node, I ruled out something involving "pre-shared secrets",
key-management systems or certificate authorities - hence my curiosity in
how to do this.  It's a really cool problem.

If the intent was to accept bundles only from trusted/authenticated
neighbors then I believe I can understand the intended approach.

*
> *
>>
>> * The protection of the local *resources* supporting bundle operation is
>> with another comparable DTN protocol and it still applies.*
>>
> *
> *

It is the responsibility of the policy engine that resides that must make a
> determination on what resources are allocated and how.  Failure to do so
> opens up the system for very simple and effective DOS attacks.  I simply
> deplete your resources.
>
>
Again, no disagreement in principle, but *that* policy engine is *not*
something to be made integral to the bundle protocol - it is something that
is exercised *prior* to submitting something to the bundle protocol
handling - or even better, prior to committing resources to receiving the
bundle.

This seems like functionality that is best placed in the CLA...

*

*
>
> * The issue of resource allocation is a separate area (and to me), far
> more complex one.  Peering agreements between mythical bundle operators
> would likely be interesting...  Even within a single operational network,
> the service policies are likely to vary on a node-by-node basis - the well
> the more sparsely connected nodes.*
>
*
*

Yes indeed. But not really a separate issue.  Failure to recognize and
> address this up front is the same old story.  Adding security as an
> afterthought tends to no work very well.  Lots of things break.
>

OK - I can see your reasoning behind the coupling and you are preaching to
the faithful regarding security.  But the role that the bundle protocol
should play in securing the system is limited to ensuring the integrity of
the bundles.  Securing the resources of the nodes hosting the bundle
protocol belongs to some other component of the system.

Think of this as a firewall.  Storage systems on wireless platforms are a
> much different beast than a router in a connected network.  The latter has
> short-term storage for buffering.  The former can store information for a
> long long time and also has to receive and transmit, both which use power.
>

I see the reasoning to be absolutely consistent with the deployment of a
firewall.  A firewall exercises policies prior to the protocol processing.

---

From: jzinky <[email-masked]>
Date: Sun, 9 Dec 2012 12:08:34 -0500

Scott, 
To paraphrase, you see only a few layers based on physical constraints.
  1) A Link Layer  between one-hop neighbors
  2) Transfer Layer that deals with multiple hops between nodes
  3) Application Layer dealing with sharing content.
My past work with situated distributed agent systems has a similar decomposition, Links, Transfer, and Agents, so I sort of agree with this partitioning. 

The DTN CLA links seems pretty strait forward, since it is completely below 5050, and is really a concern in how the BPAs are implemented. DTNs actually can have a wide variety of links, such as wired point to point, broad cast radio, long delay, intermittent, one way, data mule, and the good old reliable Internet. Just characterizing the properties of the possible links is a daunting task. But limiting the interaction between a group of neighbors seems to be a good architectural division

Since applications really are the consumer of the DTNs ability to move content from one physical location to another, the question to ask is what services do the applications desire?  liveness, checkpointing, translation, coordination?

The DTN is inherently distributed and bound the the physical world, where the applications are not. So maybe the DTN's role is to abstract those characteristics away for the applications. This is especially true in a DTN where the application can not actively measure the characteristics of the DTN, because by the time active measurement are made, the situation they are measuring has passed.  

This not-practical-to-measure-externally property implies a rich DTN to Application API, because the DTN internal gyrations may be the only opportunity to effectively observe the physical world. I would like DTNs to implement some "objective coordination" services, where the DTN helps with coordination outside the applications. As opposed to a "subjective coordination" model whereby the application directly observes behavior of the network  and form their own policies of communication. In the agent parlance, stigmergy is a kind of coordination where agents only affect their local environment and interactions with other agents happen  only indirectly from observations of the environment, for example ant-trails and traffic lights. 

One could imagine a DTN, where the content was stored in the network, and applications never interact with each other, but only with the DTN to extract that content. In this case, 5050 with non-layer extension blocks would be an adequate format for transferring content between locations and applications registering their desires. In this case, the DTN would be using Erasure Coding as one internal mechanism for overcoming physical constraints. The Erasure Coding would be over multiple hops, so not in the Link Layer, and the applications would not know it was used, so in this case Erasure Coding falls completely in to transfer layer.

> The functions that are included in DTPC are things like end-to-end acknowledgment, end-to-end retransmission, resequencing received data into transmission order, that can only be done at the source…
\

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 12 Dec 2012 08:00:48 -0600

Sorry to not get back to you sooner.  Comments in line.

- Will

________________________________

Will,

Source is the originator of the data.

I sort of agree. But the mechanism must be there to allow one to authenticate the source in order to protect the system resources because the source is indirectly requesting to use those resources.  The way the RFC5050 and BSP are design, that task is difficult because one has to receive and entire bundle in order to authenticate.  For small bundles, this is not an issue, but for large bundles, it can be.

Yes.  Agree completely.

Eric

- Will