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

John Zinky <jzinky@bbn.com> Thu, 06 December 2012 20:15 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 EC5A921F8A74 for <dtn-interest@ietfa.amsl.com>; Thu, 6 Dec 2012 12:15:58 -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 wOl+qC5Ac1xX for <dtn-interest@ietfa.amsl.com>; Thu, 6 Dec 2012 12:15:58 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CF41021F8A84 for <dtn-interest@irtf.org>; Thu, 6 Dec 2012 12:15:57 -0800 (PST)
Received: from apple.bbn.com ([128.89.72.183]:64128) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <jzinky@bbn.com>) id 1TghrP-000NNI-5G for dtn-interest@irtf.org; Thu, 06 Dec 2012 15:15:55 -0500
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Zinky <jzinky@bbn.com>
In-Reply-To: <A5BEAD028815CB40A32A5669CF737C3B0FA0F77F@ap-embx-sp40.RES.AD.JPL>
Date: Thu, 06 Dec 2012 15:15:55 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC504B2B-3965-4CCC-812E-5405BB47B721@bbn.com>
References: <A5BEAD028815CB40A32A5669CF737C3B0FA0F473@ap-embx-sp40.RES.AD.JPL> <CCE53432.D259%william.d.ivancic@nasa.gov> <A5BEAD028815CB40A32A5669CF737C3B0FA0F77F@ap-embx-sp40.RES.AD.JPL>
To: "dtn-interest@irtf.org" <dtn-interest@irtf.org>
X-Mailer: Apple Mail (2.1499)
Subject: Re: [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: Thu, 06 Dec 2012 20:15:59 -0000

A deployment context has an effective Maximum Transmission Unit (MTU), whether the limitation comes from a CLA (such as the UDP-Link CLA used on radio broadcast channels) or Contact time. If the source is somehow privy to this runtime constraint (MTU metadata), the Data Object can be divided into appropriate size bundles proactively. As with all QoS adaption the key is to dynamically identify the situation at runtime (effective MTU) and apply the appropriate mechanism (Fragmentation or Encoding). One size does not fit all.

The Eraser Coding draft and the DTN 2.9 implementation offers a different mechanism of reactive fragmentation.  Erasure Coding can be applied to a Big Bundle inside the BPA. The Big Bundle wire-format is treated as a Data Object, encoded by the source BPA,  the Encoding Bundles sent to a destination BPA that decodes the Big Bundle, and the destination reinserts the bundle into the DTN. The group of bundles acts like a tunnel to get the Big Bundle from one place in the DTN to another. The Destination can be chosen based on the runtime situation and does not have to be the same BPA as the destination EID. See Slide 9 in:
  https://dist-systems.bbn.com/papers/2011/Zinky/ErasureCodingExtBlockSpec-IRTF-2011-07-25-Rev1-2-2.pdf



On Dec 5, 2012, at 8:28 PM, "Fall, Kevin" <kfall@qti.qualcomm.com> wrote:

> The DTN fragmentation isn't intended for the same purposes as IP
> fragmentation. While IP fragmentation is about adapting an abstract datagram (IP datagram) to be carried on various underlying link layers, DTN fragmentation is about dividing a big thing into chunks appropriate to contacts (for proactive fragmentation) and to help in recovery for unexpected outages (for reactive).


On Dec 5, 2012, at 8:54 PM, "Burleigh, Scott C (313B)" <scott.c.burleigh@jpl.nasa.gov> wrote:

> But I'd argue that you can do just as well with proactive fragmentation within the network.  "Would be nice" implies that there is some value in retransmitting 3 MB instead of all 10 MB of the bundle.  How much value is that?  
...
> Okay, suppose your link is only 4800 bps.  Now the extra cost of not doing reactive fragmentation is 11,667 seconds of transmission -- unless you do proactive fragmentation at the time you start sending the bundle, i.e., you break off 600-byte fragments of the bundle one at a time and send them over the link.  Now when the link fails the cost of not doing reactive fragmentation is one entire bundle, 
...
> This is of course a topic on which we've been arguing for over a decade in DTNRG and I am confident that I haven't changed many minds here.  I just want to suggest that it's possible to engineer DTN to be relatively efficient over an opportunistic contact without jettisoning bundle authentication.