From nobody Fri Dec 12 16:02:45 2014 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 E80191A1AB9 for ; Fri, 12 Dec 2014 16:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VnwTuXCTmD7l for ; Fri, 12 Dec 2014 16:02:40 -0800 (PST) Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]) by ietfa.amsl.com (Postfix) with ESMTP id A517D1A07BD for ; Fri, 12 Dec 2014 16:02:39 -0800 (PST) Received: from netmode.ece.ntua.gr (dolly.netmode.ece.ntua.gr [147.102.13.10]) by ulysses.noc.ntua.gr (8.14.5/8.14.5) with ESMTP id sBD02anY075079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Dec 2014 02:02:37 +0200 (EET) (envelope-from vangelis@netmode.ntua.gr) Received: from [147.102.13.130] (dhcp-130.netmode.ece.ntua.gr [147.102.13.130]) (authenticated bits=0) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id sBD028jX061269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 13 Dec 2014 02:02:09 +0200 (EET) (envelope-from vangelis@netmode.ntua.gr) Message-ID: <548B81FD.7030500@netmode.ntua.gr> Date: Sat, 13 Dec 2014 02:02:05 +0200 From: Vangelis Anifantis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" , "dtn-users@irtf.org" References: <544124B9.9010600@netmode.ntua.gr> <94CFB3711B4CAE4DBFC5BEB3374BF0C6131741@NDMSMBX404.ndc.nasa.gov> In-Reply-To: <94CFB3711B4CAE4DBFC5BEB3374BF0C6131741@NDMSMBX404.ndc.nasa.gov> Content-Type: multipart/alternative; boundary="------------010403090200080108010204" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ulysses.noc.ntua.gr [147.102.222.230]); Sat, 13 Dec 2014 02:02:37 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97.5 at ulysses.noc.ntua.gr X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-users/VSOn-g73eLPXO7yQ4dWu2sZmuJ0 Subject: Re: [dtn-users] DTN2 custody signal handling 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: Sat, 13 Dec 2014 00:02:44 -0000 This is a multi-part message in MIME format. --------------010403090200080108010204 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello David, Thanks for your response. It actually helps a lot, since it answers my question regarding the custody signal handling from the administrative element. However, on the subject of the Custody Timer, I still have problems on setting the custody timer default values using the param command (e.g., param set custody_timer_max 1000). It seems that I cannot manually override the default values by using the command "param" (it has been validated by the debug logs, the forwarding log of each bundle, as well as in practice by measuring the retransmission delay). Following your suggestion/implementation, I have changed the timeout calculation in the CustodyTimer.cc so as to cover my own needs and it works fine, but it would be convenient for me to be able to change on-the-fly the min/max values via the param command. May i miss any configuration setup (or external package) that prevent my dtn installation (i have not used any special customization) from this kind of functionality? I would appreciate any help. Regards, Vangelis Anifantis On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote: > Hi Vangelis, > Since the bundles are displaying as (NOT PENDING) the custody signal wa= s actually processed by the administrative element (AdminRegistration.cc)= =2E=20 > The initial bundles remain in the all_bundles list because the Custody = Timer still has a reference to the bundle - when the timer expires the bu= ndle will be deleted. The Custody Signal remains in the all_bundles and p= ending list because AdminRegistration does not update the fwdlog to indic= ate that the bundle was delivered. > > I have not noticed a functional issue after changing the custody timer = default values using the param command but may not have paid close enough= attention. It could just be a logging issue but I can't say for sure.=20 > > While on the subject of the Custody Timer, I will say that I do not lik= e the implementation which sets the timeout to the min plus the percentag= e and then overrides that with the max if appropriate. We changed ours so= that it starts with the percentage and then overrides with the min and m= ax if needed. > > Hope this helps a bit, > DZ > > -----Original Message----- > From: dtn-users [mailto:dtn-users-bounces@irtf.org] On Behalf Of Vangel= is Anifantis > Sent: Friday, October 17, 2014 9:16 AM > To: dtn-users@irtf.org > Subject: [dtn-users] DTN2 custody signal handling > > hello, > > I have been recently playing around with DTN2 (dtn2.9.0 version) refere= nce implementation to better understand the custody transfer capability (= e.g., sending a bundle via dtnsend with activated the option -c). > > What i am seeing is that, as expected, each dtn node in the communicati= on chain accepts the custody request, becomes the custodian and sends bac= k a custody signal administrative record to indicate "custody_succeeded s= et to 1" (with indications regarding custody timer parameters as configur= ed in the current custodian). However, I observe that the custody signal = is not handled (neither received) by the administrative element, thus, re= maining on the "all_bundles list" and "pending list"; and consequently, t= he bundle protocol agent does not follow the custody transfer success pro= cedure by deleting the initial bundle (i.e., there is still a reference o= n the "all_bundles list"=20 > regarding the initial bundle with indication (NOT PENDING)). Do i miss = any configuration setup regarding the administrative element which is dee= med necessary? > > Furthermore, even though I have set manually (custody_timer_min, custod= y_timer_lifetime_pct, custody_timer_max) at all dtn nodes to differ from= the default values, the forwarding log of the initial generated bundle k= eeps displaying the default values, e.g., e.g., > forwarding log: > TRANSMITTED -> link_name [dtn:none] FORWARD at 1412929830.5129= 9 [custody min 1800 pct 25 max 0] Why is this happening? > > Thanks in advance for any help. > > Regards, > Vangelis Anifantis > > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users > --=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 =09 --------------010403090200080108010204 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hello David,

Thanks for your response. It actually helps a lot, since it answers my question regarding the custody signal handling from the administrative element.

However, on the subject of the Custody Timer, I still have problems on setting the custody timer default values using the param command (e.g., param set custody_timer_max 1000). It seems that I cannot manually override the default values by using the command "param" (it has been validated by the debug logs, the forwarding log of each bundle, as well as in practice by measuring the retransmission delay).

Following your suggestion/implementation, I have changed the timeout calculation in the CustodyTimer.cc so as to cover my own needs and it works fine, but it would be convenient for me to be able to change on-the-fly the min/max values via the param command. May i miss any configuration setup (or external package) that prevent my dtn installation (i have not used any special customization) from this kind of functionality?

I would appreciate any help.

Regards,
Vangelis Anifantis


On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote:
Hi Vangelis,
Since the bundles are displaying as (NOT PENDING) the custody signal was actually processed by the administrative element (AdminRegistration.cc). 
The initial bundles remain in the all_bundles list because the Custody Timer still has a reference to the bundle - when the timer expires the bundle will be deleted. The Custody Signal remains in the all_bundles and pending list because AdminRegistration does not update the fwdlog to indicate that the bundle was delivered.

I have not noticed a functional issue after changing the custody timer default values using the param command but may not have paid close enough attention. It could just be a logging issue but I can't say for sure. 

While on the subject of the Custody Timer, I will say that I do not like the implementation which sets the timeout to the min plus the percentage and then overrides that with the max if appropriate. We changed ours so that it starts with the percentage and then overrides with the min and max if needed.

Hope this helps a bit,
DZ

-----Original Message-----
From: dtn-users [mailto:dtn-users-bounces@irtf.org] On Behalf Of Vangelis Anifantis
Sent: Friday, October 17, 2014 9:16 AM
To: dtn-users@irtf.org
Subject: [dtn-users] DTN2 custody signal handling

hello,

I have been recently playing around with DTN2 (dtn2.9.0 version) reference implementation to better understand the custody transfer capability (e.g., sending a bundle via dtnsend with activated the option -c).

What i am seeing is that, as expected, each dtn node in the communication chain accepts the custody request, becomes the custodian and sends back a custody signal administrative record to indicate "custody_succeeded set to 1" (with indications regarding custody timer parameters as configured in the current custodian). However, I observe that the custody signal is not handled (neither received) by the administrative element, thus, remaining on the "all_bundles list" and "pending list"; and consequently, the bundle protocol agent does not follow the custody transfer success procedure by deleting the initial bundle (i.e., there is still a reference on the "all_bundles list" 
regarding the initial bundle with indication (NOT PENDING)). Do i miss any configuration setup regarding the administrative element which is deemed necessary?

Furthermore, even though I have set manually (custody_timer_min, custody_timer_lifetime_pct,  custody_timer_max) at all dtn nodes to differ from the default values, the forwarding log of the initial generated bundle keeps displaying the default values, e.g., e.g.,
  forwarding log:
         TRANSMITTED -> link_name [dtn:none] FORWARD at 1412929830.51299 [custody min 1800 pct 25 max 0] Why is this happening?

Thanks in advance for any help.

Regards,
Vangelis Anifantis

_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users
-- 
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

--------------010403090200080108010204-- From nobody Sun Dec 14 02:26:14 2014 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 4C7541A6F2B for ; Sun, 14 Dec 2014 02:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JigpJl_fwjgf for ; Sun, 14 Dec 2014 02:26:06 -0800 (PST) Received: from diomedes.noc.ntua.gr (diomedes.noc.ntua.gr [IPv6:2001:648:2000:de::220]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9921A6F2A for ; Sun, 14 Dec 2014 02:26:05 -0800 (PST) Received: from netmode.ece.ntua.gr (dolly.netmode.ece.ntua.gr [147.102.13.10]) by diomedes.noc.ntua.gr (8.14.5/8.14.5) with ESMTP id sBEAQ3JT059371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Dec 2014 12:26:03 +0200 (EET) (envelope-from vangelis@netmode.ntua.gr) Received: from [192.168.1.4] (178-242-48.dynamic.cyta.gr [178.59.242.48]) (authenticated bits=0) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id sBEAPaA6096332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 14 Dec 2014 12:25:37 +0200 (EET) (envelope-from vangelis@netmode.ntua.gr) Message-ID: <548D65A0.2040601@netmode.ntua.gr> Date: Sun, 14 Dec 2014 12:25:36 +0200 From: Vangelis Anifantis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" , "dtn-users@irtf.org" References: <544124B9.9010600@netmode.ntua.gr> <94CFB3711B4CAE4DBFC5BEB3374BF0C6131741@NDMSMBX404.ndc.nasa.gov> <548B81FD.7030500@netmode.ntua.gr> In-Reply-To: <548B81FD.7030500@netmode.ntua.gr> Content-Type: multipart/alternative; boundary="------------090706080107070800090601" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (diomedes.noc.ntua.gr [147.102.222.220]); Sun, 14 Dec 2014 12:26:03 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97.5 at diomedes.noc.ntua.gr X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-users/U2aBBeo2_Eb1Yn3bDY7UmqQ0Jas Subject: Re: [dtn-users] DTN2 custody signal handling 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, 14 Dec 2014 10:26:11 -0000 This is a multi-part message in MIME format. --------------090706080107070800090601 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Just for the records, I have finally found out what was going on regarding the param command. For my testing scenarios I used a static routing scheme by which each bundle was forwarded to a predetermined link. To create disruptions, I used to shut down the dtnd daemon of the remote dtn node. In this case, each generated bundle was directly forwarded to the predetermined link (as specified in the route entry by the initial configuration file), where the custody timers (i.e., min, lifetime_pct, max) had values equal to the ones at the time of the specific route entry creation/definition (for my case, the route entry was static and created by the initial dtn.conf, namely, before any param command reconfiguration). Thus, I always noticed the default custody timer values ([custody min 1800 pct 25 max 0]). In case that I change the custody timer values (using param), and then I re-create the route entry, e.g., route del dtn://node20.dtn/* route add dtn://node20.dtn/* link_0 any new custodian bundle will be bound with the new custody timer values (as set using the param command). Besides, I have also noticed that a custody timer is not rescheduled. Specifically, if the custody_timeout fires and the bundle is not successfully delivered to the next custodian node, the custody_timeout is not rescheduled so as to try a new retransmission of the bundle in the future (does this make sense?). Regards, Vangelis Anifantis On 12/13/2014 2:02 AM, Vangelis Anifantis wrote: > Hello David, > > Thanks for your response. It actually helps a lot, since it answers my > question regarding the custody signal handling from the administrative > element. > > However, on the subject of the Custody Timer, I still have problems on > setting the custody timer default values using the param command > (e.g., param set custody_timer_max 1000). It seems that I cannot > manually override the default values by using the command "param" (it > has been validated by the debug logs, the forwarding log of each > bundle, as well as in practice by measuring the retransmission delay). > > Following your suggestion/implementation, I have changed the timeout > calculation in the CustodyTimer.cc so as to cover my own needs and it > works fine, but it would be convenient for me to be able to change > on-the-fly the min/max values via the param command. May i miss any > configuration setup (or external package) that prevent my dtn > installation (i have not used any special customization) from this > kind of functionality? > > I would appreciate any help. > > Regards, > Vangelis Anifantis > > > On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES > CONTRACT] wrote: >> Hi Vangelis, >> Since the bundles are displaying as (NOT PENDING) the custody signal was actually processed by the administrative element (AdminRegistration.cc). >> The initial bundles remain in the all_bundles list because the Custody Timer still has a reference to the bundle - when the timer expires the bundle will be deleted. The Custody Signal remains in the all_bundles and pending list because AdminRegistration does not update the fwdlog to indicate that the bundle was delivered. >> >> I have not noticed a functional issue after changing the custody timer default values using the param command but may not have paid close enough attention. It could just be a logging issue but I can't say for sure. >> >> While on the subject of the Custody Timer, I will say that I do not like the implementation which sets the timeout to the min plus the percentage and then overrides that with the max if appropriate. We changed ours so that it starts with the percentage and then overrides with the min and max if needed. >> >> Hope this helps a bit, >> DZ >> >> -----Original Message----- >> From: dtn-users [mailto:dtn-users-bounces@irtf.org] On Behalf Of Vangelis Anifantis >> Sent: Friday, October 17, 2014 9:16 AM >> To: dtn-users@irtf.org >> Subject: [dtn-users] DTN2 custody signal handling >> >> hello, >> >> I have been recently playing around with DTN2 (dtn2.9.0 version) reference implementation to better understand the custody transfer capability (e.g., sending a bundle via dtnsend with activated the option -c). >> >> What i am seeing is that, as expected, each dtn node in the communication chain accepts the custody request, becomes the custodian and sends back a custody signal administrative record to indicate "custody_succeeded set to 1" (with indications regarding custody timer parameters as configured in the current custodian). However, I observe that the custody signal is not handled (neither received) by the administrative element, thus, remaining on the "all_bundles list" and "pending list"; and consequently, the bundle protocol agent does not follow the custody transfer success procedure by deleting the initial bundle (i.e., there is still a reference on the "all_bundles list" >> regarding the initial bundle with indication (NOT PENDING)). Do i miss any configuration setup regarding the administrative element which is deemed necessary? >> >> Furthermore, even though I have set manually (custody_timer_min, custody_timer_lifetime_pct, custody_timer_max) at all dtn nodes to differ from the default values, the forwarding log of the initial generated bundle keeps displaying the default values, e.g., e.g., >> forwarding log: >> TRANSMITTED -> link_name [dtn:none] FORWARD at 1412929830.51299 [custody min 1800 pct 25 max 0] Why is this happening? >> >> Thanks in advance for any help. >> >> Regards, >> Vangelis Anifantis >> >> _______________________________________________ >> dtn-users mailing list >> dtn-users@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-users >> > -- > OpenPGP public key ID: > pub 4096R/A97BA940 2014-11-15 Evangelos Anifantis > Fingerprint=9759 E043 8873 9FD3 D095 C717 DFB6 31A0 A97B A940 > > > --------------090706080107070800090601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Just for the records, I have finally found out what was going on regarding the param command.

For my testing scenarios I used a static routing scheme by which each bundle was forwarded to a predetermined link. To create disruptions, I used to shut down the dtnd daemon of the remote dtn node. In this case, each generated bundle was directly forwarded to the predetermined link (as specified in the route entry by the initial configuration file), where the custody timers (i.e., min, lifetime_pct, max) had values equal to the ones at the time of the specific route entry creation/definition (for my case, the route entry was static and created by the initial dtn.conf, namely, before any param command reconfiguration). Thus, I always noticed the default custody timer values ([custody min 1800 pct 25 max 0]).

In case that I change the custody timer values (using param), and then I re-create the route entry, e.g.,
route del dtn://node20.dtn/*
route add dtn://node20.dtn/* link_0
any new custodian bundle will be bound with the new custody timer values (as set using the param command).

Besides, I have also noticed that a custody timer is not rescheduled. Specifically, if the custody_timeout fires and the bundle is not successfully delivered to the next custodian node, the custody_timeout is not rescheduled so as to try a new retransmission of the bundle in the future (does this make sense?).

Regards,
Vangelis Anifantis


On 12/13/2014 2:02 AM, Vangelis Anifantis wrote:
Hello David,

Thanks for your response. It actually helps a lot, since it answers my question regarding the custody signal handling from the administrative element.

However, on the subject of the Custody Timer, I still have problems on setting the custody timer default values using the param command (e.g., param set custody_timer_max 1000). It seems that I cannot manually override the default values by using the command "param" (it has been validated by the debug logs, the forwarding log of each bundle, as well as in practice by measuring the retransmission delay).

Following your suggestion/implementation, I have changed the timeout calculation in the CustodyTimer.cc so as to cover my own needs and it works fine, but it would be convenient for me to be able to change on-the-fly the min/max values via the param command. May i miss any configuration setup (or external package) that prevent my dtn installation (i have not used any special customization) from this kind of functionality?

I would appreciate any help.

Regards,
Vangelis Anifantis


On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote:
Hi Vangelis,
Since the bundles are displaying as (NOT PENDING) the custody signal was actually processed by the administrative element (AdminRegistration.cc). 
The initial bundles remain in the all_bundles list because the Custody Timer still has a reference to the bundle - when the timer expires the bundle will be deleted. The Custody Signal remains in the all_bundles and pending list because AdminRegistration does not update the fwdlog to indicate that the bundle was delivered.

I have not noticed a functional issue after changing the custody timer default values using the param command but may not have paid close enough attention. It could just be a logging issue but I can't say for sure. 

While on the subject of the Custody Timer, I will say that I do not like the implementation which sets the timeout to the min plus the percentage and then overrides that with the max if appropriate. We changed ours so that it starts with the percentage and then overrides with the min and max if needed.

Hope this helps a bit,
DZ

-----Original Message-----
From: dtn-users [mailto:dtn-users-bounces@irtf.org] On Behalf Of Vangelis Anifantis
Sent: Friday, October 17, 2014 9:16 AM
To: dtn-users@irtf.org
Subject: [dtn-users] DTN2 custody signal handling

hello,

I have been recently playing around with DTN2 (dtn2.9.0 version) reference implementation to better understand the custody transfer capability (e.g., sending a bundle via dtnsend with activated the option -c).

What i am seeing is that, as expected, each dtn node in the communication chain accepts the custody request, becomes the custodian and sends back a custody signal administrative record to indicate "custody_succeeded set to 1" (with indications regarding custody timer parameters as configured in the current custodian). However, I observe that the custody signal is not handled (neither received) by the administrative element, thus, remaining on the "all_bundles list" and "pending list"; and consequently, the bundle protocol agent does not follow the custody transfer success procedure by deleting the initial bundle (i.e., there is still a reference on the "all_bundles list" 
regarding the initial bundle with indication (NOT PENDING)). Do i miss any configuration setup regarding the administrative element which is deemed necessary?

Furthermore, even though I have set manually (custody_timer_min, custody_timer_lifetime_pct,  custody_timer_max) at all dtn nodes to differ from the default values, the forwarding log of the initial generated bundle keeps displaying the default values, e.g., e.g.,
  forwarding log:
         TRANSMITTED -> link_name [dtn:none] FORWARD at 1412929830.51299 [custody min 1800 pct 25 max 0] Why is this happening?

Thanks in advance for any help.

Regards,
Vangelis Anifantis

_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users
-- 
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


--------------090706080107070800090601-- From nobody Mon Dec 15 06:50:15 2014 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 63B821A6F5B for ; Mon, 15 Dec 2014 06:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7-Yfod4S6B55 for ; Mon, 15 Dec 2014 06:50:08 -0800 (PST) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0BD1A1B64 for ; Mon, 15 Dec 2014 06:50:08 -0800 (PST) Received: from ndmsppt103.ndc.nasa.gov (ndmsppt103.ndc.nasa.gov [198.117.0.68]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 6F12F26005A; Mon, 15 Dec 2014 08:50:07 -0600 (CST) Received: from NDMSCHT112.ndc.nasa.gov (ndmscht112-pub.ndc.nasa.gov [198.117.0.212]) by ndmsppt103.ndc.nasa.gov (8.14.7/8.14.7) with ESMTP id sBFEo7O3018677; Mon, 15 Dec 2014 08:50:07 -0600 Received: from NDMSMBX404.ndc.nasa.gov ([169.254.1.68]) by NDMSCHT112.ndc.nasa.gov ([198.117.0.212]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 08:50:07 -0600 From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" To: Vangelis Anifantis , "dtn-users@irtf.org" Thread-Topic: [dtn-users] DTN2 custody signal handling Thread-Index: AQHP6hUPkdQ7fepR00uUzvS8flw0WJw0W2vggFkFDoCAAkCLAIABYjeg Date: Mon, 15 Dec 2014 14:50:06 +0000 Message-ID: <94CFB3711B4CAE4DBFC5BEB3374BF0C616935F@NDMSMBX404.ndc.nasa.gov> References: <544124B9.9010600@netmode.ntua.gr> <94CFB3711B4CAE4DBFC5BEB3374BF0C6131741@NDMSMBX404.ndc.nasa.gov> <548B81FD.7030500@netmode.ntua.gr> <548D65A0.2040601@netmode.ntua.gr> In-Reply-To: <548D65A0.2040601@netmode.ntua.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.119.225.186] Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C616935FNDMSMBX404ndcnasa_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-15_02:2014-12-15,2014-12-15,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-users/3iOYQzCq8OjbYkrumzGFgzz26nY Subject: Re: [dtn-users] DTN2 custody signal handling 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: Mon, 15 Dec 2014 14:50:14 -0000 --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C616935FNDMSMBX404ndcnasa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Vangelis, Thanks for digging into and figuring out how the custody timer specs and ro= ute specs interrelate. It looks like it would be useful to be able to overr= ide custody spec params on the "route add" command and possibly to implemen= t a "route reconfigure" command to change them on the fly. A custody timer is started for the bundle as part of the BundleDaemon's pro= cessing of the BundleTransmitted event which the convergence layer issues. = When a custody_timeout fires, the bundle should be re-routed and transmitte= d resulting in another BundleTransmitted event being issued resulting in st= arting a new custody timer. If there is not an open connection when the cus= tody_timeout fires, then the bundle should either be queued as deferred on = a known link(s) or there may not be a link to add it to at the time. If the= known link eventually establishes its connection then the bundle should be= transmitted which starts the next custody timer. If a new link is establis= hed then all pending bundles are checked to see if they can be routed throu= gh the new connection which when transmitted would start a new custody time= r. Basically, the custody timer is only started after it is known that the bun= dle has been transmitted. There is a special case in the comments in Bundle= Daemon::handle_bundle_transmitted() if configured to wait for reliable tran= smission that could result in returning without starting a new custody time= r which should issue a warning "XXX/demmer fixme transmitted special case". Could you be hitting the special case? Or, can you provide more detail on the custody timer not being rescheduled = scenario including which convergence layer? Regards, DZ From: Vangelis Anifantis [mailto:vangelis@netmode.ntua.gr] Sent: Sunday, December 14, 2014 4:26 AM To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; dtn-users@irtf.or= g Subject: Re: [dtn-users] DTN2 custody signal handling Just for the records, I have finally found out what was going on regarding = the param command. For my testing scenarios I used a static routing scheme by which each bundl= e was forwarded to a predetermined link. To create disruptions, I used to s= hut down the dtnd daemon of the remote dtn node. In this case, each generat= ed bundle was directly forwarded to the predetermined link (as specified in= the route entry by the initial configuration file), where the custody time= rs (i.e., min, lifetime_pct, max) had values equal to the ones at the time = of the specific route entry creation/definition (for my case, the route ent= ry was static and created by the initial dtn.conf, namely, before any param= command reconfiguration). Thus, I always noticed the default custody timer= values ([custody min 1800 pct 25 max 0]). In case that I change the custody timer values (using param), and then I re= -create the route entry, e.g., route del dtn://node20.dtn/* route add dtn://node20.dtn/* link_0 any new custodian bundle will be bound with the new custody timer values (a= s set using the param command). Besides, I have also noticed that a custody timer is not rescheduled. Speci= fically, if the custody_timeout fires and the bundle is not successfully de= livered to the next custodian node, the custody_timeout is not rescheduled = so as to try a new retransmission of the bundle in the future (does this ma= ke sense?). Regards, Vangelis Anifantis On 12/13/2014 2:02 AM, Vangelis Anifantis wrote: Hello David, Thanks for your response. It actually helps a lot, since it answers my ques= tion regarding the custody signal handling from the administrative element. However, on the subject of the Custody Timer, I still have problems on sett= ing the custody timer default values using the param command (e.g., param s= et custody_timer_max 1000). It seems that I cannot manually override the de= fault values by using the command "param" (it has been validated by the deb= ug logs, the forwarding log of each bundle, as well as in practice by measu= ring the retransmission delay). Following your suggestion/implementation, I have changed the timeout calcul= ation in the CustodyTimer.cc so as to cover my own needs and it works fine,= but it would be convenient for me to be able to change on-the-fly the min/= max values via the param command. May i miss any configuration setup (or ex= ternal package) that prevent my dtn installation (i have not used any speci= al customization) from this kind of functionality? I would appreciate any help. Regards, Vangelis Anifantis On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT= ] wrote: Hi Vangelis, Since the bundles are displaying as (NOT PENDING) the custody signal was ac= tually processed by the administrative element (AdminRegistration.cc). The initial bundles remain in the all_bundles list because the Custody Time= r still has a reference to the bundle - when the timer expires the bundle w= ill be deleted. The Custody Signal remains in the all_bundles and pending l= ist because AdminRegistration does not update the fwdlog to indicate that t= he bundle was delivered. I have not noticed a functional issue after changing the custody timer defa= ult values using the param command but may not have paid close enough atten= tion. It could just be a logging issue but I can't say for sure. While on the subject of the Custody Timer, I will say that I do not like th= e implementation which sets the timeout to the min plus the percentage and = then overrides that with the max if appropriate. We changed ours so that it= starts with the percentage and then overrides with the min and max if need= ed. Hope this helps a bit, DZ -----Original Message----- From: dtn-users [mailto:dtn-users-bounces@irtf.org] On Behalf Of Vangelis A= nifantis Sent: Friday, October 17, 2014 9:16 AM To: dtn-users@irtf.org Subject: [dtn-users] DTN2 custody signal handling hello, I have been recently playing around with DTN2 (dtn2.9.0 version) reference = implementation to better understand the custody transfer capability (e.g., = sending a bundle via dtnsend with activated the option -c). What i am seeing is that, as expected, each dtn node in the communication c= hain accepts the custody request, becomes the custodian and sends back a cu= stody signal administrative record to indicate "custody_succeeded set to 1"= (with indications regarding custody timer parameters as configured in the = current custodian). However, I observe that the custody signal is not handl= ed (neither received) by the administrative element, thus, remaining on the= "all_bundles list" and "pending list"; and consequently, the bundle protoc= ol agent does not follow the custody transfer success procedure by deleting= the initial bundle (i.e., there is still a reference on the "all_bundles l= ist" regarding the initial bundle with indication (NOT PENDING)). Do i miss any = configuration setup regarding the administrative element which is deemed ne= cessary? Furthermore, even though I have set manually (custody_timer_min, custody_ti= mer_lifetime_pct, custody_timer_max) at all dtn nodes to differ from the d= efault values, the forwarding log of the initial generated bundle keeps dis= playing the default values, e.g., e.g., forwarding log: TRANSMITTED -> link_name [dtn:none] FORWARD at 1412929830.51299 [c= ustody min 1800 pct 25 max 0] Why is this happening? Thanks in advance for any help. Regards, Vangelis Anifantis _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users -- OpenPGP public key ID: pub 4096R/A97BA940 2014-11-15 Evangelos Anifantis Fingerprint=3D9759 E043 8873 9FD3 D095 C717 DFB6 31A0 A97B A940 --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C616935FNDMSMBX404ndcnasa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Vangelis,

Thanks for digging into a= nd figuring out how the custody timer specs and route specs interrelate. It= looks like it would be useful to be able to override custody spec params on the “route add” command and possibly to impleme= nt a “route reconfigure” command to change them on the fly.

 <= /p>

A custody timer is starte= d for the bundle as part of the BundleDaemon’s processing of the Bund= leTransmitted event which the convergence layer issues. When a custody_timeout fires, the bundle should be re-routed and transmitted resu= lting in another BundleTransmitted event being issued resulting in starting= a new custody timer. If there is not an open connection when the custody_t= imeout fires, then the bundle should either be queued as deferred on a known link(s) or there may not be a link= to add it to at the time. If the known link eventually establishes its con= nection then the bundle should be transmitted which starts the next custody= timer. If a new link is established then all pending bundles are checked to see if they can be routed through = the new connection which when transmitted would start a new custody timer.<= o:p>

 <= /p>

Basically, the custody ti= mer is only started after it is known that the bundle has been transmitted.= There is a special case in the comments in BundleDaemon::handle_bundle_tra= nsmitted() if configured to wait for reliable transmission that could result in retur= ning without starting a new custody timer which should issue a warning R= 20;XXX/demmer fixme transmitted special case”.

 <= /p>

Could you be hitting the = special case?

Or, can you provide more = detail on the custody timer not being rescheduled scenario including which = convergence layer?  

Regards,

DZ

 <= /p>

 <= /p>

From: Vangelis Anifantis [mailto:vangelis@netmode.ntua.= gr]
Sent: Sunday, December 14, 2014 4:26 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; dtn-users@= irtf.org
Subject: Re: [dtn-users] DTN2 custody signal handling

 

Just for the records,= I have finally found out what was going on regarding the param command.

For my testing scenarios I used a static routing scheme by which each bundl= e was forwarded to a predetermined link. To create disruptions, I used to s= hut down the dtnd daemon of the remote dtn node. In this case, each generat= ed bundle was directly forwarded to the predetermined link (as specified in the route entry by the initial = configuration file), where the custody timers (i.e., min, lifetime_pct, max= ) had values equal to the ones at the time of the specific route entry crea= tion/definition (for my case, the route entry was static and created by the initial dtn.conf, namely, before= any param command reconfiguration). Thus, I always noticed the default cus= tody timer values ([custody min 1800 pct 25 max 0]).

In case that I change the custody timer values (using param), and then I re= -create the route entry, e.g.,
route del dtn://node20.dtn/*
route add dtn://node20.dtn/* link_0
any new custodian bundle will be bound with the new custody timer values (a= s set using the param command).

Besides, I have also noticed that a custody timer is not rescheduled. Speci= fically, if the custody_timeout fires and the bundle is not successfully de= livered to the next custodian node, the custody_timeout is not rescheduled = so as to try a new retransmission of the bundle in the future (does this make sense?).

Regards,
Vangelis Anifantis

On 12/13/2014 2:02 AM, Vangelis Anifantis wrote:

Hello David,

Thanks for your response. It actually helps a lot, since it answers my ques= tion regarding the custody signal handling from the administrative element.=

However, on the subject of the Custody Timer, I still have problems on sett= ing the custody timer default values using the param command (e.g., param s= et custody_timer_max 1000). It seems that I cannot manually override the de= fault values by using the command "param" (it has been validated by the debug logs, the forwarding= log of each bundle, as well as in practice by measuring the retransmission= delay).

Following your suggestion/implementation, I have changed the timeout calcul= ation in the CustodyTimer.cc so as to cover my own needs and it works fine,= but it would be convenient for me to be able to change on-the-fly the min/= max values via the param command. May i miss any configuration setup (or external package) that prevent my d= tn installation (i have not used any special customization) from this kind = of functionality?

I would appreciate any help.

Regards,
Vangelis Anifantis

On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)= [HOSC SERVICES CONTRACT] wrote:

Hi Vangelis,
Since the bundles are displaying as (NOT PENDING) the custody signal w=
as actually processed by the administrative element (AdminRegistration.cc).=
 
The initial bundles remain in the all_bundles list because the Custody=
 Timer still has a reference to the bundle - when the timer expires the bun=
dle will be deleted. The Custody Signal remains in the all_bundles and pend=
ing list because AdminRegistration does not update the fwdlog to indicate t=
hat the bundle was delivered.
 
I have not noticed a functional issue after changing the custody timer=
 default values using the param command but may not have paid close enough =
attention. It could just be a logging issue but I can't say for sure. =

 
While on the subject of the Custody Timer, I will say that I do not li=
ke the implementation which sets the timeout to the min plus the percentage=
 and then overrides that with the max if appropriate. We changed ours so th=
at it starts with the percentage and then overrides with the min and max if=
 needed.
 
Hope this helps a bit,
DZ
 
-----Original Message-----
From: dtn-users [mailto:=
dtn-users-bounces@irtf.org] On Behalf Of Vangelis Anifantis<=
/pre>

Sent: Friday, October 17, 2014 9:16 AM


To: dtn-users@irtf.org<=
/o:p>


Subject: [dtn-users] DTN2 custody signal handling


 


hello,


 


I have been recently playing around with DTN2 (dtn2.9.0 version) refer=
ence implementation to better understand the custody transfer capability (e=
.g., sending a bundle via dtnsend with activated the option -c).=



 


What i am seeing is that, as expected, each dtn node in the communicat=
ion chain accepts the custody request, becomes the custodian and sends back=
 a custody signal administrative record to indicate "custody_succeeded=
 set to 1" (with indications regarding custody timer parameters as con=
figured in the current custodian). However, I observe that the custody sign=
al is not handled (neither received) by the administrative element, thus, r=
emaining on the "all_bundles list" and "pending list"; =
and consequently, the bundle protocol agent does not follow the custody tra=
nsfer success procedure by deleting the initial bundle (i.e., there is stil=
l a reference on the "all_bundles list" 


regarding the initial bundle with indication (NOT PENDING)). Do i miss=
 any configuration setup regarding the administrative element which is deem=
ed necessary?


 


Furthermore, even though I have set manually (custody_timer_min, custo=
dy_timer_lifetime_pct,  custody_timer_max) at all dtn nodes to differ =
from the default values, the forwarding log of the initial generated bundle=
 keeps displaying the default values, e.g., e.g.,


  forwarding log:


         TRANSMITTED -> lin=
k_name [dtn:none] FORWARD at 1412929830.51299 [custody min 1800 pct 25 max =
0] Why is this happening?


 


Thanks in advance for any help.


 


Regards,


Vangelis Anifantis


 


_______________________________________________


dtn-users mailing list


dtn-users@irtf.org


https://ww=
w.irtf.org/mailman/listinfo/dtn-users


 

-- 

OpenPGP public key ID: 

pub  4096R/A97BA940 2014-=
11-15 Evangelos Anifantis <vangelis@net=
mode.ntua.gr>


   Fingerprint=3D9759 E043 8873 9FD3 D=
095  C717 DFB6 31A0 A97B A940 


  


 

 

--_000_94CFB3711B4CAE4DBFC5BEB3374BF0C616935FNDMSMBX404ndcnasa_-- From nobody Sat Dec 20 11:15:32 2014 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 536681A88CF for ; Sat, 20 Dec 2014 11:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MSZPE7BjvSyG for ; Sat, 20 Dec 2014 11:15:26 -0800 (PST) Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCCB1A878A for ; Sat, 20 Dec 2014 11:15:25 -0800 (PST) Received: from netmode.ece.ntua.gr (dolly.netmode.ece.ntua.gr [147.102.13.10]) by ulysses.noc.ntua.gr (8.14.5/8.14.5) with ESMTP id sBKJFNHi078604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Dec 2014 21:15:24 +0200 (EET) (envelope-from vangelis@netmode.ntua.gr) Received: from [147.102.13.49] (dimitra.netmode.ece.ntua.gr [147.102.13.49]) (authenticated bits=0) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id sBKJEvFw078627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 Dec 2014 21:14:57 +0200 (EET) (envelope-from vangelis@netmode.ntua.gr) Message-ID: <5495CAAC.3000501@netmode.ntua.gr> Date: Sat, 20 Dec 2014 21:14:52 +0200 From: Vangelis Anifantis User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" , "dtn-users@irtf.org" References: <544124B9.9010600@netmode.ntua.gr> <94CFB3711B4CAE4DBFC5BEB3374BF0C6131741@NDMSMBX404.ndc.nasa.gov> <548B81FD.7030500@netmode.ntua.gr> <548D65A0.2040601@netmode.ntua.gr> <94CFB3711B4CAE4DBFC5BEB3374BF0C616935F@NDMSMBX404.ndc.nasa.gov> In-Reply-To: <94CFB3711B4CAE4DBFC5BEB3374BF0C616935F@NDMSMBX404.ndc.nasa.gov> Content-Type: multipart/alternative; boundary="------------070809080906070701080003" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ulysses.noc.ntua.gr [147.102.222.230]); Sat, 20 Dec 2014 21:15:24 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97.5 at ulysses.noc.ntua.gr X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-users/_aV5rkYGGFeDJdoThHNxcYIZhi0 Subject: Re: [dtn-users] DTN2 custody signal handling 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: Sat, 20 Dec 2014 19:15:31 -0000 This is a multi-part message in MIME format. --------------070809080906070701080003 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello David, Thanks again for your response. The problem with the custody timer not being rescheduled happens with the UDPconvergenceLayer. To reproduce the problem with the custody timer rescheduling, consider a trivial scenario: Let assume two dtn nodes (node A and node B) communicating using udp convergence layer and via a static routing. By using "link dump" I observe the corresponding link, e.g., my_link ONDEMAND udp state=AVAILABLE. Now, shut down the dtnd in node B and then send a bundle with custody transfer enabled from node A to node B. I observe that the custody_timer is started. When it fires, node A attempts to retransmit the bundle and now i have a debug message [1419099989.900814 CustodyTimer 0xb4416a60 info] CustodyTimer::timeout [1419099989.940186 UDPConvergenceLayer::Sender 0xb4404e24 error] send_bundle: error sending bundle (wrote -1/110): Connection refused Then, the bundle remains in the "custody_bundles" list and it is added to the list "my_link:queue". Now on, it would be never been retransmitted again. Start the dtnd daemon at node B. The bundle remains as custodian in node A, but it would not be rescheduled for retransmission. Sorry, I have not checked if i hit the special case that you mentioned in the previous mail. I will check it out and i ll come back soon. p.s. By using the TCP convergence layer, the problem does not exist. Regards, Vangelis On 12/15/2014 4:50 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote: > > Hello Vangelis, > > Thanks for digging into and figuring out how the custody timer specs > and route specs interrelate. It looks like it would be useful to be > able to override custody spec params on the “route add” command and > possibly to implement a “route reconfigure” command to change them on > the fly. > > A custody timer is started for the bundle as part of the > BundleDaemon’s processing of the BundleTransmitted event which the > convergence layer issues. When a custody_timeout fires, the bundle > should be re-routed and transmitted resulting in another > BundleTransmitted event being issued resulting in starting a new > custody timer. If there is not an open connection when the > custody_timeout fires, then the bundle should either be queued as > deferred on a known link(s) or there may not be a link to add it to at > the time. If the known link eventually establishes its connection then > the bundle should be transmitted which starts the next custody timer. > If a new link is established then all pending bundles are checked to > see if they can be routed through the new connection which when > transmitted would start a new custody timer. > > Basically, the custody timer is only started after it is known that > the bundle has been transmitted. There is a special case in the > comments in BundleDaemon::handle_bundle_transmitted() if configured to > wait for reliable transmission that could result in returning without > starting a new custody timer which should issue a warning “XXX/demmer > fixme transmitted special case”. > > Could you be hitting the special case? > > Or, can you provide more detail on the custody timer not being > rescheduled scenario including which convergence layer? > > Regards, > > DZ > > *From:*Vangelis Anifantis [mailto:vangelis@netmode.ntua.gr] > *Sent:* Sunday, December 14, 2014 4:26 AM > *To:* Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; > dtn-users@irtf.org > *Subject:* Re: [dtn-users] DTN2 custody signal handling > > Just for the records, I have finally found out what was going on > regarding the param command. > > For my testing scenarios I used a static routing scheme by which each > bundle was forwarded to a predetermined link. To create disruptions, I > used to shut down the dtnd daemon of the remote dtn node. In this > case, each generated bundle was directly forwarded to the > predetermined link (as specified in the route entry by the initial > configuration file), where the custody timers (i.e., min, > lifetime_pct, max) had values equal to the ones at the time of the > specific route entry creation/definition (for my case, the route entry > was static and created by the initial dtn.conf, namely, before any > param command reconfiguration). Thus, I always noticed the default > custody timer values ([custody min 1800 pct 25 max 0]). > > In case that I change the custody timer values (using param), and then > I re-create the route entry, e.g., > route del dtn://node20.dtn/* > route add dtn://node20.dtn/* link_0 > any new custodian bundle will be bound with the new custody timer > values (as set using the param command). > > Besides, I have also noticed that a custody timer is not rescheduled. > Specifically, if the custody_timeout fires and the bundle is not > successfully delivered to the next custodian node, the custody_timeout > is not rescheduled so as to try a new retransmission of the bundle in > the future (does this make sense?). > > Regards, > Vangelis Anifantis > > On 12/13/2014 2:02 AM, Vangelis Anifantis wrote: > > Hello David, > > Thanks for your response. It actually helps a lot, since it > answers my question regarding the custody signal handling from the > administrative element. > > However, on the subject of the Custody Timer, I still have > problems on setting the custody timer default values using the > param command (e.g., param set custody_timer_max 1000). It seems > that I cannot manually override the default values by using the > command "param" (it has been validated by the debug logs, the > forwarding log of each bundle, as well as in practice by measuring > the retransmission delay). > > Following your suggestion/implementation, I have changed the > timeout calculation in the CustodyTimer.cc so as to cover my own > needs and it works fine, but it would be convenient for me to be > able to change on-the-fly the min/max values via the param > command. May i miss any configuration setup (or external package) > that prevent my dtn installation (i have not used any special > customization) from this kind of functionality? > > I would appreciate any help. > > Regards, > Vangelis Anifantis > > On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES > CONTRACT] wrote: > > Hi Vangelis, > > Since the bundles are displaying as (NOT PENDING) the custody signal was actually processed by the administrative element (AdminRegistration.cc). > > The initial bundles remain in the all_bundles list because the Custody Timer still has a reference to the bundle - when the timer expires the bundle will be deleted. The Custody Signal remains in the all_bundles and pending list because AdminRegistration does not update the fwdlog to indicate that the bundle was delivered. > > > > I have not noticed a functional issue after changing the custody timer default values using the param command but may not have paid close enough attention. It could just be a logging issue but I can't say for sure. > > > > While on the subject of the Custody Timer, I will say that I do not like the implementation which sets the timeout to the min plus the percentage and then overrides that with the max if appropriate. We changed ours so that it starts with the percentage and then overrides with the min and max if needed. > > > > Hope this helps a bit, > > DZ > > > > -----Original Message----- > > From: dtn-users [mailto:dtn-users-bounces@irtf.org] On Behalf Of Vangelis Anifantis > > Sent: Friday, October 17, 2014 9:16 AM > > To:dtn-users@irtf.org > > Subject: [dtn-users] DTN2 custody signal handling > > > > hello, > > > > I have been recently playing around with DTN2 (dtn2.9.0 version) reference implementation to better understand the custody transfer capability (e.g., sending a bundle via dtnsend with activated the option -c). > > > > What i am seeing is that, as expected, each dtn node in the communication chain accepts the custody request, becomes the custodian and sends back a custody signal administrative record to indicate "custody_succeeded set to 1" (with indications regarding custody timer parameters as configured in the current custodian). However, I observe that the custody signal is not handled (neither received) by the administrative element, thus, remaining on the "all_bundles list" and "pending list"; and consequently, the bundle protocol agent does not follow the custody transfer success procedure by deleting the initial bundle (i.e., there is still a reference on the "all_bundles list" > > regarding the initial bundle with indication (NOT PENDING)). Do i miss any configuration setup regarding the administrative element which is deemed necessary? > > > > Furthermore, even though I have set manually (custody_timer_min, custody_timer_lifetime_pct, custody_timer_max) at all dtn nodes to differ from the default values, the forwarding log of the initial generated bundle keeps displaying the default values, e.g., e.g., > > forwarding log: > > TRANSMITTED -> link_name [dtn:none] FORWARD at 1412929830.51299 [custody min 1800 pct 25 max 0] Why is this happening? > > > > Thanks in advance for any help. > > > > Regards, > > Vangelis Anifantis > > > > _______________________________________________ > > dtn-users mailing list > > dtn-users@irtf.org > > https://www.irtf.org/mailman/listinfo/dtn-users > > > > -- > > OpenPGP public key ID: > > pub 4096R/A97BA940 2014-11-15Evangelos Anifantis > > Fingerprint=9759 E043 8873 9FD3 D095 C717 DFB6 31A0 A97B A940 > > > > > > > --------------070809080906070701080003 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hello David,

Thanks again for your response.
The problem with the custody timer not being rescheduled happens with the UDPconvergenceLayer. To reproduce the problem with the custody timer rescheduling, consider a trivial scenario:
Let assume two dtn nodes (node A and node B) communicating using udp convergence layer and via a static routing. By using "link dump" I observe the corresponding link, e.g., my_link  ONDEMAND udp state=AVAILABLE. Now,  shut down the dtnd in node B and then send a bundle with custody transfer enabled from node A to node B. I observe that the custody_timer is started. When it fires, node A attempts to retransmit the bundle and now i have a debug message
[1419099989.900814 CustodyTimer 0xb4416a60 info] CustodyTimer::timeout     
[1419099989.940186 UDPConvergenceLayer::Sender 0xb4404e24 error] send_bundle: error sending bundle (wrote -1/110): Connection refused 
Then, the bundle remains in the "custody_bundles" list and it is added to the list "my_link:queue". Now on, it would be never been retransmitted again. Start the dtnd daemon at node B. The bundle remains as custodian in node A, but it would not be rescheduled for retransmission.

Sorry, I have not checked if i hit the special case that you mentioned in the previous mail. I will check it out and i ll come back soon.

p.s. By using the TCP convergence layer, the problem does not exist.

Regards,
Vangelis

On 12/15/2014 4:50 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote:

Hello Vangelis,

Thanks for digging into and figuring out how the custody timer specs and route specs interrelate. It looks like it would be useful to be able to override custody spec params on the “route add” command and possibly to implement a “route reconfigure” command to change them on the fly.

 

A custody timer is started for the bundle as part of the BundleDaemon’s processing of the BundleTransmitted event which the convergence layer issues. When a custody_timeout fires, the bundle should be re-routed and transmitted resulting in another BundleTransmitted event being issued resulting in starting a new custody timer. If there is not an open connection when the custody_timeout fires, then the bundle should either be queued as deferred on a known link(s) or there may not be a link to add it to at the time. If the known link eventually establishes its connection then the bundle should be transmitted which starts the next custody timer. If a new link is established then all pending bundles are checked to see if they can be routed through the new connection which when transmitted would start a new custody timer.

 

Basically, the custody timer is only started after it is known that the bundle has been transmitted. There is a special case in the comments in BundleDaemon::handle_bundle_transmitted() if configured to wait for reliable transmission that could result in returning without starting a new custody timer which should issue a warning “XXX/demmer fixme transmitted special case”.

 

Could you be hitting the special case?

Or, can you provide more detail on the custody timer not being rescheduled scenario including which convergence layer?  

Regards,

DZ

 

 

From: Vangelis Anifantis [mailto:vangelis@netmode.ntua.gr]
Sent: Sunday, December 14, 2014 4:26 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; dtn-users@irtf.org
Subject: Re: [dtn-users] DTN2 custody signal handling

 

Just for the records, I have finally found out what was going on regarding the param command.

For my testing scenarios I used a static routing scheme by which each bundle was forwarded to a predetermined link. To create disruptions, I used to shut down the dtnd daemon of the remote dtn node. In this case, each generated bundle was directly forwarded to the predetermined link (as specified in the route entry by the initial configuration file), where the custody timers (i.e., min, lifetime_pct, max) had values equal to the ones at the time of the specific route entry creation/definition (for my case, the route entry was static and created by the initial dtn.conf, namely, before any param command reconfiguration). Thus, I always noticed the default custody timer values ([custody min 1800 pct 25 max 0]).

In case that I change the custody timer values (using param), and then I re-create the route entry, e.g.,
route del dtn://node20.dtn/*
route add dtn://node20.dtn/* link_0
any new custodian bundle will be bound with the new custody timer values (as set using the param command).

Besides, I have also noticed that a custody timer is not rescheduled. Specifically, if the custody_timeout fires and the bundle is not successfully delivered to the next custodian node, the custody_timeout is not rescheduled so as to try a new retransmission of the bundle in the future (does this make sense?).

Regards,
Vangelis Anifantis

On 12/13/2014 2:02 AM, Vangelis Anifantis wrote:

Hello David,

Thanks for your response. It actually helps a lot, since it answers my question regarding the custody signal handling from the administrative element.

However, on the subject of the Custody Timer, I still have problems on setting the custody timer default values using the param command (e.g., param set custody_timer_max 1000). It seems that I cannot manually override the default values by using the command "param" (it has been validated by the debug logs, the forwarding log of each bundle, as well as in practice by measuring the retransmission delay).

Following your suggestion/implementation, I have changed the timeout calculation in the CustodyTimer.cc so as to cover my own needs and it works fine, but it would be convenient for me to be able to change on-the-fly the min/max values via the param command. May i miss any configuration setup (or external package) that prevent my dtn installation (i have not used any special customization) from this kind of functionality?

I would appreciate any help.

Regards,
Vangelis Anifantis

On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote:

Hi Vangelis,
Since the bundles are displaying as (NOT PENDING) the custody signal was actually processed by the administrative element (AdminRegistration.cc). 
The initial bundles remain in the all_bundles list because the Custody Timer still has a reference to the bundle - when the timer expires the bundle will be deleted. The Custody Signal remains in the all_bundles and pending list because AdminRegistration does not update the fwdlog to indicate that the bundle was delivered.
 
I have not noticed a functional issue after changing the custody timer default values using the param command but may not have paid close enough attention. It could just be a logging issue but I can't say for sure. 
 
While on the subject of the Custody Timer, I will say that I do not like the implementation which sets the timeout to the min plus the percentage and then overrides that with the max if appropriate. We changed ours so that it starts with the percentage and then overrides with the min and max if needed.
 
Hope this helps a bit,
DZ
 
-----Original Message-----
From: dtn-users [mailto:dtn-users-bounces@irtf.org] On Behalf Of Vangelis Anifantis
Sent: Friday, October 17, 2014 9:16 AM
To: dtn-users@irtf.org
Subject: [dtn-users] DTN2 custody signal handling
 
hello,
 
I have been recently playing around with DTN2 (dtn2.9.0 version) reference implementation to better understand the custody transfer capability (e.g., sending a bundle via dtnsend with activated the option -c).
 
What i am seeing is that, as expected, each dtn node in the communication chain accepts the custody request, becomes the custodian and sends back a custody signal administrative record to indicate "custody_succeeded set to 1" (with indications regarding custody timer parameters as configured in the current custodian). However, I observe that the custody signal is not handled (neither received) by the administrative element, thus, remaining on the "all_bundles list" and "pending list"; and consequently, the bundle protocol agent does not follow the custody transfer success procedure by deleting the initial bundle (i.e., there is still a reference on the "all_bundles list" 
regarding the initial bundle with indication (NOT PENDING)). Do i miss any configuration setup regarding the administrative element which is deemed necessary?
 
Furthermore, even though I have set manually (custody_timer_min, custody_timer_lifetime_pct,  custody_timer_max) at all dtn nodes to differ from the default values, the forwarding log of the initial generated bundle keeps displaying the default values, e.g., e.g.,
  forwarding log:
         TRANSMITTED -> link_name [dtn:none] FORWARD at 1412929830.51299 [custody min 1800 pct 25 max 0] Why is this happening?
 
Thanks in advance for any help.
 
Regards,
Vangelis Anifantis
 
_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users
 

-- 

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 
  
 



 


--------------070809080906070701080003-- From nobody Fri Dec 26 08:07:41 2014 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 4431F1A8969 for ; Fri, 26 Dec 2014 08:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WA5s8R7H_aBm for ; Fri, 26 Dec 2014 08:07:31 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFC81A895E for ; Fri, 26 Dec 2014 08:07:31 -0800 (PST) Received: from ndmsppt102.ndc.nasa.gov (ndmsppt102.ndc.nasa.gov [198.117.0.67]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 39BA11829FA; Fri, 26 Dec 2014 10:07:30 -0600 (CST) Received: from NDMSCHT105.ndc.nasa.gov (ndmscht105-pub.ndc.nasa.gov [198.117.0.205]) by ndmsppt102.ndc.nasa.gov (8.14.7/8.14.7) with ESMTP id sBQG7Mah025100; Fri, 26 Dec 2014 10:07:29 -0600 Received: from NDMSMBX404.ndc.nasa.gov ([169.254.1.190]) by NDMSCHT105.ndc.nasa.gov ([198.117.0.205]) with mapi id 14.03.0195.001; Fri, 26 Dec 2014 10:07:22 -0600 From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" To: Vangelis Anifantis , "dtn-users@irtf.org" Thread-Topic: [dtn-users] DTN2 custody signal handling Thread-Index: AQHP6hUPkdQ7fepR00uUzvS8flw0WJw0W2vggFkFDoCAAkCLAIABYjeggAifpgCACLxB8A== Date: Fri, 26 Dec 2014 16:07:22 +0000 Message-ID: <94CFB3711B4CAE4DBFC5BEB3374BF0C61730AC@NDMSMBX404.ndc.nasa.gov> References: <544124B9.9010600@netmode.ntua.gr> <94CFB3711B4CAE4DBFC5BEB3374BF0C6131741@NDMSMBX404.ndc.nasa.gov> <548B81FD.7030500@netmode.ntua.gr> <548D65A0.2040601@netmode.ntua.gr> <94CFB3711B4CAE4DBFC5BEB3374BF0C616935F@NDMSMBX404.ndc.nasa.gov> <5495CAAC.3000501@netmode.ntua.gr> In-Reply-To: <5495CAAC.3000501@netmode.ntua.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.119.225.186] Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C61730ACNDMSMBX404ndcnasa_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-26_06:2014-12-24,2014-12-26,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-users/bjmIJuad181rFPbGzW6ozuL844E Subject: Re: [dtn-users] DTN2 custody signal handling 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: Fri, 26 Dec 2014 16:07:39 -0000 --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C61730ACNDMSMBX404ndcnasa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vangelis, Good catch! No need to check for the special case because you are not hitti= ng it. I experimented with the UDP CL and reproduced the issue just as you = outlined. After the connection refused error is generated, the state of the= Link remains "OPEN" so there is no attempt to ever re-establish the connec= tion. After bringing up node B again, if you send a new bundle then that bu= ndle will be sent but the original one remains queued at the Link level ins= tead of being sent. I think that to continue cleanly along the lines of the current implementat= ion would require at a minimum issuing an event to close the contact when a= n error is detected on the socket write. However, after reading through th= e latest specification for the UDP CL (RFC 7122), I do not see any reason t= o use a connected UDP socket and my opinion is that the UDP CL should be ch= anged to use an unconnected socket and it should always transmit bundles as= they are queued. It is fairly easy to change to using an unconnected socke= t: In UDPConvergenceLayer::Sender::init() * Insert these lines right after the line socket_.set_logfd(false): socket_.init_socket(); socket_.set_remote_addr(addr); socket_.set_remote_port(port); * Comment out or delete the socket_.connect() code block. In UDPConvergenceLayer::Sender::send_bundle() * Change the socket_.write to use sendto: int cc =3D socket_.sendto((char*)buf_, total_len, 0, socket_.remote_addr(), socket_.remote_port()); That is my take on it. Regards, DZ From: Vangelis Anifantis [mailto:vangelis@netmode.ntua.gr] Sent: Saturday, December 20, 2014 1:15 PM To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; dtn-users@irtf.or= g Subject: Re: [dtn-users] DTN2 custody signal handling Hello David, Thanks again for your response. The problem with the custody timer not being rescheduled happens with the U= DPconvergenceLayer. To reproduce the problem with the custody timer resched= uling, consider a trivial scenario: Let assume two dtn nodes (node A and node B) communicating using udp conver= gence layer and via a static routing. By using "link dump" I observe the co= rresponding link, e.g., my_link ONDEMAND udp state=3DAVAILABLE. Now, shut= down the dtnd in node B and then send a bundle with custody transfer enabl= ed from node A to node B. I observe that the custody_timer is started. When= it fires, node A attempts to retransmit the bundle and now i have a debug = message [1419099989.900814 CustodyTimer 0xb4416a60 info] CustodyTimer::timeout [1419099989.940186 UDPConvergenceLayer::Sender 0xb4404e24 error] send_bundl= e: error sending bundle (wrote -1/110): Connection refused Then, the bundle remains in the "custody_bundles" list and it is added to t= he list "my_link:queue". Now on, it would be never been retransmitted again= . Start the dtnd daemon at node B. The bundle remains as custodian in node = A, but it would not be rescheduled for retransmission. Sorry, I have not checked if i hit the special case that you mentioned in t= he previous mail. I will check it out and i ll come back soon. p.s. By using the TCP convergence layer, the problem does not exist. Regards, Vangelis On 12/15/2014 4:50 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]= wrote: Hello Vangelis, Thanks for digging into and figuring out how the custody timer specs and ro= ute specs interrelate. It looks like it would be useful to be able to overr= ide custody spec params on the "route add" command and possibly to implemen= t a "route reconfigure" command to change them on the fly. A custody timer is started for the bundle as part of the BundleDaemon's pro= cessing of the BundleTransmitted event which the convergence layer issues. = When a custody_timeout fires, the bundle should be re-routed and transmitte= d resulting in another BundleTransmitted event being issued resulting in st= arting a new custody timer. If there is not an open connection when the cus= tody_timeout fires, then the bundle should either be queued as deferred on = a known link(s) or there may not be a link to add it to at the time. If the= known link eventually establishes its connection then the bundle should be= transmitted which starts the next custody timer. If a new link is establis= hed then all pending bundles are checked to see if they can be routed throu= gh the new connection which when transmitted would start a new custody time= r. Basically, the custody timer is only started after it is known that the bun= dle has been transmitted. There is a special case in the comments in Bundle= Daemon::handle_bundle_transmitted() if configured to wait for reliable tran= smission that could result in returning without starting a new custody time= r which should issue a warning "XXX/demmer fixme transmitted special case". Could you be hitting the special case? Or, can you provide more detail on the custody timer not being rescheduled = scenario including which convergence layer? Regards, DZ From: Vangelis Anifantis [mailto:vangelis@netmode.ntua.gr] Sent: Sunday, December 14, 2014 4:26 AM To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; dtn-users@irtf.or= g Subject: Re: [dtn-users] DTN2 custody signal handling Just for the records, I have finally found out what was going on regarding = the param command. For my testing scenarios I used a static routing scheme by which each bundl= e was forwarded to a predetermined link. To create disruptions, I used to s= hut down the dtnd daemon of the remote dtn node. In this case, each generat= ed bundle was directly forwarded to the predetermined link (as specified in= the route entry by the initial configuration file), where the custody time= rs (i.e., min, lifetime_pct, max) had values equal to the ones at the time = of the specific route entry creation/definition (for my case, the route ent= ry was static and created by the initial dtn.conf, namely, before any param= command reconfiguration). Thus, I always noticed the default custody timer= values ([custody min 1800 pct 25 max 0]). In case that I change the custody timer values (using param), and then I re= -create the route entry, e.g., route del dtn://node20.dtn/* route add dtn://node20.dtn/* link_0 any new custodian bundle will be bound with the new custody timer values (a= s set using the param command). Besides, I have also noticed that a custody timer is not rescheduled. Speci= fically, if the custody_timeout fires and the bundle is not successfully de= livered to the next custodian node, the custody_timeout is not rescheduled = so as to try a new retransmission of the bundle in the future (does this ma= ke sense?). Regards, Vangelis Anifantis On 12/13/2014 2:02 AM, Vangelis Anifantis wrote: Hello David, Thanks for your response. It actually helps a lot, since it answers my ques= tion regarding the custody signal handling from the administrative element. However, on the subject of the Custody Timer, I still have problems on sett= ing the custody timer default values using the param command (e.g., param s= et custody_timer_max 1000). It seems that I cannot manually override the de= fault values by using the command "param" (it has been validated by the deb= ug logs, the forwarding log of each bundle, as well as in practice by measu= ring the retransmission delay). Following your suggestion/implementation, I have changed the timeout calcul= ation in the CustodyTimer.cc so as to cover my own needs and it works fine,= but it would be convenient for me to be able to change on-the-fly the min/= max values via the param command. May i miss any configuration setup (or ex= ternal package) that prevent my dtn installation (i have not used any speci= al customization) from this kind of functionality? I would appreciate any help. Regards, Vangelis Anifantis On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT= ] wrote: Hi Vangelis, Since the bundles are displaying as (NOT PENDING) the custody signal was ac= tually processed by the administrative element (AdminRegistration.cc). The initial bundles remain in the all_bundles list because the Custody Time= r still has a reference to the bundle - when the timer expires the bundle w= ill be deleted. The Custody Signal remains in the all_bundles and pending l= ist because AdminRegistration does not update the fwdlog to indicate that t= he bundle was delivered. I have not noticed a functional issue after changing the custody timer defa= ult values using the param command but may not have paid close enough atten= tion. It could just be a logging issue but I can't say for sure. While on the subject of the Custody Timer, I will say that I do not like th= e implementation which sets the timeout to the min plus the percentage and = then overrides that with the max if appropriate. We changed ours so that it= starts with the percentage and then overrides with the min and max if need= ed. Hope this helps a bit, DZ -----Original Message----- From: dtn-users [mailto:dtn-users-bounces@irtf.org] On Behalf Of Vangelis A= nifantis Sent: Friday, October 17, 2014 9:16 AM To: dtn-users@irtf.org Subject: [dtn-users] DTN2 custody signal handling hello, I have been recently playing around with DTN2 (dtn2.9.0 version) reference = implementation to better understand the custody transfer capability (e.g., = sending a bundle via dtnsend with activated the option -c). What i am seeing is that, as expected, each dtn node in the communication c= hain accepts the custody request, becomes the custodian and sends back a cu= stody signal administrative record to indicate "custody_succeeded set to 1"= (with indications regarding custody timer parameters as configured in the = current custodian). However, I observe that the custody signal is not handl= ed (neither received) by the administrative element, thus, remaining on the= "all_bundles list" and "pending list"; and consequently, the bundle protoc= ol agent does not follow the custody transfer success procedure by deleting= the initial bundle (i.e., there is still a reference on the "all_bundles l= ist" regarding the initial bundle with indication (NOT PENDING)). Do i miss any = configuration setup regarding the administrative element which is deemed ne= cessary? Furthermore, even though I have set manually (custody_timer_min, custody_ti= mer_lifetime_pct, custody_timer_max) at all dtn nodes to differ from the d= efault values, the forwarding log of the initial generated bundle keeps dis= playing the default values, e.g., e.g., forwarding log: TRANSMITTED -> link_name [dtn:none] FORWARD at 1412929830.51299 [c= ustody min 1800 pct 25 max 0] Why is this happening? Thanks in advance for any help. Regards, Vangelis Anifantis _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users -- OpenPGP public key ID: pub 4096R/A97BA940 2014-11-15 Evangelos Anifantis Fingerprint=3D9759 E043 8873 9FD3 D095 C717 DFB6 31A0 A97B A940 --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C61730ACNDMSMBX404ndcnasa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vangelis,

Good catch! No need to ch= eck for the special case because you are not hitting it. I experimented wit= h the UDP CL and reproduced the issue just as you outlined. After the connection refused error is generated, the state of the Link rem= ains “OPEN” so there is no attempt to ever re-establish the con= nection. After bringing up node B again, if you send a new bundle then that= bundle will be sent but the original one remains queued at the Link level instead of being sent.

 <= /p>

I think that to continue = cleanly along the lines of the current implementation would require at a mi= nimum issuing an event to close the contact when an error is detected on the socket write.  However, after reading through the = latest specification for the UDP CL (RFC 7122), I do not see any reason to = use a connected UDP socket and my opinion is that the UDP CL should be chan= ged to use an unconnected socket and it should always transmit bundles as they are queued. It is fairly easy to= change to using an unconnected socket:

 <= /p>

In UDPConvergenceLayer::S= ender::init()

·      = ;   Insert these line= s right after the line socket_.set_logfd(false):<= o:p>

socket_.i= nit_socket();

socket_.s= et_remote_addr(addr);

socket_.s= et_remote_port(port);

 

·      = ;   Comment out or de= lete the socket_.connect() code block.

 <= /p>

 <= /p>

In UDPConvergenceLayer::S= ender::send_bundle()

·      = ;   Change the socket= _.write to use sendto:

int cc =3D= socket_.sendto((char*)buf_, total_len, 0,

 &nbs= p;            &= nbsp;         socket_.remote_a= ddr(), socket_.remote_port());

 <= /p>

That is my take on it.

Regards,
DZ

 <= /p>

 <= /p>

From: Vangelis Anifantis [mailto:vangelis@netmode.ntua.= gr]
Sent: Saturday, December 20, 2014 1:15 PM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; dtn-users@= irtf.org
Subject: Re: [dtn-users] DTN2 custody signal handling

 

Hello David,

Thanks again for your response.
The problem with the custody timer not being rescheduled happens with the U= DPconvergenceLayer. To reproduce the problem with the custody timer resched= uling, consider a trivial scenario:
Let assume two dtn nodes (node A and node B) communicating using udp conver= gence layer and via a static routing. By using "link dump" I obse= rve the corresponding link, e.g., my_link  ONDEMAND udp state=3DAVAILA= BLE. Now,  shut down the dtnd in node B and then send a bundle with custody transfer enabled from node A to node B. I obser= ve that the custody_timer is started. When it fires, node A attempts to ret= ransmit the bundle and now i have a debug message
[1419099989.900814 CustodyTimer 0xb4416a60 info] CustodyTimer::timeout = ;    
[1419099989.940186 UDPConvergenceLayer::Sender 0xb4404e24 error] send_bundl= e: error sending bundle (wrote -1/110): Connection refused 
Then, the bundle remains in the "custody_bundles" list and it is = added to the list "my_link:queue". Now on, it would be never been= retransmitted again. Start the dtnd daemon at node B. The bundle remains a= s custodian in node A, but it would not be rescheduled for retransmission.

Sorry, I have not checked if i hit the special case that you mentioned in t= he previous mail. I will check it out and i ll come back soon.

p.s. By using the TCP convergence layer, the problem does not exist.

Regards,
Vangelis

On 12/15/2014 4:50 PM, Zoller, David A. (MSFC-EO50)[= HOSC SERVICES CONTRACT] wrote:

Hello Vangelis,

Thanks for digging into a= nd figuring out how the custody timer specs and route specs interrelate. It= looks like it would be useful to be able to override custody spec params on the “route add” command and possibly to impleme= nt a “route reconfigure” command to change them on the fly.

 <= /p>

A custody timer is starte= d for the bundle as part of the BundleDaemon’s processing of the Bund= leTransmitted event which the convergence layer issues. When a custody_timeout fires, the bundle should be re-routed and transmitted resu= lting in another BundleTransmitted event being issued resulting in starting= a new custody timer. If there is not an open connection when the custody_t= imeout fires, then the bundle should either be queued as deferred on a known link(s) or there may not be a link= to add it to at the time. If the known link eventually establishes its con= nection then the bundle should be transmitted which starts the next custody= timer. If a new link is established then all pending bundles are checked to see if they can be routed through = the new connection which when transmitted would start a new custody timer.<= /span>

 <= /p>

Basically, the custody ti= mer is only started after it is known that the bundle has been transmitted.= There is a special case in the comments in BundleDaemon::handle_bundle_tra= nsmitted() if configured to wait for reliable transmission that could result in retur= ning without starting a new custody timer which should issue a warning R= 20;XXX/demmer fixme transmitted special case”.

 <= /p>

Could you be hitting the = special case?

Or, can you provide more = detail on the custody timer not being rescheduled scenario including which = convergence layer?  

Regards,

DZ

 <= /p>

 <= /p>

From: Vangelis Anifantis [mailto:vangelis@netmode.ntua.gr]
Sent: Sunday, December 14, 2014 4:26 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; dtn-users@irtf.org
Subject: Re: [dtn-users] DTN2 custody signal handling

 

Just for the records,= I have finally found out what was going on regarding the param command.

For my testing scenarios I used a static routing scheme by which each bundl= e was forwarded to a predetermined link. To create disruptions, I used to s= hut down the dtnd daemon of the remote dtn node. In this case, each generat= ed bundle was directly forwarded to the predetermined link (as specified in the route entry by the initial = configuration file), where the custody timers (i.e., min, lifetime_pct, max= ) had values equal to the ones at the time of the specific route entry crea= tion/definition (for my case, the route entry was static and created by the initial dtn.conf, namely, before= any param command reconfiguration). Thus, I always noticed the default cus= tody timer values ([custody min 1800 pct 25 max 0]).

In case that I change the custody timer values (using param), and then I re= -create the route entry, e.g.,
route del dtn://node20.dtn/*
route add dtn://node20.dtn/* link_0
any new custodian bundle will be bound with the new custody timer values (a= s set using the param command).

Besides, I have also noticed that a custody timer is not rescheduled. Speci= fically, if the custody_timeout fires and the bundle is not successfully de= livered to the next custodian node, the custody_timeout is not rescheduled = so as to try a new retransmission of the bundle in the future (does this make sense?).

Regards,
Vangelis Anifantis


On 12/13/2014 2:02 AM, Vangelis Anifantis wrote:

Hello David,

Thanks for your response. It actually helps a lot, since it answers my ques= tion regarding the custody signal handling from the administrative element.=

However, on the subject of the Custody Timer, I still have problems on sett= ing the custody timer default values using the param command (e.g., param s= et custody_timer_max 1000). It seems that I cannot manually override the de= fault values by using the command "param" (it has been validated by the debug logs, the forwarding= log of each bundle, as well as in practice by measuring the retransmission= delay).

Following your suggestion/implementation, I have changed the timeout calcul= ation in the CustodyTimer.cc so as to cover my own needs and it works fine,= but it would be convenient for me to be able to change on-the-fly the min/= max values via the param command. May i miss any configuration setup (or external package) that prevent my d= tn installation (i have not used any special customization) from this kind = of functionality?

I would appreciate any help.

Regards,
Vangelis Anifantis


On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)= [HOSC SERVICES CONTRACT] wrote:

Hi Vangelis,
Since the bundles are displaying as (NOT PENDING) the custody signal w=
as actually processed by the administrative element (AdminRegistration.cc).=
 
The initial bundles remain in the all_bundles list because the Custody=
 Timer still has a reference to the bundle - when the timer expires the bun=
dle will be deleted. The Custody Signal remains in the all_bundles and pend=
ing list because AdminRegistration does not update the fwdlog to indicate t=
hat the bundle was delivered.
 
I have not noticed a functional issue after changing the custody timer=
 default values using the param command but may not have paid close enough =
attention. It could just be a logging issue but I can't say for sure. =

 
While on the subject of the Custody Timer, I will say that I do not li=
ke the implementation which sets the timeout to the min plus the percentage=
 and then overrides that with the max if appropriate. We changed ours so th=
at it starts with the percentage and then overrides with the min and max if=
 needed.
 
Hope this helps a bit,
DZ
 
-----Original Message-----
From: dtn-users [mailto:=
dtn-users-bounces@irtf.org] On Behalf Of Vangelis Anifantis<=
/pre>

Sent: Friday, October 17, 2014 9:16 AM


To: dtn-users@irtf.org<=
/o:p>


Subject: [dtn-users] DTN2 custody signal handling


 


hello,


 


I have been recently playing around with DTN2 (dtn2.9.0 version) refer=
ence implementation to better understand the custody transfer capability (e=
.g., sending a bundle via dtnsend with activated the option -c).=



 


What i am seeing is that, as expected, each dtn node in the communicat=
ion chain accepts the custody request, becomes the custodian and sends back=
 a custody signal administrative record to indicate "custody_succeeded=
 set to 1" (with indications regarding custody timer parameters as con=
figured in the current custodian). However, I observe that the custody sign=
al is not handled (neither received) by the administrative element, thus, r=
emaining on the "all_bundles list" and "pending list"; =
and consequently, the bundle protocol agent does not follow the custody tra=
nsfer success procedure by deleting the initial bundle (i.e., there is stil=
l a reference on the "all_bundles list" 


regarding the initial bundle with indication (NOT PENDING)). Do i miss=
 any configuration setup regarding the administrative element which is deem=
ed necessary?


 


Furthermore, even though I have set manually (custody_timer_min, custo=
dy_timer_lifetime_pct,  custody_timer_max) at all dtn nodes to differ =
from the default values, the forwarding log of the initial generated bundle=
 keeps displaying the default values, e.g., e.g.,


  forwarding log:


         TRANSMITTED -> lin=
k_name [dtn:none] FORWARD at 1412929830.51299 [custody min 1800 pct 25 max =
0] Why is this happening?


 


Thanks in advance for any help.


 


Regards,


Vangelis Anifantis


 


_______________________________________________


dtn-users mailing list


dtn-users@irtf.org


https://ww=
w.irtf.org/mailman/listinfo/dtn-users


 

-- 

OpenPGP public key ID: 

pub  4096R/A97BA940 2014-=
11-15 Evangelos Anifantis <vangelis@net=
mode.ntua.gr>


   Fingerprint=3D9759 E043 8873 9=
FD3 D095  C717 DFB6 31A0 A97B A940 


  


 

 

 

--_000_94CFB3711B4CAE4DBFC5BEB3374BF0C61730ACNDMSMBX404ndcnasa_-- From nobody Fri Dec 26 09:34:16 2014 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 178B61A90FD for ; Fri, 26 Dec 2014 09:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 So7WlONCyUZW for ; Fri, 26 Dec 2014 09:34:08 -0800 (PST) Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]) by ietfa.amsl.com (Postfix) with ESMTP id 686351A90D8 for ; Fri, 26 Dec 2014 09:34:07 -0800 (PST) Received: from netmode.ece.ntua.gr (dolly.netmode.ece.ntua.gr [147.102.13.10]) by ulysses.noc.ntua.gr (8.14.5/8.14.5) with ESMTP id sBQHY4CN099950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Dec 2014 19:34:05 +0200 (EET) (envelope-from vangelis@netmode.ntua.gr) Received: from [192.168.2.4] (ppp005055100099.access.hol.gr [5.55.100.99]) (authenticated bits=0) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id sBQHXb5R082714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 Dec 2014 19:33:38 +0200 (EET) (envelope-from vangelis@netmode.ntua.gr) Message-ID: <549D9BEF.7060503@netmode.ntua.gr> Date: Fri, 26 Dec 2014 19:33:35 +0200 From: Vangelis Anifantis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" , "dtn-users@irtf.org" References: <544124B9.9010600@netmode.ntua.gr> <94CFB3711B4CAE4DBFC5BEB3374BF0C6131741@NDMSMBX404.ndc.nasa.gov> <548B81FD.7030500@netmode.ntua.gr> <548D65A0.2040601@netmode.ntua.gr> <94CFB3711B4CAE4DBFC5BEB3374BF0C616935F@NDMSMBX404.ndc.nasa.gov> <5495CAAC.3000501@netmode.ntua.gr> <94CFB3711B4CAE4DBFC5BEB3374BF0C61730AC@NDMSMBX404.ndc.nasa.gov> In-Reply-To: <94CFB3711B4CAE4DBFC5BEB3374BF0C61730AC@NDMSMBX404.ndc.nasa.gov> Content-Type: multipart/alternative; boundary="------------000807030001010603050905" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ulysses.noc.ntua.gr [147.102.222.230]); Fri, 26 Dec 2014 19:34:05 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97.5 at ulysses.noc.ntua.gr X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-users/LSpEGusNAE2b73Ndr17yxu203dA Subject: Re: [dtn-users] DTN2 custody signal handling 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: Fri, 26 Dec 2014 17:34:14 -0000 This is a multi-part message in MIME format. --------------000807030001010603050905 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks a lot David for your time on addressing all my inquiries. Merry Christmas and a Happy New Year, --Vangelis On 12/26/2014 6:07 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote: > > Hi Vangelis, > > Good catch! No need to check for the special case because you are not > hitting it. I experimented with the UDP CL and reproduced the issue > just as you outlined. After the connection refused error is generated, > the state of the Link remains =93OPEN=94 so there is no attempt to ever= > re-establish the connection. After bringing up node B again, if you > send a new bundle then that bundle will be sent but the original one > remains queued at the Link level instead of being sent. > > =20 > > I think that to continue cleanly along the lines of the current > implementation would require at a minimum issuing an event to close > the contact when an error is detected on the socket write. However, > after reading through the latest specification for the UDP CL (RFC > 7122), I do not see any reason to use a connected UDP socket and my > opinion is that the UDP CL should be changed to use an unconnected > socket and it should always transmit bundles as they are queued. It is > fairly easy to change to using an unconnected socket: > > =20 > > In UDPConvergenceLayer::Sender::init() > > =B7 Insert these lines right after the line > socket_.set_logfd(false): > > socket_.init_socket(); > > socket_.set_remote_addr(addr); > > socket_.set_remote_port(port); > > =20 > > =B7 Comment out or delete the socket_.connect() code block. > > =20 > > =20 > > In UDPConvergenceLayer::Sender::send_bundle() > > =B7 Change the socket_.write to use sendto: > > int cc =3D socket_.sendto((char*)buf_, total_len, 0, > > socket_.remote_addr(), socket_.remote_port()); > > =20 > > That is my take on it. > > Regards, > DZ > > =20 > > =20 > > *From:*Vangelis Anifantis [mailto:vangelis@netmode.ntua.gr] > *Sent:* Saturday, December 20, 2014 1:15 PM > *To:* Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; > dtn-users@irtf.org > *Subject:* Re: [dtn-users] DTN2 custody signal handling > > =20 > > Hello David, > > Thanks again for your response. > The problem with the custody timer not being rescheduled happens with > the UDPconvergenceLayer. To reproduce the problem with the custody > timer rescheduling, consider a trivial scenario: > Let assume two dtn nodes (node A and node B) communicating using udp > convergence layer and via a static routing. By using "link dump" I > observe the corresponding link, e.g., my_link ONDEMAND udp > state=3DAVAILABLE. Now, shut down the dtnd in node B and then send a > bundle with custody transfer enabled from node A to node B. I observe > that the custody_timer is started. When it fires, node A attempts to > retransmit the bundle and now i have a debug message > [1419099989.900814 CustodyTimer 0xb4416a60 info] > CustodyTimer::timeout =20 > [1419099989.940186 UDPConvergenceLayer::Sender 0xb4404e24 error] > send_bundle: error sending bundle (wrote -1/110): Connection refused=20 > Then, the bundle remains in the "custody_bundles" list and it is added > to the list "my_link:queue". Now on, it would be never been > retransmitted again. Start the dtnd daemon at node B. The bundle > remains as custodian in node A, but it would not be rescheduled for > retransmission. > > Sorry, I have not checked if i hit the special case that you mentioned > in the previous mail. I will check it out and i ll come back soon. > > p.s. By using the TCP convergence layer, the problem does not exist. > > Regards, > Vangelis > > On 12/15/2014 4:50 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES > CONTRACT] wrote: > > Hello Vangelis, > > Thanks for digging into and figuring out how the custody timer > specs and route specs interrelate. It looks like it would be > useful to be able to override custody spec params on the =93route > add=94 command and possibly to implement a =93route reconfigure=94 > command to change them on the fly. > > =20 > > A custody timer is started for the bundle as part of the > BundleDaemon=92s processing of the BundleTransmitted event which th= e > convergence layer issues. When a custody_timeout fires, the bundle > should be re-routed and transmitted resulting in another > BundleTransmitted event being issued resulting in starting a new > custody timer. If there is not an open connection when the > custody_timeout fires, then the bundle should either be queued as > deferred on a known link(s) or there may not be a link to add it > to at the time. If the known link eventually establishes its > connection then the bundle should be transmitted which starts the > next custody timer. If a new link is established then all pending > bundles are checked to see if they can be routed through the new > connection which when transmitted would start a new custody timer. > > =20 > > Basically, the custody timer is only started after it is known > that the bundle has been transmitted. There is a special case in > the comments in BundleDaemon::handle_bundle_transmitted() if > configured to wait for reliable transmission that could result in > returning without starting a new custody timer which should issue > a warning =93XXX/demmer fixme transmitted special case=94. > > =20 > > Could you be hitting the special case? > > Or, can you provide more detail on the custody timer not being > rescheduled scenario including which convergence layer? =20 > > Regards, > > DZ > > =20 > > =20 > > *From:*Vangelis Anifantis [mailto:vangelis@netmode.ntua.gr] > *Sent:* Sunday, December 14, 2014 4:26 AM > *To:* Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; > dtn-users@irtf.org > *Subject:* Re: [dtn-users] DTN2 custody signal handling > > =20 > > Just for the records, I have finally found out what was going on > regarding the param command. > > For my testing scenarios I used a static routing scheme by which > each bundle was forwarded to a predetermined link. To create > disruptions, I used to shut down the dtnd daemon of the remote dtn > node. In this case, each generated bundle was directly forwarded > to the predetermined link (as specified in the route entry by the > initial configuration file), where the custody timers (i.e., min, > lifetime_pct, max) had values equal to the ones at the time of the > specific route entry creation/definition (for my case, the route > entry was static and created by the initial dtn.conf, namely, > before any param command reconfiguration). Thus, I always noticed > the default custody timer values ([custody min 1800 pct 25 max 0]).= > > In case that I change the custody timer values (using param), and > then I re-create the route entry, e.g., > route del dtn://node20.dtn/* > route add dtn://node20.dtn/* link_0 > any new custodian bundle will be bound with the new custody timer > values (as set using the param command). > > Besides, I have also noticed that a custody timer is not > rescheduled. Specifically, if the custody_timeout fires and the > bundle is not successfully delivered to the next custodian node, > the custody_timeout is not rescheduled so as to try a new > retransmission of the bundle in the future (does this make sense?).= > > Regards, > Vangelis Anifantis > > > On 12/13/2014 2:02 AM, Vangelis Anifantis wrote: > > Hello David, > > Thanks for your response. It actually helps a lot, since it > answers my question regarding the custody signal handling from > the administrative element. > > However, on the subject of the Custody Timer, I still have > problems on setting the custody timer default values using the > param command (e.g., param set custody_timer_max 1000). It > seems that I cannot manually override the default values by > using the command "param" (it has been validated by the debug > logs, the forwarding log of each bundle, as well as in > practice by measuring the retransmission delay). > > Following your suggestion/implementation, I have changed the > timeout calculation in the CustodyTimer.cc so as to cover my > own needs and it works fine, but it would be convenient for me > to be able to change on-the-fly the min/max values via the > param command. May i miss any configuration setup (or external > package) that prevent my dtn installation (i have not used any > special customization) from this kind of functionality? > > I would appreciate any help. > > Regards, > Vangelis Anifantis > > > On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)[HOSC > SERVICES CONTRACT] wrote: > > Hi Vangelis, > > Since the bundles are displaying as (NOT PENDING) the custo= dy signal was actually processed by the administrative element (AdminRegi= stration.cc).=20 > > The initial bundles remain in the all_bundles list because = the Custody Timer still has a reference to the bundle - when the timer ex= pires the bundle will be deleted. The Custody Signal remains in the all_b= undles and pending list because AdminRegistration does not update the fwd= log to indicate that the bundle was delivered. > > =20 > > I have not noticed a functional issue after changing the cu= stody timer default values using the param command but may not have paid = close enough attention. It could just be a logging issue but I can't say = for sure.=20 > > =20 > > While on the subject of the Custody Timer, I will say that = I do not like the implementation which sets the timeout to the min plus t= he percentage and then overrides that with the max if appropriate. We cha= nged ours so that it starts with the percentage and then overrides with t= he min and max if needed. > > =20 > > Hope this helps a bit, > > DZ > > =20 > > -----Original Message----- > > From: dtn-users [mailto:dtn-users-bounces@irtf.org] On Beha= lf Of Vangelis Anifantis > > Sent: Friday, October 17, 2014 9:16 AM > > To: dtn-users@irtf.org > > Subject: [dtn-users] DTN2 custody signal handling > > =20 > > hello, > > =20 > > I have been recently playing around with DTN2 (dtn2.9.0 ver= sion) reference implementation to better understand the custody transfer = capability (e.g., sending a bundle via dtnsend with activated the option = -c). > > =20 > > What i am seeing is that, as expected, each dtn node in the= communication chain accepts the custody request, becomes the custodian a= nd sends back a custody signal administrative record to indicate "custody= _succeeded set to 1" (with indications regarding custody timer parameters= as configured in the current custodian). However, I observe that the cus= tody signal is not handled (neither received) by the administrative eleme= nt, thus, remaining on the "all_bundles list" and "pending list"; and con= sequently, the bundle protocol agent does not follow the custody transfer= success procedure by deleting the initial bundle (i.e., there is still a= reference on the "all_bundles list"=20 > > regarding the initial bundle with indication (NOT PENDING))= =2E Do i miss any configuration setup regarding the administrative elemen= t which is deemed necessary? > > =20 > > Furthermore, even though I have set manually (custody_timer= _min, custody_timer_lifetime_pct, custody_timer_max) at all dtn nodes to= differ from the default values, the forwarding log of the initial genera= ted bundle keeps displaying the default values, e.g., e.g., > > forwarding log: > > TRANSMITTED -> link_name [dtn:none] FORWARD at 141= 2929830.51299 [custody min 1800 pct 25 max 0] Why is this happening? > > =20 > > Thanks in advance for any help. > > =20 > > Regards, > > Vangelis Anifantis > > =20 > > _______________________________________________ > > dtn-users mailing list > > dtn-users@irtf.org > > https://www.irtf.org/mailman/listinfo/dtn-users > > =20 > > --=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 > > =20 > > =20 > > > > > =20 > > =20 > --------------000807030001010603050905 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Thanks a lot David for your time on addressing all my inquiries.

Merry Christmas and a Happy New Year,
--Vangelis


On 12/26/2014 6:07 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote:

Hi Vangelis,

Good catch! No need to check for the special case because you are not hitting it. I experimented with the UDP CL and reproduced the issue just as you outlined. After the connection refused error is generated, the state of the Link remains “OPEN” so there is no attempt to ever re-establish the connection. After bringing up node B again, if you send a new bundle then that bundle will be sent but the original one remains queued at the Link level instead of being sent.

 

I think that to continue cleanly along the lines of the current implementation would require at a minimum issuing an event to close the contact when an error is detected on the socket write.  However, after reading through the latest specification for the UDP CL (RFC 7122), I do not see any reason to use a connected UDP socket and my opinion is that the UDP CL should be changed to use an unconnected socket and it should always transmit bundles as they are queued. It is fairly easy to change to using an unconnected socket:

 

In UDPConvergenceLayer::Sender::init()

·         Insert these lines right after the line socket_.set_logfd(false):

socket_.init_socket();

socket_.set_remote_addr(addr);

socket_.set_remote_port(port);

 

·         Comment out or delete the socket_.connect() code block.

 

 

In UDPConvergenceLayer::Sender::send_bundle()

·         Change the socket_.write to use sendto:

int cc = socket_.sendto((char*)buf_, total_len, 0,

                        socket_.remote_addr(), socket_.remote_port());

 

That is my take on it.

Regards,
DZ

 

 

From: Vangelis Anifantis [mailto:vangelis@netmode.ntua.gr]
Sent: Saturday, December 20, 2014 1:15 PM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; dtn-users@irtf.org
Subject: Re: [dtn-users] DTN2 custody signal handling

 

Hello David,

Thanks again for your response.
The problem with the custody timer not being rescheduled happens with the UDPconvergenceLayer. To reproduce the problem with the custody timer rescheduling, consider a trivial scenario:
Let assume two dtn nodes (node A and node B) communicating using udp convergence layer and via a static routing. By using "link dump" I observe the corresponding link, e.g., my_link  ONDEMAND udp state=AVAILABLE. Now,  shut down the dtnd in node B and then send a bundle with custody transfer enabled from node A to node B. I observe that the custody_timer is started. When it fires, node A attempts to retransmit the bundle and now i have a debug message
[1419099989.900814 CustodyTimer 0xb4416a60 info] CustodyTimer::timeout     
[1419099989.940186 UDPConvergenceLayer::Sender 0xb4404e24 error] send_bundle: error sending bundle (wrote -1/110): Connection refused 
Then, the bundle remains in the "custody_bundles" list and it is added to the list "my_link:queue". Now on, it would be never been retransmitted again. Start the dtnd daemon at node B. The bundle remains as custodian in node A, but it would not be rescheduled for retransmission.

Sorry, I have not checked if i hit the special case that you mentioned in the previous mail. I will check it out and i ll come back soon.

p.s. By using the TCP convergence layer, the problem does not exist.

Regards,
Vangelis

On 12/15/2014 4:50 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote:

Hello Vangelis,

Thanks for digging into and figuring out how the custody timer specs and route specs interrelate. It looks like it would be useful to be able to override custody spec params on the “route add” command and possibly to implement a “route reconfigure” command to change them on the fly.

 

A custody timer is started for the bundle as part of the BundleDaemon’s processing of the BundleTransmitted event which the convergence layer issues. When a custody_timeout fires, the bundle should be re-routed and transmitted resulting in another BundleTransmitted event being issued resulting in starting a new custody timer. If there is not an open connection when the custody_timeout fires, then the bundle should either be queued as deferred on a known link(s) or there may not be a link to add it to at the time. If the known link eventually establishes its connection then the bundle should be transmitted which starts the next custody timer. If a new link is established then all pending bundles are checked to see if they can be routed through the new connection which when transmitted would start a new custody timer.

 

Basically, the custody timer is only started after it is known that the bundle has been transmitted. There is a special case in the comments in BundleDaemon::handle_bundle_transmitted() if configured to wait for reliable transmission that could result in returning without starting a new custody timer which should issue a warning “XXX/demmer fixme transmitted special case”.

 

Could you be hitting the special case?

Or, can you provide more detail on the custody timer not being rescheduled scenario including which convergence layer?  

Regards,

DZ

 

 

From: Vangelis Anifantis [mailto:vangelis@netmode.ntua.gr]
Sent: Sunday, December 14, 2014 4:26 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; dtn-users@irtf.org
Subject: Re: [dtn-users] DTN2 custody signal handling

 

Just for the records, I have finally found out what was going on regarding the param command.

For my testing scenarios I used a static routing scheme by which each bundle was forwarded to a predetermined link. To create disruptions, I used to shut down the dtnd daemon of the remote dtn node. In this case, each generated bundle was directly forwarded to the predetermined link (as specified in the route entry by the initial configuration file), where the custody timers (i.e., min, lifetime_pct, max) had values equal to the ones at the time of the specific route entry creation/definition (for my case, the route entry was static and created by the initial dtn.conf, namely, before any param command reconfiguration). Thus, I always noticed the default custody timer values ([custody min 1800 pct 25 max 0]).

In case that I change the custody timer values (using param), and then I re-create the route entry, e.g.,
route del dtn://node20.dtn/*
route add dtn://node20.dtn/* link_0
any new custodian bundle will be bound with the new custody timer values (as set using the param command).

Besides, I have also noticed that a custody timer is not rescheduled. Specifically, if the custody_timeout fires and the bundle is not successfully delivered to the next custodian node, the custody_timeout is not rescheduled so as to try a new retransmission of the bundle in the future (does this make sense?).

Regards,
Vangelis Anifantis


On 12/13/2014 2:02 AM, Vangelis Anifantis wrote:

Hello David,

Thanks for your response. It actually helps a lot, since it answers my question regarding the custody signal handling from the administrative element.

However, on the subject of the Custody Timer, I still have problems on setting the custody timer default values using the param command (e.g., param set custody_timer_max 1000). It seems that I cannot manually override the default values by using the command "param" (it has been validated by the debug logs, the forwarding log of each bundle, as well as in practice by measuring the retransmission delay).

Following your suggestion/implementation, I have changed the timeout calculation in the CustodyTimer.cc so as to cover my own needs and it works fine, but it would be convenient for me to be able to change on-the-fly the min/max values via the param command. May i miss any configuration setup (or external package) that prevent my dtn installation (i have not used any special customization) from this kind of functionality?

I would appreciate any help.

Regards,
Vangelis Anifantis


On 10/22/2014 12:04 AM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote:

Hi Vangelis,
Since the bundles are displaying as (NOT PENDING) the custody signal was actually processed by the administrative element (AdminRegistration.cc). 
The initial bundles remain in the all_bundles list because the Custody Timer still has a reference to the bundle - when the timer expires the bundle will be deleted. The Custody Signal remains in the all_bundles and pending list because AdminRegistration does not update the fwdlog to indicate that the bundle was delivered.
 
I have not noticed a functional issue after changing the custody timer default values using the param command but may not have paid close enough attention. It could just be a logging issue but I can't say for sure. 
 
While on the subject of the Custody Timer, I will say that I do not like the implementation which sets the timeout to the min plus the percentage and then overrides that with the max if appropriate. We changed ours so that it starts with the percentage and then overrides with the min and max if needed.
 
Hope this helps a bit,
DZ
 
-----Original Message-----
From: dtn-users [mailto:dtn-users-bounces@irtf.org] On Behalf Of Vangelis Anifantis
Sent: Friday, October 17, 2014 9:16 AM
To: dtn-users@irtf.org
Subject: [dtn-users] DTN2 custody signal handling
 
hello,
 
I have been recently playing around with DTN2 (dtn2.9.0 version) reference implementation to better understand the custody transfer capability (e.g., sending a bundle via dtnsend with activated the option -c).
 
What i am seeing is that, as expected, each dtn node in the communication chain accepts the custody request, becomes the custodian and sends back a custody signal administrative record to indicate "custody_succeeded set to 1" (with indications regarding custody timer parameters as configured in the current custodian). However, I observe that the custody signal is not handled (neither received) by the administrative element, thus, remaining on the "all_bundles list" and "pending list"; and consequently, the bundle protocol agent does not follow the custody transfer success procedure by deleting the initial bundle (i.e., there is still a reference on the "all_bundles list" 
regarding the initial bundle with indication (NOT PENDING)). Do i miss any configuration setup regarding the administrative element which is deemed necessary?
 
Furthermore, even though I have set manually (custody_timer_min, custody_timer_lifetime_pct,  custody_timer_max) at all dtn nodes to differ from the default values, the forwarding log of the initial generated bundle keeps displaying the default values, e.g., e.g.,
  forwarding log:
         TRANSMITTED -> link_name [dtn:none] FORWARD at 1412929830.51299 [custody min 1800 pct 25 max 0] Why is this happening?
 
Thanks in advance for any help.
 
Regards,
Vangelis Anifantis
 
_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users
 

-- 

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 
  
 




 

 


--------------000807030001010603050905--