Re: [dtn-interest] Question

[[e-mail]]

> On Mon, 2013-01-28 at 09:44 +0530, [e-mail] wrote:
>> 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...
> 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).
  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

>> 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..
> 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
>
>>  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, [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.
>> > 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: [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.
>> >
>>
>>
>>
>
>
> --
> 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.