Re: [dtn-interest] Question

[Vint Cerf <[e-mail]>]

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.


On Sun, Jan 27, 2013 at 11:14 PM, <[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...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
> > 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.
>
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>