Subject: [dtn-interest] Question

From: [email-masked]
Date: Sun, 27 Jan 2013 22:21:26 +0530 (IST)

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.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Sun, 27 Jan 2013 19:04:01 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, January 27, 2013 8:51 AM
To: [email-masked]
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
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: [email-masked]
Date: Mon, 28 Jan 2013 05:30:48 +0530 (IST)

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. (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?
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
>
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>

---

From: Vint Cerf <[email-masked]>
Date: Sun, 27 Jan 2013 19:11:17 -0500

If it is 10s of days and there are no intermediate nodes, you are talking
about a long-delay one-hop link. This is what the Deep Space Network has to
deal with all the time. Forward error correction is your friend in these
cases. Repeated transmissions are possible but for systems like the DSN,
you only get to point to the destination at certain times (when "contact"
is feasible and when you are scheduled to transmit or receive - it is a
huge scheduling challenge since the DSN resource is potentially
over-subscribed). If the probability of loss is relatively low except for
noise, forward error correction may be enough to reduce loss probability in
which case one would not retransmit until no response is obtained after the
round trip time has expired. One of the reasons the IPN is attractive is
that it can position messages closer to destination and recover from
forward hop failures more quickly.

Your scenario of "packet loss" in 4 days on a one hop link is a bit weird
because you can't conclude loss until the signal gets to the receiver.

v

On Sun, Jan 27, 2013 at 7:00 PM, <[email-masked]> wrote:

> > From: [email-masked] [mailto:
> [email-masked]]
> > On Behalf Of [email-masked]

---

From: [email-masked]
Date: Mon, 28 Jan 2013 05:59:52 +0530 (IST)

OK i never thought about FEC in this context.
When you say positioning messages "closer to the destination" that is
exactly my question, the fundamental problem of distance and possible
intermediate disruption (the case that you mention as wierd) is not
handled, it is worked around essentially by reducing the distance, that is
by simply building a bridge that makes the fundamental problem non
existant.
 For star communication, we perhaps couldnt afford to wait for the round
trip time, and what if there are severe packet loss...i was seeing one of
those Nat Geo programs where terribly nasty intense radiation pulses
floating around that could destroy anything in it path let alone frail
packets....This problem intensifies as the distance become longer.
 Should we look for ways then to address the fundamental distance +
disruption challenge other than placing messages close and making the
distance smaller, to address tougher challenges in DSN is the question i
still seem to ask myself...Or should we think this problem is not
addressable at all? Like those mathematician types who can prove
intractability is this proven to be an intractible problem?
 Sitaraman

---

From: Vint Cerf <[email-masked]>
Date: Sun, 27 Jan 2013 19:34:49 -0500

DTN is inappropriate for inter-stellar communication. One can only code
like crazy (FEC) and transmit more or less continuously. one would need
dedicated resources to receive as well.

v

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 28 Jan 2013 00:57:01 +0000

Hi, Sitaraman.

On Mon, 2013-01-28 at 05:30 +0530, [email-masked] wrote:
> 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
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

---

From: [email-masked]
Date: Mon, 28 Jan 2013 09:31:10 +0530 (IST)

Hi Vint,
  Ok, thanks for that clarification. I had misunderstood as DTN was
proposed for DSN too...didnt carefully notice the difference in
terminology between Interplanetary Internet and DSN.
  Could you please elaborate on what you mean by send continuously...
Thanks
Sitaraman
>> > about a long-delay one-hop link. This is what the Deep Space Network
>> has
>> > to
>> > noise, forward error correction may be enough to reduce loss
>> probability
>> > in
>> > which case one would not retransmit until no response is obtained
>> after
>> > the
>> >>  Thanks for the help in understanding all this. I still have a
>> question
>> >> in
>> >> > source-destination pair is handled by storage and retransmission,
>> both
>> >> at
>> >> > communication.  Intermediate nodes are not required in order to
>> make
>> >> DTN
>> >> > work.
>> >> >
>> >> >  Is it correct to state that DTN adopts a store and forward
>> mechansim
>> >> and
>> >> > on failure indication from its immediate neighbor? If this is true
>> is
>> >> it

---

From: [email-masked]
Date: Mon, 28 Jan 2013 09:44:01 +0530 (IST)

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
>> > From: [email-masked]
>> [mailto:[email-masked]]

---

From: Vint Cerf <[email-masked]>
Date: Mon, 28 Jan 2013 08:03:59 -0500

continuous sending (or regularly episodic sending) should not be needed for
the interplanetary system. Celestial motion might make continuous sending
unworkable and a waste of power. Even if an antenna is dedicated to a
particular spacecraft, it may not be possible for it to receive continuous
communications.  An interstellar system could also suffer if one of the
receivers is on a planet that rotates and is in orbit around a sun. If the
intermediate nodes can be in relatively continuous contact, then a forward
error corrected signal might be feasible in both directions.

---

From: [email-masked]
Date: Mon, 28 Jan 2013 19:03:22 +0530 (IST)

What is the typical order of magnitude ratio between the roundtrip time
and the time contact window for each case of interplanetary and
interstellar...

Also (this is going to be costly for sure) is an array of senders and
recievers encircling the planet possible  or a  sender and a pairing set
of reflectors moving in synchrony, that together reflect the senders
signal back to the earth..nothing to do with the protocol itself but
still...
Sitaraman

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 28 Jan 2013 13:49:33 +0000

On Mon, 2013-01-28 at 09:44 +0530, [email-masked] wrote:
> that would avoid the large round trip time, before retransmitting...
You cannot beat our current understanding of physics.  If you have two
stations separated by a distance corresponding to a transit time T at
the speed of light, then, using direct transmission with no
intermediates available, the earliest you can find out anything about
the success or otherwise of the transmission is (2T + epsilon). Of
course hyperspace may come to our rescue (eventually).
> this...lets wait to see what Vint says on this..
As Vint and I have both pointed out, continuous sending may be of no
help if a big body gets in the way sometimes.  Episodic (re)sending is
only going to help (perhaps) if you know exactly when the destination
can receive.  And you have absolutely no control over the conditions on
the transmission path.

Also with robotic spacecraft you sometimes have to cope with imperfect
hardware at the destination.  Check out the things that have to be done
to send commands to Voyager 2.  Continuous transmission would be
completely useless!

In all of these cases resource limits tend to be the critical
consideration... transmission power availability either because the
spacecraft can't afford to transmit all the time or a giant directional
aerial is needed on the ground,  actual bandwidth realisable, length of
communication opportunities.

Regards,
Elwyn

---

From: "Scott, Keith L." <[email-masked]>
Date: Mon, 28 Jan 2013 14:09:46 +0000

I can't find a DSN schedule page any more, but I thought NASA wanted to communicate with the Mars rovers twice a day, which would mean at least two passes to the Mars Odyssey spacecraft per day.  Mars is between about 3 and 20 light-minutes from Earth depending on the planets' locations in their orbits.  The big question then is 'how long is a pass'?

MRO's primary science mission (not communicating with the rovers) had it transmitting 10 or 11 hours per day, for a ratio of:  6/(11*60) ---- 40/(10*60) or between .009 and .066

Not sure what Mars Odyssey's current comm schedule is, but I suspect it communicates with the DSN about twice a day for (a couple hours each pass)?

I don't think there's a 'typical' ratio for interstellar communications, but Voyager 1 is currently about 123 AU from the sun, or about 17 light hours from Earth (one-way).  If NASA really wanted to they could track it full-time (by dedicating the large antennas of all three DSN stations to it).  The week of December 7, 2012 voyager-1 got 34.2 hours of DSN coverage<http://voyager.jpl.nasa.gov/mission/weekly-reports/index.htm> of which 26.6 were large-aperture coverage (though the page doesn't say how that's distributed).  If we break the large-aperture coverage into roughly 7 4-hour chunks that would be 1 pass per day, so you could have a roughly 41-hour RTT (send @0, received at 17, response received @ 34).  [Also, if I'm interpreting the page correctly, these operations resulted in a single frame of GS-4 data - well, it's a long way away!]

This gives an optimistic bound of about (34)/4 or 8.5

And a pessimistic bound (assuming you want to transmit immediately after a transmission opportunity) of about (34+24)/4 or 7.25

                        --keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, January 28, 2013 8:33 AM
To: Vint Cerf
Cc: [email-masked]
Subject: Re: [dtn-interest] Question

interstellar...

still...

Sitaraman

> continuous sending (or regularly episodic sending) should not be needed

> for

> On Sun, Jan 27, 2013 at 11:14 PM, <[email-masked]<mailto:[email-masked]>> wrote:

>>  Thanks for this discussion. Yes, i did have the second one you

>> mentioned

>> > On Mon, 2013-01-28 at 05:30 +0530, [email-masked]<mailto:[email-masked]> wrote:

>> >> mind. For arguments sake consider the scenario where it takes 10s of

>> >> days

>> > - The source knows that there is no communication opportunity until

>> some

>> > try again if it doesn't look as if the bundle reached the destination

>> >> at Chennai,  this is on the works for messages to a star ion pumps

>> >> 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

>> > the way to look at this (mainly because neither end would know that

>> > bundle - not packet: DTN doesn't think in packets - had been lost in

>> > deep space model).  If the bundle doesn't arrive or is received too

>> late

>> > 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,

>> > expected delay before the destination can have the opportunity to send

>> a

>> > times.  One terrestrial experiment in which I was involved could

>> deliver

>> > time, but 'missing the post' would mean probably mean at least a day

>> for

>> > 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

>> >> > Hi, Sitaraman.  It's correct to state that DTN is based on

>> potentially

>> >> > prolonged, potentially non-volatile storage at forwarding points

>> (the

>> >> > But forwarding points other than the original source are features

>> of

>> >> > 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

>> >> > difficulty handling them despite the fact that there were no

>> >> intermediate

>> >> > nodes between the spacecraft and the data sources and sinks on

>> Earth.

>> >> > From: [email-masked]<mailto:[email-masked]>

>> >> > On Behalf Of [email-masked]<mailto:[email-masked]>

>> >> > To: [email-masked]<mailto:[email-masked]>

>> >> > gets around delay and disruption by having intermediate nodes

>> >> retransmit

>> >> > correct to state that fundamentally, the problem of disruption in

>> long

>> >> > storing and forwarding thereby acting as a "virtual" or "proxy"

>> source

>> >> > [email-masked]<mailto:[email-masked]>

>> [email-masked]<mailto:[email-masked]>

--

believed to be clean.

[email-masked]<mailto:[email-masked]>

---

From: [email-masked]
Date: Mon, 28 Jan 2013 20:58:06 +0530 (IST)

Thanks so much Keith...Let us consider the Mars favorable ratio case. In
this scenario, if during the coverage period NASA sends a continous stream
in both direction (with possible time stamped) "channel liveness"
lightweight (meaning consuming less bandwidth) packets, or bundles of
them) by reading the timestamped series of liveness packets the sender may
able to guess a packet loss much before a round trip  time...say it occurs
in the first minute after sending...then it could save some time (RTT-1+)
in making a decision to resend.
Extending further by reading the streams and timestamps it can get "bad
weather reports much farther away and delay sending packets...
Sitaraman

> I can't find a DSN schedule page any more, but I thought NASA wanted to
> communicate with the Mars rovers twice a day, which would mean at least
> two passes to the Mars Odyssey spacecraft per day.  Mars is between about
> 3 and 20 light-minutes from Earth depending on the planets' locations in
> their orbits.  The big question then is 'how long is a pass'?
>
>
>
> MRO's primary science mission (not communicating with the rovers) had it
> transmitting 10 or 11 hours per day, for a ratio of:  6/(11*60) ----
> 40/(10*60) or between .009 and .066
>
>
>
> Not sure what Mars Odyssey's current comm schedule is, but I suspect it
> communicates with the DSN about twice a day for (a couple hours each
> pass)?
>
>
>
>
>
>
>
> I don't think there's a 'typical' ratio for interstellar communications,
> but Voyager 1 is currently about 123 AU from the sun, or about 17 light
> hours from Earth (one-way).  If NASA really wanted to they could track it
> full-time (by dedicating the large antennas of all three DSN stations to
> it).  The week of December 7, 2012 voyager-1 got 34.2 hours of DSN
> coverage<http://voyager.jpl.nasa.gov/mission/weekly-reports/index.htm> of
> which 26.6 were large-aperture coverage (though the page doesn't say how
> that's distributed).  If we break the large-aperture coverage into roughly
> 7 4-hour chunks that would be 1 pass per day, so you could have a roughly
> 41-hour RTT (send @0, received at 17, response received @ 34).  [Also, if
> I'm interpreting the page correctly, these operations resulted in a single
> frame of GS-4 data - well, it's a long way away!]
>
>
>
> And a pessimistic bound (assuming you want to transmit immediately after a
> transmission opportunity) of about (34+24)/4 or 7.25
>
>
>
>                         --keith
>
>
>
>
>
>> On Sun, Jan 27, 2013 at 11:14 PM,
>> <[email-masked]<mailto:[email-masked]>> wrote:
>
>>
>
>>> Hi Elwyn,
>
>>> > On Mon, 2013-01-28 at 05:30 +0530,
>>> [email-masked]<mailto:[email-masked]> wrote:
>
>>> >> Hi Scott,
>
>>> >> > From:
>>> [email-masked]<mailto:[email-masked]>
>
>>> >> > On Behalf Of
>>> [email-masked]<mailto:[email-masked]>
>

---

From: [email-masked]
Date: Mon, 28 Jan 2013 21:09:58 +0530 (IST)

> course hyperspace may come to our rescue (eventually).
  Given that you have got coverage and if technology is available (and
taxpayers oblige sacrificing perhaps superbowl/cricket/football tickets
or betting :-)) is what you have mentioned really true...remember we can
work in stochastic regimes and we can rely on these mathematicians to
buy us very good benefits out of "guessing"...
Sitaraman

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Mon, 28 Jan 2013 15:54:38 +0000

Actually DTN definitely is proposed for DSN transmissions -- the DSN is mainly used for communications with spacecraft in our solar system, which was the original use case for the DTN design.

Our current understanding of the physics of electromagnetic radiation imposes limits on what we could do in interstellar communication, no question.  But I wouldn't say there's an outer limit at which DTN no longer works; rather, as round-trip times increase it just becomes diminishingly attractive to accomplish reliable data delivery by selective negative acknowledgment and retransmission.

When round-trip times are very brief, acknowledgment and retransmission usually doesn't impose enough of a penalty in end-to-end delivery latency to justify the bandwidth overhead cost of heavy forward error correction.  For interstellar communications this trade would likely be inverted: 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) to reduce the incidence of data loss and NACK-based retransmission that would result in painfully high delivery latency.

So I think the DTN transmission principles would still apply.  You want to send everything you know, as soon as you know it; you want to encode the data to minimize the impact of noise, as much as you think you can afford; you want to retransmit only as a last resort, in the event that your coding wasn't enough to ensure successful delivery.

You might very well want to try to optimize transmission by forwarding through intermediate nodes, somehow; in addition to moving the point of retransmission toward the destination, they would also give you the opportunity to do forward transmission at high power, restoring signal strength that diminishes over all those light minutes.  But you could spend a lot of money on that strategy: everything in space tends to be orbiting something else.  That is, you can't just put a repeater between here and Jupiter, for example; it won't stay there.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, January 27, 2013 8:01 PM
To: Vint Cerf
Cc: Burleigh, Scott C (313B); [email-masked]
Subject: Re: [dtn-interest] Question

Hi Vint,
  Ok, thanks for that clarification. I had misunderstood as DTN was proposed for DSN too...didnt carefully notice the difference in terminology between Interplanetary Internet and DSN.
  Could you please elaborate on what you mean by send continuously...
Thanks
Sitaraman
> DTN is inappropriate for inter-stellar communication. One can only 
> code like crazy (FEC) and transmit more or less continuously. one 
> would need dedicated resources to receive as well.
>
> v
>
>
>
>> handled, it is worked around essentially by reducing the distance, 
>> that is by simply building a bridge that makes the fundamental 
>> problem non existant.
>>  For star communication, we perhaps couldnt afford to wait for the 
>> round trip time, and what if there are severe packet loss...i was 
>> seeing one of those Nat Geo programs where terribly nasty intense 
>> radiation pulses floating around that could destroy anything in it 
>> path let alone frail packets....This problem intensifies as the 
>> distance become longer.
>> distance smaller, to address tougher challenges in DSN is the 
>> question i still seem to ask myself...Or should we think this problem 
>> is not addressable at all? Like those mathematician types who can 
>> prove intractability is this proven to be an intractible problem?
>>  Sitaraman
>> > is feasible and when you are scheduled to transmit or receive - it 
>> > is
>> a
>> > over-subscribed). If the probability of loss is relatively low 
>> > except
>> for
>> > round trip time has expired. One of the reasons the IPN is 
>> > attractive
>> is
>> > that it can position messages closer to destination and recover 
>> > from forward hop failures more quickly.
>> >
>> >> 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. (If i understood Vint right the other day 
>> >> in the
>> talk
>> >> > original source and all routers along the end-to-end path) and 
>> >> > on potential retransmission at all forwarding points.
>> >> >
>> >> > 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.
>> >> >
>> >> > -- lapses in connectivity -- lasting several days, but DTN had 
>> >> > no difficulty handling them despite the fact that there were no
>> >> intermediate
>> >> > 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.
>> >> >
>> >> > This message has been scanned for viruses and dangerous content 
>> >> > by MailScanner, and is believed to be clean.
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --

---

From: Dai Stanton <[email-masked]>
Date: Mon, 28 Jan 2013 19:09:27 +0000

On 28 Jan 2013, at 15:54, "Burleigh, Scott C (313B)" <[email-masked]> 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

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Mon, 28 Jan 2013 19:51:52 +0000

No argument from me, Dai.  A Digital Fountain-like solution seems likely to be more efficient than repeated transmission.  It seems to me possible that it might fail (or be less efficient) under some outage scenarios, but maybe that's a trade that has already been resolved.

Scott

From: Dai Stanton [mailto:[email-masked]]
Sent: Monday, January 28, 2013 11:09 AM
To: Burleigh, Scott C (313B)
Cc: [email-masked]; Vint Cerf; [email-masked]
Subject: Re: [dtn-interest] Question

On 28 Jan 2013, at 15:54, "Burleigh, Scott C (313B)" <[email-masked]<mailto:[email-masked]>> wrote:

Dai

---

From: [email-masked]
Date: Tue, 29 Jan 2013 06:46:45 +0530 (IST)

Is it correct understanding the coding can only address corruption and not
entire looses (or even severe) corruption...? if that is correct, we would
still need to address losses....which is the he use case i meant to
address with the low bandwidth timestamped "livenss channel" approach,
this sending of these liveness neednt even be contin ous, in scenarios
where one is willing to tradeoff granularity of detection location that
is....?
Sitaraman
 > No argument from e me, Dai.  A Digital Fountain-like solution seems likely
> to be more efficient than repeated transmission.  It seems to me possible
> that it might fail (or be less efficient) under some outage scenarios, but
> maybe that's a trade that has already been resolved.
>
> Scott
>
> On 28 Jan 2013, at 15:54, "Burleigh, Scott C (313B)"
> <[email-masked]<mailto:[email-masked]>>
> 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
>
> --

---

From: Vint Cerf <[email-masked]>
Date: Mon, 28 Jan 2013 20:44:28 -0500

see Digital Fountain

v

---

From: [email-masked]
Date: Tue, 29 Jan 2013 07:14:55 +0530 (IST)

I did, and my understanding is it is an erasure code  with a larger margin
of error allowed for the signal can be recovered from a subset of the
encoded signals...so it still cant handle losses?
Sitaraman

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 28 Jan 2013 22:12:14 -0500

> encoded signals...so it still cant handle losses?

It is correct that a "digital fountain" is an instance of a forward
error-correcting code.

As such, it has the property that it encodes a string of data D of
length N as a set of much smaller strings e0, e1, ..., eX such that
the original string D can be reconstructed from any subset of e0,
e1, ... eX if the sum of the lengths of each e in the subset is
greater or equal to N.  (an "efficient" FEC is one such that any
subset of length N will suffice; my recollection is that fountain
codes are not guaranteed to be efficient, but are generally within a
small margin of it.)  It is possible to choose an encoding method to
make each e computable independently of the rest, and the set of all
possible e's for a given D practically unlimited.

The sender can continuously compute and transmit e's, and as soon as
the receiver receives enough e's, the receiver is successful.  It
doesn't matter how many e's are lost en route (or which are lost) as
long as enough arrive eventually.

Fountain codes are one example of a FEC with this property, but the
last time I checked (which was a while ago, admittedly) they had two
drawbacks: first, the efficient implementations were protected by
patents, and second, they weren't well-described or available as
open-source.  Perhaps that has changed.

In any case, if you want to understand the basic theory of efficient
FECs, Rabin's "Information Dispersal Algorithm", based on polynomial
interpolation, is a good place to start.  For implementations of
related codes that can be implemented efficiently, James Plank's
work on erasure codes for storage is the most practical work of
which I am aware.

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
Raytheon BBN Technologies
[email-masked]

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Tue, 29 Jan 2013 10:54:41 -0600

I think a lot of work in reliable multicasts has foundations in tornado
codes such as digital fountain.  They may be using non-proprietary stuff
here.

http://en.wikipedia.org/wiki/Tornado_code

Interleaving helps with gaps.

That being said, most of this discussion  is related to reliable transport
(convergence layer) more so than store and forward.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

> From: Daniel Ellard <[email-masked]>
> Date: Mon, 28 Jan 2013 21:12:14 -0600
> To: "[email-masked]" <[email-masked]>

---

From: [email-masked]
Date: Wed, 30 Jan 2013 00:26:13 +0530 (IST)

Yes, thats a question i still seem to have, for DSN and even distant
plantes, will reliable transport alone suffice? and is intermediate nodes
all the way upto the desitnation is feasible? For, DTN, it appears,
essentially relies on, intermediate nodes (or the distance between source
and destination say such as for mars say being mangeable) so as to not
have intermediate nodes and do store and forward at source.

---

From: Vincent Roca <[email-masked]>
Date: Wed, 30 Jan 2013 09:31:18 +0100 (CET)

Hello,

If you're interested in AL-FEC codes for the erasure channel,
you should have a look at:
      http://openfec.org

Many, many AL-FEC codes exist. Some of them have the property
of being able to produce a huge number of repair symbols
(Raptor/RaptorQ being good examples of such codes),
others requiring to define in advance the maximum number 
of repair symbols you need (LDPC-Staircase and Reed-Solomon
codes being good examples).

Of course there are IPR aspects that I won't discuss here.
In openfec, we tried to keep away from known IPRs, and you'll
find in this web site not only C-language codecs for Reed-Solomon,
2D parity check and LDPC-Staircase codes, as well as 
simulation environments to assess their performance.

All of them have been specified as FEC schemes in various
RFCs in the context of RMT and FECFRAME working groups.

Hope it answers some of your questions.

Cheers,

    Vincent

---

From: [email-masked]
Date: Wed, 30 Jan 2013 14:20:27 +0530 (IST)

Hi Vincent,
 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?
 From the space folks, it would be nice to get inputs on....is it(loss
prevention schemes) a relevant problem to study given the extent of
correction and redundancy that is packed in the data.
 If the above is indeed relevant, from the Protocol folks, the protocols
that exists in the DTN or DSN that addresses this (other than store-
forward as i understand it is proposed now,  which has the limitation of
needing the RTT between immediate neighbors).
Sitaraman