Re: [dtn-interest] Question

[Elwyn Davies <[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).
> 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.
> >
> 
> 
>