Re: [dtn-interest] Question

Dai Stanton <dstanton@keltik.co.uk> Mon, 28 January 2013 19:09 UTC

Return-Path: <dstanton@keltik.co.uk>
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 05A3821F870E for <dtn-interest@ietfa.amsl.com>; Mon, 28 Jan 2013 11:09:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 puXcqvIrRX5P for <dtn-interest@ietfa.amsl.com>; Mon, 28 Jan 2013 11:09:37 -0800 (PST)
Received: from plesk.aquiss.net (plesk.aquiss.net [87.239.16.151]) by ietfa.amsl.com (Postfix) with ESMTP id 281C521F85E0 for <dtn-interest@irtf.org>; Mon, 28 Jan 2013 11:09:29 -0800 (PST)
Received: (qmail 29512 invoked from network); 28 Jan 2013 19:09:28 +0000
Received: from cpc23-nmal17-2-0-cust168.croy.cable.virginmedia.com (HELO ?192.168.1.103?) (77.96.104.169) by plesk.aquiss.net with (AES128-SHA encrypted) SMTP; 28 Jan 2013 19:09:28 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_D1C036BB-515B-4F06-A548-F81449A8D07A"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Dai Stanton <dstanton@keltik.co.uk>
In-Reply-To: <A5BEAD028815CB40A32A5669CF737C3B235749F7@ap-embx-sp40.RES.AD.JPL>
Date: Mon, 28 Jan 2013 19:09:27 +0000
Message-Id: <A6D06B64-E354-47CC-8F32-DF2F8CB51C4C@keltik.co.uk>
References: <60540.115.242.217.223.1359305486.squirrel@www.nmsworks.co.in> <A5BEAD028815CB40A32A5669CF737C3B23574324@ap-embx-sp40.RES.AD.JPL> <64406.115.242.217.223.1359331248.squirrel@www.nmsworks.co.in> <CAHxHggdt4MgK4Uwro6gXrrr+aqgkzGRpmwo8_1zFDYn0Z9DQhQ@mail.gmail.com> <65367.115.242.158.9.1359332992.squirrel@www.nmsworks.co.in> <CAHxHgge5RFC+bAG6MTWjAGFo6JAegiB+R6eiOM+75p8fuv0wcA@mail.gmail.com> <49280.192.168.9.56.1359345670.squirrel@www.nmsworks.co.in> <A5BEAD028815CB40A32A5669CF737C3B235749F7@ap-embx-sp40.RES.AD.JPL>
To: "Burleigh, Scott C (313B)" <scott.c.burleigh@jpl.nasa.gov>
X-Mailer: Apple Mail (2.1499)
Cc: "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Subject: Re: [dtn-interest] Question
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: Mon, 28 Jan 2013 19:09:38 -0000

On 28 Jan 2013, at 15:54, "Burleigh, Scott C (313B)" <scott.c.burleigh@jpl.nasa.gov> wrote:

> you'd be willing to invest quite a lot of bandwidth in heavy coding and even repeated transmission (which you can think of as proactive, rather than reactive, retransmission)

I'd have to respectfully disagree on this. I prefer to think of repeated transmission as very inefficient FEC. The ideal pro-active solution IMHO is to go for a Fountain Code to fix unplanned outages with conventional FEC being there solely to fix the link budget.  

Dai