Re: [dtn-interest] Question

sitaraman@nmsworks.co.in Mon, 28 January 2013 04:16 UTC

Return-Path: <sitaraman@nmsworks.co.in>
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 4586E21F885C for <dtn-interest@ietfa.amsl.com>; Sun, 27 Jan 2013 20:16:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.992
X-Spam-Level:
X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
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 sRsFtCfUYjZQ for <dtn-interest@ietfa.amsl.com>; Sun, 27 Jan 2013 20:16:23 -0800 (PST)
Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id CD2C621F87D5 for <dtn-interest@irtf.org>; Sun, 27 Jan 2013 20:16:22 -0800 (PST)
Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0S4DwKI026414; Mon, 28 Jan 2013 09:43:59 +0530
Received: from 192.168.9.56 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Mon, 28 Jan 2013 09:44:01 +0530 (IST)
Message-ID: <49314.192.168.9.56.1359346441.squirrel@www.nmsworks.co.in>
In-Reply-To: <1359334621.28723.19512.camel@mightyatom>
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> <1359334621.28723.19512.camel@mightyatom>
Date: Mon, 28 Jan 2013 09:44:01 +0530
From: sitaraman@nmsworks.co.in
To: Elwyn Davies <elwynd@folly.org.uk>
User-Agent: SquirrelMail/1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-NMSWorks-MailScanner-Information: Please contact the ISP for more information
X-NMSWorks-MailScanner-ID: r0S4DwKI026414
X-NMSWorks-MailScanner: Found to be clean
X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90)
X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in
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 04:16:24 -0000

Hi Elwyn,
 Thanks for this discussion. Yes, i did have the second one you mentioned
in mind, where the distance is so large that it takes a long time. In
that scenario, i am wondering if there would be schemes of communicating
that would avoid the large round trip time, before retransmitting...and
this is related to the continous sending that Vint was mentioning, but i
am not sure if thats the application that Vint had in mind for
this...lets wait to see what Vint says on this..
 Also a question for Vint is, if for interstellar we need to resort to
continuous sending, (given that error correction wont do for severe
losses), why cannot the same be adopted for Interplanetary too?
Sitaraman
> Hi, Sitaraman.
>
> On Mon, 2013-01-28 at 05:30 +0530, sitaraman@nmsworks.co.in wrote:
>> Hi Scott,
>>  Thanks for the help in understanding all this. I still have a question
>> in
>> mind. For arguments sake consider the scenario where it takes 10s of
>> days
>> for message to reach from source to destination and there is no
>> intermediate node.
> There are two cases to consider that would make the message take some
> large period of time to reach its destination:
> - The source knows that there is no communication opportunity until some
> time in the future (e.g., it hasn't got time on the DSN or the
> destination is hidden behind a star) and hence hasn't transmitted the
> bundle as yet (probably not what you are thinking of), or
> - the actual transmission time (speed of light or close approximation)
> to the destination is (e.g.) 10's of days.
> Assuming the source knows what the situation is, it has to set the
> expiry time of the bundle so that the bundle will not expire before it
> has a chance to reach its destination (i.e.,  the time till actual
> transmission plus the length of time for transit to destination plus a
> margin for error).
>
> If it doesn't know exactly then it has to take a guess and then has to
> try again if it doesn't look as if the bundle reached the destination in
> time (because the destination will probably ignore the bundle if it
> arrives after its expiry time assuming it makes it at all).
>> (If i understood Vint right the other day in the talk
>> at Chennai,  this is on the works for messages to a star ion pumps and
>> all! so hoping this is still a relevant case)Say a packet loss happens 4
>> days down the road. How long would the source wait to decide to resend
>> from its store?
> The concept of a 'packet loss a few days down the road' is not really
> the way to look at this (mainly because neither end would know that the
> bundle - not packet: DTN doesn't think in packets - had been lost in the
> deep space model).  If the bundle doesn't arrive or is received too late
> or corrupted, then no report will come back because the destination
> either never saw the bundle or ignored a corrupt/expired bundle.  The
> source can make an estimate of the latest time that it would expect to
> receive a delivery report from the destination - and that is all it can
> expect to receive at the DTN level (the convergence layer protocol might
> have a little more information if the bundle was transmitted in chunks,
> but no guarantees).  This will clearly be related to the expected
> transit time and hence the expiry time of the transmitted bundle.  The
> source might start thinking about retransmitting when the latest time
> that a report might have been received has passed - thus sent bundle
> expiry time plus transit time from destination to source plus any
> expected delay before the destination can have the opportunity to send a
> confirmation. In space networks this may be quite a complicated
> calculation but is probably reasonably deterministic.
>
> Once you get into multi-hop bundle transmission in opportunistic
> networks it is generally necessary to be very generous with expiry
> times.  One terrestrial experiment in which I was involved could deliver
> a bundle in less than an hour end-to-end if it was sent at the 'right'
> time, but 'missing the post' would mean probably mean at least a day for
> delivery and if it hit congestion perhaps up to 3 days.   When do you
> retransmit?  Well.... What are the error characteristics of the
> convergence layer in use (adding FEC as with LTP is probably a good move
> on essentially unidirectional links)? How much resource are you willing
> to put into retransmission? Would the information be of any value if you
> did retransmit 20 days later?  These decisions are really application
> decisions rather than network protocol decisions in many cases.
>
> Regards,
> Elwyn
>> Sitaraman
>> > Hi, Sitaraman.  It's correct to state that DTN is based on potentially
>> > prolonged, potentially non-volatile storage at forwarding points (the
>> > original source and all routers along the end-to-end path) and on
>> > potential retransmission at all forwarding points.
>> >
>> > But forwarding points other than the original source are features of
>> > specific topologies, not mandatory elements of the architecture.
>> > Disruption in communication between the endpoints of a long-delay
>> > source-destination pair is handled by storage and retransmission, both
>> at
>> > the source and also at whatever other nodes may be involved in the
>> > communication.  Intermediate nodes are not required in order to make
>> DTN
>> > work.
>> >
>> > For example, in the DINET experiment in 2008 we did DTN communication
>> > between nodes on Earth and a node aboard the Deep Impact flyby
>> spacecraft
>> > in interplanetary space, 10-15 million miles away.  There were
>> disruptions
>> > -- lapses in connectivity -- lasting several days, but DTN had no
>> > difficulty handling them despite the fact that there were no
>> intermediate
>> > nodes between the spacecraft and the data sources and sinks on Earth.
>> >
>> > Scott
>> >
>> > -----Original Message-----
>> > From: dtn-interest-bounces@irtf.org
>> [mailto:dtn-interest-bounces@irtf.org]
>> > On Behalf Of sitaraman@nmsworks.co.in
>> > Sent: Sunday, January 27, 2013 8:51 AM
>> > To: dtn-interest@irtf.org
>> > Subject: [dtn-interest] Question
>> >
>> > Hi,
>> >  Is it correct to state that DTN adopts a store and forward mechansim
>> and
>> > gets around delay and disruption by having intermediate nodes
>> retransmit
>> > on failure indication from its immediate neighbor? If this is true is
>> it
>> > correct to state that fundamentally, the problem of disruption in long
>> > delay source-destination pair is not handled, but is solved by
>> > essentially reducing the said distance by having intermediate nodes
>> > storing and forwarding thereby acting as a "virtual" or "proxy" source
>> > and destinations?
>> >  Thanks
>> > Sitaraman
>> >
>> >
>> > --
>> > This message has been scanned for viruses and dangerous content by
>> > MailScanner, and is believed to be clean.
>> >
>> > _______________________________________________
>> > dtn-interest mailing list
>> > dtn-interest@irtf.org
>> > https://www.irtf.org/mailman/listinfo/dtn-interest
>> >
>> > --
>> > This message has been scanned for viruses and
>> > dangerous content by MailScanner, and is
>> > believed to be clean.
>> >
>> >
>>
>>
>>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.