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

[jzinky <[e-mail]>]

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.

 
On Dec 6, 2012, at 8:50 PM, Burleigh, Scott C (313B) wrote:

> 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.
\