From nobody Sun Jul 12 11:46:43 2015 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6214C1A87CD for ; Sun, 12 Jul 2015 11:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.653 X-Spam-Level: ** X-Spam-Status: No, score=2.653 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YW0kuMmnd5Y for ; Sun, 12 Jul 2015 11:46:41 -0700 (PDT) Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A88E1A87CC for ; Sun, 12 Jul 2015 11:46:41 -0700 (PDT) Received: by vnbf190 with SMTP id f190so26599292vnb.6 for ; Sun, 12 Jul 2015 11:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EqQPBg77ic07M7I5qS/VHQmM1ams3Zwyu6ZpohMZ9hc=; b=fGYoJYc6a1kcCZOEAF0SWlLh0JnetcMiqcYSj+rOfKD5+yxoVamYJd+upwbPlkQ+g7 7AzzpD0l1m9qSHbovXn33yL3gzEytYfJeibgP7MIRy812WU15RORBxMm8SnnHdPZwCWw KCuXcTMnCHT+4nFMLf0cAeHe7irUs+sXu/eNb6kn4CMzDX1b02NR0oHNdaHdD1SMZJdY wD1nJt+bsBppSSdpHx2SBWH0wEUhG72vFrQJSCW+ZSFeRdkXeYgVvp6FgLt64MmmYFrt pzs0H7v+yTbzoV9UZGU5YPIwrcbyMW4TN0E/qY9r99hzs0HmDumRGMSxs1pDn/tTeRjB TC0g== MIME-Version: 1.0 X-Received: by 10.52.3.230 with SMTP id f6mr27871220vdf.49.1436726800192; Sun, 12 Jul 2015 11:46:40 -0700 (PDT) Received: by 10.31.54.19 with HTTP; Sun, 12 Jul 2015 11:46:40 -0700 (PDT) Date: Sun, 12 Jul 2015 11:46:40 -0700 Message-ID: From: Rucha Vaidya To: dtn-users@irtf.org Content-Type: multipart/alternative; boundary=485b397dd5ef909a27051ab206c6 Archived-At: Subject: [dtn-users] Delay in receiving files due to link down X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 18:46:42 -0000 --485b397dd5ef909a27051ab206c6 Content-Type: text/plain; charset=UTF-8 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 Bundle Protocol specification includes "bulk", "normal", and "expedited" markings. Does dtncpd have this which might help me in solving the above problem? Thanks Rucha --485b397dd5ef909a27051ab206c6 Content-Type: text/html; charset=UTF-8
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 Bundle Protocol specification includes "bulk", "normal", and "expedited" markings. Does dtncpd have this which might help me in solving the above problem?

Thanks
Rucha
--485b397dd5ef909a27051ab206c6-- From nobody Sun Jul 12 14:24:34 2015 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B49B1A00B7 for ; Sun, 12 Jul 2015 14:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.391 X-Spam-Level: * X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTIV8OowP1OM for ; Sun, 12 Jul 2015 14:24:30 -0700 (PDT) Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8EE1A0058 for ; Sun, 12 Jul 2015 14:24:29 -0700 (PDT) Received: from netmode.ece.ntua.gr (dolly.netmode.ece.ntua.gr [147.102.13.10]) by ulysses.noc.ntua.gr (8.15.1/8.15.1) with ESMTPS id t6CLOSHN095179 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 13 Jul 2015 00:24:28 +0300 (EEST) (envelope-from vangelis@netmode.ntua.gr) X-Authentication-Warning: ulysses.noc.ntua.gr: Host dolly.netmode.ece.ntua.gr [147.102.13.10] claimed to be netmode.ece.ntua.gr Received: from [192.168.1.4] (46-205-217.adsl.cyta.gr [46.103.205.217]) (authenticated bits=0) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id t6CLOE7M005607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 13 Jul 2015 00:24:15 +0300 (EEST) (envelope-from vangelis@netmode.ntua.gr) Message-ID: <55A2DAFD.7080004@netmode.ntua.gr> Date: Mon, 13 Jul 2015 00:24:13 +0300 From: Vangelis Anifantis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dtn-users@irtf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000900020505070108090807" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (ulysses.noc.ntua.gr [147.102.222.230]); Mon, 13 Jul 2015 00:24:28 +0300 (EEST) X-Virus-Scanned: clamav-milter 0.98.6 at ulysses.noc.ntua.gr X-Virus-Status: Clean Archived-At: Subject: Re: [dtn-users] Delay in receiving files due to link down X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 21:24:32 -0000 This is a multi-part message in MIME format. --------------000900020505070108090807 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 --=20 OpenPGP public key ID:=20 pub 4096R/A97BA940 2014-11-15 Evangelos Anifantis Fingerprint=3D9759 E043 8873 9FD3 D095 C717 DFB6 31A0 A97B A940=20 =09 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 > 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 > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users --------------000900020505070108090807 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 2014-11-15 Evangelos Anifantis <vangelis@netmode.ntua.gr>
	 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 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
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users


--------------000900020505070108090807-- From nobody Tue Jul 14 00:52:07 2015 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414AA1A902E for ; Tue, 14 Jul 2015 00:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.917 X-Spam-Level: *** X-Spam-Status: No, score=3.917 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_54=0.6, RCVD_IN_BRBL_LASTEXT=1.449, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUnnmzaigX7S for ; Tue, 14 Jul 2015 00:52:04 -0700 (PDT) Received: from mx01.unibo.it (mx01.unibo.it [137.204.24.54]) by ietfa.amsl.com (Postfix) with ESMTP id 14D1E1A902C for ; Tue, 14 Jul 2015 00:52:03 -0700 (PDT) X-AuditID: 89cc1836-f79676d000004656-7e-55a4bfa2d350 Received: from mail.unibo.it (e10-hc4-dr.unibo.loc [10.11.1.42]) by mx01.unibo.it (UNIBO) with SMTP id 47.F3.18006.2AFB4A55; Tue, 14 Jul 2015 09:52:02 +0200 (CEST) Received: from ccaini-PC.unibo.it (137.204.143.2) by mail.unibo.it (10.11.1.42) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 14 Jul 2015 09:52:01 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Jul 2015 09:51:56 +0200 To: Rucha Vaidya , From: Carlo Caini In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <9f967b6f-c509-411d-bb1e-aa3e150a112b@E10-HC4-DR.personale.dir.unibo.it> X-Originating-IP: [137.204.143.2] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsXCxc2opbto/5JQg82dchZX775isjjU187i wOSxc9Zddo/JGw+zBTBFcdskJZaUBWem5+nbJXBnXP54m6XgjXjFl50/2BsY5wp3MXJySAiY SNxce4QRwhaTuHBvPVsXIxeHkMBSRontv76wQDiLGSWuHvsElOEAqjKU2L6ABaSBRUBV4uPj bUwgtoiAo8Sf119ZQWw2AQ2Jg7cus4OUCws4Sfy4EAcS5hQIkVi8dRUbiC0kECCxbd4rZhCb V0BQ4uTMJywg5cwC1hLrH2VBhMMklj/8wwxRriix7tAUqDMVJXau2sg+gVFgFpLuWQjdCxiZ VjGKFeem6xYnJ+YZ6iUX65XmZSbl6+XkJ29iBAZf5xkJsx2Mq867HWKU5GBSEuX9s3BJqBBf Un5KZUZicUZ8UWlOavEhRhkODiUJXuF9QDnBotT01Iq0zBxgHMCkmTg4DzFKcHBJiRSn5qWk FiWWlmTEg0I8vhgY5CApHiURXm+Qdt7igsRcoChE6ylGRSlxXneQhABIIqM0D26sEth5/Uyv GMU5GJWEeSVBqniAcQ/X/QpoMBPQ4Llii0AGlyQipKQaGBlSIy689NnF/kJP4vKaMv5nUTPv Lwm6OP2us0CR7Re9eG6bjeV97+6Yxayq65rbFv6lsOlw7fq20zvmC7JZNpw7sKHRvS/4U9zL 93N6VmXPmv/haXLJbJUOjp4DF9qXpEpVPS/gYLd5fvrQ0nNTdP8FifaYH469yPBeS+xuYXy5 gUPM1oPZR5VYijMSDbWYi4oTAaFnmM64AgAA Archived-At: Subject: Re: [dtn-users] Delay in receiving files due to link down X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 07:52:06 -0000 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: >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 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 >dtn-users@irtf.org >https://www.irtf.org/mailman/listinfo/dtn-users