Subject: Re: [dtn-interest] Re : Re: Question

From: LOCHIN Emmanuel <[email-masked]>
Date: Wed, 30 Jan 2013 19:33:19 +0100

Hi Sitaraman

> Thanks much for this pointer, it will help me learn this aspect.
> In general a question remains that i have, for the group as  whole.
> A lot seems to have already been done  and literature and code 
> available
> in FEC and Erasure Codes as has been made available from  the 
> discussion
> on this group  Do these complement or can they replace loss (chunks 
> of
> data compeletely lost so that there is not anything to decode from)
> handling mechansims?

Concerning this point, you'll find a study that uses such scheme to 
rebuild lost chunks in "Robust streaming in delay tolerant networks": 
see http://oatao.univ-toulouse.fr/4111/
The erasure coding scheme is a specific elastic-window encoding scheme 
named Tetrys: see http://websites.isae.fr/tetrys/

Emmanuel

---

From: [email-masked]
Date: Thu, 31 Jan 2013 05:47:07 +0530 (IST)

Hi Emmanuel,
 This looks great to me, thanks for this pointer. Only one scenario comes
to mind, if it so happens that the expected bundle loss rate, even if for
brief periods, is underestimated. Such scenarios could perhaps be
relevant in space as intense disturbances for brief period is more likely
than a steady noise, and with Tetrys, it would be inefficient to have the
expected bundle loss rate set at its peak.
 I am tending to think while Tetrys could be a default scheme running in
the DTN, DSN, there is needed a scheme that can put out fires
occasionally?
Sitaraman
> --
> 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.

---

From: [email-masked]
Date: Thu, 31 Jan 2013 07:03:15 +0530 (IST)

Hi Emmanuel,
 Tetrys could become more powerful if the expected bundle loss rate can be
made dynamically alterable in a feedback control loop, especially if it
can be triggered by a NACK as opposed to an ACK...and if the NACK can be
triggered without needing an RTT, that would be ensure a rather wide
coverage of loss scenarios using FEC as is used in Tetrys...
Sitaraman

---

From: [email-masked]
Date: Thu, 31 Jan 2013 07:04:11 +0530 (IST)

I should rather say "in addition to" instead of "as opposed to" in the below
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>

---

From: Emmanuel Lochin <[email-masked]>
Date: Thu, 31 Jan 2013 11:55:58 +0100

Hi Sitaraman

Thanks for your interest. We are currently working on these aspects for deep space communication on top of a DTN architecture with CNES (the French space agency).
In particular, we seek to integrate erasure coding inside the DTN architecture.
Note that there is also an IETF draft on this subject : http://www.ietf.org/id/draft-zinky-dtnrg-erasure-coding-objects-00.txt

Emmanuel

-- 
Emmanuel Lochin
Professeur ISAE - OSSI
Institut Supérieur de l'Aéronautique et de l'Espace (ISAE)
Issu du rapprochement SUPAERO et ENSICA
10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4
Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88
Web : http://personnel.isae.fr/emmanuel-lochin/
---
"This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed"

---

From: <[email-masked]>
Date: Thu, 31 Jan 2013 11:03:31 +0000

Dear All,

If it might be of interest, a similar activity is also carried out within CCSDS, where DLR is writing an orange book for erasure codes in near-earth and deep-space scenarios. The orange book is mostly on the code (encoding and decoding) design, but it gives also some notes on the implementation within the DTN architecture, namely around the LTP protocol.

Best Regards,

Tomaso

------------------------ 
Deutsches Zentrum für Luft- und Raumfahrt (DLR) 
German Aerospace Center 
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany 
Tomaso de Cola, Ph.D. 
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked] 
http://www.dlr.de/kn/institut/abteilungen/san 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Lochin
Sent: Thursday, January 31, 2013 11:56 AM
To: [email-masked]
Cc: Dubois Emmanuel; [email-masked]; Gelard Patrick
Subject: Re: [dtn-interest] Re : Re: Question

Hi Sitaraman

Emmanuel

On 31/01/2013 02:34, [email-masked] wrote:
>>   This looks great to me, thanks for this pointer. Only one scenario 
>> comes to mind, if it so happens that the expected bundle loss rate, 
>> even if for brief periods, is underestimated. Such scenarios could 
>> perhaps be relevant in space as intense disturbances for brief period 
>> is more likely than a steady noise, and with Tetrys, it would be 
>> inefficient to have the expected bundle loss rate set at its peak.
>>   I am tending to think while Tetrys could be a default scheme 
>> running in the DTN, DSN, there is needed a scheme that can put out 
>> fires occasionally?
>> Sitaraman
>>> Hi Sitaraman
>>>
>>>> available in FEC and Erasure Codes as has been made available from  
>>>> the discussion on this group  Do these complement or can they 
>>>> replace loss (chunks of data compeletely lost so that there is not 
>>>> anything to decode from) handling mechansims?
>>> The erasure coding scheme is a specific elastic-window encoding 
>>> scheme named Tetrys: see http://websites.isae.fr/tetrys/
>>>
>>> Emmanuel
>>>
>>> --
>>> This message has been scanned for viruses and dangerous content by 
>>> MailScanner, and is believed to be clean.
>>>
>>
>>
>> --

---

From: Emmanuel Lochin <[email-masked]>
Date: Thu, 31 Jan 2013 12:41:14 +0100

> If it might be of interest, a similar activity is also carried out within CCSDS, where DLR is writing an orange book for erasure codes in near-earth and deep-space scenarios. The orange book is mos…

Interesting indeed, however the big advantage with on-the-fly coding 
scheme is that you do not need to size a FEC block size.
Only an average PLR is needed, making such scheme much more easier to 
configure.

Emmanuel

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 31 Jan 2013 16:11:45 +0000

I would say this is why it's usually advantageous to run an erasure coding scheme underneath an ARQ system, such as LTP.  Most of the time, the erasure coding will be sufficient for recovery from data loss and the acknowledgments will only be positive; end-to-end delivery latency is minimized and transmission overhead is relatively constant.  On rare occasions, data loss will  be so severe and prolonged that too few code blocks will be received to reassemble the original data.  On those rare occasions, negative acknowledgment will initiate retransmission; end-to-end delivery is unavoidably delayed and transmission overhead spikes, but there's no permanent data loss.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 30, 2013 5:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Re : Re: Question

>  I am tending to think while Tetrys could be a default scheme running 
> in the DTN, DSN, there is needed a scheme that can put out fires 
> occasionally?
> Sitaraman
>>
>> Hi Sitaraman
>>

---

From: [email-masked]
Date: Thu, 31 Jan 2013 22:19:53 +0530 (IST)

Hi Scott,
I looked up RFC5325... it relies on a recieve report from the reciever and
timeouts are calculated based on RTT.
Consider a situation where the coverage window is going to end and
subsequent availability window will take a while...there is a critical
piece of data that needs to be sent (say, criticality which cannot be
deterimined before hand but only dynamically based on the context of the
recent recieved data...). In this scenario a NACK without needing the RTT
could be helpful?
Sitaraman

> I would say this is why it's usually advantageous to run an erasure coding
> scheme underneath an ARQ system, such as LTP.  Most of the time, the
> erasure coding will be sufficient for recovery from data loss and the
> acknowledgments will only be positive; end-to-end delivery latency is
> minimized and transmission overhead is relatively constant.  On rare
> occasions, data loss will  be so severe and prolonged that too few code
> blocks will be received to reassemble the original data.  On those rare
> occasions, negative acknowledgment will initiate retransmission;
> end-to-end delivery is unavoidably delayed and transmission overhead
> spikes, but there's no permanent data loss.
>
> Scott
>

---

From: [email-masked]
Date: Thu, 31 Jan 2013 22:19:56 +0530 (IST)

Hi Scott,

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 31 Jan 2013 17:06:03 +0000

I'd say the fact that the information is critical is, itself, new information; it should result in transmission of a new message (from whichever application entity discovered the critical nature of the data) that encapsulates the original data and has "critical" priority, causing it to be transmitted as soon as possible.  I don't see how any sort of artificial NAK would be useful, regardless of what sort of  convergence-layer protocol you were using.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, January 31, 2013 8:50 AM
To: Burleigh, Scott C (313B)
Cc: [email-masked]
Subject: RE: [dtn-interest] Re : Re: Question

Hi Scott,
I looked up RFC5325... it relies on a recieve report from the reciever and timeouts are calculated based on RTT.
Consider a situation where the coverage window is going to end and subsequent availability window will take a while...there is a critical piece of data that needs to be sent (say, criticality which cannot be deterimined before hand but only dynamically based on the context of the recent recieved data...). In this scenario a NACK without needing the RTT could be helpful?
Sitaraman

> I would say this is why it's usually advantageous to run an erasure 
> coding scheme underneath an ARQ system, such as LTP.  Most of the 
> time, the erasure coding will be sufficient for recovery from data 
> loss and the acknowledgments will only be positive; end-to-end 
> delivery latency is minimized and transmission overhead is relatively 
> constant.  On rare occasions, data loss will  be so severe and 
> prolonged that too few code blocks will be received to reassemble the 
> original data.  On those rare occasions, negative acknowledgment will 
> initiate retransmission; end-to-end delivery is unavoidably delayed 
> and transmission overhead spikes, but there's no permanent data loss.
>
> Scott
>
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of [email-masked]

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

---

From: [email-masked]
Date: Thu, 31 Jan 2013 23:01:48 +0530 (IST)

Maybe i should elaborate, i was considering the scenario, a critical data
that has been sent at the boundary of the coverage availability window
gets lost...and RTT straddles the availability window boundary.
Sitaraman
> I'd say the fact that the information is critical is, itself, new
> information; it should result in transmission of a new message (from
> whichever application entity discovered the critical nature of the data)
> that encapsulates the original data and has "critical" priority, causing
> it to be transmitted as soon as possible.  I don't see how any sort of
> artificial NAK would be useful, regardless of what sort of
> convergence-layer protocol you were using.
>
> Scott
>

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 31 Jan 2013 18:20:27 +0000

I don't understand what you are proposing, Sitaraman.  What would you add to or change in the protocols as currently specified?  [Note that LTP timeout intervals are calculated based on RTT but are also extended in response to lapses of contact (see RFC 5326 sections 6.5 and 6.6).]

Scott 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, January 31, 2013 9:32 AM
To: Burleigh, Scott C (313B)
Cc: [email-masked]
Subject: RE: [dtn-interest] Re : Re: Question

Maybe i should elaborate, i was considering the scenario, a critical data that has been sent at the boundary of the coverage availability window gets lost...and RTT straddles the availability window boundary.
Sitaraman
> whichever application entity discovered the critical nature of the 
> data) that encapsulates the original data and has "critical" priority, 
> causing it to be transmitted as soon as possible.  I don't see how any 
> sort of artificial NAK would be useful, regardless of what sort of 
> I looked up RFC5325... it relies on a recieve report from the reciever 
> and timeouts are calculated based on RTT.
> deterimined before hand but only dynamically based on the context of 
> the recent recieved data...). In this scenario a NACK without needing 
> the RTT could be helpful?
> Sitaraman
>
>>> perhaps be relevant in space as intense disturbances for brief 
>>> period is more likely than a steady noise, and with Tetrys, it would 
>>> be inefficient to have the expected bundle loss rate set at its peak.

---

From: [email-masked]
Date: Fri, 1 Feb 2013 10:12:08 +0530 (IST)

Hi Scott,
  I will try harder...
  First, taking a step back from the specifics of what i am proposing, my
intent is to better understand what are the open challenges that space
folks would like to solve that can be addressed by protocol, that and
opportunties for research explorations that can further enchance the
capabilities for DSN that space folks would appreciate seeing brought
in.
  With that intent, from what understanding i have so far, one limitation
that i see is as follows.
 a)Erasure Coding addresses the fundamental distance and delay problem for
disruptions (not loss of coverage but unfortunate events either due to
interference or due to physical blockage). This it does by redudancy in
the packets (essentially a form of a more continuous and granular
retransmission). However due to the continuous retransmission nature,
while it works well for low intensity  losses even if it is spread over a
long time, it becomes inefficient (and costly perhaps) to extend this for
relatively medium-time-length spikes in losses.
 b)Store and forward while it can handle coverage lost does not address
the funamental distance problem. It addresses the problem by essentially
storing and forwarding at intermediates thereby making the distance
problem non-existant, a workaround.
 c)LTP relies on RTT therefore is tied to the physical distance.
 I was wondering if there is a protocol oriented way that we can allievate
the above complementing limitations. It occured to me, maybe one aspect
that is lacking is, in the event of a severe loss (spike such as due to a
relatively long-enough physical obstruction in space, other than coverage
loss, that is,  due to line-of-sight loss between source and
destination), there is not an immediate transmission of that bad news
back to the sender so that the sender can retransmit the entire chunk. A
use case where such a capability could be exploited is the one i describe
below where a critical data (criticality not kown apriori, so you cannot
plan for or schedule the sending of this data) sending event occurs at
the boundary of a coverage loss (loss of line-of-sight due to celestial
motion) and RTT stradles the boundary.
 Therefore, i was wondering if we can consider adding support in the
protocol a low bandwidth liveness streaming (which could carry data too,
such as a form of green data in LTP), that can potentially NACK sooner
than that required by RTT based acks. This is especially useful if the
spike loss occurs very close to the sender, therefore, RTT especially in
DSN scenario would be a relatively large (avoidable if possible) delta.
Sitaraman

> I don't understand what you are proposing, Sitaraman.  What would you add
> to or change in the protocols as currently specified?  [Note that LTP
> timeout intervals are calculated based on RTT but are also extended in
> response to lapses of contact (see RFC 5326 sections 6.5 and 6.6).]
>
> Scott
>