Re: [dtn-interest] Question

[[e-mail]]

What is the typical order of magnitude ratio between the roundtrip time
and the time contact window for each case of interplanetary and
interstellar...


Also (this is going to be costly for sure) is an array of senders and
recievers encircling the planet possible  or a  sender and a pairing set
of reflectors moving in synchrony, that together reflect the senders
signal back to the earth..nothing to do with the protocol itself but
still...
Sitaraman

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