Re: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

John Zinky <jzinky@bbn.com> Fri, 07 September 2012 20:28 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 9532821F8444 for <dtn-interest@ietfa.amsl.com>; Fri, 7 Sep 2012 13:28:52 -0700 (PDT)
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 8QQ8vFpYh5iZ for <dtn-interest@ietfa.amsl.com>; Fri, 7 Sep 2012 13:28:51 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D9E4C21F8442 for <dtn-interest@irtf.org>; Fri, 7 Sep 2012 13:28:51 -0700 (PDT)
Received: from apple.bbn.com ([128.89.72.183]:62996) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <jzinky@bbn.com>) id 1TA5AG-0004KR-Sv; Fri, 07 Sep 2012 16:28:32 -0400
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="iso-8859-1"
From: John Zinky <jzinky@bbn.com>
In-Reply-To: <1346961915.39088.YahooMailNeo@web142502.mail.bf1.yahoo.com>
Date: Fri, 07 Sep 2012 16:28:32 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2732026A-2571-4DFE-9574-2855301989B9@bbn.com>
References: <85614F8C-DE13-46DB-A0A7-76A0407EABB5@bbn.com> <A5BEAD028815CB40A32A5669CF737C3B0D8873@ap-embx-sp20.RES.AD.JPL> <1346961915.39088.YahooMailNeo@web142502.mail.bf1.yahoo.com>
To: dtn-interest@irtf.org
X-Mailer: Apple Mail (2.1278)
Subject: Re: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.
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: Fri, 07 Sep 2012 20:28:52 -0000

Jay, 
Thanks for the reference to your paper.

Some notes to tease out distinctions.
1) If I understand your paper, FEC is used hop-by-hop at the CLA/link layer to protect the integrity of a single bundle.
The Eraser-Coding extension is designed for the end-to-end transfer of a large data object, so it handles the reliable transfer of a GROUP of bundles that represent one data object.

2) I am glad that your QoS model includes the concepts of Urgency (Immediacy) and Importance (Intrinsic Value).
DTN has good support (relative to IP) for Urgency, with its fine grain notion of lifetime.
But the use of priority class is lacking, because there is no specification for trading off High Urgency Low Importance bundles against Low Urgency High Importance bundles. 

3) An extension of your work would be how to handle groups of bundles. 
The current DTN 5050 specification does not have a way of marking bundles that are part of the same group, stream, or flow.
The Handling Specification would define how to handle bundles within the same group and between groups.
As one can see from your paper FEC is one knob for the Handling Spec, it is not the only knob. 
For example, maybe the FEC Handling Specification should be pulled out into a separate extension block.

On Sep 6, 2012, at 4:05 PM, Jayram Déshpandé wrote:

> Hello,
> 
> Here's a Master's thesis work[1] that explores the End to End QoS aspects of Delay and Disruption tolerant networking scenarios where bundles are transmitted across multiple (deep space or otherwise ) hops. 
> 
> The efforts were focused towards optimizing immediate next hop link resource (typically bandwidth ) by minimizing the amount of FEC applied to a given bundle based upon how critical the bundle is. In simplest scenario high priority bundles are heavily encoded while low priority bundles are not encoded at all. 
> 
> The work goes a step further to find optimal FEC to be applied by taking into consideration the end to end link characteristics. As in D (Delay )TN environments this information may be stale and/or completely out of date, it tries to find appropriate correction factor.
>  
> 
> We defined an experimental QoS Extension Bundle header to transport some of these parameters on the way to destination.
> 
> Regards,
> -Jay.
> 
> [1] http://etd.ohiolink.edu/view.cgi?acc_num=ohiou1163644692
>