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

John Zinky <jzinky@bbn.com> Tue, 04 December 2012 23:00 UTC

Return-Path: <jzinky@bbn.com>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC3F21F8BCD for <dtn-interest@ietfa.amsl.com>; Tue, 4 Dec 2012 15:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnDe28qw747P for <dtn-interest@ietfa.amsl.com>; Tue, 4 Dec 2012 15:00:30 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E706121F8BBF for <dtn-interest@irtf.org>; Tue, 4 Dec 2012 15:00:29 -0800 (PST)
Received: from apple.bbn.com ([128.89.72.183]:58596) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <jzinky@bbn.com>) id 1Tg1TZ-000Exq-9p; Tue, 04 Dec 2012 18:00:29 -0500
From: John Zinky <jzinky@bbn.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 04 Dec 2012 18:00:29 -0500
Message-Id: <0F5B3127-09CD-4FEA-9937-01D12DF71953@bbn.com>
To: "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: [dtn-interest] DTN architecture issues for handling Huge Content Objects
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <dtn-interest.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-interest>
List-Post: <mailto:dtn-interest@irtf.org>
List-Help: <mailto:dtn-interest-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 23:00:30 -0000

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. 

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

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. 

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

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.

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?"