Re: [dtn-interest] Question

[[e-mail]]

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.