Re: [dtn-interest] Question

[Elwyn Davies <[e-mail]>]

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.
> >
> >
> 
> 
>