Subject: [dtn-users] Delay in receiving files due to link down

From: Rucha Vaidya <[email-masked]>
Date: Sun, 12 Jul 2015 11:46:40 -0700

Hello,
I have installed dtn-2.9.0 and have deployed it on a network where I am
checking it for connections which last for a very short time and then get
disconnected. So I am currently using dtncpd and dtncp to transfer files
from one node to another. However when the link is put down for some time
and if I send a lot of files(even as less as 10) and then the link is put
up it takes a lot of time for the files to get received by the dtncpd. As
per our observations, the time taken was dependent on the duration for
which the link was down and the number of files sent. Is there any
configuration through which I can change this. Can it be made to tranfer
atleast some files rather than nothing at all, because the application
won't be possible if transfer doesn't happen in short duration.
Along the lines I read: the RFC 5050 <https://tools.ietf.org/html/rfc5050>
Bundle Protocol specification includes "bulk", "normal", and "expedited"
markings. Does dtncpd have this which might help me in solving the above
problem?

Thanks
Rucha

---

From: Vangelis Anifantis <[email-masked]>
Date: Mon, 13 Jul 2015 00:24:13 +0300

Dear Rucha,

The time needed for recovering a link disruption depends on the
retry_interval parameter which stands for the seconds to wait between
attempts to re-open an unavailable link. It is initially set to
min_retry_interval and then doubles up to max_retry_interval. Thus, by
configuring, e.g., using the link command, the min_retry_interval and
the max_retry_interval, you can overcome your prob and achieve a quick
link recovery based on your needs (see also
http://dtn.sourceforge.net/DTN2/doc/manual/configuration.html#link ).

Best Regards,
--vangelis

-- 

OpenPGP public key ID: 
pub  4096R/A97BA940 <https://pgp.mit.edu/pks/lookup?op=get&search=0xDFB631A0A97BA940> 2014-11-15 Evangelos Anifantis <[email-masked]> <https://pgp.mit.edu/pks/lookup?op=vindex&fingerprint=on&search=0xDFB631A0A97BA940>
	 Fingerprint=9759 E043 8873 9FD3 D095  C717 DFB6 31A0 A97B A940 

On 7/12/2015 9:46 PM, Rucha Vaidya wrote:
> Hello,
> I have installed dtn-2.9.0 and have deployed it on a network where I
> am checking it for connections which last for a very short time and
> then get disconnected. So I am currently using dtncpd and dtncp to
> transfer files from one node to another. However when the link is put
> down for some time and if I send a lot of files(even as less as 10)
> and then the link is put up it takes a lot of time for the files to
> get received by the dtncpd. As per our observations, the time taken
> was dependent on the duration for which the link was down and the
> number of files sent. Is there any configuration through which I can
> change this. Can it be made to tranfer atleast some files rather than
> nothing at all, because the application won't be possible if transfer
> doesn't happen in short duration.
> Along the lines I read: the RFC 5050
> <https://tools.ietf.org/html/rfc5050> Bundle Protocol specification
> includes "bulk", "normal", and "expedited" markings. Does dtncpd have
> this which might help me in solving the above problem?
>
> Thanks
> Rucha
>
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-users

---

From: Carlo Caini <[email-masked]>
Date: Tue, 14 Jul 2015 09:51:56 +0200

Dear Rucha,
    you can find some insights on DTN2 channel probing here:

C. Caini, R. Firrincieli, M. Livini, "DTN Bundle Layer over TCP: 
Retransmission Algorithms in the Presence of Channel Disruptions", in 
Journal of Communications (JCM), Academy Publisher, special issue on 
Delay Tolerant Networks, Architecture, and Applications, Vol. 5, N. 
2, pp. 106-116, February, 2010.

In brief, a disruption slow down bundle delivery because of:
1) the channel is not available during the disruption, as obvious;
2) the availability of the channel is probed at given (exponentially 
increasing until a ceiling is reached) intervals. Therefore there is 
a delay between channel availability and recognition at bundle layer 
of this availability (on average a half of the retry interval); see 
the response by Vangelis on how to reduce this;
3) if you use TCP at convergence layer, a brand new TCP connection is 
open when a probing attempt is successful; this connection has the 
CWND set to the minumum and it may take some time, in the presence of 
long RTTs, to increase enough to exploit the bandwidth available at 
physical layer; this effect, as said, is strongly related to your 
RTT. It is significant for GEO satellite channels (RTT= about 600ms), 
much less for terrestrial connections.

Two other considerations:
1) scheduled links are not actually implemented in DTN2 (there is 
only a stub); they could be useful if you knew the contacts in advance;
2) to the better of my knowledge (maybe I am wrong) priorities can be 
set but standard static routers does not enforce them in DTN2. 
Anyway, priorities would not have any effect if all the traffic had 
the same priority, as likely in your case.

Yours,
     Carlo

At 20:46 12/07/2015, Rucha Vaidya wrote:
>transfer files from one node to another. However when the link is 
>put down for some time and if I send a lot of files(even as less as 
>10) and then the link is put up it takes a lot of time for the files 
>to get received by the dtncpd. As per our observations, the time 
>taken was dependent on the duration for which the link was down and 
>the number of files sent. Is there any configuration through which I 
>can change this. Can it be made to tranfer atleast some files rather 
>than nothing at all, because the application won't be possible if 
>transfer doesn't happen in short duration.
>Along the lines I read: the <https://tools.ietf.org/html/rfc5050>RFC 
>5050 Bundle Protocol specification includes "bulk", "normal", and 
>"expedited" markings. Does dtncpd have this which might help me in 
>solving the above problem?
>
>Thanks
>[]
>Rucha