Re: [dtn-interest] Question

["Burleigh, Scott C (313B)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
Sent: Sunday, January 27, 2013 8:01 PM
To: Vint Cerf
Cc: Burleigh, Scott C (313B); [e-mail]
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
>
>
>
> On Sun, Jan 27, 2013 at 7:29 PM, <[e-mail]> wrote:
>
>> 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
>> > 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, <[e-mail]> 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. (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
>> >> >
>> >> > -----Original Message-----
>> >> > From: [e-mail] [mailto:
>> >> [e-mail]]
>> >> > On Behalf Of [e-mail]
>> >> > Sent: Sunday, January 27, 2013 8:51 AM
>> >> > To: [e-mail]
>> >> > 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
>> >> > [e-mail]
>> >> > 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.
>> >>
>> >> _______________________________________________
>> >> dtn-interest mailing list
>> >> [e-mail]
>> >> 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.
>
>



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