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

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

John, some comments in-line below.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of John Zinky
Sent: Tuesday, December 04, 2012 3:00 PM
To: [e-mail]
Subject: [dtn-interest] DTN architecture issues for handling Huge Content Objects

Kevin Fall says:
[The Erasure Coding] document really defines a new, different architecture that seems to use DTN as a sort of transport mechanism underneath yet it also seems to liberally make changes in a variety of bits and pieces of the existing structure, protocols and even architecture

I think the DTN architecture you are referring to is a DTN envisioned as a push model of content (payload) to destination (URI). Given delays and disruption, the DTN push is open loop (one-way) reducing reliance on end-to-end feedback. 

Erasure Coding embraces that architecture, but unfortunately Huge Content (multiple GBs) can not go into one bundle. So this may be the first use case where DTN must deal with the end-to-end transfer of GROUPS of bundles.

	>>>	Is this really true?  Payload size is an SDNV, and bundle fragmentation in DTN is pretty well defined; there's nothing in the spec to prevent you from sending a Huge Content item in a single bundle, then proactively fragmenting that bundle into N fragmentary bundles.  The fragments would then be forwarded to the destination endpoint, where their fragmentary payloads would be reassembled into the original Huge Content item for delivery.  In this sense, dealing with the end-to-end transfer of a group of related bundles has been covered by DTN for many years, right?

Dealing with End-to-End issues and multiple bundles is traditionally done by the transport, session, and presentation layers. But if you look at the Erasure Coding suite, it seems to cross cut this layered protocol model. See Slide 20 in:
  https://dist-systems.bbn.com/papers/2011/Zinky/ErasureCodingExtBlockSpec-IRTF-2011-07-25-Rev1-2-2.pdf

	>>>	But in DTN the bundle protocol handles all these issues.  There are some end-to-end issues, such as end-to-end acknowledgment, that must be handled at a layer above BP, but fragmentation and reassembly isn't one of them.

I would claim that all Quality of Service (QoS) management issues cross-cut the OSI layering model. Getting QoS into the TCP/IP stack has been hard because of the information hiding restrictions of a layered architecture. DTN by its very name is suppose to handle extreme QoS issues and in my opinion would benefit from a non-layered architecture.

	>>>	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.
 
What I mean is that the DTN extension blocks could be organized so that they do not form a nested layer of headers, but instead are open to multiple protocol aspects each of which can peak and poke into any extension block they choose.

	>>>	Sure, this is already the case.  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.

This architecture was proposed in:

Robert Braden, Ted Faber, and Mark Handley. 2003. From protocol stack to protocol heap: role-based architecture. SIGCOMM Computer. Comm. Rev. 33, 1 (January 2003), 17-22. DOI=10.1145/774763.774765 
  http://doi.acm.org/10.1145/774763.774765

And I used it successfully in the Cougaar Agent System Message transport. See section 4 of
  https://dist-systems.bbn.com/papers/2007/DOA/

I think your criticism of the EC suite is that it has to touch so many layers. But I think that is an opportunity, not a flaw. DTN actually has the chance of creating a different kind of protocol suite, one not based on layers, but based on composeable building blocks.

	>>>	And in fact it is already doing so.  Layering doesn't go away altogether: 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 at a different layer.  But anything that has to do with operating the network itself does indeed go into extension blocks rather than into additional layers.
 
Note, Erasure Coding needs to deal with several issues that overlap with other building blocks.
 1) grouping bundles (session)
 2) End-to-End transfer requirement (transport)
 3) Forwarding order (Handling specification)
 4) Object format (presentation)

Some of these feature where added to the single Erasure Coding extension block. But that extension block could be divided into multiple pieces if more a comprehensive approach was taken for designing a holistic DTN protocol suite.

For example, the handling spec should be pulled out into an extension block that specifically deals with choosing the order of which bundles to send to neighbors. But that is a topic for a different thread.

	>>>	But grouping of bundles is already handled by core BP (fragmentation and reassembly), and forwarding order is already handled by BP's class of service and the various routing mechanisms.  And does payload format actually have anything to do with erasure coding, or indeed with network operation at all?
	>>>	Incorporating erasure coding into an end-to-end transfer service may indeed make a lot of sense, but that is the one piece of the picture that really *should* be at a layer above BP.  It ought to be operating only at the ends, not at every bundle forwarding agent along the path.
	>>>	Given all of which, I don't see a strong argument for redesigning the Bundle Protocol.  What am I missing?

So the question for the community is:
"How should a DTN protocol suite be designed that can handle the wide range of Application with a wide range of QoS requirements?"

_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest