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

["Burleigh, Scott C (313B)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, December 06, 2012 10:33 PM
To: Burleigh, Scott C (313B); [e-mail]; [e-mail]
Subject: RE: [dtn-interest] DTN architecture issues for handling Huge Content Objects

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: [e-mail] [[e-mail]] On Behalf Of Burleigh, Scott C (313B) [[e-mail]]
Sent: 07 December 2012 01:50
To: John Zinky; [e-mail]
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

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: [e-mail] [mailto:[e-mail]] On Behalf Of John Zinky
Sent: Thursday, December 06, 2012 2:30 PM
To: [e-mail]
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)" <[e-mail]> 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)" <[e-mail]> 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
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest
_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest