Re: [dtn-interest] Question

[[e-mail]]

Thanks so much Keith...Let us consider the Mars favorable ratio case. In
this scenario, if during the coverage period NASA sends a continous stream
in both direction (with possible time stamped) "channel liveness"
lightweight (meaning consuming less bandwidth) packets, or bundles of
them) by reading the timestamped series of liveness packets the sender may
able to guess a packet loss much before a round trip  time...say it occurs
in the first minute after sending...then it could save some time (RTT-1+)
in making a decision to resend.
Extending further by reading the streams and timestamps it can get "bad
weather reports much farther away and delay sending packets...
Sitaraman

> I can't find a DSN schedule page any more, but I thought NASA wanted to
> communicate with the Mars rovers twice a day, which would mean at least
> two passes to the Mars Odyssey spacecraft per day.  Mars is between about
> 3 and 20 light-minutes from Earth depending on the planets' locations in
> their orbits.  The big question then is 'how long is a pass'?
>
>
>
> MRO's primary science mission (not communicating with the rovers) had it
> transmitting 10 or 11 hours per day, for a ratio of:  6/(11*60) ----
> 40/(10*60) or between .009 and .066
>
>
>
> Not sure what Mars Odyssey's current comm schedule is, but I suspect it
> communicates with the DSN about twice a day for (a couple hours each
> pass)?
>
>
>
>
>
>
>
> I don't think there's a 'typical' ratio for interstellar communications,
> but Voyager 1 is currently about 123 AU from the sun, or about 17 light
> hours from Earth (one-way).  If NASA really wanted to they could track it
> full-time (by dedicating the large antennas of all three DSN stations to
> it).  The week of December 7, 2012 voyager-1 got 34.2 hours of DSN
> coverage<http://voyager.jpl.nasa.gov/mission/weekly-reports/index.htm> of
> which 26.6 were large-aperture coverage (though the page doesn't say how
> that's distributed).  If we break the large-aperture coverage into roughly
> 7 4-hour chunks that would be 1 pass per day, so you could have a roughly
> 41-hour RTT (send @0, received at 17, response received @ 34).  [Also, if
> I'm interpreting the page correctly, these operations resulted in a single
> frame of GS-4 data - well, it's a long way away!]
>
>
>
> This gives an optimistic bound of about (34)/4 or 8.5
>
> And a pessimistic bound (assuming you want to transmit immediately after a
> transmission opportunity) of about (34+24)/4 or 7.25
>
>
>
>                         --keith
>
>
>
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of [e-mail]
> Sent: Monday, January 28, 2013 8:33 AM
> To: Vint Cerf
> Cc: [e-mail]
> Subject: Re: [dtn-interest] Question
>
>
>
> 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]<mailto:[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]<mailto:[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]>
>
>>> >> [mailto:[e-mail]]
>
>>> >> > On Behalf Of
>>> [e-mail]<mailto:[e-mail]>
>
>>> >> > Sent: Sunday, January 27, 2013 8:51 AM
>
>>> >> > To: [e-mail]<mailto:[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]<mailto:[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]<mailto:[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.
>
>
>
> _______________________________________________
>
> dtn-interest mailing list
>
> [e-mail]<mailto:[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.