From TSELIKIS.Christos@haicorp.com Thu Sep 6 01:06:08 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCEE21F84E6 for ; Thu, 6 Sep 2012 01:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.816 X-Spam-Level: X-Spam-Status: No, score=0.816 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqsmCp+22WUD for ; Thu, 6 Sep 2012 01:06:07 -0700 (PDT) Received: from HAIRDGESRV2.haicorp.com (hairdgesrv2.haicorp.com [212.205.103.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8B85721F856C for ; Thu, 6 Sep 2012 01:06:06 -0700 (PDT) Received: from haimail2.hai.gr (10.0.200.55) by HAIRDGESRV2.haicorp.com (192.168.2.4) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 6 Sep 2012 11:09:15 +0300 Received: from HAIMAIL1.hai.gr ([10.0.200.56]) by haimail2.hai.gr ([10.0.200.55]) with mapi; Thu, 6 Sep 2012 11:05:45 +0300 From: TSELIKIS.Christos To: "'dtn-users@irtf.org'" Date: Thu, 6 Sep 2012 11:05:45 +0300 Thread-Topic: On measuring the DTN2 performance Thread-Index: Ac2MBm2Q1C7MS29RS5mL8nLC75X0eg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_E57BD7A928881D48B732EFA5435DDAED02CCB687BD84HAIMAIL1hai_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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: Thu, 06 Sep 2012 08:06:08 -0000 --_004_E57BD7A928881D48B732EFA5435DDAED02CCB687BD84HAIMAIL1hai_ Content-Type: multipart/alternative; boundary="_000_E57BD7A928881D48B732EFA5435DDAED02CCB687BD84HAIMAIL1hai_" --_000_E57BD7A928881D48B732EFA5435DDAED02CCB687BD84HAIMAIL1hai_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I'm returning on the very interesting dtn2 performance issues/results that = appeared in the list around July 2012 (seems that I let the thread sleeping= for too long, but it's never too late). Well, just a few simple things, how do you find the dtn_perf (v2) dtn2 appl= ication as a measuring the DTN network throughput tool? I suspect that sinc= e the results are reported at the client side of the appl, it can be consid= ered for network throughput/delay estimations, yes especially versus the bu= ndle payload sizes (ACKs are taken into account). Also can be used for API = measurements and multi-hop scenarios, in my opinion. Finally, has anybody b= umped into some newer version of it (v3)? With very kind regards, ctselikis Tselikis Christos Hellenic Aerospace Industry S.A. Electronics Engineering Department e-mail: Tselikis.Christos@haicorp.com PO Box 23, GR-32009 Schimatari, Greece Tel. : +30 22620 52561 Fax: +30 22620 52910 [cid:image001.png@01CD8C1B.36767170] --_000_E57BD7A928881D48B732EFA5435DDAED02CCB687BD84HAIMAIL1hai_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I’m returning on the very int= eresting dtn2 performance issues/results that appeared in the list around July 2012 = (seems that I let the thread sleeping for too long, but it’s never too late)= .

Well, just a few simple things, how= do you find the dtn_perf (v2) dtn2 application as a measuring the DTN network throughput tool? I suspect that since the results are reported at the clien= t side of the appl, it can be considered for network throughput/delay estimat= ions, yes especially versus the bundle payload sizes (ACKs are taken into account= ). Also can be used for API measurements and multi-hop scenarios, in my opinio= n. Finally, has anybody bumped into some newer version of it (v3)?<= /span>

With very kind regards,<= /span>

ctselikis  <= /p>

 

Tselikis Christos Hellenic Aerospace Industry S.A.
Electronics Engineering Department 
e-mail: Tselikis.Christos@haicorp.com

PO Box 23, GR-32009 Schimatari, Greece

Tel. : +30 22620 52561
Fax: +30 22620 52910

3Dunt=

 

--_000_E57BD7A928881D48B732EFA5435DDAED02CCB687BD84HAIMAIL1hai_-- --_004_E57BD7A928881D48B732EFA5435DDAED02CCB687BD84HAIMAIL1hai_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=10192; creation-date="Thu, 06 Sep 2012 10:34:35 GMT"; modification-date="Thu, 06 Sep 2012 10:34:35 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAF8AAAA8CAIAAACPTvFWAAAAAXNSR0IArs4c6QAAJ4pJREFUeF7F fAmUJddZ3q296u1Lv6X79et9m95m0+yj1bI8smWDjUEYR44DDhACAYxPFodYgoNPDpCTnOQ4Jphg bI4BOyCwZS2WbFljabSMRqNRz/SsPT29b6/77UvtVfluvZ6eHi2gITIpPT31e6/q1r3f/f/vX0uM bdvkx3cwlstgfIsQFjdhtt2IcfHBoV/Qv7w/iOMSnrgyfW8eLr3qpoNedfOxfdDtvzDNMbcf9Bum ea+bRm7exXu/eXzmx4sOFswCHUzIQ2fbvTf/3lzDjZW4RHCbE70x47dg9JZ13/jiJlCa990Ok8O8 FfHN2/1/QGdr2m9G56Ztvo6ayzh4kbfZdu/0Gwt7W7zeIiwYB5e8aTQ6yNte/jZy+uOWnU2J3ZSU t+qFt+obMsVgOVDDW1B2l/FU660o3CRfWzemN/iH0NmSOPbHjk5z5W8jz29CqvkRK2UhO+b1pb2V O5q/bH3PXldDXPkO2N8EE6YDUnuTmLzpLv9U6IACGRerdYm7RZ7XKXBLTd60KJzIGNtkYfvP15dx Q1moIGxnMw+jdyJqKsgemu+EzjaYPK388coOQyyGQBC2awoVj82Xy7gMe0PUm1LW3Ooba9w0Z5sS cBOJuPRsOsh2dtu0ADcr1g046B1vHDcR9s23oDP4p0EHk7i+wXQlm0zRhIYSh+tJu3fKpiQ019jE 6CZpgCRufU//BjQgcmju9nMhIJ68Nt892W2OtInj29iyt0DjbdV7ZdEZjx1d18WAjkP3hMOB+W1O Dd9AVrHbeGG+jGWZhOGIyxGWYwi3JTVN4cBZdAUulTq8OziDnuJJlTfG9e8dyzFxBiwTAGEJdx0L YO2yHEsR9tCxt+5MRcdxsSceI2K2mDM+0PnfEMzNvXzP0ME9cNCFMQxg2VyKhwk2DuTjuJiT7TAO ix9Zl+d4zwukWoapA08KqUN4CBMF0Jtt8+WpAlaxtfVbygGpYRlct0npOMN26Pa4DiNLclNBLct1 bLp+QWCwD5ap2wCUEB4HR91OXNWc+VuP9xKdLZFh6Z55cmQx/JYx2aJjz13VdI1KBcezLE5pmmXP ZFGeglHfftArbU9cthC7frpbaRRwN9yR4wSsliOC9xN8UAgcHc/bNQYn4Cx8bjSKQZ+vScyWbQFK SZRwZ2yeJ5k3EfZ7hk4TmqbsNKGhG+IKvEcfnlDRd9u1DadhuUZAlj1No/qGl70p1qZMTBA53XPs Ol6m4wk/I4qyN2Bz9k0wqR8cEPxb33jCh3Ck+SsnUKQ29wRXWvjJtgKcgN1paBrmqUgK9SBcp1Sq RCLR6+jc8NTfM3SwBsoz0GbXtbAuT3SxYYZO10JFGI4M0V2iO/RlMJQK7BqplesVHNVqvVqvm5Y6 ffWs4+qmaRs4dBNvGMy23HK5gpGpAkIqqBp62+EQgZdEjpdln9/vDwRCwUBIUfyiKLa1duCbSCQW iUQCgaBPDPCEynG9Xg3IisjJ2CfMjGOaCAKjJvTb7D1gfq9YGYhQGvYYZ4uAvMDSdDxl0UjFMMs1 rVhV1xt65Y2Jk4atNfRaTW3UcNTrmqZbtq74eMfBYI6JA8hYDujbcVyeF4ELVBWkD+zoYUF1Gb0O I+DapmNYJt5tChklLllURFkJBYLhSCyGV0s8FokHfcGje490tLYn4imc2Khr0EggC4wQwnjoIAy+ odTvGToYsqlcEJnm8Lqua0ZRCWqF2nJufWFtYyFfXNwoLRUqyzW1kGyLOowBFbNdCyzatB1gz0ZD A6cCAnwBtQI6jk2Jt1pp4B3oeMBRjcMfxGaIITk271qOgd9wIbWCsFycAwTB7/QGjmNi7YzEixIr l1ersWC8q7P70KFDx449MDa8EzpYqdYCgfCb0flHyM5mBsAjsE3PqunFcZTkIA6iCJMCoTXXy0sb pbkTp77TMFdVrQJ9kXyMzw81cBjebBh1xzFMXAIrYkFMbConNmeYrOtwFBocJt4dyAg1S1g7Rcdj I3NTfCA1lkZxdCycSZUOdo0BBYNxXMrUDCJ+quqeIUMQ4Sg7OvfsHtm3Z8+e9kxHNBoLh6MiL1u2 g5O3u12bHHpLmkUjA9ZVK1VBlHiJ0mGjYYsCzAXFA0bCJfWqvTg18+rklZfmFiaLtdl4qyD6bEWR ZEVgWUi+DjoxLB3UYABL1dJNSA7nOizlF5NvNEBTokftrGOBfSywD12/JyyGTr+BBmHxHMczvC0G QPOabWAQEDtIhGNswbU4xgXLsFrdgAhLghgKhfp7+seHD338vl+S+bgsU3u//bhuVa5bVrr9t8g7 FB3KW5gIhNaqa6CJAKaJ3YXrsV6Zf/38icnLJ5bzZ4lQisRJIOrqTonlzKbRBbKbETXIWcOaGeAC u+baom1xJiRCZ/z+Fk2zqtUqqLpehW3RsPPYdjgAlOsdosh8OBgJBsOwYoQ1q2ZedzXIDsvwPMPZ JmlU9EZN54gk8z5BkNOJzK6x3UODo309/ZnQgKVHRDZCtd+zbB4Z3BysbFpDahNvjXfgsGOneIm6 poZZIZwhcHAwrZnVqZOvvwRCWd2Yr6pLrlAVFEOQNEYwlICELQCY19HZdOahSvBmQTEOpMZ0dc1W VQOQbeSrpgnOIoZBpw2WFwVwGYEOwCgF/SEIqqYa9XpDa6iWzUm+qAYyV+uNRsUyDTgQoiCLvBgO trQls62J7u7s0NDA7mQ0yxJJIAHe9XPN3CO2mto+in1TG73j/8XfAavbBLPnZdhv1SXlqrN2/tLp k2+8cHnqvOk2CG9IfjYQ5iUf7qlBdXBj8DT0CO+UkGwbtoiaf5bHO9QE0qFphqqqmkq5o1wlgkAU hfh8bMDnVxQFMsJzInUHbdfUTSBIlQsjwNNkAgtzmiBGOM7V9Kqp14MBpbOjoz2TjYbiQ/3jXZkd YSktkihDFAOs4AgKLzf3pwnNlnK9N+hQd1MlcgDDFhYKZ5578W/PTP5oeW06mQmDTFkeThgriAwn 8iznRVusDG8Ylh6yA0mhVAuTY1NbbYFSYNZMDYQC3YGYgBkTqTArsLIANEVcSL0bELPtNqoNtYHz TTg4iuTD2kqlcrng8k63pgkCx7a2JYcGe9vbM4okgeqHd4ynAu0iCVjUzfFBcDgiIxBrevFgmabI UBnadNTfRESeeN0SKyP2xbQsrEQwVXfhie//6dPPfqPcmA/GOCnIiTJeEivAYSEwo9T7dflYpAWm 1nNeqGNyXYyZeqNKGEokDGsJIqsogj+gyEBFYajXAv9Ft4AFaNgy4OIi3BAl0cdzMgStXKjCu4V/ 5FqhluDYQO++of5BEG29XgdwAwND2UiWrhqSDJ/TASoyxoT+BqQgC8OFeYA/oUUs9Ve3IsS3wnPL 6FR1V1Gw7vJLbzz27af+ZHF1IpJgAhHOJjqsMOyyacE68qIiB/wIaHz1Sh1Oqee2YL5gcI5Gf9hC BqAwksyKEsMLLmIdsKgosnW1BmChfKbh2AYoCUkW0XV4teGaBqmW1EK+YmhWPJYCCp3ZwfbkaLVM bINpibd2dw61+FoR2dbqDegyxyIetqGTDIHPWGg0qtFgUiQtrisBHxotszQoa3remPM2dDZ5+tbQ wX1UR0eoV9RnvvGt/3n8hUcDMSeR8oGPoQScKEiwKJIImoAjQrnBMmqVMs8iPpYlSYJSCIJE6Zlx Q2EfoIFnzAuIqzXTatiOAX8Qukg9KQc6xZtAR2NMnbcNwbHE9Vy1WjZSLZnx8T19vYOyIGuqXVhv tCU6OzsGYoFWjoRQ0oB59Mwx/uOwpGGQ4vLqxQuXTll2tad7ZFfPMZcEAQcFB04agSdBfVFM7GZ0 KEDviA7WALakYT5PRbEZKFiM4bK6Teo/OPn4H3/1v4YirOFUGNYQZLAGS3ERBGp/ECFYdYzNc1AQ 0taKIAC2yclksuFwGJLs9yuIvKrVou1oih+huo6NhSiFgrHcWtkvRVhGggk3VAG4FPP6xmqjUrJ3 7zw8NrqvO9svS8H5ueVapZHNZlMtiWQ4BU7RHEdmw/CfIXcA3jBrMpWM6tTime89/a2737d/duG8 bfh+4n2/ypME7AJkGaralFPsHPUkPUPWpOymmf/70MHPXjxjA6lmfGDB+yPri+Wpv/v2N1985TlQ hj8o6KYaDgc9uoFrB2elbph1y1Wxd0gZJFrwCiAyxBEMBhFVYqjOzqwkC+vrq+VKHjAh82KYsFp1 6FE62ruRU7W6RVxlI1fPrdbjoexg/56Dt93d1TFSLmpTV+Z5IqXT7fFYIhoMe345RA5ijTxRMyKx fIK4vD5dKK509SQKpcVnn3v8p3/6gbn5y9emNu488FA80IeToescC1CAgAs13ERnEyAPHRqYvEMt 1BM26oY3Gg2Y1SZ76aTkMMUnTv711//8q7pRBfenMwlwIZZdqdcaCCcbFdPV/EEST/hiLYo/wEfD vlBQwVA8XGWWrdWqUPhUKoHRypViqVSC5QKh+nwyjBRjy7U8L3OxjfXy9NSyX4ofPfyB/bfdFQ91 VMvW7MxaPlfNtvfAtaNpP6TKOBrpuwSEb8AmmaQiEAvsdGV24oUTP4DaDg71jg2P/OjF54aHh1uj qe8+cXyk5+7B3j2KGKTpFEBKFdnTj63cNxWffwgdOOAAhcqLZTUFB5vrymrZufalP/2Dp595orU1 KfsRRDD5fF431HK1ASlQfGw4piTTgVR7KJUMBAIKDDjdGccyDA27AXKG+OAjdgxhTsAfgmGqVVW4 MKAAzgnMXSzpFT6VzN51xwcOj9xNiDKfW786taTW7PHRfV2ZLswEDhf1ACAAPKnrJuV1xiw2FjYK M73tKYuUnjnxnWQq0pppfeZ7z3zg2ANXLl6bX1j59E9+5pWJieKKdWDvXelEO3CxqKFAUM5zuPNW Ar6JDrWnLvfwww+/jaG/Hmpjh5tJCVhkz69jvnf8u8/+6PuWpSNnwgvOzMzVal3dKJihEEm1yUPD 2ZHRzo7OaCiMq2q63iCOqKuuTwklk2kwcK1aR0JOFJVgIOY6gtYgpi6yblhvSHPTpcnXl8b733fv 7R/7mQ//QndybGm9cvrMxXrR7mofPLT3aDQEp45omimB9gXqH20UNkIh2WVUWIsTp743tzQ5vTQR axMYHolHI5Voee306WSyvSM7MDW1tGv4ECP6rl68lk5lkNNoVm88U7XdWjWpByGW56y9Ezq4Doh4 TgELOWrSs2o3vv5XX52auQQx2cgvr63nF5ZIOkMyWTK+O9PTk+zojIVi1Nc3raLlViAqIX87jE42 2znWPY7AcG5uDg5xKtk2P7sicCHX9s/PFE6fmtpYM8ZGbv/ET/3KBw8/2J4aWlosnHptsryhjw7d Njq0uwVeA2EqpQrkBSpoWvVaPa9IjN9HNuog6POqvTa3eKF/MLOamxVEl+XdJ596SpL9g4NjIh/s jo0sFwsLy+tD/WOry+ttqdZAMIB8DtI6eKPma7tD+G7QwQVQAZA5AAL1NIPaE6+88J0nH6s2qqpW g+sKne/sIWPjocEdic6umD9MXQ3dgKIVkIQTRVuRgyKfsQ0lFIoKfimXWy8USgjHdc1KJTqvXV05 NzHDkvCRAx+8/76f27PrrnSk78wrVy+dmzd1du+uo6ND4z45BIcQjjc8FJ8PDrRjWlWO1300HlB/ 8Pzfzi2fEfyqy9XL1bWRsX5Nb0BVfUrYdaTOrpGRtn3np6dF0GJVLRarY71joiwk40leEGmKgyYG KTqw7Tfy7tvQYWDsm5p1vZhNa0BUtlwbFt0XoNRTKhdgiWuN2h9+6Yt/+Z0/lqNw7httWSXWwu8/ NMSJDcxYUqCrBmwgbodQEA4gEnam6XP1rGUGfbKCDxgQeUxkqi5emMqtFUPB1OjwgcMH7s2k+wt5 Y35mtVIwOxJ9mWRXuiUlUl+EMotnOpHU0A29LCmYu75Umq83KrbeWNuYu7z4+kMf/WcqcR597NFk Oqzr9UQicXjorr/+/uPtme62dObZHxz/yAMPgjxL+UZXR3+YC2II2DjINWIemjiif0heYWOrDIkE CHWa4MDAuzXxAY4adWoNG8EiJ7LIrbEiZ1kwzIiUKbmvV1a/8J9/84kXn0x3kr7+UHt7ayAkcDyc fJPjDZbXHVhxxgBD4q4cvBc4da5g2X7XVkK+eL3s1iru1IWFteXijoFdIzv2jO7Y2ZrqKuTrb7x2 ybL5XWO3pdq6g4HUqVcnJ0+c+a1ff6ikESSRMOtSZT0TAlqlirH20hsvLldy+ULhUx/9xNzsxcsL p95/z4f8pO/k5Cszcy899KGPXivN1kpOIjZ44vhJtVFsTbbdf8+DHIk7dpA6xzQzbbKipZlFSYBo qID78ecfh33YtXOfwscsUwgIKceSDJVwn3/kP9JkrMtgofBhQd94BzMBMw5wOXAIMT3TIur04oWX zzyd6iy393AtyZik8J5DjKwk6naQTuSjkF2HVygSAveB9imB8KDhYK6Zq4uvvny2mNP6u3ffdfTD B/bctW/XndcuLZ59/XJpQ71t1+Hd4/u7W/sUMQRJXspVX3jh5M7dR2X/puz4JaWurhChdunaxEp+ tneoq1DKwQlIpEPr5ZVILBkUeqsNo1JdTHSGV5Zyat3d0XEwEk51ZtuGh0Z9fIsFKmf8LoQbEiGA clWOQw6tdvrq8xNTL9mkslFahiRlom0CB/mUGKzColExLSRspyWQNTxJAdlvRnd5AwOtVGe++cRX /+7Jv2BFuy3b0RJHHBxhXNk2RbyIg+F8PBvUGlwxb1ZKAM0v8nFUU9Q6f+bkxRM/fOP8mcUdfaMf Pvaxuw7fm23trpaMv/nmo47FHj185wMf/MhA52DMH0fya6NYhCbt3N0bzGam8lVWIpDdag7FC9ZW /A4J6gwiUutAZsdItn1m7kJEiTVq9uJsgSOB1pZuYod/9MOJpTlV5NICiXelR7szwxEp1UAuEkEa CyPaICKSj6VcabpsrJXdXC6/tJZbuu/I+2PxyOLiolfygDGCVdFkhXD/6ZEveBEH75WCqOOIDD8K CfAAaHWFUS8vnP3eD//2meOPreSmY2nZcKo4wYvcaMqOFmgp4TvFYhGp2XA4Fg7FEQfkN6oz15Zn rq5pNacr07tn56H33/2TrB2au5YvrKtIBh49fM/e8UPRUIvMBnPFfEAJGyYJBwJlnWAur15c2qjW xobaJ05tqOUKyjBExgQt3S1dPX92/+iwKDuvTLzaPdyDnJdWEfqzBwNiHEklZDl6OkeGBw4RgnBc aZhVgZOgGJBKEKFMaav88tlnTp89sZqfgdp2dLXNLVzr6+sLR2NTl6Yz2S5ZCBAH6VceFyLeQ/4D ORlah6KJF5cmCziR00kdYffktdPfePR/P/fS43JET3XKrlhDGtRxDRSeTCTLwVLgJ6+4AncZ5SQ4 5gvzyyCOiYn5arURjybvOHTs6IEHIv7OixNLkxPz8Wj3np13Hrvvp7rbxh0iIdZB/iURzSIjrqrU bZchL4T0Du9cXCvmiuTEyTPlmhmMQL39DUK64oPQjOnFK22hZCQs5AtrAz0japWfW1qH/Pa37jmy /9hI1+0SSWmaiNSFIMAnRl0NNzKuzL1hk0KZzC0Vz3fviHOKPj17HqEhkhmXF64mlTRcjaWlFZGg dAEHltZHUYberEp79W+Gh3qCTIkBs/Pd5/7ma3/1lbOXTzKyGo5zjlCFGyooNstBwFCN1sFOcMmQ eUKcAMGDZJ4+NX32bLFRI5m26K6xvbftPcIzLVMXi+cnVm0rfmD/h+498jOKr11kWi0SqBliucb8 /n/7o5dfP1dqOIjagcuFRXtDI3ccbNNU5/K0zsKN7O5AxRDeH+OKEIdEKntldrZOquGgtHztWjSQ bE/3Id+uQvaQNeVChPhVE3X0IGwQT0RUwxqkNjF96vTZ584vvqyT9UCc6e5vC8al9dJasZZPpdLF Qp0jvlSyfWluparXvBifEgyKGhQMqlDIcUCEkCohWlFff/71Z//mu395fuq0L8woYaaira9XlnWn rOtl06y6NqheY1yUW1CsKxULuYkzcwtzKjK346Oxe+/Zu2/vbeFAsJArFwvEL/ce+8Cnf/r+Xx0b uG9uQ/v6N56cXasBCITIqq1YbJiV4rKPzZXIs68sfPkbf/EXj76I2qBkcadfP+v4FD1I7Qosh89C Slhua+9dUxvHJ17hbSc/v8hY/G079/dku/xeOdyrwnKSoNDiHbFXyvMbjeWF5emLU68lMtxrZ59C ZaxuFp86/tji6kJ3Xy+ybV0dQ1cuLeSNxvDQXkPnalWzXK+BeUEX3O888ghgQvkMXIpAAYxT1jZW crNf/MOHc8X5wbFOTjbXC/P+iKT4GaTFUb5HEh05OoFV4NehbJBb21hd0uMxtq87PTYy3JrsQHyw vlKulk3XjhzY97Hb9tzfldhjk0CuZtXrwvMvTuzefyQQ8HqeJPbowd1SKKRZ5L9/6f+UdSve3XPx 8tXbhkZdU55eWJpdXuSU6FBv0A/NgWdl1dItiTpXWdtYGupsl4gPWYB4pAdWRjNrNldVqIMkoObX 0KDZudcmngNDgWJVvfj+g3svLZ0uqhuygiyiNjqyczA9NrOwnG3tyy2XbZ0f6dyD/MlA97DIKZLg R22Ve+QLj9DOH8QbAlduFJBM0NzK5x/+rM02UAXDoAxvyApfU8uGYSqCZDV4xvEJbBiZl+XF4tJ8 ySeFdgwODg2MJ+OdsB35XD2/ZoQD7YcPHPvQkU+lYnslLqsR/olnX336+69K/tZcoSEFE+3tMkWH IefnyLe/+8LAcOf5y+stbR3v/9Dg5ORSWEiMDSdfPnVu177dJ146IQotgx1BVGOQX7OImY4k5Qg3 nhw4PXEhGhtqiXVRT44zVGsV5RJU/TZKa6ZdOX7icd3O3bnnwEYjv15YuLT8kj/MRePJvs7hazOL HZl+zSCXLyyAxRnbH/KlJDG4o3enyPu9ejSCSplHqURSOIQFik9Esg7e0Te/9We5/KLkd/1hweUM +P4oXUZjIUnmTM2N+9qJLS3NrFUr6pEj9xw7dqxUKj7z/Se1QqigIqdBWuJdu/aP9feNJOWsQ6Iq CT11/MXLVxYXlsp33f3A6K7ktcWByUsLme7I2XMrmUxrNktqJrOwTnglvLZeCJHuVCRyeepCe/sh ENxQX3cmFf/qH385IfzCHQcTFhFM4ptZnnzxxKn1vqTDR5RAsoFiGNKrrFGtr51fmi4XSD5fOvbB ++JJhKN+mzRS6cQLL6509nNDO/oaddmw+LC/9cLEjGtJPiEuMeHhwVZTJQElgnoPTf97+WZaxhGQ F0GaQKGsjqTj5fmJx576ayQZNb1i2RoIFxlxxlaMuqSVBK3on56snXulmI0f/MPf+cv/8Itf3t3x kf7MXb/00O/W1yNxZfzg2Mc/cu+/unP059rkfTzpbJh+nsg6ahhyRNXseKItqJDuvr7l9eJzL87+ 4PmXn37ueWQ3a5pWQOpv327YPrVGBtrby2YFuYrWTGz24rljB0I//4lPmrJYIuT01VWXhPtTu7qT u/IVKd4+kk2NSlxI1RvwP5ZzV6/Nnxd8elVdrWtLyVa5WlsHjcbZRFsqm4imO4Se1YVKdZ3sHr6j JdgZUVp3Dh8QSchHwlElIRAfcZClRcMaAKIuMeUdlJ1gc4q1NVkkf/ZXfzQxeTIck1uSkXKlgFg4 6A+HAwkdRqJgOw2lM7n73/767336wV8J+tP1uuuT4hFfmnWVdKJz99ihkYG9YSkDq2EaAuMGZAHR F2nr6tg51jc3X7YcfrA/DPPz6mvT3b1dPf3di0uLY+M9F87Po0qwc2fs+DMnd/YPd3WEvvPM092D e1KRQD2/MdyXGRwIJ9Pycpn8+de+lYy29KYzg11DbV2IyEZ1Nygwgu42HK56afZVuNd37L1jNb/A 8mpXZ9up0ye7e3dwXAs8z3OTr+Yb5Y1luyXc058aaU13ZVLdiUAbqqa0C4uVvUCK1iuo4Hjda7SX 0ctUuFCc87NnfvjcU4ofAYFVLOckqHssydnK0nRpY97sS+//5E/92pd+/2v7xu7giD8gRKL+JJxP U+PigczuHQeziX6JhOFDcw7Scj6JZgdoqiQikLBAMonYzJWLuGk0gpyeE/AL998eFXgXFYXhwZ7V pVnYu1hYufD6RHuU7Bzq2Vid2T2e/PjH9ysijQ7Xa6Su4q5JXYNqgNEDDGnd0Plnnj6Tr8D8xVB9 FyQezeA8YYJRefraBYEwiViqkFNlkh7vvScdG12e0Xoye9KxPuTnFRINCS2AhkN3hguRQcRpIZiC UwD3Fq4XAg0W//H7ZfQ1+Hjpqe89VqisgX1QIajC20fnRKFWWK/Hg9kH3v+Jf/mpzz34oc8gy0wb ZTSUG2gZza8ICganLTS0BAEPGi4Czdp5ySUos4iqEu2UIX0dmVo5ZyLa5kh/T2b26iW6PXZj7tr0 6EiH3iiXNshtu0ZLxTU4xQ997P6ju/tRUkSKYWpefflM7sv/41uX3pgNBVLgr3ydlC3ajMA64dOn 5+YXdK+Yp8SSqUK5lCcb4+PDuq5uVHN9fUMXz80gEkYUev+RT37sg/9i7+gdbZFeXUMji0IcAckY 2puKeiRoHVNHAwmNFgGNgZ4GmhsDVDDnCxsLp069DAligJijt6Za0HNU2CgN9o785r/+95/75S+M 9x8iSPsjoydYMJOOUysV8ihHEldHggw+NM8hf6g21PVqea2hVoEQGvTgc6JBJ+ong70p16gtzSHC g7B0Vcs5CNaukYHpqQtBH4kExNWlxc7O1mMfvg8hUZIjaQ/WvGb8+Xe+8eiTf/fpn33wI3d3DXQM vH7uytlF8yvfOnHpas2qYPwWx5Fgs1wippMZEOXCwkIUAhqJrK2tp5OdjqUUVq3iBtCMx+RuhY1B XlD2QHcD+jR8aKzDPOhW0xIEoRE1XCYUNNGdZ7LITeSr6yjh/uiF48vLq+B+BO9owZq6sNEW7/+V X/jc7/72fzkwdif6SKplHTEGz0uNBkpyFUmWIvFwKBQwdIQAtEUL8gPXwKf4g5GQzw81ppVg2lpi 6Li1jG0w6/XKOjJG6Dwo5RbhUu8dHVifm8YzR4f3DPdmYuPdQjpGIjIJ8kSvoI+Caj0nigePHE0k aJDhD4YFXzDdLZw4Pfniaxf8ISKHIihb00Yu4sZIeySQmp6anVy6VC7XVxbXA2Lk3ns/0JYJxKLE 0CCIQdOg1hoeo6ki/QsfQfJqMzRipOVSXadladoihRACNReSF4PG8VeeeuYHT9dqDk9aGC1Vz0V+ 4n2/+Nlf/INPfeS3Yjzg50RGjIRoww5tdlVCsi+MlBpttSOwegGGRciPX33IyDkuSpc04UYLsaKA eBUl0XJZDfrJjqGeS+dOAan+rNLiFy+/fj7Ms5/66AOkXLx7T++urA+V3Rb0Jal1TB9mFBKRDvqj vsTc7LIviPWTvt3MNFzfFfLbD//yMydOv3rZ1kVYRLpAH4G9Dx0c/wDv+CZeO9vXPVytgE+FiBKq 1PMoYaC9EK09SEmj1gjqRczESSLKKsgRomRDnT4U79HHi1yMg3wOaqki9xuPfEYk/Fe+9pWzk+cU KWQZrMxHfvZn/vlDD36mr3tEYHygbDC57LVn0iasZtuslyfZ9mpm1bDZXkaveYJXOUMLE48aqIwM LpmZXbh2bXp81/6wn2yslXtQ6O0IpuKxtpgCL47SU2kdrRfoIqMlXlQRbSBMZhfKy6t5ImdfeWM1 ngiXK46m2SMjIctJnL98wdArY2N9kQDdfdRsgqwv3hIcHhpsT3fOzC2xgoIsjyz6eUa29GaPwfU0 6Pbpv3k59DfaKY047drK7JXL10zDPT95Odve9fnP//YnP/lQKp5GYZ8GLRyHcrjXTW+jMtNMs777 A01r+KcJZ2dHO9StWq4CwnvuuqO7E9xCfCL9CYQOAUB+lnZOcZA+igssBi7szLZXysUzp06uLMwa DdLRnro8+QbI6+4jXbnlObAacu8YEODS0h2s21rl0sWZyQtTPKf4fVF0yaHblBoAWITmPN71gRRY 4PRr544fP5HPlX7j33z2i7/3+4dvuyPABxs6WkAhmWinhw4yyDkhTUzrf7cyOg2kkLd3bcQ8uG6g t/fQgX0hv4JJpmJMxEezopBNKp6omTMu0pPeEwAcEkg438sfAdM0upcSsfCDH7ujq52kYyHYQrBn e4zcc/uhYnGlobqoXgMXhQsIxE9scWWpdOnCXGd2qLtlEO4o2g8BHVTlXcOyeSKLAP/xbz91eP/t n/31f/e53/r33W29mLFmGT4pgHZDrwOcoU2PaMWipu7m0s+7uBuSK+iuMTUVU4tHpLtvP5yK0lGg o17/K3IwtDEgoEBe0MNlUPTpv1QHcAn+SkZJLKj4BSYbx9JJS1BijMr8VBWCPb6jC1W1SIjBwr1e N/gS0tDg7oP77n7fnQ/sHDiI3aH5wOZoiOG3SnrvYubUG1xe2GiJpv/kf339l3/+1xyTzRWQhZTg E9FCFnLoBjJiJnoHFJ+PQkN7JG7hgB1AeAwm9/vQWYSeZTuAfoQmLdl0PXh5Xg8eVKJF92ZrBPaC eqs0W0PRwVS6s21Ls1dUxLIQpQwfC0rV/BIuNOpFnjGCMnWL8BNafuCOKUykMzmUTQwiJEYeGbGl wFBg0DXm3ewWEGIl3v87D38xk+hcWVv3C6F0LFNv1EHXm/Jyc2sUisW3gM3WqY7jR1KNNuIbSChS O40mIKSzMFMLthO9FjDHaCtwBVTNaO8HRQeJW0gEtgMnDPZ0VAtrSBMAhZhE7n/f0Z3DfVixyJiN KlKsukqzxkTkFdptSlDrUgyL1RESEEVkkPxgUeOnvW/v9MTpO6yKzaSz0WACch6PJJrPvaGqiwwq av4SWpQkH1zgWrUKzwWzhwTdKjq8JKn1Gi3rum7ArzTFhDYHwPNykSjW8FHwGEEHRtSgsGjYpd5d s6zmKWBbKlourEno5kFNiJB9OzszcR5Nf6ytHti7swXuEwgZ6KAFkwfNIQkLd8OnsCGQDlBXddWP RmkJOQ70zdyC7DAGbdm7ici958CuNz9tfzKn+SV90uzdHptPPl5//gwue/MxzuZ7szH8+jne1zCN 3jm0Bc976oQGap4dOHHiVEdHRyaTEijO3qPriIbQ1eXNBdqHzDMPKJtzxKAweZsNxNgPh6MNrt5P 6IS/ubH071kMQ9vwPSKg7ttbsKBPdW4dzQeY3/XQ21a+if/WU4ceDDeehb5+F+9rLJPiQuFrAtQ8 0K/rh/H3DlQvcTEOC13T3k5SdFA+2HpY+zo6FFlkzik6Ds0Q3yI6tC5M9dHbL/r0xZaH5328+ZmT pi/1jzg2vQCgsPmiC7/+940N2HIWKCXTe2+bT8CHeJauDq3y0CNkwCE7zZ7sphPTXEVTPKhreENC mo+eehJ1i/6IJ+HNBx3epGD/CBDecok38Ntg6t3xbfR/+yOtWwB57X80BoJPZOoqLU3Qh75oVrz5 yNkND2y77HuTaS7NU+br03ib/5fBOy71/wJiiAD5npnXkAAAAABJRU5ErkJggg== --_004_E57BD7A928881D48B732EFA5435DDAED02CCB687BD84HAIMAIL1hai_-- From michirod@gmail.com Thu Sep 6 04:48:36 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669E721F8552 for ; Thu, 6 Sep 2012 04:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUKojuYSFfqW for ; Thu, 6 Sep 2012 04:48:35 -0700 (PDT) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id F3AD621F8545 for ; Thu, 6 Sep 2012 04:48:34 -0700 (PDT) Received: by lage12 with SMTP id e12so1346007lag.13 for ; Thu, 06 Sep 2012 04:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lBCjp7gCX1VMRnEA/2WVAXH++EMD2jK3icEYDe3YKN8=; b=XwN/LxWib5w2YZVzCPqkIqvqVpOh7UxuBfesNwwUWNGlYvdzLww7I0O3BLhFRMPeBC gLgD+J5QBj2ITCdv0mOK0Bu6EGANthmaoTrUG02Lwc779xXj3lK+aaxU9qE7TI0Ql5BA +T3QYUwqqhjMnMUjcYasWcH+TBdLRob3XW4q8xp1n3GsmAUNdRhQGtGUCWMM3b2tWcbw rShcRW6ajWDgIwfv2G1X9UvmbsJiqLM3od23JBm9T2ARkXyK9FIvB+g0kNpSMqkppCKC 1gG7ncbo5uRCc7rfU7lYURs6xX/VZaYjUGsDZ8XmwpMd9rGoqDwr8IbZQyb02td7RvB7 j1sQ== Received: by 10.112.42.34 with SMTP id k2mr786106lbl.11.1346932113682; Thu, 06 Sep 2012 04:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.16.137 with HTTP; Thu, 6 Sep 2012 04:48:12 -0700 (PDT) In-Reply-To: References: From: Michele Rodolfi Date: Thu, 6 Sep 2012 13:48:12 +0200 Message-ID: To: "TSELIKIS.Christos" Content-Type: multipart/related; boundary=485b390f7dae2c33a204c9071257 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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: Thu, 06 Sep 2012 11:48:36 -0000 --485b390f7dae2c33a204c9071257 Content-Type: multipart/alternative; boundary=485b390f7dae2c339d04c9071256 --485b390f7dae2c339d04c9071256 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/9/6 TSELIKIS.Christos > Hi all, > Hi Christos, > **** > > I=92m returning on the very interesting dtn2 performance issues/results t= hat > appeared in the list around July 2012 (seems that I let the thread sleepi= ng > for too long, but it=92s never too late).**** > > Well, just a few simple things, how do you find the dtn_perf (v2) dtn2 > application as a measuring the DTN network throughput tool? I suspect tha= t > since the results are reported at the client side of the appl, it can be > considered for network throughput/delay estimations, yes especially versu= s > the bundle payload sizes (ACKs are taken into account). Also can be used > for API measurements and multi-hop scenarios, in my opinion. Finally, has > anybody bumped into some newer version of it (v3)? > I'm actually working on the development of dtnperf (v3) for my thesis at the university of Bologna (Italy). There are many changes and improvements and i need one or two weeks to ultimate the program and write some documentation. Then I'll have to test the application to find bugs and fix them, but i hope you can try the app and send me some feedback so i can consider another point of view. **** > > With very kind regards,**** > > ctselikis > Best regards Michele Rodolfi > **** > > ** ** > > *Tselikis Christos *** > > Hellenic Aerospace Industry S.A. > Electronics Engineering Department > e-mail: Tselikis.Christos@haicorp.com **** > > PO Box 23, GR-32009 Schimatari, Greece**** > > Tel. : +30 22620 52561 > Fax: +30 22620 52910**** > > [image: untitled]**** > > ** ** > > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users > > --485b390f7dae2c339d04c9071256 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

2012/9/6 TSELIKIS.Christos <TSELIKIS.Christos@haicorp.com>

Hi all,

<= /blockquote>
=A0
Hi Christos,
=A0

I=92m returning on the very int= eresting dtn2 performance issues/results that appeared in the list around July 2012 = (seems that I let the thread sleeping for too long, but it=92s never too late).=

Well, just a few simple things,= how do you find the dtn_perf (v2) dtn2 application as a measuring the DTN network throughput tool? I suspect that since the results are reported at the clien= t side of the appl, it can be considered for network throughput/delay estimat= ions, yes especially versus the bundle payload sizes (ACKs are taken into account= ). Also can be used for API measurements and multi-hop scenarios, in my opinio= n. Finally, has anybody bumped into some newer version of it (v3)?

<= /div>

I'm actually working on the developmen= t of dtnperf (v3) for my thesis at the university of Bologna (Italy).
There are many changes and improvements and i need one or two weeks to ulti= mate the program and write some documentation.
Then I'll have to tes= t the application to find bugs and fix them, but i hope you can try the app= and send me some feedback so i can consider another point of view.

With very kind regards,<= u>

ctselikis =A0

<= /div>
=A0
Best regards
=A0=A0 Michele Rodolfi=

=A0

=A0

Tselikis Christos

Hellenic Aerospace Industry S.A.
Electronics Engineering Department=A0
e-mail: = Tselikis.Christos@haicorp.com

PO Box 23, GR-32009 Schimatari, Greece

Tel. : +30 22620 52561<= /a>
Fax:
+30 22620 52910

3D"untitled"=

=A0


_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users


--485b390f7dae2c339d04c9071256-- --485b390f7dae2c33a204c9071257 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 4d7146c04162ec68_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAF8AAAA8CAIAAACPTvFWAAAAAXNSR0IArs4c6QAAJ4pJREFUeF7F fAmUJddZ3q296u1Lv6X79et9m95m0+yj1bI8smWDjUEYR44DDhACAYxPFodYgoNPDpCTnOQ4Jphg bI4BOyCwZS2WbFljabSMRqNRz/SsPT29b6/77UvtVfluvZ6eHi2gITIpPT31e6/q1r3f/f/vX0uM bdvkx3cwlstgfIsQFjdhtt2IcfHBoV/Qv7w/iOMSnrgyfW8eLr3qpoNedfOxfdDtvzDNMbcf9Bum ea+bRm7exXu/eXzmx4sOFswCHUzIQ2fbvTf/3lzDjZW4RHCbE70x47dg9JZ13/jiJlCa990Ok8O8 FfHN2/1/QGdr2m9G56Ztvo6ayzh4kbfZdu/0Gwt7W7zeIiwYB5e8aTQ6yNte/jZy+uOWnU2J3ZSU t+qFt+obMsVgOVDDW1B2l/FU660o3CRfWzemN/iH0NmSOPbHjk5z5W8jz29CqvkRK2UhO+b1pb2V O5q/bH3PXldDXPkO2N8EE6YDUnuTmLzpLv9U6IACGRerdYm7RZ7XKXBLTd60KJzIGNtkYfvP15dx Q1moIGxnMw+jdyJqKsgemu+EzjaYPK388coOQyyGQBC2awoVj82Xy7gMe0PUm1LW3Ooba9w0Z5sS cBOJuPRsOsh2dtu0ADcr1g046B1vHDcR9s23oDP4p0EHk7i+wXQlm0zRhIYSh+tJu3fKpiQ019jE 6CZpgCRufU//BjQgcmju9nMhIJ68Nt892W2OtInj29iyt0DjbdV7ZdEZjx1d18WAjkP3hMOB+W1O Dd9AVrHbeGG+jGWZhOGIyxGWYwi3JTVN4cBZdAUulTq8OziDnuJJlTfG9e8dyzFxBiwTAGEJdx0L YO2yHEsR9tCxt+5MRcdxsSceI2K2mDM+0PnfEMzNvXzP0ME9cNCFMQxg2VyKhwk2DuTjuJiT7TAO ix9Zl+d4zwukWoapA08KqUN4CBMF0Jtt8+WpAlaxtfVbygGpYRlct0npOMN26Pa4DiNLclNBLct1 bLp+QWCwD5ap2wCUEB4HR91OXNWc+VuP9xKdLZFh6Z55cmQx/JYx2aJjz13VdI1KBcezLE5pmmXP ZFGeglHfftArbU9cthC7frpbaRRwN9yR4wSsliOC9xN8UAgcHc/bNQYn4Cx8bjSKQZ+vScyWbQFK SZRwZ2yeJ5k3EfZ7hk4TmqbsNKGhG+IKvEcfnlDRd9u1DadhuUZAlj1No/qGl70p1qZMTBA53XPs Ol6m4wk/I4qyN2Bz9k0wqR8cEPxb33jCh3Ck+SsnUKQ29wRXWvjJtgKcgN1paBrmqUgK9SBcp1Sq RCLR6+jc8NTfM3SwBsoz0GbXtbAuT3SxYYZO10JFGI4M0V2iO/RlMJQK7BqplesVHNVqvVqvm5Y6 ffWs4+qmaRs4dBNvGMy23HK5gpGpAkIqqBp62+EQgZdEjpdln9/vDwRCwUBIUfyiKLa1duCbSCQW iUQCgaBPDPCEynG9Xg3IisjJ2CfMjGOaCAKjJvTb7D1gfq9YGYhQGvYYZ4uAvMDSdDxl0UjFMMs1 rVhV1xt65Y2Jk4atNfRaTW3UcNTrmqZbtq74eMfBYI6JA8hYDujbcVyeF4ELVBWkD+zoYUF1Gb0O I+DapmNYJt5tChklLllURFkJBYLhSCyGV0s8FokHfcGje490tLYn4imc2Khr0EggC4wQwnjoIAy+ odTvGToYsqlcEJnm8Lqua0ZRCWqF2nJufWFtYyFfXNwoLRUqyzW1kGyLOowBFbNdCyzatB1gz0ZD A6cCAnwBtQI6jk2Jt1pp4B3oeMBRjcMfxGaIITk271qOgd9wIbWCsFycAwTB7/QGjmNi7YzEixIr l1ersWC8q7P70KFDx449MDa8EzpYqdYCgfCb0flHyM5mBsAjsE3PqunFcZTkIA6iCJMCoTXXy0sb pbkTp77TMFdVrQJ9kXyMzw81cBjebBh1xzFMXAIrYkFMbConNmeYrOtwFBocJt4dyAg1S1g7Rcdj I3NTfCA1lkZxdCycSZUOdo0BBYNxXMrUDCJ+quqeIUMQ4Sg7OvfsHtm3Z8+e9kxHNBoLh6MiL1u2 g5O3u12bHHpLmkUjA9ZVK1VBlHiJ0mGjYYsCzAXFA0bCJfWqvTg18+rklZfmFiaLtdl4qyD6bEWR ZEVgWUi+DjoxLB3UYABL1dJNSA7nOizlF5NvNEBTokftrGOBfSywD12/JyyGTr+BBmHxHMczvC0G QPOabWAQEDtIhGNswbU4xgXLsFrdgAhLghgKhfp7+seHD338vl+S+bgsU3u//bhuVa5bVrr9t8g7 FB3KW5gIhNaqa6CJAKaJ3YXrsV6Zf/38icnLJ5bzZ4lQisRJIOrqTonlzKbRBbKbETXIWcOaGeAC u+baom1xJiRCZ/z+Fk2zqtUqqLpehW3RsPPYdjgAlOsdosh8OBgJBsOwYoQ1q2ZedzXIDsvwPMPZ JmlU9EZN54gk8z5BkNOJzK6x3UODo309/ZnQgKVHRDZCtd+zbB4Z3BysbFpDahNvjXfgsGOneIm6 poZZIZwhcHAwrZnVqZOvvwRCWd2Yr6pLrlAVFEOQNEYwlICELQCY19HZdOahSvBmQTEOpMZ0dc1W VQOQbeSrpgnOIoZBpw2WFwVwGYEOwCgF/SEIqqYa9XpDa6iWzUm+qAYyV+uNRsUyDTgQoiCLvBgO trQls62J7u7s0NDA7mQ0yxJJIAHe9XPN3CO2mto+in1TG73j/8XfAavbBLPnZdhv1SXlqrN2/tLp k2+8cHnqvOk2CG9IfjYQ5iUf7qlBdXBj8DT0CO+UkGwbtoiaf5bHO9QE0qFphqqqmkq5o1wlgkAU hfh8bMDnVxQFMsJzInUHbdfUTSBIlQsjwNNkAgtzmiBGOM7V9Kqp14MBpbOjoz2TjYbiQ/3jXZkd YSktkihDFAOs4AgKLzf3pwnNlnK9N+hQd1MlcgDDFhYKZ5578W/PTP5oeW06mQmDTFkeThgriAwn 8iznRVusDG8Ylh6yA0mhVAuTY1NbbYFSYNZMDYQC3YGYgBkTqTArsLIANEVcSL0bELPtNqoNtYHz TTg4iuTD2kqlcrng8k63pgkCx7a2JYcGe9vbM4okgeqHd4ynAu0iCVjUzfFBcDgiIxBrevFgmabI UBnadNTfRESeeN0SKyP2xbQsrEQwVXfhie//6dPPfqPcmA/GOCnIiTJeEivAYSEwo9T7dflYpAWm 1nNeqGNyXYyZeqNKGEokDGsJIqsogj+gyEBFYajXAv9Ft4AFaNgy4OIi3BAl0cdzMgStXKjCu4V/ 5FqhluDYQO++of5BEG29XgdwAwND2UiWrhqSDJ/TASoyxoT+BqQgC8OFeYA/oUUs9Ve3IsS3wnPL 6FR1V1Gw7vJLbzz27af+ZHF1IpJgAhHOJjqsMOyyacE68qIiB/wIaHz1Sh1Oqee2YL5gcI5Gf9hC BqAwksyKEsMLLmIdsKgosnW1BmChfKbh2AYoCUkW0XV4teGaBqmW1EK+YmhWPJYCCp3ZwfbkaLVM bINpibd2dw61+FoR2dbqDegyxyIetqGTDIHPWGg0qtFgUiQtrisBHxotszQoa3remPM2dDZ5+tbQ wX1UR0eoV9RnvvGt/3n8hUcDMSeR8oGPoQScKEiwKJIImoAjQrnBMmqVMs8iPpYlSYJSCIJE6Zlx Q2EfoIFnzAuIqzXTatiOAX8Qukg9KQc6xZtAR2NMnbcNwbHE9Vy1WjZSLZnx8T19vYOyIGuqXVhv tCU6OzsGYoFWjoRQ0oB59Mwx/uOwpGGQ4vLqxQuXTll2tad7ZFfPMZcEAQcFB04agSdBfVFM7GZ0 KEDviA7WALakYT5PRbEZKFiM4bK6Teo/OPn4H3/1v4YirOFUGNYQZLAGS3ERBGp/ECFYdYzNc1AQ 0taKIAC2yclksuFwGJLs9yuIvKrVou1oih+huo6NhSiFgrHcWtkvRVhGggk3VAG4FPP6xmqjUrJ3 7zw8NrqvO9svS8H5ueVapZHNZlMtiWQ4BU7RHEdmw/CfIXcA3jBrMpWM6tTime89/a2737d/duG8 bfh+4n2/ypME7AJkGaralFPsHPUkPUPWpOymmf/70MHPXjxjA6lmfGDB+yPri+Wpv/v2N1985TlQ hj8o6KYaDgc9uoFrB2elbph1y1Wxd0gZJFrwCiAyxBEMBhFVYqjOzqwkC+vrq+VKHjAh82KYsFp1 6FE62ruRU7W6RVxlI1fPrdbjoexg/56Dt93d1TFSLmpTV+Z5IqXT7fFYIhoMe345RA5ijTxRMyKx fIK4vD5dKK509SQKpcVnn3v8p3/6gbn5y9emNu488FA80IeToescC1CAgAs13ERnEyAPHRqYvEMt 1BM26oY3Gg2Y1SZ76aTkMMUnTv711//8q7pRBfenMwlwIZZdqdcaCCcbFdPV/EEST/hiLYo/wEfD vlBQwVA8XGWWrdWqUPhUKoHRypViqVSC5QKh+nwyjBRjy7U8L3OxjfXy9NSyX4ofPfyB/bfdFQ91 VMvW7MxaPlfNtvfAtaNpP6TKOBrpuwSEb8AmmaQiEAvsdGV24oUTP4DaDg71jg2P/OjF54aHh1uj qe8+cXyk5+7B3j2KGKTpFEBKFdnTj63cNxWffwgdOOAAhcqLZTUFB5vrymrZufalP/2Dp595orU1 KfsRRDD5fF431HK1ASlQfGw4piTTgVR7KJUMBAIKDDjdGccyDA27AXKG+OAjdgxhTsAfgmGqVVW4 MKAAzgnMXSzpFT6VzN51xwcOj9xNiDKfW786taTW7PHRfV2ZLswEDhf1ACAAPKnrJuV1xiw2FjYK M73tKYuUnjnxnWQq0pppfeZ7z3zg2ANXLl6bX1j59E9+5pWJieKKdWDvXelEO3CxqKFAUM5zuPNW Ar6JDrWnLvfwww+/jaG/Hmpjh5tJCVhkz69jvnf8u8/+6PuWpSNnwgvOzMzVal3dKJihEEm1yUPD 2ZHRzo7OaCiMq2q63iCOqKuuTwklk2kwcK1aR0JOFJVgIOY6gtYgpi6yblhvSHPTpcnXl8b733fv 7R/7mQ//QndybGm9cvrMxXrR7mofPLT3aDQEp45omimB9gXqH20UNkIh2WVUWIsTp743tzQ5vTQR axMYHolHI5Voee306WSyvSM7MDW1tGv4ECP6rl68lk5lkNNoVm88U7XdWjWpByGW56y9Ezq4Doh4 TgELOWrSs2o3vv5XX52auQQx2cgvr63nF5ZIOkMyWTK+O9PTk+zojIVi1Nc3raLlViAqIX87jE42 2znWPY7AcG5uDg5xKtk2P7sicCHX9s/PFE6fmtpYM8ZGbv/ET/3KBw8/2J4aWlosnHptsryhjw7d Njq0uwVeA2EqpQrkBSpoWvVaPa9IjN9HNuog6POqvTa3eKF/MLOamxVEl+XdJ596SpL9g4NjIh/s jo0sFwsLy+tD/WOry+ttqdZAMIB8DtI6eKPma7tD+G7QwQVQAZA5AAL1NIPaE6+88J0nH6s2qqpW g+sKne/sIWPjocEdic6umD9MXQ3dgKIVkIQTRVuRgyKfsQ0lFIoKfimXWy8USgjHdc1KJTqvXV05 NzHDkvCRAx+8/76f27PrrnSk78wrVy+dmzd1du+uo6ND4z45BIcQjjc8FJ8PDrRjWlWO1300HlB/ 8Pzfzi2fEfyqy9XL1bWRsX5Nb0BVfUrYdaTOrpGRtn3np6dF0GJVLRarY71joiwk40leEGmKgyYG KTqw7Tfy7tvQYWDsm5p1vZhNa0BUtlwbFt0XoNRTKhdgiWuN2h9+6Yt/+Z0/lqNw7httWSXWwu8/ NMSJDcxYUqCrBmwgbodQEA4gEnam6XP1rGUGfbKCDxgQeUxkqi5emMqtFUPB1OjwgcMH7s2k+wt5 Y35mtVIwOxJ9mWRXuiUlUl+EMotnOpHU0A29LCmYu75Umq83KrbeWNuYu7z4+kMf/WcqcR597NFk Oqzr9UQicXjorr/+/uPtme62dObZHxz/yAMPgjxL+UZXR3+YC2II2DjINWIemjiif0heYWOrDIkE CHWa4MDAuzXxAY4adWoNG8EiJ7LIrbEiZ1kwzIiUKbmvV1a/8J9/84kXn0x3kr7+UHt7ayAkcDyc fJPjDZbXHVhxxgBD4q4cvBc4da5g2X7XVkK+eL3s1iru1IWFteXijoFdIzv2jO7Y2ZrqKuTrb7x2 ybL5XWO3pdq6g4HUqVcnJ0+c+a1ff6ikESSRMOtSZT0TAlqlirH20hsvLldy+ULhUx/9xNzsxcsL p95/z4f8pO/k5Cszcy899KGPXivN1kpOIjZ44vhJtVFsTbbdf8+DHIk7dpA6xzQzbbKipZlFSYBo qID78ecfh33YtXOfwscsUwgIKceSDJVwn3/kP9JkrMtgofBhQd94BzMBMw5wOXAIMT3TIur04oWX zzyd6iy393AtyZik8J5DjKwk6naQTuSjkF2HVygSAveB9imB8KDhYK6Zq4uvvny2mNP6u3ffdfTD B/bctW/XndcuLZ59/XJpQ71t1+Hd4/u7W/sUMQRJXspVX3jh5M7dR2X/puz4JaWurhChdunaxEp+ tneoq1DKwQlIpEPr5ZVILBkUeqsNo1JdTHSGV5Zyat3d0XEwEk51ZtuGh0Z9fIsFKmf8LoQbEiGA clWOQw6tdvrq8xNTL9mkslFahiRlom0CB/mUGKzColExLSRspyWQNTxJAdlvRnd5AwOtVGe++cRX /+7Jv2BFuy3b0RJHHBxhXNk2RbyIg+F8PBvUGlwxb1ZKAM0v8nFUU9Q6f+bkxRM/fOP8mcUdfaMf Pvaxuw7fm23trpaMv/nmo47FHj185wMf/MhA52DMH0fya6NYhCbt3N0bzGam8lVWIpDdag7FC9ZW /A4J6gwiUutAZsdItn1m7kJEiTVq9uJsgSOB1pZuYod/9MOJpTlV5NICiXelR7szwxEp1UAuEkEa CyPaICKSj6VcabpsrJXdXC6/tJZbuu/I+2PxyOLiolfygDGCVdFkhXD/6ZEveBEH75WCqOOIDD8K CfAAaHWFUS8vnP3eD//2meOPreSmY2nZcKo4wYvcaMqOFmgp4TvFYhGp2XA4Fg7FEQfkN6oz15Zn rq5pNacr07tn56H33/2TrB2au5YvrKtIBh49fM/e8UPRUIvMBnPFfEAJGyYJBwJlnWAur15c2qjW xobaJ05tqOUKyjBExgQt3S1dPX92/+iwKDuvTLzaPdyDnJdWEfqzBwNiHEklZDl6OkeGBw4RgnBc aZhVgZOgGJBKEKFMaav88tlnTp89sZqfgdp2dLXNLVzr6+sLR2NTl6Yz2S5ZCBAH6VceFyLeQ/4D ORlah6KJF5cmCziR00kdYffktdPfePR/P/fS43JET3XKrlhDGtRxDRSeTCTLwVLgJ6+4AncZ5SQ4 5gvzyyCOiYn5arURjybvOHTs6IEHIv7OixNLkxPz8Wj3np13Hrvvp7rbxh0iIdZB/iURzSIjrqrU bZchL4T0Du9cXCvmiuTEyTPlmhmMQL39DUK64oPQjOnFK22hZCQs5AtrAz0japWfW1qH/Pa37jmy /9hI1+0SSWmaiNSFIMAnRl0NNzKuzL1hk0KZzC0Vz3fviHOKPj17HqEhkhmXF64mlTRcjaWlFZGg dAEHltZHUYberEp79W+Gh3qCTIkBs/Pd5/7ma3/1lbOXTzKyGo5zjlCFGyooNstBwFCN1sFOcMmQ eUKcAMGDZJ4+NX32bLFRI5m26K6xvbftPcIzLVMXi+cnVm0rfmD/h+498jOKr11kWi0SqBliucb8 /n/7o5dfP1dqOIjagcuFRXtDI3ccbNNU5/K0zsKN7O5AxRDeH+OKEIdEKntldrZOquGgtHztWjSQ bE/3Id+uQvaQNeVChPhVE3X0IGwQT0RUwxqkNjF96vTZ584vvqyT9UCc6e5vC8al9dJasZZPpdLF Qp0jvlSyfWluparXvBifEgyKGhQMqlDIcUCEkCohWlFff/71Z//mu395fuq0L8woYaaira9XlnWn rOtl06y6NqheY1yUW1CsKxULuYkzcwtzKjK346Oxe+/Zu2/vbeFAsJArFwvEL/ce+8Cnf/r+Xx0b uG9uQ/v6N56cXasBCITIqq1YbJiV4rKPzZXIs68sfPkbf/EXj76I2qBkcadfP+v4FD1I7Qosh89C Slhua+9dUxvHJ17hbSc/v8hY/G079/dku/xeOdyrwnKSoNDiHbFXyvMbjeWF5emLU68lMtxrZ59C ZaxuFp86/tji6kJ3Xy+ybV0dQ1cuLeSNxvDQXkPnalWzXK+BeUEX3O888ghgQvkMXIpAAYxT1jZW crNf/MOHc8X5wbFOTjbXC/P+iKT4GaTFUb5HEh05OoFV4NehbJBb21hd0uMxtq87PTYy3JrsQHyw vlKulk3XjhzY97Hb9tzfldhjk0CuZtXrwvMvTuzefyQQ8HqeJPbowd1SKKRZ5L9/6f+UdSve3XPx 8tXbhkZdU55eWJpdXuSU6FBv0A/NgWdl1dItiTpXWdtYGupsl4gPWYB4pAdWRjNrNldVqIMkoObX 0KDZudcmngNDgWJVvfj+g3svLZ0uqhuygiyiNjqyczA9NrOwnG3tyy2XbZ0f6dyD/MlA97DIKZLg R22Ve+QLj9DOH8QbAlduFJBM0NzK5x/+rM02UAXDoAxvyApfU8uGYSqCZDV4xvEJbBiZl+XF4tJ8 ySeFdgwODg2MJ+OdsB35XD2/ZoQD7YcPHPvQkU+lYnslLqsR/olnX336+69K/tZcoSEFE+3tMkWH IefnyLe/+8LAcOf5y+stbR3v/9Dg5ORSWEiMDSdfPnVu177dJ146IQotgx1BVGOQX7OImY4k5Qg3 nhw4PXEhGhtqiXVRT44zVGsV5RJU/TZKa6ZdOX7icd3O3bnnwEYjv15YuLT8kj/MRePJvs7hazOL HZl+zSCXLyyAxRnbH/KlJDG4o3enyPu9ejSCSplHqURSOIQFik9Esg7e0Te/9We5/KLkd/1hweUM +P4oXUZjIUnmTM2N+9qJLS3NrFUr6pEj9xw7dqxUKj7z/Se1QqigIqdBWuJdu/aP9feNJOWsQ6Iq CT11/MXLVxYXlsp33f3A6K7ktcWByUsLme7I2XMrmUxrNktqJrOwTnglvLZeCJHuVCRyeepCe/sh ENxQX3cmFf/qH385IfzCHQcTFhFM4ptZnnzxxKn1vqTDR5RAsoFiGNKrrFGtr51fmi4XSD5fOvbB ++JJhKN+mzRS6cQLL6509nNDO/oaddmw+LC/9cLEjGtJPiEuMeHhwVZTJQElgnoPTf97+WZaxhGQ F0GaQKGsjqTj5fmJx576ayQZNb1i2RoIFxlxxlaMuqSVBK3on56snXulmI0f/MPf+cv/8Itf3t3x kf7MXb/00O/W1yNxZfzg2Mc/cu+/unP059rkfTzpbJh+nsg6ahhyRNXseKItqJDuvr7l9eJzL87+ 4PmXn37ueWQ3a5pWQOpv327YPrVGBtrby2YFuYrWTGz24rljB0I//4lPmrJYIuT01VWXhPtTu7qT u/IVKd4+kk2NSlxI1RvwP5ZzV6/Nnxd8elVdrWtLyVa5WlsHjcbZRFsqm4imO4Se1YVKdZ3sHr6j JdgZUVp3Dh8QSchHwlElIRAfcZClRcMaAKIuMeUdlJ1gc4q1NVkkf/ZXfzQxeTIck1uSkXKlgFg4 6A+HAwkdRqJgOw2lM7n73/767336wV8J+tP1uuuT4hFfmnWVdKJz99ihkYG9YSkDq2EaAuMGZAHR F2nr6tg51jc3X7YcfrA/DPPz6mvT3b1dPf3di0uLY+M9F87Po0qwc2fs+DMnd/YPd3WEvvPM092D e1KRQD2/MdyXGRwIJ9Pycpn8+de+lYy29KYzg11DbV2IyEZ1Nygwgu42HK56afZVuNd37L1jNb/A 8mpXZ9up0ye7e3dwXAs8z3OTr+Yb5Y1luyXc058aaU13ZVLdiUAbqqa0C4uVvUCK1iuo4Hjda7SX 0ctUuFCc87NnfvjcU4ofAYFVLOckqHssydnK0nRpY97sS+//5E/92pd+/2v7xu7giD8gRKL+JJxP U+PigczuHQeziX6JhOFDcw7Scj6JZgdoqiQikLBAMonYzJWLuGk0gpyeE/AL998eFXgXFYXhwZ7V pVnYu1hYufD6RHuU7Bzq2Vid2T2e/PjH9ysijQ7Xa6Su4q5JXYNqgNEDDGnd0Plnnj6Tr8D8xVB9 FyQezeA8YYJRefraBYEwiViqkFNlkh7vvScdG12e0Xoye9KxPuTnFRINCS2AhkN3hguRQcRpIZiC UwD3Fq4XAg0W//H7ZfQ1+Hjpqe89VqisgX1QIajC20fnRKFWWK/Hg9kH3v+Jf/mpzz34oc8gy0wb ZTSUG2gZza8ICganLTS0BAEPGi4Czdp5ySUos4iqEu2UIX0dmVo5ZyLa5kh/T2b26iW6PXZj7tr0 6EiH3iiXNshtu0ZLxTU4xQ997P6ju/tRUkSKYWpefflM7sv/41uX3pgNBVLgr3ydlC3ajMA64dOn 5+YXdK+Yp8SSqUK5lCcb4+PDuq5uVHN9fUMXz80gEkYUev+RT37sg/9i7+gdbZFeXUMji0IcAckY 2puKeiRoHVNHAwmNFgGNgZ4GmhsDVDDnCxsLp069DAligJijt6Za0HNU2CgN9o785r/+95/75S+M 9x8iSPsjoydYMJOOUysV8ihHEldHggw+NM8hf6g21PVqea2hVoEQGvTgc6JBJ+ong70p16gtzSHC g7B0Vcs5CNaukYHpqQtBH4kExNWlxc7O1mMfvg8hUZIjaQ/WvGb8+Xe+8eiTf/fpn33wI3d3DXQM vH7uytlF8yvfOnHpas2qYPwWx5Fgs1wippMZEOXCwkIUAhqJrK2tp5OdjqUUVq3iBtCMx+RuhY1B XlD2QHcD+jR8aKzDPOhW0xIEoRE1XCYUNNGdZ7LITeSr6yjh/uiF48vLq+B+BO9owZq6sNEW7/+V X/jc7/72fzkwdif6SKplHTEGz0uNBkpyFUmWIvFwKBQwdIQAtEUL8gPXwKf4g5GQzw81ppVg2lpi 6Li1jG0w6/XKOjJG6Dwo5RbhUu8dHVifm8YzR4f3DPdmYuPdQjpGIjIJ8kSvoI+Caj0nigePHE0k aJDhD4YFXzDdLZw4Pfniaxf8ISKHIihb00Yu4sZIeySQmp6anVy6VC7XVxbXA2Lk3ns/0JYJxKLE 0CCIQdOg1hoeo6ki/QsfQfJqMzRipOVSXadladoihRACNReSF4PG8VeeeuYHT9dqDk9aGC1Vz0V+ 4n2/+Nlf/INPfeS3Yjzg50RGjIRoww5tdlVCsi+MlBpttSOwegGGRciPX33IyDkuSpc04UYLsaKA eBUl0XJZDfrJjqGeS+dOAan+rNLiFy+/fj7Ms5/66AOkXLx7T++urA+V3Rb0Jal1TB9mFBKRDvqj vsTc7LIviPWTvt3MNFzfFfLbD//yMydOv3rZ1kVYRLpAH4G9Dx0c/wDv+CZeO9vXPVytgE+FiBKq 1PMoYaC9EK09SEmj1gjqRczESSLKKsgRomRDnT4U79HHi1yMg3wOaqki9xuPfEYk/Fe+9pWzk+cU KWQZrMxHfvZn/vlDD36mr3tEYHygbDC57LVn0iasZtuslyfZ9mpm1bDZXkaveYJXOUMLE48aqIwM LpmZXbh2bXp81/6wn2yslXtQ6O0IpuKxtpgCL47SU2kdrRfoIqMlXlQRbSBMZhfKy6t5ImdfeWM1 ngiXK46m2SMjIctJnL98wdArY2N9kQDdfdRsgqwv3hIcHhpsT3fOzC2xgoIsjyz6eUa29GaPwfU0 6Pbpv3k59DfaKY047drK7JXL10zDPT95Odve9fnP//YnP/lQKp5GYZ8GLRyHcrjXTW+jMtNMs777 A01r+KcJZ2dHO9StWq4CwnvuuqO7E9xCfCL9CYQOAUB+lnZOcZA+igssBi7szLZXysUzp06uLMwa DdLRnro8+QbI6+4jXbnlObAacu8YEODS0h2s21rl0sWZyQtTPKf4fVF0yaHblBoAWITmPN71gRRY 4PRr544fP5HPlX7j33z2i7/3+4dvuyPABxs6WkAhmWinhw4yyDkhTUzrf7cyOg2kkLd3bcQ8uG6g t/fQgX0hv4JJpmJMxEezopBNKp6omTMu0pPeEwAcEkg438sfAdM0upcSsfCDH7ujq52kYyHYQrBn e4zcc/uhYnGlobqoXgMXhQsIxE9scWWpdOnCXGd2qLtlEO4o2g8BHVTlXcOyeSKLAP/xbz91eP/t n/31f/e53/r33W29mLFmGT4pgHZDrwOcoU2PaMWipu7m0s+7uBuSK+iuMTUVU4tHpLtvP5yK0lGg o17/K3IwtDEgoEBe0MNlUPTpv1QHcAn+SkZJLKj4BSYbx9JJS1BijMr8VBWCPb6jC1W1SIjBwr1e N/gS0tDg7oP77n7fnQ/sHDiI3aH5wOZoiOG3SnrvYubUG1xe2GiJpv/kf339l3/+1xyTzRWQhZTg E9FCFnLoBjJiJnoHFJ+PQkN7JG7hgB1AeAwm9/vQWYSeZTuAfoQmLdl0PXh5Xg8eVKJF92ZrBPaC eqs0W0PRwVS6s21Ls1dUxLIQpQwfC0rV/BIuNOpFnjGCMnWL8BNafuCOKUykMzmUTQwiJEYeGbGl wFBg0DXm3ewWEGIl3v87D38xk+hcWVv3C6F0LFNv1EHXm/Jyc2sUisW3gM3WqY7jR1KNNuIbSChS O40mIKSzMFMLthO9FjDHaCtwBVTNaO8HRQeJW0gEtgMnDPZ0VAtrSBMAhZhE7n/f0Z3DfVixyJiN KlKsukqzxkTkFdptSlDrUgyL1RESEEVkkPxgUeOnvW/v9MTpO6yKzaSz0WACch6PJJrPvaGqiwwq av4SWpQkH1zgWrUKzwWzhwTdKjq8JKn1Gi3rum7ArzTFhDYHwPNykSjW8FHwGEEHRtSgsGjYpd5d s6zmKWBbKlourEno5kFNiJB9OzszcR5Nf6ytHti7swXuEwgZ6KAFkwfNIQkLd8OnsCGQDlBXddWP RmkJOQ70zdyC7DAGbdm7ici958CuNz9tfzKn+SV90uzdHptPPl5//gwue/MxzuZ7szH8+jne1zCN 3jm0Bc976oQGap4dOHHiVEdHRyaTEijO3qPriIbQ1eXNBdqHzDMPKJtzxKAweZsNxNgPh6MNrt5P 6IS/ubH071kMQ9vwPSKg7ttbsKBPdW4dzQeY3/XQ21a+if/WU4ceDDeehb5+F+9rLJPiQuFrAtQ8 0K/rh/H3DlQvcTEOC13T3k5SdFA+2HpY+zo6FFlkzik6Ds0Q3yI6tC5M9dHbL/r0xZaH5328+ZmT pi/1jzg2vQCgsPmiC7/+940N2HIWKCXTe2+bT8CHeJauDq3y0CNkwCE7zZ7sphPTXEVTPKhreENC mo+eehJ1i/6IJ+HNBx3epGD/CBDecok38Ntg6t3xbfR/+yOtWwB57X80BoJPZOoqLU3Qh75oVrz5 yNkND2y77HuTaS7NU+br03ib/5fBOy71/wJiiAD5npnXkAAAAABJRU5ErkJggg== --485b390f7dae2c33a204c9071257-- From TSELIKIS.Christos@haicorp.com Thu Sep 6 05:00:20 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6313521F853E for ; Thu, 6 Sep 2012 05:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIfE8lGVwYrG for ; Thu, 6 Sep 2012 05:00:18 -0700 (PDT) Received: from haiedgesrv1.haicorp.com (haiedgesrv1.haicorp.com [212.205.103.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9E121F8587 for ; Thu, 6 Sep 2012 05:00:16 -0700 (PDT) Received: from haimail2.hai.gr (10.0.200.55) by haiedgesrv1.haicorp.com (192.168.2.6) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 6 Sep 2012 14:52:59 +0300 Received: from HAIMAIL1.hai.gr ([10.0.200.56]) by haimail2.hai.gr ([10.0.200.55]) with mapi; Thu, 6 Sep 2012 14:59:59 +0300 From: TSELIKIS.Christos To: 'Michele Rodolfi' Date: Thu, 6 Sep 2012 14:59:58 +0300 Thread-Topic: [dtn-users] On measuring the DTN2 performance Thread-Index: Ac2MJYU2HubqUzxwQBmcd9Lv5LiCcQAAKxFg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_E57BD7A928881D48B732EFA5435DDAED02CCB687BD85HAIMAIL1hai_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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: Thu, 06 Sep 2012 12:00:20 -0000 --_004_E57BD7A928881D48B732EFA5435DDAED02CCB687BD85HAIMAIL1hai_ Content-Type: multipart/alternative; boundary="_000_E57BD7A928881D48B732EFA5435DDAED02CCB687BD85HAIMAIL1hai_" --_000_E57BD7A928881D48B732EFA5435DDAED02CCB687BD85HAIMAIL1hai_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michele, Thanks, I look forward to sending you feedback on new dtn_perf features. Whenever would be convenient for you, I remain tuned for further discussion= s. With very kind regards, Tselikis Christos Hellenic Aerospace Industry S.A. Electronics Engineering Department e-mail: Tselikis.Christos@haicorp.com PO Box 23, GR-32009 Schimatari, Greece Tel. : +30 22620 52561 Fax: +30 22620 52910 [cid:image001.png@01CD8C40.4B6DE020] From: Michele Rodolfi [mailto:michirod@gmail.com] Sent: Thursday, September 06, 2012 2:48 PM To: TSELIKIS.Christos Cc: dtn-users@irtf.org Subject: Re: [dtn-users] On measuring the DTN2 performance 2012/9/6 TSELIKIS.Christos > Hi all, Hi Christos, I'm returning on the very interesting dtn2 performance issues/results that = appeared in the list around July 2012 (seems that I let the thread sleeping= for too long, but it's never too late). Well, just a few simple things, how do you find the dtn_perf (v2) dtn2 appl= ication as a measuring the DTN network throughput tool? I suspect that sinc= e the results are reported at the client side of the appl, it can be consid= ered for network throughput/delay estimations, yes especially versus the bu= ndle payload sizes (ACKs are taken into account). Also can be used for API = measurements and multi-hop scenarios, in my opinion. Finally, has anybody b= umped into some newer version of it (v3)? I'm actually working on the development of dtnperf (v3) for my thesis at th= e university of Bologna (Italy). There are many changes and improvements and i need one or two weeks to ulti= mate the program and write some documentation. Then I'll have to test the application to find bugs and fix them, but i hop= e you can try the app and send me some feedback so i can consider another p= oint of view. With very kind regards, ctselikis Best regards Michele Rodolfi Tselikis Christos Hellenic Aerospace Industry S.A. Electronics Engineering Department e-mail: Tselikis.Christos@haicorp.com PO Box 23, GR-32009 Schimatari, Greece Tel. : +30 22620 52561 Fax: +30 22620 52910 [cid:image001.png@01CD8C40.4B6DE020] _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users --_000_E57BD7A928881D48B732EFA5435DDAED02CCB687BD85HAIMAIL1hai_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michele,

Thanks, I look forward to sending you feedback on new dtn_pe= rf features.

Whenever would be convenient for you, I remain tuned for fur= ther discussions.

With very kind regards,

 

 

Tselikis Christos

Hellenic Aerospace Industry S.A.
Electronics Engineering Department 
e-mail: Tselikis.Christos@= haicorp.com

PO Box 23, GR-32009 Schimatari, Greece

Tel. : +30 22620 52561
Fax: +30 22620 52910

3Duntitled

 

From: Michele Rodolfi [mailto:michirod@gmail.= com]
Sent: Thursday, September 06, 2012 2:48 PM
To: TSELIKIS.Christos
Cc: dtn-users@irtf.org
Subject: Re: [dtn-users] On measuring the DTN2 performance

 

 

2012/9/6 TSELIKIS.Christos <TSELIKIS.Ch= ristos@haicorp.com>

Hi all,

 

Hi Christos,
 

I’m returning on the very interesting dtn2 performance issues/results that appeared in the list around July 2012 (seems that I let= the thread sleeping for too long, but it’s never too late).

Well, just a few simple things, how do you find the dtn_perf (= v2) dtn2 application as a measuring the DTN network throughput tool? I suspect = that since the results are reported at the client side of the appl, it can be considered for network throughput/delay estimations, yes especially versus = the bundle payload sizes (ACKs are taken into account). Also can be used for AP= I measurements and multi-hop scenarios, in my opinion. Finally, has anybody bumped into some newer version of it (v3)?


I'm actually working on the development of dtnperf (v3) for my thesis at th= e university of Bologna (Italy).
There are many changes and improvements and i need one or two weeks to ulti= mate the program and write some documentation.
Then I'll have to test the application to find bugs and fix them, but i hop= e you can try the app and send me some feedback so i can consider another poi= nt of view.

With very kind regards,

ctselikis  

 

Best regards
   Michele Rodolfi

 

 

Tselikis Christos =

Hellenic Aerospace Industry S.A.
Electronics Engineering Department&nbs= p;
e-mail: = Tselikis.Christos@haicorp.com

PO Box 23, GR-32009 Schimatari, Greece

Tel. : +30 22620 52561
Fax: +3= 0 22620 52910

3Duntitled

 


_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users

 

--_000_E57BD7A928881D48B732EFA5435DDAED02CCB687BD85HAIMAIL1hai_-- --_004_E57BD7A928881D48B732EFA5435DDAED02CCB687BD85HAIMAIL1hai_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=10192; creation-date="Thu, 06 Sep 2012 14:59:57 GMT"; modification-date="Thu, 06 Sep 2012 14:59:57 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAF8AAAA8CAIAAACPTvFWAAAAAXNSR0IArs4c6QAAJ4pJREFUeF7F fAmUJddZ3q296u1Lv6X79et9m95m0+yj1bI8smWDjUEYR44DDhACAYxPFodYgoNPDpCTnOQ4Jphg bI4BOyCwZS2WbFljabSMRqNRz/SsPT29b6/77UvtVfluvZ6eHi2gITIpPT31e6/q1r3f/f/vX0uM bdvkx3cwlstgfIsQFjdhtt2IcfHBoV/Qv7w/iOMSnrgyfW8eLr3qpoNedfOxfdDtvzDNMbcf9Bum ea+bRm7exXu/eXzmx4sOFswCHUzIQ2fbvTf/3lzDjZW4RHCbE70x47dg9JZ13/jiJlCa990Ok8O8 FfHN2/1/QGdr2m9G56Ztvo6ayzh4kbfZdu/0Gwt7W7zeIiwYB5e8aTQ6yNte/jZy+uOWnU2J3ZSU t+qFt+obMsVgOVDDW1B2l/FU660o3CRfWzemN/iH0NmSOPbHjk5z5W8jz29CqvkRK2UhO+b1pb2V O5q/bH3PXldDXPkO2N8EE6YDUnuTmLzpLv9U6IACGRerdYm7RZ7XKXBLTd60KJzIGNtkYfvP15dx Q1moIGxnMw+jdyJqKsgemu+EzjaYPK388coOQyyGQBC2awoVj82Xy7gMe0PUm1LW3Ooba9w0Z5sS cBOJuPRsOsh2dtu0ADcr1g046B1vHDcR9s23oDP4p0EHk7i+wXQlm0zRhIYSh+tJu3fKpiQ019jE 6CZpgCRufU//BjQgcmju9nMhIJ68Nt892W2OtInj29iyt0DjbdV7ZdEZjx1d18WAjkP3hMOB+W1O Dd9AVrHbeGG+jGWZhOGIyxGWYwi3JTVN4cBZdAUulTq8OziDnuJJlTfG9e8dyzFxBiwTAGEJdx0L YO2yHEsR9tCxt+5MRcdxsSceI2K2mDM+0PnfEMzNvXzP0ME9cNCFMQxg2VyKhwk2DuTjuJiT7TAO ix9Zl+d4zwukWoapA08KqUN4CBMF0Jtt8+WpAlaxtfVbygGpYRlct0npOMN26Pa4DiNLclNBLct1 bLp+QWCwD5ap2wCUEB4HR91OXNWc+VuP9xKdLZFh6Z55cmQx/JYx2aJjz13VdI1KBcezLE5pmmXP ZFGeglHfftArbU9cthC7frpbaRRwN9yR4wSsliOC9xN8UAgcHc/bNQYn4Cx8bjSKQZ+vScyWbQFK SZRwZ2yeJ5k3EfZ7hk4TmqbsNKGhG+IKvEcfnlDRd9u1DadhuUZAlj1No/qGl70p1qZMTBA53XPs Ol6m4wk/I4qyN2Bz9k0wqR8cEPxb33jCh3Ck+SsnUKQ29wRXWvjJtgKcgN1paBrmqUgK9SBcp1Sq RCLR6+jc8NTfM3SwBsoz0GbXtbAuT3SxYYZO10JFGI4M0V2iO/RlMJQK7BqplesVHNVqvVqvm5Y6 ffWs4+qmaRs4dBNvGMy23HK5gpGpAkIqqBp62+EQgZdEjpdln9/vDwRCwUBIUfyiKLa1duCbSCQW iUQCgaBPDPCEynG9Xg3IisjJ2CfMjGOaCAKjJvTb7D1gfq9YGYhQGvYYZ4uAvMDSdDxl0UjFMMs1 rVhV1xt65Y2Jk4atNfRaTW3UcNTrmqZbtq74eMfBYI6JA8hYDujbcVyeF4ELVBWkD+zoYUF1Gb0O I+DapmNYJt5tChklLllURFkJBYLhSCyGV0s8FokHfcGje490tLYn4imc2Khr0EggC4wQwnjoIAy+ odTvGToYsqlcEJnm8Lqua0ZRCWqF2nJufWFtYyFfXNwoLRUqyzW1kGyLOowBFbNdCyzatB1gz0ZD A6cCAnwBtQI6jk2Jt1pp4B3oeMBRjcMfxGaIITk271qOgd9wIbWCsFycAwTB7/QGjmNi7YzEixIr l1ersWC8q7P70KFDx449MDa8EzpYqdYCgfCb0flHyM5mBsAjsE3PqunFcZTkIA6iCJMCoTXXy0sb pbkTp77TMFdVrQJ9kXyMzw81cBjebBh1xzFMXAIrYkFMbConNmeYrOtwFBocJt4dyAg1S1g7Rcdj I3NTfCA1lkZxdCycSZUOdo0BBYNxXMrUDCJ+quqeIUMQ4Sg7OvfsHtm3Z8+e9kxHNBoLh6MiL1u2 g5O3u12bHHpLmkUjA9ZVK1VBlHiJ0mGjYYsCzAXFA0bCJfWqvTg18+rklZfmFiaLtdl4qyD6bEWR ZEVgWUi+DjoxLB3UYABL1dJNSA7nOizlF5NvNEBTokftrGOBfSywD12/JyyGTr+BBmHxHMczvC0G QPOabWAQEDtIhGNswbU4xgXLsFrdgAhLghgKhfp7+seHD338vl+S+bgsU3u//bhuVa5bVrr9t8g7 FB3KW5gIhNaqa6CJAKaJ3YXrsV6Zf/38icnLJ5bzZ4lQisRJIOrqTonlzKbRBbKbETXIWcOaGeAC u+baom1xJiRCZ/z+Fk2zqtUqqLpehW3RsPPYdjgAlOsdosh8OBgJBsOwYoQ1q2ZedzXIDsvwPMPZ JmlU9EZN54gk8z5BkNOJzK6x3UODo309/ZnQgKVHRDZCtd+zbB4Z3BysbFpDahNvjXfgsGOneIm6 poZZIZwhcHAwrZnVqZOvvwRCWd2Yr6pLrlAVFEOQNEYwlICELQCY19HZdOahSvBmQTEOpMZ0dc1W VQOQbeSrpgnOIoZBpw2WFwVwGYEOwCgF/SEIqqYa9XpDa6iWzUm+qAYyV+uNRsUyDTgQoiCLvBgO trQls62J7u7s0NDA7mQ0yxJJIAHe9XPN3CO2mto+in1TG73j/8XfAavbBLPnZdhv1SXlqrN2/tLp k2+8cHnqvOk2CG9IfjYQ5iUf7qlBdXBj8DT0CO+UkGwbtoiaf5bHO9QE0qFphqqqmkq5o1wlgkAU hfh8bMDnVxQFMsJzInUHbdfUTSBIlQsjwNNkAgtzmiBGOM7V9Kqp14MBpbOjoz2TjYbiQ/3jXZkd YSktkihDFAOs4AgKLzf3pwnNlnK9N+hQd1MlcgDDFhYKZ5578W/PTP5oeW06mQmDTFkeThgriAwn 8iznRVusDG8Ylh6yA0mhVAuTY1NbbYFSYNZMDYQC3YGYgBkTqTArsLIANEVcSL0bELPtNqoNtYHz TTg4iuTD2kqlcrng8k63pgkCx7a2JYcGe9vbM4okgeqHd4ynAu0iCVjUzfFBcDgiIxBrevFgmabI UBnadNTfRESeeN0SKyP2xbQsrEQwVXfhie//6dPPfqPcmA/GOCnIiTJeEivAYSEwo9T7dflYpAWm 1nNeqGNyXYyZeqNKGEokDGsJIqsogj+gyEBFYajXAv9Ft4AFaNgy4OIi3BAl0cdzMgStXKjCu4V/ 5FqhluDYQO++of5BEG29XgdwAwND2UiWrhqSDJ/TASoyxoT+BqQgC8OFeYA/oUUs9Ve3IsS3wnPL 6FR1V1Gw7vJLbzz27af+ZHF1IpJgAhHOJjqsMOyyacE68qIiB/wIaHz1Sh1Oqee2YL5gcI5Gf9hC BqAwksyKEsMLLmIdsKgosnW1BmChfKbh2AYoCUkW0XV4teGaBqmW1EK+YmhWPJYCCp3ZwfbkaLVM bINpibd2dw61+FoR2dbqDegyxyIetqGTDIHPWGg0qtFgUiQtrisBHxotszQoa3remPM2dDZ5+tbQ wX1UR0eoV9RnvvGt/3n8hUcDMSeR8oGPoQScKEiwKJIImoAjQrnBMmqVMs8iPpYlSYJSCIJE6Zlx Q2EfoIFnzAuIqzXTatiOAX8Qukg9KQc6xZtAR2NMnbcNwbHE9Vy1WjZSLZnx8T19vYOyIGuqXVhv tCU6OzsGYoFWjoRQ0oB59Mwx/uOwpGGQ4vLqxQuXTll2tad7ZFfPMZcEAQcFB04agSdBfVFM7GZ0 KEDviA7WALakYT5PRbEZKFiM4bK6Teo/OPn4H3/1v4YirOFUGNYQZLAGS3ERBGp/ECFYdYzNc1AQ 0taKIAC2yclksuFwGJLs9yuIvKrVou1oih+huo6NhSiFgrHcWtkvRVhGggk3VAG4FPP6xmqjUrJ3 7zw8NrqvO9svS8H5ueVapZHNZlMtiWQ4BU7RHEdmw/CfIXcA3jBrMpWM6tTime89/a2737d/duG8 bfh+4n2/ypME7AJkGaralFPsHPUkPUPWpOymmf/70MHPXjxjA6lmfGDB+yPri+Wpv/v2N1985TlQ hj8o6KYaDgc9uoFrB2elbph1y1Wxd0gZJFrwCiAyxBEMBhFVYqjOzqwkC+vrq+VKHjAh82KYsFp1 6FE62ruRU7W6RVxlI1fPrdbjoexg/56Dt93d1TFSLmpTV+Z5IqXT7fFYIhoMe345RA5ijTxRMyKx fIK4vD5dKK509SQKpcVnn3v8p3/6gbn5y9emNu488FA80IeToescC1CAgAs13ERnEyAPHRqYvEMt 1BM26oY3Gg2Y1SZ76aTkMMUnTv711//8q7pRBfenMwlwIZZdqdcaCCcbFdPV/EEST/hiLYo/wEfD vlBQwVA8XGWWrdWqUPhUKoHRypViqVSC5QKh+nwyjBRjy7U8L3OxjfXy9NSyX4ofPfyB/bfdFQ91 VMvW7MxaPlfNtvfAtaNpP6TKOBrpuwSEb8AmmaQiEAvsdGV24oUTP4DaDg71jg2P/OjF54aHh1uj qe8+cXyk5+7B3j2KGKTpFEBKFdnTj63cNxWffwgdOOAAhcqLZTUFB5vrymrZufalP/2Dp595orU1 KfsRRDD5fF431HK1ASlQfGw4piTTgVR7KJUMBAIKDDjdGccyDA27AXKG+OAjdgxhTsAfgmGqVVW4 MKAAzgnMXSzpFT6VzN51xwcOj9xNiDKfW786taTW7PHRfV2ZLswEDhf1ACAAPKnrJuV1xiw2FjYK M73tKYuUnjnxnWQq0pppfeZ7z3zg2ANXLl6bX1j59E9+5pWJieKKdWDvXelEO3CxqKFAUM5zuPNW Ar6JDrWnLvfwww+/jaG/Hmpjh5tJCVhkz69jvnf8u8/+6PuWpSNnwgvOzMzVal3dKJihEEm1yUPD 2ZHRzo7OaCiMq2q63iCOqKuuTwklk2kwcK1aR0JOFJVgIOY6gtYgpi6yblhvSHPTpcnXl8b733fv 7R/7mQ//QndybGm9cvrMxXrR7mofPLT3aDQEp45omimB9gXqH20UNkIh2WVUWIsTp743tzQ5vTQR axMYHolHI5Voee306WSyvSM7MDW1tGv4ECP6rl68lk5lkNNoVm88U7XdWjWpByGW56y9Ezq4Doh4 TgELOWrSs2o3vv5XX52auQQx2cgvr63nF5ZIOkMyWTK+O9PTk+zojIVi1Nc3raLlViAqIX87jE42 2znWPY7AcG5uDg5xKtk2P7sicCHX9s/PFE6fmtpYM8ZGbv/ET/3KBw8/2J4aWlosnHptsryhjw7d Njq0uwVeA2EqpQrkBSpoWvVaPa9IjN9HNuog6POqvTa3eKF/MLOamxVEl+XdJ596SpL9g4NjIh/s jo0sFwsLy+tD/WOry+ttqdZAMIB8DtI6eKPma7tD+G7QwQVQAZA5AAL1NIPaE6+88J0nH6s2qqpW g+sKne/sIWPjocEdic6umD9MXQ3dgKIVkIQTRVuRgyKfsQ0lFIoKfimXWy8USgjHdc1KJTqvXV05 NzHDkvCRAx+8/76f27PrrnSk78wrVy+dmzd1du+uo6ND4z45BIcQjjc8FJ8PDrRjWlWO1300HlB/ 8Pzfzi2fEfyqy9XL1bWRsX5Nb0BVfUrYdaTOrpGRtn3np6dF0GJVLRarY71joiwk40leEGmKgyYG KTqw7Tfy7tvQYWDsm5p1vZhNa0BUtlwbFt0XoNRTKhdgiWuN2h9+6Yt/+Z0/lqNw7httWSXWwu8/ NMSJDcxYUqCrBmwgbodQEA4gEnam6XP1rGUGfbKCDxgQeUxkqi5emMqtFUPB1OjwgcMH7s2k+wt5 Y35mtVIwOxJ9mWRXuiUlUl+EMotnOpHU0A29LCmYu75Umq83KrbeWNuYu7z4+kMf/WcqcR597NFk Oqzr9UQicXjorr/+/uPtme62dObZHxz/yAMPgjxL+UZXR3+YC2II2DjINWIemjiif0heYWOrDIkE CHWa4MDAuzXxAY4adWoNG8EiJ7LIrbEiZ1kwzIiUKbmvV1a/8J9/84kXn0x3kr7+UHt7ayAkcDyc fJPjDZbXHVhxxgBD4q4cvBc4da5g2X7XVkK+eL3s1iru1IWFteXijoFdIzv2jO7Y2ZrqKuTrb7x2 ybL5XWO3pdq6g4HUqVcnJ0+c+a1ff6ikESSRMOtSZT0TAlqlirH20hsvLldy+ULhUx/9xNzsxcsL p95/z4f8pO/k5Cszcy899KGPXivN1kpOIjZ44vhJtVFsTbbdf8+DHIk7dpA6xzQzbbKipZlFSYBo qID78ecfh33YtXOfwscsUwgIKceSDJVwn3/kP9JkrMtgofBhQd94BzMBMw5wOXAIMT3TIur04oWX zzyd6iy393AtyZik8J5DjKwk6naQTuSjkF2HVygSAveB9imB8KDhYK6Zq4uvvny2mNP6u3ffdfTD B/bctW/XndcuLZ59/XJpQ71t1+Hd4/u7W/sUMQRJXspVX3jh5M7dR2X/puz4JaWurhChdunaxEp+ tneoq1DKwQlIpEPr5ZVILBkUeqsNo1JdTHSGV5Zyat3d0XEwEk51ZtuGh0Z9fIsFKmf8LoQbEiGA clWOQw6tdvrq8xNTL9mkslFahiRlom0CB/mUGKzColExLSRspyWQNTxJAdlvRnd5AwOtVGe++cRX /+7Jv2BFuy3b0RJHHBxhXNk2RbyIg+F8PBvUGlwxb1ZKAM0v8nFUU9Q6f+bkxRM/fOP8mcUdfaMf Pvaxuw7fm23trpaMv/nmo47FHj185wMf/MhA52DMH0fya6NYhCbt3N0bzGam8lVWIpDdag7FC9ZW /A4J6gwiUutAZsdItn1m7kJEiTVq9uJsgSOB1pZuYod/9MOJpTlV5NICiXelR7szwxEp1UAuEkEa CyPaICKSj6VcabpsrJXdXC6/tJZbuu/I+2PxyOLiolfygDGCVdFkhXD/6ZEveBEH75WCqOOIDD8K CfAAaHWFUS8vnP3eD//2meOPreSmY2nZcKo4wYvcaMqOFmgp4TvFYhGp2XA4Fg7FEQfkN6oz15Zn rq5pNacr07tn56H33/2TrB2au5YvrKtIBh49fM/e8UPRUIvMBnPFfEAJGyYJBwJlnWAur15c2qjW xobaJ05tqOUKyjBExgQt3S1dPX92/+iwKDuvTLzaPdyDnJdWEfqzBwNiHEklZDl6OkeGBw4RgnBc aZhVgZOgGJBKEKFMaav88tlnTp89sZqfgdp2dLXNLVzr6+sLR2NTl6Yz2S5ZCBAH6VceFyLeQ/4D ORlah6KJF5cmCziR00kdYffktdPfePR/P/fS43JET3XKrlhDGtRxDRSeTCTLwVLgJ6+4AncZ5SQ4 5gvzyyCOiYn5arURjybvOHTs6IEHIv7OixNLkxPz8Wj3np13Hrvvp7rbxh0iIdZB/iURzSIjrqrU bZchL4T0Du9cXCvmiuTEyTPlmhmMQL39DUK64oPQjOnFK22hZCQs5AtrAz0japWfW1qH/Pa37jmy /9hI1+0SSWmaiNSFIMAnRl0NNzKuzL1hk0KZzC0Vz3fviHOKPj17HqEhkhmXF64mlTRcjaWlFZGg dAEHltZHUYberEp79W+Gh3qCTIkBs/Pd5/7ma3/1lbOXTzKyGo5zjlCFGyooNstBwFCN1sFOcMmQ eUKcAMGDZJ4+NX32bLFRI5m26K6xvbftPcIzLVMXi+cnVm0rfmD/h+498jOKr11kWi0SqBliucb8 /n/7o5dfP1dqOIjagcuFRXtDI3ccbNNU5/K0zsKN7O5AxRDeH+OKEIdEKntldrZOquGgtHztWjSQ bE/3Id+uQvaQNeVChPhVE3X0IGwQT0RUwxqkNjF96vTZ584vvqyT9UCc6e5vC8al9dJasZZPpdLF Qp0jvlSyfWluparXvBifEgyKGhQMqlDIcUCEkCohWlFff/71Z//mu395fuq0L8woYaaira9XlnWn rOtl06y6NqheY1yUW1CsKxULuYkzcwtzKjK346Oxe+/Zu2/vbeFAsJArFwvEL/ce+8Cnf/r+Xx0b uG9uQ/v6N56cXasBCITIqq1YbJiV4rKPzZXIs68sfPkbf/EXj76I2qBkcadfP+v4FD1I7Qosh89C Slhua+9dUxvHJ17hbSc/v8hY/G079/dku/xeOdyrwnKSoNDiHbFXyvMbjeWF5emLU68lMtxrZ59C ZaxuFp86/tji6kJ3Xy+ybV0dQ1cuLeSNxvDQXkPnalWzXK+BeUEX3O888ghgQvkMXIpAAYxT1jZW crNf/MOHc8X5wbFOTjbXC/P+iKT4GaTFUb5HEh05OoFV4NehbJBb21hd0uMxtq87PTYy3JrsQHyw vlKulk3XjhzY97Hb9tzfldhjk0CuZtXrwvMvTuzefyQQ8HqeJPbowd1SKKRZ5L9/6f+UdSve3XPx 8tXbhkZdU55eWJpdXuSU6FBv0A/NgWdl1dItiTpXWdtYGupsl4gPWYB4pAdWRjNrNldVqIMkoObX 0KDZudcmngNDgWJVvfj+g3svLZ0uqhuygiyiNjqyczA9NrOwnG3tyy2XbZ0f6dyD/MlA97DIKZLg R22Ve+QLj9DOH8QbAlduFJBM0NzK5x/+rM02UAXDoAxvyApfU8uGYSqCZDV4xvEJbBiZl+XF4tJ8 ySeFdgwODg2MJ+OdsB35XD2/ZoQD7YcPHPvQkU+lYnslLqsR/olnX336+69K/tZcoSEFE+3tMkWH IefnyLe/+8LAcOf5y+stbR3v/9Dg5ORSWEiMDSdfPnVu177dJ146IQotgx1BVGOQX7OImY4k5Qg3 nhw4PXEhGhtqiXVRT44zVGsV5RJU/TZKa6ZdOX7icd3O3bnnwEYjv15YuLT8kj/MRePJvs7hazOL HZl+zSCXLyyAxRnbH/KlJDG4o3enyPu9ejSCSplHqURSOIQFik9Esg7e0Te/9We5/KLkd/1hweUM +P4oXUZjIUnmTM2N+9qJLS3NrFUr6pEj9xw7dqxUKj7z/Se1QqigIqdBWuJdu/aP9feNJOWsQ6Iq CT11/MXLVxYXlsp33f3A6K7ktcWByUsLme7I2XMrmUxrNktqJrOwTnglvLZeCJHuVCRyeepCe/sh ENxQX3cmFf/qH385IfzCHQcTFhFM4ptZnnzxxKn1vqTDR5RAsoFiGNKrrFGtr51fmi4XSD5fOvbB ++JJhKN+mzRS6cQLL6509nNDO/oaddmw+LC/9cLEjGtJPiEuMeHhwVZTJQElgnoPTf97+WZaxhGQ F0GaQKGsjqTj5fmJx576ayQZNb1i2RoIFxlxxlaMuqSVBK3on56snXulmI0f/MPf+cv/8Itf3t3x kf7MXb/00O/W1yNxZfzg2Mc/cu+/unP059rkfTzpbJh+nsg6ahhyRNXseKItqJDuvr7l9eJzL87+ 4PmXn37ueWQ3a5pWQOpv327YPrVGBtrby2YFuYrWTGz24rljB0I//4lPmrJYIuT01VWXhPtTu7qT u/IVKd4+kk2NSlxI1RvwP5ZzV6/Nnxd8elVdrWtLyVa5WlsHjcbZRFsqm4imO4Se1YVKdZ3sHr6j JdgZUVp3Dh8QSchHwlElIRAfcZClRcMaAKIuMeUdlJ1gc4q1NVkkf/ZXfzQxeTIck1uSkXKlgFg4 6A+HAwkdRqJgOw2lM7n73/767336wV8J+tP1uuuT4hFfmnWVdKJz99ihkYG9YSkDq2EaAuMGZAHR F2nr6tg51jc3X7YcfrA/DPPz6mvT3b1dPf3di0uLY+M9F87Po0qwc2fs+DMnd/YPd3WEvvPM092D e1KRQD2/MdyXGRwIJ9Pycpn8+de+lYy29KYzg11DbV2IyEZ1Nygwgu42HK56afZVuNd37L1jNb/A 8mpXZ9up0ye7e3dwXAs8z3OTr+Yb5Y1luyXc058aaU13ZVLdiUAbqqa0C4uVvUCK1iuo4Hjda7SX 0ctUuFCc87NnfvjcU4ofAYFVLOckqHssydnK0nRpY97sS+//5E/92pd+/2v7xu7giD8gRKL+JJxP U+PigczuHQeziX6JhOFDcw7Scj6JZgdoqiQikLBAMonYzJWLuGk0gpyeE/AL998eFXgXFYXhwZ7V pVnYu1hYufD6RHuU7Bzq2Vid2T2e/PjH9ysijQ7Xa6Su4q5JXYNqgNEDDGnd0Plnnj6Tr8D8xVB9 FyQezeA8YYJRefraBYEwiViqkFNlkh7vvScdG12e0Xoye9KxPuTnFRINCS2AhkN3hguRQcRpIZiC UwD3Fq4XAg0W//H7ZfQ1+Hjpqe89VqisgX1QIajC20fnRKFWWK/Hg9kH3v+Jf/mpzz34oc8gy0wb ZTSUG2gZza8ICganLTS0BAEPGi4Czdp5ySUos4iqEu2UIX0dmVo5ZyLa5kh/T2b26iW6PXZj7tr0 6EiH3iiXNshtu0ZLxTU4xQ997P6ju/tRUkSKYWpefflM7sv/41uX3pgNBVLgr3ydlC3ajMA64dOn 5+YXdK+Yp8SSqUK5lCcb4+PDuq5uVHN9fUMXz80gEkYUev+RT37sg/9i7+gdbZFeXUMji0IcAckY 2puKeiRoHVNHAwmNFgGNgZ4GmhsDVDDnCxsLp069DAligJijt6Za0HNU2CgN9o785r/+95/75S+M 9x8iSPsjoydYMJOOUysV8ihHEldHggw+NM8hf6g21PVqea2hVoEQGvTgc6JBJ+ong70p16gtzSHC g7B0Vcs5CNaukYHpqQtBH4kExNWlxc7O1mMfvg8hUZIjaQ/WvGb8+Xe+8eiTf/fpn33wI3d3DXQM vH7uytlF8yvfOnHpas2qYPwWx5Fgs1wippMZEOXCwkIUAhqJrK2tp5OdjqUUVq3iBtCMx+RuhY1B XlD2QHcD+jR8aKzDPOhW0xIEoRE1XCYUNNGdZ7LITeSr6yjh/uiF48vLq+B+BO9owZq6sNEW7/+V X/jc7/72fzkwdif6SKplHTEGz0uNBkpyFUmWIvFwKBQwdIQAtEUL8gPXwKf4g5GQzw81ppVg2lpi 6Li1jG0w6/XKOjJG6Dwo5RbhUu8dHVifm8YzR4f3DPdmYuPdQjpGIjIJ8kSvoI+Caj0nigePHE0k aJDhD4YFXzDdLZw4Pfniaxf8ISKHIihb00Yu4sZIeySQmp6anVy6VC7XVxbXA2Lk3ns/0JYJxKLE 0CCIQdOg1hoeo6ki/QsfQfJqMzRipOVSXadladoihRACNReSF4PG8VeeeuYHT9dqDk9aGC1Vz0V+ 4n2/+Nlf/INPfeS3Yjzg50RGjIRoww5tdlVCsi+MlBpttSOwegGGRciPX33IyDkuSpc04UYLsaKA eBUl0XJZDfrJjqGeS+dOAan+rNLiFy+/fj7Ms5/66AOkXLx7T++urA+V3Rb0Jal1TB9mFBKRDvqj vsTc7LIviPWTvt3MNFzfFfLbD//yMydOv3rZ1kVYRLpAH4G9Dx0c/wDv+CZeO9vXPVytgE+FiBKq 1PMoYaC9EK09SEmj1gjqRczESSLKKsgRomRDnT4U79HHi1yMg3wOaqki9xuPfEYk/Fe+9pWzk+cU KWQZrMxHfvZn/vlDD36mr3tEYHygbDC57LVn0iasZtuslyfZ9mpm1bDZXkaveYJXOUMLE48aqIwM LpmZXbh2bXp81/6wn2yslXtQ6O0IpuKxtpgCL47SU2kdrRfoIqMlXlQRbSBMZhfKy6t5ImdfeWM1 ngiXK46m2SMjIctJnL98wdArY2N9kQDdfdRsgqwv3hIcHhpsT3fOzC2xgoIsjyz6eUa29GaPwfU0 6Pbpv3k59DfaKY047drK7JXL10zDPT95Odve9fnP//YnP/lQKp5GYZ8GLRyHcrjXTW+jMtNMs777 A01r+KcJZ2dHO9StWq4CwnvuuqO7E9xCfCL9CYQOAUB+lnZOcZA+igssBi7szLZXysUzp06uLMwa DdLRnro8+QbI6+4jXbnlObAacu8YEODS0h2s21rl0sWZyQtTPKf4fVF0yaHblBoAWITmPN71gRRY 4PRr544fP5HPlX7j33z2i7/3+4dvuyPABxs6WkAhmWinhw4yyDkhTUzrf7cyOg2kkLd3bcQ8uG6g t/fQgX0hv4JJpmJMxEezopBNKp6omTMu0pPeEwAcEkg438sfAdM0upcSsfCDH7ujq52kYyHYQrBn e4zcc/uhYnGlobqoXgMXhQsIxE9scWWpdOnCXGd2qLtlEO4o2g8BHVTlXcOyeSKLAP/xbz91eP/t n/31f/e53/r33W29mLFmGT4pgHZDrwOcoU2PaMWipu7m0s+7uBuSK+iuMTUVU4tHpLtvP5yK0lGg o17/K3IwtDEgoEBe0MNlUPTpv1QHcAn+SkZJLKj4BSYbx9JJS1BijMr8VBWCPb6jC1W1SIjBwr1e N/gS0tDg7oP77n7fnQ/sHDiI3aH5wOZoiOG3SnrvYubUG1xe2GiJpv/kf339l3/+1xyTzRWQhZTg E9FCFnLoBjJiJnoHFJ+PQkN7JG7hgB1AeAwm9/vQWYSeZTuAfoQmLdl0PXh5Xg8eVKJF92ZrBPaC eqs0W0PRwVS6s21Ls1dUxLIQpQwfC0rV/BIuNOpFnjGCMnWL8BNafuCOKUykMzmUTQwiJEYeGbGl wFBg0DXm3ewWEGIl3v87D38xk+hcWVv3C6F0LFNv1EHXm/Jyc2sUisW3gM3WqY7jR1KNNuIbSChS O40mIKSzMFMLthO9FjDHaCtwBVTNaO8HRQeJW0gEtgMnDPZ0VAtrSBMAhZhE7n/f0Z3DfVixyJiN KlKsukqzxkTkFdptSlDrUgyL1RESEEVkkPxgUeOnvW/v9MTpO6yKzaSz0WACch6PJJrPvaGqiwwq av4SWpQkH1zgWrUKzwWzhwTdKjq8JKn1Gi3rum7ArzTFhDYHwPNykSjW8FHwGEEHRtSgsGjYpd5d s6zmKWBbKlourEno5kFNiJB9OzszcR5Nf6ytHti7swXuEwgZ6KAFkwfNIQkLd8OnsCGQDlBXddWP RmkJOQ70zdyC7DAGbdm7ici958CuNz9tfzKn+SV90uzdHptPPl5//gwue/MxzuZ7szH8+jne1zCN 3jm0Bc976oQGap4dOHHiVEdHRyaTEijO3qPriIbQ1eXNBdqHzDMPKJtzxKAweZsNxNgPh6MNrt5P 6IS/ubH071kMQ9vwPSKg7ttbsKBPdW4dzQeY3/XQ21a+if/WU4ceDDeehb5+F+9rLJPiQuFrAtQ8 0K/rh/H3DlQvcTEOC13T3k5SdFA+2HpY+zo6FFlkzik6Ds0Q3yI6tC5M9dHbL/r0xZaH5328+ZmT pi/1jzg2vQCgsPmiC7/+940N2HIWKCXTe2+bT8CHeJauDq3y0CNkwCE7zZ7sphPTXEVTPKhreENC mo+eehJ1i/6IJ+HNBx3epGD/CBDecok38Ntg6t3xbfR/+yOtWwB57X80BoJPZOoqLU3Qh75oVrz5 yNkND2y77HuTaS7NU+br03ib/5fBOy71/wJiiAD5npnXkAAAAABJRU5ErkJggg== --_004_E57BD7A928881D48B732EFA5435DDAED02CCB687BD85HAIMAIL1hai_-- From william.d.ivancic@nasa.gov Thu Sep 6 05:41:03 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A686E21F8528 for ; Thu, 6 Sep 2012 05:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeBWcdH4vmiX for ; Thu, 6 Sep 2012 05:41:03 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1F90921F852E for ; Thu, 6 Sep 2012 05:41:03 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 57DF1108517; Thu, 6 Sep 2012 07:41:02 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q86Cf1mq022170; Thu, 6 Sep 2012 07:41:01 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Thu, 6 Sep 2012 07:41:01 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Michele Rodolfi Date: Thu, 6 Sep 2012 07:41:10 -0500 Thread-Topic: [dtn-users] On measuring the DTN2 performance Thread-Index: Ac2MLN9nKIrkrHvwTw+Sj85Vx1fUEg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-06_02:2012-09-06, 2012-09-06, 1970-01-01 signatures=0 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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: Thu, 06 Sep 2012 12:41:03 -0000 DTN perf and DTNtraceroute are interesting concepts. Do you have a writeup= on the operations concepts. IMHO, performance needs consider this is a di= sconnected network. Return path may be totally different than forward path= . It probably would be good to be able to have sender-to-receiver option w= ithout an ACK similar to the original ttcp and an option in nuttcp. If you= have a back channel (like in an experimental testbed), you can get one-way= performance. Basically, think about how the operation would work if none = of the these as continuous connectivity and every bundle has to be stored, = carried and forwarded over a multi-hop system and the forwarding agents are= changing in the topology. That is much different than a string-of-pearls = fully connected set of forwarding agents. - Will From razvan@nict.go.jp Thu Sep 6 17:00:54 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD1D21E8041 for ; Thu, 6 Sep 2012 17:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKlghepiKJN5 for ; Thu, 6 Sep 2012 17:00:53 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D84521E803A for ; Thu, 6 Sep 2012 17:00:53 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q8700nFL004615; Fri, 7 Sep 2012 09:00:49 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q8700mdb025091; Fri, 7 Sep 2012 09:00:48 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q8700m8T025088; Fri, 7 Sep 2012 09:00:48 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 0A56615F44; Fri, 7 Sep 2012 09:00:48 +0900 (JST) Received: from ssh (ssh.nict.go.jp [133.243.3.49]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 0498D15EC4; Fri, 7 Sep 2012 09:00:48 +0900 (JST) Date: Fri, 7 Sep 2012 09:00:47 +0900 (JST) From: Razvan BEURAN To: "Ivancic, William D. (GRC-RHN0)" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 00:00:54 -0000 Hi all, I think there can be a very long discussion as to what exactly is "performance" in DTNs, but I also believe that a tool such as dtnperf can be used for very useful purposes. For instance, one may imagine using the same network (with the same disconnections and mobility patterns -- which can readily be obtained through emulation) to compare how several routing protocols affect end-to-end performance. I believe that such kind of end-to-end performance is actually what matters for the users. As a side note, last time I used dtnperf (in dtn-2.8) I was very surprised to discover that for the UDP convergence layer the test would stall indefinitely as soon as there was loss in the network. The reason seems to be that, as opposed to TCP, UDP doesn't recover from loss, and dtnperf keeps waiting forever for some kind of bundle receipt. I hope the new version mentioned by Michele takes this into account, because it is clearly unexpected for a tool which is supposed to evaluate DNT. Note that for the TCP convergence layer dtnperf behaves as expected over lossy links, but this is probably due to TCP' behaviour. By all means though, this mailing list should be the perfect place to discuss about how to evaluate DTN performance, and I am very willing to contribute to this discussion. I know for instance that IBR-DTN doesn't include anything similar to dtnperf, which shows that its developers don't see much value in dtnperf either. Best wishes, Razvan On Thu, 6 Sep 2012, Ivancic, William D. (GRC-RHN0) wrote: > DTN perf and DTNtraceroute are interesting concepts. Do you have a writeup on the operations concepts. IMHO, performance needs consider this is a disconnected network. Return path may be totally different than forward path. It probably would be good to be able to have sender-to-receiver option without an ACK similar to the original ttcp and an option in nuttcp. If you have a back channel (like in an experimental testbed), you can get one-way performance. Basically, think about how the operation would work if none of the these as continuous connectivity and every bundle has to be stored, carried and forwarded over a multi-hop system and the forwarding agents are changing in the topology. That is much different than a string-of-pearls fully connected set of forwarding agents. > > - Will > > > > > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users > From TSELIKIS.Christos@haicorp.com Fri Sep 7 02:48:57 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD9C21F8731 for ; Fri, 7 Sep 2012 02:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=1.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f-CVr8lx+P4 for ; Fri, 7 Sep 2012 02:48:56 -0700 (PDT) Received: from HAIRDGESRV2.haicorp.com (hairdgesrv2.haicorp.com [212.205.103.5]) by ietfa.amsl.com (Postfix) with ESMTP id 337D921F84A1 for ; Fri, 7 Sep 2012 02:48:55 -0700 (PDT) Received: from haimail3.hai.gr (10.0.200.60) by HAIRDGESRV2.haicorp.com (192.168.2.4) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 7 Sep 2012 12:52:04 +0300 Received: from HAIMAIL1.hai.gr ([10.0.200.56]) by haimail3.hai.gr ([10.0.200.60]) with mapi; Fri, 7 Sep 2012 12:48:37 +0300 From: TSELIKIS.Christos To: 'Razvan BEURAN' , "Ivancic, William D. (GRC-RHN0)" Date: Fri, 7 Sep 2012 12:48:36 +0300 Thread-Topic: [dtn-users] On measuring the DTN2 performance Thread-Index: Ac2Mi9XJGcwe3Va8S8WdB3L1FsN2OQAS2m1Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 09:48:57 -0000 Hi all, I fully agree with Razvan, "what exactly is=20 performance in DTNs", perhaps some other metrics (except from throughput an= d delay) might provide more accurate descriptions (one way metrics such as = delivery rate, loss, etc, which have already been studied as well). On some= tests with dtn-perf2/TCP I also recall the dtn_perf application was able t= o resume after reasonable link disruptions (for the sake of accuracy just t= o mention that "ACKs" in dtn-perf2 are actually bundle delivery reports, if= requested). Now for sure DTN performance has to be analyzed under adaptive routing cond= itions and it would be valuable to measure performance with two-way e2e met= rics, since DTN/BP offers many interactive options. =20 With very kind regards, ctselikis Tselikis Christos=20 Hellenic Aerospace Industry S.A. Electronics Engineering Department=A0=20 e-mail: Tselikis.Christos@haicorp.com=20 PO Box 23, GR-32009 Schimatari, Greece Tel. : +30 22620 52561 Fax: +30 22620 52910 -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of Razvan BEURAN Sent: Friday, September 07, 2012 3:01 AM To: Ivancic, William D. (GRC-RHN0) Cc: dtn-users@irtf.org Subject: Re: [dtn-users] On measuring the DTN2 performance Hi all, I think there can be a very long discussion as to what exactly is=20 "performance" in DTNs, but I also believe that a tool such as dtnperf can=20 be used for very useful purposes. For instance, one may imagine using the=20 same network (with the same disconnections and mobility patterns -- which=20 can readily be obtained through emulation) to compare how several routing=20 protocols affect end-to-end performance. I believe that such kind of=20 end-to-end performance is actually what matters for the users. As a side note, last time I used dtnperf (in dtn-2.8) I was very surprised= =20 to discover that for the UDP convergence layer the test would stall=20 indefinitely as soon as there was loss in the network. The reason seems=20 to be that, as opposed to TCP, UDP doesn't recover from loss, and dtnperf=20 keeps waiting forever for some kind of bundle receipt. I hope the new=20 version mentioned by Michele takes this into account, because it is=20 clearly unexpected for a tool which is supposed to evaluate DNT. Note that= =20 for the TCP convergence layer dtnperf behaves as expected over lossy=20 links, but this is probably due to TCP' behaviour. By all means though, this mailing list should be the perfect place to=20 discuss about how to evaluate DTN performance, and I am very willing to=20 contribute to this discussion. I know for instance that IBR-DTN doesn't=20 include anything similar to dtnperf, which shows that its developers=20 don't see much value in dtnperf either. Best wishes, Razvan On Thu, 6 Sep 2012, Ivancic, William D. (GRC-RHN0) wrote: > DTN perf and DTNtraceroute are interesting concepts. Do you have a write= up on the operations concepts. IMHO, performance needs consider this is a = disconnected network. Return path may be totally different than forward pa= th. It probably would be good to be able to have sender-to-receiver option= without an ACK similar to the original ttcp and an option in nuttcp. If y= ou have a back channel (like in an experimental testbed), you can get one-w= ay performance. Basically, think about how the operation would work if non= e of the these as continuous connectivity and every bundle has to be stored= , carried and forwarded over a multi-hop system and the forwarding agents a= re changing in the topology. That is much different than a string-of-pearl= s fully connected set of forwarding agents. > > - Will > > > > > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users > _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users From ccaini@arces.unibo.it Fri Sep 7 05:10:23 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B219321F87BE for ; Fri, 7 Sep 2012 05:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GafpfFP4WFB for ; Fri, 7 Sep 2012 05:10:23 -0700 (PDT) Received: from mail.arces.unibo.it (mail.arces.unibo.it [137.204.143.6]) by ietfa.amsl.com (Postfix) with ESMTP id D449221F872A for ; Fri, 7 Sep 2012 05:10:22 -0700 (PDT) Received: from webmail.arces.unibo.it (web.arces.unibo.it [137.204.143.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.arces.unibo.it (Postfix) with ESMTP id 9F8034018E73; Fri, 7 Sep 2012 14:10:14 +0200 (CEST) MIME-Version: 1.0 Date: Fri, 07 Sep 2012 14:10:14 +0200 From: ccaini To: Razvan BEURAN In-Reply-To: References: Message-ID: <19696fc15d952cbbc0e406c5395b88fc@arces.unibo.it> X-Sender: ccaini@arces.unibo.it User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-Arces-MailScanner-Information: Please contact the ISP for more information X-Arces-MailScanner-ID: 9F8034018E73.73509 X-Arces-MailScanner: Found to be clean X-Arces-MailScanner-From: ccaini@arces.unibo.it Cc: dtn-users@irtf.org Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 12:10:23 -0000 Dear all, as telecommunication professor at the University of Bologna I am the supervisor of the development of the DTNperf tool. I would like to thank Razvan, William and other people for their comments and suggestions on DTNperf. Let me just summarized the development of DTNperf: DTNperf 1.x (by Piero Cornice) was conceived as a tool to evaluate perfromance on DTN continously connected networks, but with long delays, like GEO satellites, and it design takes after the IPerf tool. It was "stop and wait": a bundle was sent and then we had to waith for the reception at sender site of the delivered status reports before sending another bundle. DTNperf 2.x (Piero Cornice and Marco Livini) aim was twofold On Fri, 7 Sep 2012 09:00:47 +0900 (JST), Razvan BEURAN wrote: > Hi all, > > I think there can be a very long discussion as to what exactly is > "performance" in DTNs, but I also believe that a tool such as dtnperf can > be used for very useful purposes. For instance, one may imagine using the > same network (with the same disconnections and mobility patterns -- which > can readily be obtained through emulation) to compare how several routing > protocols affect end-to-end performance. I believe that such kind of > end-to-end performance is actually what matters for the users. > > As a side note, last time I used dtnperf (in dtn-2.8) I was very surprised > to discover that for the UDP convergence layer the test would stall > indefinitely as soon as there was loss in the network. The reason seems > to be that, as opposed to TCP, UDP doesn't recover from loss, and dtnperf > keeps waiting forever for some kind of bundle receipt. I hope the new > version mentioned by Michele takes this into account, because it is > clearly unexpected for a tool which is supposed to evaluate DNT. Note that > for the TCP convergence layer dtnperf behaves as expected over lossy > links, but this is probably due to TCP' behaviour. > > By all means though, this mailing list should be the perfect place to > discuss about how to evaluate DTN performance, and I am very willing to > contribute to this discussion. I know for instance that IBR-DTN doesn't > include anything similar to dtnperf, which shows that its developers > don't see much value in dtnperf either. > > Best wishes, > Razvan > > > On Thu, 6 Sep 2012, Ivancic, William D. (GRC-RHN0) wrote: > >> DTN perf and DTNtraceroute are interesting concepts. Do you have a >> writeup on the operations concepts. IMHO, performance needs consider >> this is a disconnected network. Return path may be totally different >> than forward path. It probably would be good to be able to have >> sender-to-receiver option without an ACK similar to the original ttcp and >> an option in nuttcp. If you have a back channel (like in an experimental >> testbed), you can get one-way performance. Basically, think about how >> the operation would work if none of the these as continuous connectivity >> and every bundle has to be stored, carried and forwarded over a multi-hop >> system and the forwarding agents are changing in the topology. That is >> much different than a string-of-pearls fully connected set of forwarding >> agents. >> >> - Will >> >> >> >> >> _______________________________________________ >> dtn-users mailing list >> dtn-users@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-users >> > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users From ccaini@arces.unibo.it Fri Sep 7 05:46:31 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC70121F8715 for ; Fri, 7 Sep 2012 05:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd3kTmOCEj+V for ; Fri, 7 Sep 2012 05:46:31 -0700 (PDT) Received: from mail.arces.unibo.it (mail.arces.unibo.it [137.204.143.6]) by ietfa.amsl.com (Postfix) with ESMTP id EC6D721F8758 for ; Fri, 7 Sep 2012 05:46:30 -0700 (PDT) Received: from webmail.arces.unibo.it (web.arces.unibo.it [137.204.143.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.arces.unibo.it (Postfix) with ESMTP id 9D0CA41C69CB; Fri, 7 Sep 2012 14:46:22 +0200 (CEST) MIME-Version: 1.0 Date: Fri, 07 Sep 2012 14:46:22 +0200 From: ccaini To: Razvan BEURAN In-Reply-To: References: Message-ID: <1ea07ac88e57144327a0486866a7c9ce@arces.unibo.it> X-Sender: ccaini@arces.unibo.it User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-Arces-MailScanner-Information: Please contact the ISP for more information X-Arces-MailScanner-ID: 9D0CA41C69CB.F1F85 X-Arces-MailScanner: Found to be clean X-Arces-MailScanner-From: ccaini@arces.unibo.it Cc: dtn-users@irtf.org Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 12:46:32 -0000 This time the text should be complete. Sorry for the previous e-mail. Carlo Caini Dear all, as telecommunication professor at the University of Bologna I am the supervisor of the development of the DTNperf tool. I would like to thank Razvan, William and other people for their comments and suggestions on DTNperf. Let me just summarized the development of DTNperf: DTNperf 1.x (by Piero Cornice) was conceived as a tool to evaluate perfromance on DTN continously connected networks, but with long delays, like GEO satellites, and it design takes after the IPerf tool. It was "stop and wait": a bundle was sent and then we had to waith for the reception at sender site of the delivered status reports before sending another bundle. DTNperf 2.x (Piero Cornice and Marco Livini) aim is twofold: to evaluate goodput at application layer, as before, and to collect status reports log. This latter feature is very important in the presence of disruption and/or network partitioning. For exemple, in a data mule experiment it is more important to know if and when bundle have been delivered, if there was fragmentation, and so on, than to know the actual goodput. Other features of 2.x: it is possible to send "w" bundles in parallel, which is important to fill the pipe in the presence of multiple hops, or to exploit two parallel TCP connections both active on the same hop (e.g. in DTN2 with ALWAYSON from node A to B and viceversa). Another freature is the possibility of sending a file, which can be segmented into multiple bundles of the wanted dimension, which is useful in DTN networks that do not support fragmentation. DTNperf 3.x (by Michele Rodolfi, supervised by me and by Piero Cornice) want to be a significant step forward. The most important novelties are: 1) new monitor mode; status reports can be sent to and logged by a third node, acting as monitor. In a testbed DTN nodes can be connected to this monitor node by means of links not affected by any impairment and used only for management, not to send data. This is aligned with what suggested by William Ivancic. 2) new additional "rate based" bundle transmission. Bundle can be sent at a certain rate, independently from the reception of any ACKs, like UDP packets. This feature should well match the comment by Razvan Beuran, who, like me, seems not to happy to see, in case of no feedback, the dtnperf 2.x sender "frozen", waiting for a status delivered report that maybe will never arrive. 3) Both DTN2 and ION support. DTNperf 3.x has been conceived to support both DTN2 and ION. It should be a unique application, able to recognize at run time if on a given node either DTN2 or ION BP implementation is active, and to call the appropriate DTN2 or ION APIs accordingly. My and my students commitment is to provide with DTNperf 3.x the DTN community with a useful evaluation/log tool, independent from the BP implementation, and of course interoperable. A preliminary version of DTNperf 3.x is going to be released in the next weeks, unfortunately without the ION support yet. This will be added immediately after, as it is the thesis work of another student, Anna D'Amico, who is going to start in October. I thank you all for your past and future comments and suggestions. Yours, Carlo Caini On Fri, 7 Sep 2012 09:00:47 +0900 (JST), Razvan BEURAN wrote: > Hi all, > > I think there can be a very long discussion as to what exactly is > "performance" in DTNs, but I also believe that a tool such as dtnperf can > be used for very useful purposes. For instance, one may imagine using the > same network (with the same disconnections and mobility patterns -- which > can readily be obtained through emulation) to compare how several routing > protocols affect end-to-end performance. I believe that such kind of > end-to-end performance is actually what matters for the users. > > As a side note, last time I used dtnperf (in dtn-2.8) I was very surprised > to discover that for the UDP convergence layer the test would stall > indefinitely as soon as there was loss in the network. The reason seems > to be that, as opposed to TCP, UDP doesn't recover from loss, and dtnperf > keeps waiting forever for some kind of bundle receipt. I hope the new > version mentioned by Michele takes this into account, because it is > clearly unexpected for a tool which is supposed to evaluate DNT. Note that > for the TCP convergence layer dtnperf behaves as expected over lossy > links, but this is probably due to TCP' behaviour. > > By all means though, this mailing list should be the perfect place to > discuss about how to evaluate DTN performance, and I am very willing to > contribute to this discussion. I know for instance that IBR-DTN doesn't > include anything similar to dtnperf, which shows that its developers > don't see much value in dtnperf either. > > Best wishes, > Razvan > > > On Thu, 6 Sep 2012, Ivancic, William D. (GRC-RHN0) wrote: > >> DTN perf and DTNtraceroute are interesting concepts. Do you have a >> writeup on the operations concepts. IMHO, performance needs consider >> this is a disconnected network. Return path may be totally different >> than forward path. It probably would be good to be able to have >> sender-to-receiver option without an ACK similar to the original ttcp and >> an option in nuttcp. If you have a back channel (like in an experimental >> testbed), you can get one-way performance. Basically, think about how >> the operation would work if none of the these as continuous connectivity >> and every bundle has to be stored, carried and forwarded over a multi-hop >> system and the forwarding agents are changing in the topology. That is >> much different than a string-of-pearls fully connected set of forwarding >> agents. >> >> - Will >> >> >> >> >> _______________________________________________ >> dtn-users mailing list >> dtn-users@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-users >> > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users From william.d.ivancic@nasa.gov Fri Sep 7 06:01:21 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4634021F8715 for ; Fri, 7 Sep 2012 06:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8ch8Ary-6YA for ; Fri, 7 Sep 2012 06:01:20 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4BE21F87C5 for ; Fri, 7 Sep 2012 06:01:20 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 6B1672D83F7; Fri, 7 Sep 2012 08:01:15 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q87D1F6H017494; Fri, 7 Sep 2012 08:01:15 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Fri, 7 Sep 2012 08:01:15 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "TSELIKIS.Christos" Date: Fri, 7 Sep 2012 08:01:13 -0500 Thread-Topic: [dtn-users] On measuring the DTN2 performance Thread-Index: Ac2M+NybBc/XdsVUStqOqAcz1fYmgA== Message-ID: <3A3A4FA8-0A97-43F9-800C-5BF2D894ADC5@nasa.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-07_03:2012-09-06, 2012-09-07, 1970-01-01 signatures=0 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 13:01:21 -0000 On Sep 7, 2012, at 5:48 AM, TSELIKIS.Christos wrote: > Hi all, > I fully agree with Razvan, "what exactly is=20 > performance in DTNs", perhaps some other metrics (except from throughput = and delay) might provide more accurate descriptions (one way metrics such a= s delivery rate, loss, etc, which have already been studied as well). For RFC5050 DTNs where there is a bundle lifetime, than delay should be ins= ignificant. The metric is successful delivery of a bundle. Think of it li= ke this: I send you a birthday gift. Your birthday is one month away. The= gift says do not open until your birthday. Whether or not you receive tha= t bundle tomorrow or in a month is meaningless. So long as get it before y= our birthday. Since you put a lifetime on the bundle, you are now allowing= the network to decide when to deliver. IMHO, the successful delivery, ove= rall bandwidth utilization, overall storage utilization and overall proces= sing utilization are the metrics. How much total network resources are you= using to successfully deliver that bundle? You may flood to improve chanc= es of delivering a bundle, but that will use a lot of resources. =20 Meaningful metrics are extremely deployment specific. Is my network heavil= y used in which case flooding may congest and be worse? Are my nodes power= constrained in which case excessive transmissions my drain my batteries? = Being able to measure is most important. What is good or bad may be differ= ent for different deployments.= From razvan@nict.go.jp Tue Sep 11 01:23:35 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3485A21F87AD for ; Tue, 11 Sep 2012 01:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8x-HgVXDtzEz for ; Tue, 11 Sep 2012 01:23:34 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 65FA921F87AB for ; Tue, 11 Sep 2012 01:23:34 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q8B8NWS2029213; Tue, 11 Sep 2012 17:23:32 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q8B8NVvG004154; Tue, 11 Sep 2012 17:23:32 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q8B8NVTM004151; Tue, 11 Sep 2012 17:23:31 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id C67D72C27A; Tue, 11 Sep 2012 17:23:31 +0900 (JST) Received: from ssh (ssh.nict.go.jp [133.243.3.49]) by mail2.nict.go.jp (NICT Mail) with ESMTP id C261E2C271; Tue, 11 Sep 2012 17:23:31 +0900 (JST) Date: Tue, 11 Sep 2012 17:23:31 +0900 (JST) From: Razvan BEURAN To: "Ivancic, William D. (GRC-RHN0)" In-Reply-To: <3A3A4FA8-0A97-43F9-800C-5BF2D894ADC5@nasa.gov> Message-ID: References: <3A3A4FA8-0A97-43F9-800C-5BF2D894ADC5@nasa.gov> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:23:35 -0000 Dear William, I found your brief analysis very useful, and I totally agree with the fact that meaningful metric are deployment/application specific. Are you by any chance aware of any thorough study that looks at the appropriate metrics for different classes of DTNs? A quick search didn't provide any useful results, and I believe that such a theoretical effort would be a great starting point for a discussion on DTN performance. If no such study exists it would be great to make one :-) Best wishes, Razvan On Fri, 7 Sep 2012, Ivancic, William D. (GRC-RHN0) wrote: > > On Sep 7, 2012, at 5:48 AM, TSELIKIS.Christos wrote: > >> Hi all, >> I fully agree with Razvan, "what exactly is >> performance in DTNs", perhaps some other metrics (except from throughput and delay) might provide more accurate descriptions (one way metrics such as delivery rate, loss, etc, which have already been studied as well). > > For RFC5050 DTNs where there is a bundle lifetime, than delay should be insignificant. The metric is successful delivery of a bundle. Think of it like this: I send you a birthday gift. Your birthday is one month away. The gift says do not open until your birthday. Whether or not you receive that bundle tomorrow or in a month is meaningless. So long as get it before your birthday. Since you put a lifetime on the bundle, you are now allowing the network to decide when to deliver. IMHO, the successful delivery, overall bandwidth utilization, overall storage utilization and overall processing utilization are the metrics. How much total network resources are you using to successfully deliver that bundle? You may flood to improve chances of delivering a bundle, but that will use a lot of resources. > > Meaningful metrics are extremely deployment specific. Is my network heavily used in which case flooding may congest and be worse? Are my nodes power constrained in which case excessive transmissions my drain my batteries? Being able to measure is most important. What is good or bad may be different for different deployments. From l.wood@surrey.ac.uk Tue Sep 11 03:11:57 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3035121F8770 for ; Tue, 11 Sep 2012 03:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOK5np6kYI+N for ; Tue, 11 Sep 2012 03:11:53 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id BA19421F8769 for ; Tue, 11 Sep 2012 03:11:52 -0700 (PDT) Received: from [195.245.230.131:32108] by server-6.bemta-3.messagelabs.com id 38/4B-29694-66E0F405; Tue, 11 Sep 2012 10:11:50 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-3.tower-78.messagelabs.com!1347358310!27198079!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 887 invoked from network); 11 Sep 2012 10:11:50 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-3.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 11 Sep 2012 10:11:50 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.82]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Tue, 11 Sep 2012 11:11:49 +0100 From: To: , Date: Tue, 11 Sep 2012 11:09:17 +0100 Thread-Topic: [dtn-users] On measuring the DTN2 performance Thread-Index: Ac2P9sAdBQmXvVgkQViVUU7WSUB8mQADsDjJ Message-ID: References: <3A3A4FA8-0A97-43F9-800C-5BF2D894ADC5@nasa.gov>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dtn-users@irtf.org Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 10:11:57 -0000 Razvan, for thoughts on DTN metrics, look into Ioannis Psaras's work: his six years= since dtn paper and accompanying tech report. http://www.ee.ucl.ac.uk/~uceeips/UCL_site/About...html Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: dtn-users-bounces@irtf.org [dtn-users-bounces@irtf.org] On Behalf Of = Razvan BEURAN [razvan@nict.go.jp] Sent: 11 September 2012 09:23 To: Ivancic, William D. (GRC-RHN0) Cc: dtn-users@irtf.org Subject: Re: [dtn-users] On measuring the DTN2 performance Dear William, I found your brief analysis very useful, and I totally agree with the fact that meaningful metric are deployment/application specific. Are you by any chance aware of any thorough study that looks at the appropriate metrics for different classes of DTNs? A quick search didn't provide any useful results, and I believe that such a theoretical effort would be a great starting point for a discussion on DTN performance. If no such study exists it would be great to make one :-) Best wishes, Razvan On Fri, 7 Sep 2012, Ivancic, William D. (GRC-RHN0) wrote: > > On Sep 7, 2012, at 5:48 AM, TSELIKIS.Christos wrote: > >> Hi all, >> I fully agree with Razvan, "what exactly is >> performance in DTNs", perhaps some other metrics (except from throughput= and delay) might provide more accurate descriptions (one way metrics such = as delivery rate, loss, etc, which have already been studied as well). > > For RFC5050 DTNs where there is a bundle lifetime, than delay should be i= nsignificant. The metric is successful delivery of a bundle. Think of it = like this: I send you a birthday gift. Your birthday is one month away. T= he gift says do not open until your birthday. Whether or not you receive t= hat bundle tomorrow or in a month is meaningless. So long as get it before= your birthday. Since you put a lifetime on the bundle, you are now allowi= ng the network to decide when to deliver. IMHO, the successful delivery, o= verall bandwidth utilization, overall storage utilization and overall proc= essing utilization are the metrics. How much total network resources are y= ou using to successfully deliver that bundle? You may flood to improve cha= nces of delivering a bundle, but that will use a lot of resources. > > Meaningful metrics are extremely deployment specific. Is my network heav= ily used in which case flooding may congest and be worse? Are my nodes pow= er constrained in which case excessive transmissions my drain my batteries?= Being able to measure is most important. What is good or bad may be diff= erent for different deployments. _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users From william.d.ivancic@nasa.gov Tue Sep 11 05:20:26 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C610D21F87E2 for ; Tue, 11 Sep 2012 05:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23Bc0LpeBznp for ; Tue, 11 Sep 2012 05:20:22 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBBF21F87DF for ; Tue, 11 Sep 2012 05:20:21 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id D735D260457; Tue, 11 Sep 2012 07:20:20 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q8BCKH8v004419; Tue, 11 Sep 2012 07:20:20 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Tue, 11 Sep 2012 07:20:19 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "" Date: Tue, 11 Sep 2012 07:20:22 -0500 Thread-Topic: [dtn-users] On measuring the DTN2 performance Thread-Index: Ac2QF87zjAxWLEF6TqynEgtw8BtTSA== Message-ID: <0428DA57-E408-4448-8209-B5989C0C9532@nasa.gov> References: <3A3A4FA8-0A97-43F9-800C-5BF2D894ADC5@nasa.gov>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0428DA57E40844488209B5989C0C9532nasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-11_03:2012-09-06, 2012-09-11, 1970-01-01 signatures=0 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 12:20:26 -0000 --_000_0428DA57E40844488209B5989C0C9532nasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lloyd, This "Six Years" paper is right on target. Razvan, I know of know studies in this area. I've seen little work done in actuall= y moving any traffic around with DTNs. I've also seen little in the way of= running DTNs over disconnected networks. Most of the work appears to be a= sting-of-pearls space scenario with maybe three or four forwarding agents = and no mix of traffic or multihoming and not much in the way of complex rou= ting. CGR works fine in this scenario. Military applications are probably the most complex scenarios to date and I= have seen little done here. Some simple demonstrations with little traffi= c. My understanding is that the military is JUST starting to "really" eval= uate DTN in real scenarios. I am not use what the traffic mix is. I would say, making your own scenario and use case would be a good start. = Perhaps first responders (but they may have little need for DTN as they are= more of a single hop store and forward scenario). Perhaps one of the gene= ric scenarios presented in this draft may help. But you will need to gener= ate some type of traffic pattern. http://ietfreport.isoc.org/ids/draft-ivancic-scf-problem-statement-00.txt - Will On Sep 11, 2012, at 6:09 AM, > wrote: Razvan, for thoughts on DTN metrics, look into Ioannis Psaras's work: his six years= since dtn paper and accompanying tech report. http://www.ee.ucl.ac.uk/~uceeips/UCL_site/About...html Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: dtn-users-bounces@irtf.org [dtn-users-bounces@irtf.org] On Behalf Of = Razvan BEURAN [razvan@nict.go.jp] Sent: 11 September 2012 09:23 To: Ivancic, William D. (GRC-RHN0) Cc: dtn-users@irtf.org Subject: Re: [dtn-users] On measuring the DTN2 performance Dear William, I found your brief analysis very useful, and I totally agree with the fact that meaningful metric are deployment/application specific. Are you by any chance aware of any thorough study that looks at the appropriate metrics for different classes of DTNs? A quick search didn't provide any useful results, and I believe that such a theoretical effort would be a great starting point for a discussion on DTN performance. If no such study exists it would be great to make one :-) Best wishes, Razvan On Fri, 7 Sep 2012, Ivancic, William D. (GRC-RHN0) wrote: On Sep 7, 2012, at 5:48 AM, TSELIKIS.Christos wrote: Hi all, I fully agree with Razvan, "what exactly is performance in DTNs", perhaps some other metrics (except from throughput an= d delay) might provide more accurate descriptions (one way metrics such as = delivery rate, loss, etc, which have already been studied as well). For RFC5050 DTNs where there is a bundle lifetime, than delay should be ins= ignificant. The metric is successful delivery of a bundle. Think of it li= ke this: I send you a birthday gift. Your birthday is one month away. The= gift says do not open until your birthday. Whether or not you receive tha= t bundle tomorrow or in a month is meaningless. So long as get it before y= our birthday. Since you put a lifetime on the bundle, you are now allowing= the network to decide when to deliver. IMHO, the successful delivery, ove= rall bandwidth utilization, overall storage utilization and overall proces= sing utilization are the metrics. How much total network resources are you= using to successfully deliver that bundle? You may flood to improve chanc= es of delivering a bundle, but that will use a lot of resources. Meaningful metrics are extremely deployment specific. Is my network heavil= y used in which case flooding may congest and be worse? Are my nodes power= constrained in which case excessive transmissions my drain my batteries? = Being able to measure is most important. What is good or bad may be differ= ent for different deployments. _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic --_000_0428DA57E40844488209B5989C0C9532nasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lloyd,
This "Six Years= "  paper is right on  target.

Razvan,

I know of know studies in this area.  I've seen= little work done in actually moving any traffic around with DTNs.  I'= ve also seen little in the way of running DTNs over disconnected networks. =  Most of the work appears to be a sting-of-pearls space scenario with = maybe three or four forwarding agents and no mix of traffic or multihoming = and not much in the way of complex routing. CGR works fine in this scenario= .

Military applications are probably the most comp= lex scenarios to date and I have seen little done here.  Some simple d= emonstrations with little traffic.  My understanding is that the milit= ary is JUST starting to "really" evaluate DTN in real scenarios.  I am= not use what the traffic mix is.

I would say, mak= ing your own scenario and use case would be a good start.  Perhaps fir= st responders (but they may have little need for DTN as they are more of a = single hop store and forward scenario).  Perhaps one of the generic sc= enarios presented in this draft may help.  But you will need to genera= te some type of traffic pattern.  


- Will



=
Razvan,

for thoughts on DTN metrics, = look into Ioannis Psaras's work: his six years since dtn paper and accompan= ying tech report.

http://www.ee.ucl.ac.uk/~uceeips/UCL_site/About...html=

Lloyd Wood
http://sat-net.com/L.Wood/


_______________= _________________________
From: dtn-users-bounces@irtf.org [dtn-users-bo= unces@irtf.org] On Behalf Of Razvan BEURAN [razvan@nict.go.jp]
Sent: 11 = September 2012 09:23
To: Ivancic, William D. (GRC-RHN0)
Cc: dtn-users= @irtf.org
Subject: Re: [dtn-users] On measuring the DTN2 performance
=
Dear William,

I found your brief analysis very useful, and I tot= ally agree with the fact
that meaningful metric are deployment/applicati= on specific. Are you by any
chance aware of any thorough study that look= s at the appropriate metrics
for different classes of DTNs?

A qui= ck search didn't provide any useful results, and I believe that such
a t= heoretical effort would be a great starting point for a discussion on
DT= N performance. If no such study exists it would be great to make one :-)
Best wishes,
Razvan


On Fri, 7 Sep 2012, Ivancic, William= D. (GRC-RHN0) wrote:


On Sep 7, 2012, at 5:48 AM, TSELIKIS.Christos wrote:=

Hi all,
<= blockquote type=3D"cite">
I fully agree with Razva= n, "what exactly is
=
performance in DTNs", perhaps some other metrics = (except from throughput and delay) might provide more accurate descriptions= (one way metrics such as delivery rate, loss, etc, which have already been= studied as well).
<= br>
For RFC5050 DTNs where there is a= bundle lifetime, than delay should be insignificant.  The metric is s= uccessful delivery of a bundle.  Think of it like this:  I send y= ou a birthday gift. Your birthday is one month away.  The gift says do= not open until your birthday.  Whether or not you receive that bundle= tomorrow or in a month is meaningless.  So long as get it before your= birthday.  Since you put a lifetime on the bundle, you are now allowi= ng the network to decide when to deliver.  IMHO, the successful delive= ry, overall bandwidth utilization, overall storage utilization  and ov= erall processing utilization are the metrics.  How much total network = resources are you using to successfully deliver that bundle?  You may = flood to improve chances of delivering a bundle, but that will use a lot of= resources.

Meaningful metrics are extremely deployment specific.=  Is my network heavily used in which case flooding may congest and be= worse?  Are my nodes power constrained in which case excessive transm= issions my drain my batteries?  Being able to measure is most importan= t.  What is good or bad may be different for different deployments._______________________________________________
dtn-users = mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo= /dtn-users

******************************
William D. Ivancic
Phone 2= 16-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~= ivancic

= --_000_0428DA57E40844488209B5989C0C9532nasagov_-- From william.d.ivancic@nasa.gov Tue Sep 11 05:32:48 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36C21F8755 for ; Tue, 11 Sep 2012 05:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlwWjaqATuu1 for ; Tue, 11 Sep 2012 05:32:47 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0A521F8758 for ; Tue, 11 Sep 2012 05:32:47 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 674D0D089A; Tue, 11 Sep 2012 07:32:46 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q8BCWkif013459; Tue, 11 Sep 2012 07:32:46 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Tue, 11 Sep 2012 07:32:46 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "" Date: Tue, 11 Sep 2012 07:32:48 -0500 Thread-Topic: [dtn-users] On measuring the DTN2 performance Thread-Index: Ac2QGYvKxcFmSnnMRy2X0gPpMelCkQ== Message-ID: <3100015A-F8CF-4865-A4E9-B590E2CF59CA@nasa.gov> References: <3A3A4FA8-0A97-43F9-800C-5BF2D894ADC5@nasa.gov>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3100015AF8CF4865A4E9B590E2CF59CAnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-11_03:2012-09-06, 2012-09-11, 1970-01-01 signatures=0 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 12:32:48 -0000 --_000_3100015AF8CF4865A4E9B590E2CF59CAnasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lloyd, This "Six Years" paper is right on target. Razvan, I know of NO studies in this area. I've seen little work done in actually = moving any traffic around with DTNs. I've also seen little in the way of r= unning DTNs over disconnected networks. Most of the work appears to be a s= ting-of-pearls space scenario with maybe three or four forwarding agents an= d no mix of traffic or multihoming and not much in the way of complex routi= ng. CGR works fine in this scenario. Military applications are probably the most complex scenarios to date and I= have seen little done here. Some simple demonstrations with little traffi= c. My understanding is that the military is JUST starting to "really" eval= uate DTN in real scenarios. I am not use what the traffic mix is. I would say, making your own scenario and use case would be a good start. = Perhaps first responders (but they may have little need for DTN as they are= more of a single hop store and forward scenario). Perhaps one of the gene= ric scenarios presented in this draft may help. But you will need to gener= ate some type of traffic pattern. http://ietfreport.isoc.org/ids/draft-ivancic-scf-problem-statement-00.txt - Will On Sep 11, 2012, at 6:09 AM, > wrote: Razvan, for thoughts on DTN metrics, look into Ioannis Psaras's work: his six years= since dtn paper and accompanying tech report. http://www.ee.ucl.ac.uk/~uceeips/UCL_site/About...html Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: dtn-users-bounces@irtf.org [dtn-users-bounces@irtf.org] On Behalf Of = Razvan BEURAN [razvan@nict.go.jp] Sent: 11 September 2012 09:23 To: Ivancic, William D. (GRC-RHN0) Cc: dtn-users@irtf.org Subject: Re: [dtn-users] On measuring the DTN2 performance Dear William, I found your brief analysis very useful, and I totally agree with the fact that meaningful metric are deployment/application specific. Are you by any chance aware of any thorough study that looks at the appropriate metrics for different classes of DTNs? A quick search didn't provide any useful results, and I believe that such a theoretical effort would be a great starting point for a discussion on DTN performance. If no such study exists it would be great to make one :-) Best wishes, Razvan On Fri, 7 Sep 2012, Ivancic, William D. (GRC-RHN0) wrote: On Sep 7, 2012, at 5:48 AM, TSELIKIS.Christos wrote: Hi all, I fully agree with Razvan, "what exactly is performance in DTNs", perhaps some other metrics (except from throughput an= d delay) might provide more accurate descriptions (one way metrics such as = delivery rate, loss, etc, which have already been studied as well). For RFC5050 DTNs where there is a bundle lifetime, than delay should be ins= ignificant. The metric is successful delivery of a bundle. Think of it li= ke this: I send you a birthday gift. Your birthday is one month away. The= gift says do not open until your birthday. Whether or not you receive tha= t bundle tomorrow or in a month is meaningless. So long as get it before y= our birthday. Since you put a lifetime on the bundle, you are now allowing= the network to decide when to deliver. IMHO, the successful delivery, ove= rall bandwidth utilization, overall storage utilization and overall proces= sing utilization are the metrics. How much total network resources are you= using to successfully deliver that bundle? You may flood to improve chanc= es of delivering a bundle, but that will use a lot of resources. Meaningful metrics are extremely deployment specific. Is my network heavil= y used in which case flooding may congest and be worse? Are my nodes power= constrained in which case excessive transmissions my drain my batteries? = Being able to measure is most important. What is good or bad may be differ= ent for different deployments. _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic --_000_3100015AF8CF4865A4E9B590E2CF59CAnasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lloyd,
This "Six Years= "  paper is right on  target.

Razvan,

I know of NO studies in this area.  I've seen l= ittle work done in actually moving any traffic around with DTNs.  I've= also seen little in the way of running DTNs over disconnected networks. &n= bsp;Most of the work appears to be a sting-of-pearls space scenario with ma= ybe three or four forwarding agents and no mix of traffic or multihoming an= d not much in the way of complex routing. CGR works fine in this scenario.<= /div>

Military applications are probably the most comple= x scenarios to date and I have seen little done here.  Some simple dem= onstrations with little traffic.  My understanding is that the militar= y is JUST starting to "really" evaluate DTN in real scenarios.  I am n= ot use what the traffic mix is.

I would say, makin= g your own scenario and use case would be a good start.  Perhaps first= responders (but they may have little need for DTN as they are more of a si= ngle hop store and forward scenario).  Perhaps one of the generic scen= arios presented in this draft may help.  But you will need to generate= some type of traffic pattern.  


- Will



Razvan,

for thoughts on DTN metrics, lo= ok into Ioannis Psaras's work: his six years since dtn paper and accompanyi= ng tech report.

http://www.ee.ucl.ac.uk/~uceeips/UCL_site/About...html
Lloyd Wood
http://sat-net.c= om/L.Wood/


________________________________________
From:= dtn-users-bounces@irtf.org [dtn-users-bounces@irtf.org] On Behalf Of Razva= n BEURAN [razvan@nict.go.jp]
Sent: 11 September 2012 09:23
To: Ivanci= c, William D. (GRC-RHN0)
Cc: dtn-users@irtf.org
Subject: Re: [dtn-use= rs] On measuring the DTN2 performance

Dear William,

I found y= our brief analysis very useful, and I totally agree with the fact
that m= eaningful metric are deployment/application specific. Are you by any
cha= nce aware of any thorough study that looks at the appropriate metrics
fo= r different classes of DTNs?

A quick search didn't provide any usefu= l results, and I believe that such
a theoretical effort would be a great= starting point for a discussion on
DTN performance. If no such study ex= ists it would be great to make one :-)

Best wishes,
Razvan

On Fri, 7 Sep 2012, Ivancic, William D. (GRC-RHN0) wrote:


On Sep 7, 2= 012, at 5:48 AM, TSELIKIS.Christos wrote:

Hi all,
I fully agree with Razvan, "what exactly is
perform= ance in DTNs", perhaps some other metrics (except from throughput and delay= ) might provide more accurate descriptions (one way metrics such as deliver= y rate, loss, etc, which have already been studied as well).

For RFC5050 DTNs where there is a bundle lifetime, than delay sho= uld be insignificant.  The metric is successful delivery of a bundle. =  Think of it like this:  I send you a birthday gift. Your birthda= y is one month away.  The gift says do not open until your birthday. &= nbsp;Whether or not you receive that bundle tomorrow or in a month is meani= ngless.  So long as get it before your birthday.  Since you put a= lifetime on the bundle, you are now allowing the network to decide when to= deliver.  IMHO, the successful delivery, overall bandwidth utilizatio= n, overall storage utilization  and overall processing utilization are= the metrics.  How much total network resources are you using to succe= ssfully deliver that bundle?  You may flood to improve chances of deli= vering a bundle, but that will use a lot of resources.

Meaningful= metrics are extremely deployment specific.  Is my network heavily use= d in which case flooding may congest and be worse?  Are my nodes power= constrained in which case excessive transmissions my drain my batteries? &= nbsp;Being able to measure is most important.  What is good or bad may= be different for different deployments.
__________________= _____________________________
dtn-users mailing list
dtn-users@irtf.o= rg
https://www.irtf.org/mailman/listinfo/dtn-users

******************************
William D. Ivancic
Phone 2= 16-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~= ivancic

= --_000_3100015AF8CF4865A4E9B590E2CF59CAnasagov_-- From william.d.ivancic@nasa.gov Tue Sep 11 06:05:53 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4572021F8800 for ; Tue, 11 Sep 2012 06:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3D+2VRRE3xcW for ; Tue, 11 Sep 2012 06:05:52 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC4421F87FB for ; Tue, 11 Sep 2012 06:05:52 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id A27C72D817F; Tue, 11 Sep 2012 08:05:51 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q8BD5pp8016763; Tue, 11 Sep 2012 08:05:51 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 11 Sep 2012 08:05:51 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Razvan BEURAN Date: Tue, 11 Sep 2012 08:05:53 -0500 Thread-Topic: [dtn-users] On measuring the DTN2 performance Thread-Index: Ac2QHisrinGNXa0xSuGi86i8R9QtdA== Message-ID: <351AF15D-0824-418A-8720-47D406E32ADF@nasa.gov> References: <3A3A4FA8-0A97-43F9-800C-5BF2D894ADC5@nasa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-11_03:2012-09-06, 2012-09-11, 1970-01-01 signatures=0 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 13:05:53 -0000 Another thought on this topic. Without meaningful measurable metrics, it w= ill be very difficult to perform many aspects of network management. - Will On Sep 11, 2012, at 4:23 AM, Razvan BEURAN wrote: >=20 > Dear William, >=20 > I found your brief analysis very useful, and I totally agree with the fac= t=20 > that meaningful metric are deployment/application specific. Are you by an= y=20 > chance aware of any thorough study that looks at the appropriate metrics= =20 > for different classes of DTNs? From TSELIKIS.Christos@haicorp.com Wed Sep 12 00:29:32 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AD221F8551 for ; Wed, 12 Sep 2012 00:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8o+TlIHx8QH for ; Wed, 12 Sep 2012 00:29:32 -0700 (PDT) Received: from haiedgesrv1.haicorp.com (haiedgesrv1.haicorp.com [212.205.103.43]) by ietfa.amsl.com (Postfix) with ESMTP id C3BDD21F856D for ; Wed, 12 Sep 2012 00:29:30 -0700 (PDT) Received: from haimail2.hai.gr (10.0.200.55) by haiedgesrv1.haicorp.com (192.168.2.6) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 12 Sep 2012 10:22:07 +0300 Received: from HAIMAIL1.hai.gr ([10.0.200.56]) by haimail2.hai.gr ([10.0.200.55]) with mapi; Wed, 12 Sep 2012 10:29:10 +0300 From: TSELIKIS.Christos To: "'Ivancic, William D. (GRC-RHN0)'" , "Razvan BEURAN" Date: Wed, 12 Sep 2012 10:29:10 +0300 Thread-Topic: [dtn-users] On measuring the DTN2 performance Thread-Index: Ac2QHisrinGNXa0xSuGi86i8R9QtdAAjXieg Message-ID: References: <3A3A4FA8-0A97-43F9-800C-5BF2D894ADC5@nasa.gov> <351AF15D-0824-418A-8720-47D406E32ADF@nasa.gov> In-Reply-To: <351AF15D-0824-418A-8720-47D406E32ADF@nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] On measuring the DTN2 performance X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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: Wed, 12 Sep 2012 07:29:32 -0000 Hi there, Dear Will, after your comments it is clear now that we have user-applicatio= n-related metrics and network utilization metrics (dtnbone may be a source = for information regarding the latter). Also, delay is not so vital for BP b= ecause of the bundle expiration time that you mentioned. Still, the study o= f how e2e delay varies below that limit with respect to some parameters sho= uld not be neglected. A good metric is bw utilization which has already bee= n studied in "Implementing Delay Tolerant Networking", M. Demmer et al. New= metrics could be defined taking into account the above. Finally, multiple = large-volume flows injected in DTN infrastructure may reveal interesting pe= rformance-related / operational characteristics of DTN/BP configurations, s= ee "DTN: An Architectural Retrospective", K. Fall, S. Farrell. With very kind regards, Tselikis Christos=20 Hellenic Aerospace Industry S.A. Electronics Engineering Department=A0=20 e-mail: Tselikis.Christos@haicorp.com=20 PO Box 23, GR-32009 Schimatari, Greece Tel. : +30 22620 52561 Fax: +30 22620 52910 -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of Ivancic, William D. (GRC-RHN0) Sent: Tuesday, September 11, 2012 4:06 PM To: Razvan BEURAN Cc: dtn-users@irtf.org Subject: Re: [dtn-users] On measuring the DTN2 performance Another thought on this topic. Without meaningful measurable metrics, it w= ill be very difficult to perform many aspects of network management. - Will On Sep 11, 2012, at 4:23 AM, Razvan BEURAN wrote: >=20 > Dear William, >=20 > I found your brief analysis very useful, and I totally agree with the fac= t=20 > that meaningful metric are deployment/application specific. Are you by an= y=20 > chance aware of any thorough study that looks at the appropriate metrics= =20 > for different classes of DTNs? _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users From michirod@gmail.com Thu Sep 13 21:07:43 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3752F21F861E for ; Thu, 13 Sep 2012 21:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdnunfWZrErw for ; Thu, 13 Sep 2012 21:07:42 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5168721F861D for ; Thu, 13 Sep 2012 21:07:42 -0700 (PDT) Received: by eeke52 with SMTP id e52so2394639eek.13 for ; Thu, 13 Sep 2012 21:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=U7b/h6WKg0MNEiknmS6VvBzCWr3haevE9x7YVWblqfo=; b=cqFFRRXK2OeGLuIg/AnN/WZr0cUWd6lo/obsTgAiAX67y3N4g+piqgQq9L1L1/psoi gL1S8kqSpsG/6fylekyaA4GyEC0Vutzw4EmJ4+2CWL7xE8oYHnwU6B2B7N40H84aSYSL pPsPzC3/LJXvhqTUWj+ByDzd7y+mLWr2riaUm7Wh9qlieVnAWWTHfOYFP6+FQ/+O7q/W 3I8ii4d07mi3WAL/aynko757FCAiitBF4DTlv4ZduBMS8Sr8tG/aCv+DQlFGr0HAcvX6 bn8JiE8NH2FYQpVAmpcC3QO19oJn4QM5fQ1DY1BYo8cTVhKIY9vfOtJ1cxuniPwGDX7X +Low== Received: by 10.14.0.198 with SMTP id 46mr1685006eeb.30.1347595661309; Thu, 13 Sep 2012 21:07:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.47.16 with HTTP; Thu, 13 Sep 2012 21:07:20 -0700 (PDT) From: Michele Rodolfi Date: Fri, 14 Sep 2012 06:07:20 +0200 Message-ID: To: dtn-users@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dtn-users] Bundle status report fragment offset and payload length X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 04:07:43 -0000 Hi all, I'm trying to get infos from the bundle status reports, and I noticed that in the fields "frag_offset" and " orig_length" in the structure bundle_id referred by the status report I get values that do not make sense. I send bundles with a 50kB payload and receive all the status delivered reports. In the frag_offset there is always the value 1348824164 and in the orig_length the value is variable but anyway too big. I can't understand why i get this behaviour Here there is a csv log of what i get: https://www.dropbox.com/s/jr0x1zc4gkhw2om/400908171_portatile-debian.dtn.csv Also I'm wondering if there is a way to read the Administrative Record Flags of an administrative record defined in the RFC 5050 pag 37. The flag I would like to read is the one that indicates that the record is relative to a fragmented bundle. I'm working with DTN2.9.0 on debian sid x86_64 With very kind regards Michele From kscott@mitre.org Mon Sep 17 05:19:53 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1B921F84C4 for ; Mon, 17 Sep 2012 05:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCgr7ipZfL9A for ; Mon, 17 Sep 2012 05:19:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFBE21F84B2 for ; Mon, 17 Sep 2012 05:19:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EBA1A21B193D; Mon, 17 Sep 2012 08:19:50 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CA09F21B1932; Mon, 17 Sep 2012 08:19:50 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.133]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 08:19:50 -0400 From: "Scott, Keith L." To: Michele Rodolfi , "dtn-users@irtf.org" Thread-Topic: [dtn-users] Bundle status report fragment offset and payload length Thread-Index: AQHNki6ABCEauZRIIUWvMZgk2U6G3JeOeM7Q Date: Mon, 17 Sep 2012 12:19:49 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE0678A515@IMCMBX01.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dtn-users] Bundle status report fragment offset and payload length X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 12:19:53 -0000 Are you saying that the APPLICATION got a bundle with frag_offset and orig_= length fields set? Applications should never receive bundle fragments, onl= y complete bundles. =09 --keith -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of Michele Rodolfi Sent: Friday, September 14, 2012 12:07 AM To: dtn-users@irtf.org Subject: [dtn-users] Bundle status report fragment offset and payload lengt= h Hi all, I'm trying to get infos from the bundle status reports, and I noticed that in the fields "frag_offset" and " orig_length" in the structure bundle_id referred by the status report I get values that do not make sense. I send bundles with a 50kB payload and receive all the status delivered rep= orts. In the frag_offset there is always the value 1348824164 and in the orig_length the value is variable but anyway too big. I can't understand why i get this behaviour Here there is a csv log of what i get: https://www.dropbox.com/s/jr0x1zc4gkhw2om/400908171_portatile-debian.dtn.cs= v Also I'm wondering if there is a way to read the Administrative Record Flags of an administrative record defined in the RFC 5050 pag 37. The flag I would like to read is the one that indicates that the record is relative to a fragmented bundle. I'm working with DTN2.9.0 on debian sid x86_64 With very kind regards Michele _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users From l.wood@surrey.ac.uk Mon Sep 17 06:02:57 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601F021F84C2 for ; Mon, 17 Sep 2012 06:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fFUtC1M7cZC for ; Mon, 17 Sep 2012 06:02:55 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 34F9721F84CD for ; Mon, 17 Sep 2012 06:02:54 -0700 (PDT) Received: from [195.245.231.67:28041] by server-7.bemta-5.messagelabs.com id 4B/8E-19703-67F17505; Mon, 17 Sep 2012 13:02:46 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-82.messagelabs.com!1347886965!35502615!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30436 invoked from network); 17 Sep 2012 13:02:45 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-12.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 17 Sep 2012 13:02:45 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.82]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Mon, 17 Sep 2012 14:00:36 +0100 From: To: , , Date: Mon, 17 Sep 2012 14:00:01 +0100 Thread-Topic: [dtn-users] Bundle status report fragment offset and payload length Thread-Index: AQHNki6ABCEauZRIIUWvMZgk2U6G3JeOeM7QgAALhyM= Message-ID: References: , <5EE81C5C4CFFF4418C5EAD12F49D64EE0678A515@IMCMBX01.MITRE.ORG> In-Reply-To: <5EE81C5C4CFFF4418C5EAD12F49D64EE0678A515@IMCMBX01.MITRE.ORG> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dtn-users] Bundle status report fragment offset and payload length X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 13:02:57 -0000 If a bundle implementation only gets a single fragment, how does it prompt = redelivery? Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: dtn-users-bounces@irtf.org [dtn-users-bounces@irtf.org] On Behalf Of = Scott, Keith L. [kscott@mitre.org] Sent: 17 September 2012 13:19 To: Michele Rodolfi; dtn-users@irtf.org Subject: Re: [dtn-users] Bundle status report fragment offset and payload l= ength Are you saying that the APPLICATION got a bundle with frag_offset and orig_= length fields set? Applications should never receive bundle fragments, onl= y complete bundles. --keith -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of Michele Rodolfi Sent: Friday, September 14, 2012 12:07 AM To: dtn-users@irtf.org Subject: [dtn-users] Bundle status report fragment offset and payload lengt= h Hi all, I'm trying to get infos from the bundle status reports, and I noticed that in the fields "frag_offset" and " orig_length" in the structure bundle_id referred by the status report I get values that do not make sense. I send bundles with a 50kB payload and receive all the status delivered rep= orts. In the frag_offset there is always the value 1348824164 and in the orig_length the value is variable but anyway too big. I can't understand why i get this behaviour Here there is a csv log of what i get: https://www.dropbox.com/s/jr0x1zc4gkhw2om/400908171_portatile-debian.dtn.cs= v Also I'm wondering if there is a way to read the Administrative Record Flags of an administrative record defined in the RFC 5050 pag 37. The flag I would like to read is the one that indicates that the record is relative to a fragmented bundle. I'm working with DTN2.9.0 on debian sid x86_64 With very kind regards Michele _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users From michirod@gmail.com Mon Sep 17 06:15:12 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DB521F862B for ; Mon, 17 Sep 2012 06:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXfmet84NtJy for ; Mon, 17 Sep 2012 06:15:11 -0700 (PDT) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1A14321F8623 for ; Mon, 17 Sep 2012 06:15:10 -0700 (PDT) Received: by lage12 with SMTP id e12so5079100lag.13 for ; Mon, 17 Sep 2012 06:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kbKeLrgDw2D70xB7rq1fSrK0oIfZX8ehm75dLJOVOr4=; b=SZzb5gZJoCX/eXHGJQOldD5GIxl4PEDmmWoA75AzbJv9ZkkI3gvQlmKgurcaNVgVdY WjFZ9XrCU6RjpuVovjGByTGnbayuNy1UWRb9k6bsz6I/Zye2GOUULFv3Y9FDGfiXBFM6 wHZ7UJZqKF53/RvNAb2z4nAQycmgCKVI1ch0UIlsWrRSHWuRPiG0LO8avzp7xUuy8fTL M8XBzMe6EmvVdFLV1szZL4H7YRSPSmH9ziVRIPa16JeWhJUOMQj64ZHLrKJhjcSkR4r+ dYx2o2hirlLaAfuupnKMLZMGZpOxKUgMe7nW+LjvilSATtkfIugbFmWTEbn9oS0gDYVK DYgw== Received: by 10.152.130.3 with SMTP id oa3mr9737426lab.27.1347887709865; Mon, 17 Sep 2012 06:15:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.16.137 with HTTP; Mon, 17 Sep 2012 06:14:49 -0700 (PDT) In-Reply-To: <5EE81C5C4CFFF4418C5EAD12F49D64EE0678A515@IMCMBX01.MITRE.ORG> References: <5EE81C5C4CFFF4418C5EAD12F49D64EE0678A515@IMCMBX01.MITRE.ORG> From: Michele Rodolfi Date: Mon, 17 Sep 2012 15:14:49 +0200 Message-ID: To: "Scott, Keith L." Content-Type: text/plain; charset=ISO-8859-1 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] Bundle status report fragment offset and payload length X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 13:15:12 -0000 2012/9/17 Scott, Keith L. : > Are you saying that the APPLICATION got a bundle with frag_offset and orig_length fields set? Applications should never receive bundle fragments, only complete bundles. I'm saying that the application got a bundle STATUS REPORT which payload refers to a bundle id (source, timestamp, frag_offset and orig_length). I noticed that the fields frag_offset and orig_length of the referred bundle id are wrong only on 64bit architecture nodes. On 32bit nodes, these fields are correctly set to 0. Michele > > --keith > > -----Original Message----- > From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Behalf Of Michele Rodolfi > Sent: Friday, September 14, 2012 12:07 AM > To: dtn-users@irtf.org > Subject: [dtn-users] Bundle status report fragment offset and payload length > > Hi all, > I'm trying to get infos from the bundle status reports, and I noticed > that in the fields "frag_offset" and " orig_length" in the structure > bundle_id referred by the status report I get values that do not make > sense. > I send bundles with a 50kB payload and receive all the status delivered reports. > In the frag_offset there is always the value 1348824164 and in the > orig_length the value is variable but anyway too big. > I can't understand why i get this behaviour > Here there is a csv log of what i get: > https://www.dropbox.com/s/jr0x1zc4gkhw2om/400908171_portatile-debian.dtn.csv > > Also I'm wondering if there is a way to read the Administrative Record > Flags of an administrative record defined in the RFC 5050 pag 37. > The flag I would like to read is the one that indicates that the > record is relative to a fragmented bundle. > > I'm working with DTN2.9.0 on debian sid x86_64 > > With very kind regards > Michele > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users From scott.c.burleigh@jpl.nasa.gov Mon Sep 17 08:03:55 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655CB21F86E1 for ; Mon, 17 Sep 2012 08:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCx+J1Ws+grY for ; Mon, 17 Sep 2012 08:03:54 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3661F21F8669 for ; Mon, 17 Sep 2012 08:03:54 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8HF3pE3006938 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 17 Sep 2012 08:03:52 -0700 Received: from AP-EMBX-SP20.RES.AD.JPL ([169.254.8.34]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.211]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 08:03:51 -0700 From: "Burleigh, Scott C (313B)" To: "l.wood@surrey.ac.uk" , "kscott@mitre.org" , "michirod@gmail.com" , "dtn-users@irtf.org" Thread-Topic: [dtn-users] Bundle status report fragment offset and payload length Thread-Index: AQHNki6AFNJn70UjdE+2/x2CeYDHlZeO7nKAgAALO4D//6saoA== Date: Mon, 17 Sep 2012 15:03:50 +0000 Message-ID: References: , <5EE81C5C4CFFF4418C5EAD12F49D64EE0678A515@IMCMBX01.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [dtn-users] Bundle status report fragment offset and payload length X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 15:03:55 -0000 In BP, a "fragment" (or "fragmentary bundle") is not a portion of a bundle = but is rather a bundle whose payload is a portion of the payload of some an= tecedent bundle. Since a fragment is a bundle, all the procedures that app= ly to bundles can be applied to it, including custodial retransmission. The main difference between a fragment and a non-fragmentary bundle is that= the payloads of fragmentary bundles are never delivered. Fragments are ac= cumulated at their destination endpoint until the union of their payloads e= quals the originally transmitted application data unit, at which point a si= ngle bundle with the fully reconstituted payload replaces the accumulated f= ragments and is delivered to the application. Scott -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of l.wood@surrey.ac.uk Sent: Monday, September 17, 2012 6:00 AM To: kscott@mitre.org; michirod@gmail.com; dtn-users@irtf.org Subject: Re: [dtn-users] Bundle status report fragment offset and payload l= ength If a bundle implementation only gets a single fragment, how does it prompt = redelivery? Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: dtn-users-bounces@irtf.org [dtn-users-bounces@irtf.org] On Behalf Of = Scott, Keith L. [kscott@mitre.org] Sent: 17 September 2012 13:19 To: Michele Rodolfi; dtn-users@irtf.org Subject: Re: [dtn-users] Bundle status report fragment offset and payload l= ength Are you saying that the APPLICATION got a bundle with frag_offset and orig_= length fields set? Applications should never receive bundle fragments, onl= y complete bundles. --keith -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of Michele Rodolfi Sent: Friday, September 14, 2012 12:07 AM To: dtn-users@irtf.org Subject: [dtn-users] Bundle status report fragment offset and payload lengt= h Hi all, I'm trying to get infos from the bundle status reports, and I noticed that = in the fields "frag_offset" and " orig_length" in the structure bundle_id r= eferred by the status report I get values that do not make sense. I send bundles with a 50kB payload and receive all the status delivered rep= orts. In the frag_offset there is always the value 1348824164 and in the orig_len= gth the value is variable but anyway too big. I can't understand why i get this behaviour Here there is a csv log of what= i get: https://www.dropbox.com/s/jr0x1zc4gkhw2om/400908171_portatile-debian.dtn.cs= v Also I'm wondering if there is a way to read the Administrative Record Flag= s of an administrative record defined in the RFC 5050 pag 37. The flag I would like to read is the one that indicates that the record is = relative to a fragmented bundle. I'm working with DTN2.9.0 on debian sid x86_64 With very kind regards Michele _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users From kscott@mitre.org Mon Sep 17 09:52:26 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948D721F871E for ; Mon, 17 Sep 2012 09:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EowwLKlhJdtf for ; Mon, 17 Sep 2012 09:52:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7C37621F8514 for ; Mon, 17 Sep 2012 09:52:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C46E321B04B4; Mon, 17 Sep 2012 12:52:17 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B2D7A21B19B6; Mon, 17 Sep 2012 12:52:17 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.133]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 12:52:17 -0400 From: "Scott, Keith L." To: Michele Rodolfi Thread-Topic: [dtn-users] Bundle status report fragment offset and payload length Thread-Index: AQHNki6ABCEauZRIIUWvMZgk2U6G3JeOeM7QgABSt4D///lscA== Date: Mon, 17 Sep 2012 16:52:16 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE0678A863@IMCMBX01.MITRE.ORG> References: <5EE81C5C4CFFF4418C5EAD12F49D64EE0678A515@IMCMBX01.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dtn-users@irtf.org" Subject: Re: [dtn-users] Bundle status report fragment offset and payload length X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 16:52:26 -0000 Ah, OK. I think I've got a 64-bit machine I can use; I'll see if I get the= same behavior. --keith -----Original Message----- From: Michele Rodolfi [mailto:michirod@gmail.com]=20 Sent: Monday, September 17, 2012 9:15 AM To: Scott, Keith L. Cc: dtn-users@irtf.org Subject: Re: [dtn-users] Bundle status report fragment offset and payload l= ength 2012/9/17 Scott, Keith L. : > Are you saying that the APPLICATION got a bundle with frag_offset and ori= g_length fields set? Applications should never receive bundle fragments, o= nly complete bundles. I'm saying that the application got a bundle STATUS REPORT which payload refers to a bundle id (source, timestamp, frag_offset and orig_length). I noticed that the fields frag_offset and orig_length of the referred bundle id are wrong only on 64bit architecture nodes. On 32bit nodes, these fields are correctly set to 0. Michele > > --keith > > -----Original Message----- > From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On B= ehalf Of Michele Rodolfi > Sent: Friday, September 14, 2012 12:07 AM > To: dtn-users@irtf.org > Subject: [dtn-users] Bundle status report fragment offset and payload len= gth > > Hi all, > I'm trying to get infos from the bundle status reports, and I noticed > that in the fields "frag_offset" and " orig_length" in the structure > bundle_id referred by the status report I get values that do not make > sense. > I send bundles with a 50kB payload and receive all the status delivered r= eports. > In the frag_offset there is always the value 1348824164 and in the > orig_length the value is variable but anyway too big. > I can't understand why i get this behaviour > Here there is a csv log of what i get: > https://www.dropbox.com/s/jr0x1zc4gkhw2om/400908171_portatile-debian.dtn.= csv > > Also I'm wondering if there is a way to read the Administrative Record > Flags of an administrative record defined in the RFC 5050 pag 37. > The flag I would like to read is the one that indicates that the > record is relative to a fragmented bundle. > > I'm working with DTN2.9.0 on debian sid x86_64 > > With very kind regards > Michele > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users From l.wood@surrey.ac.uk Mon Sep 17 15:38:34 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1A821E808C for ; Mon, 17 Sep 2012 15:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZv4zKB3TbE6 for ; Mon, 17 Sep 2012 15:38:31 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9918821E8063 for ; Mon, 17 Sep 2012 15:38:30 -0700 (PDT) Received: from [195.245.231.67:59690] by server-2.bemta-5.messagelabs.com id 33/05-11456-566A7505; Mon, 17 Sep 2012 22:38:29 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-11.tower-82.messagelabs.com!1347921508!27478242!2 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29621 invoked from network); 17 Sep 2012 22:38:28 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-11.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 17 Sep 2012 22:38:28 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.82]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Mon, 17 Sep 2012 23:37:55 +0100 From: To: , , , Date: Mon, 17 Sep 2012 23:35:21 +0100 Thread-Topic: [dtn-users] Bundle status report fragment offset and payload length Thread-Index: AQHNki6AFNJn70UjdE+2/x2CeYDHlZeO7nKAgAALO4D//6saoIAAgE05 Message-ID: References: , <5EE81C5C4CFFF4418C5EAD12F49D64EE0678A515@IMCMBX01.MITRE.ORG> , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dtn-users] Bundle status report fragment offset and payload length X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 22:38:34 -0000 I see a problem with the assumption that fragments will simply accumulate u= ntil the tunnelled bundle can be assembled. There's no way to say 'I've got two thirds of this bundle, but just need th= e other third to complete it'. Custody transfer isn't relevant here. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] Sent: 17 September 2012 16:03 To: Wood L Dr (Electronic Eng); kscott@mitre.org; michirod@gmail.com; dtn-= users@irtf.org Subject: RE: [dtn-users] Bundle status report fragment offset and payload l= ength In BP, a "fragment" (or "fragmentary bundle") is not a portion of a bundle = but is rather a bundle whose payload is a portion of the payload of some an= tecedent bundle. Since a fragment is a bundle, all the procedures that app= ly to bundles can be applied to it, including custodial retransmission. The main difference between a fragment and a non-fragmentary bundle is that= the payloads of fragmentary bundles are never delivered. Fragments are ac= cumulated at their destination endpoint until the union of their payloads e= quals the originally transmitted application data unit, at which point a si= ngle bundle with the fully reconstituted payload replaces the accumulated f= ragments and is delivered to the application. Scott -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of l.wood@surrey.ac.uk Sent: Monday, September 17, 2012 6:00 AM To: kscott@mitre.org; michirod@gmail.com; dtn-users@irtf.org Subject: Re: [dtn-users] Bundle status report fragment offset and payload l= ength If a bundle implementation only gets a single fragment, how does it prompt = redelivery? Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: dtn-users-bounces@irtf.org [dtn-users-bounces@irtf.org] On Behalf Of = Scott, Keith L. [kscott@mitre.org] Sent: 17 September 2012 13:19 To: Michele Rodolfi; dtn-users@irtf.org Subject: Re: [dtn-users] Bundle status report fragment offset and payload l= ength Are you saying that the APPLICATION got a bundle with frag_offset and orig_= length fields set? Applications should never receive bundle fragments, onl= y complete bundles. --keith -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of Michele Rodolfi Sent: Friday, September 14, 2012 12:07 AM To: dtn-users@irtf.org Subject: [dtn-users] Bundle status report fragment offset and payload lengt= h Hi all, I'm trying to get infos from the bundle status reports, and I noticed that = in the fields "frag_offset" and " orig_length" in the structure bundle_id r= eferred by the status report I get values that do not make sense. I send bundles with a 50kB payload and receive all the status delivered rep= orts. In the frag_offset there is always the value 1348824164 and in the orig_len= gth the value is variable but anyway too big. I can't understand why i get this behaviour Here there is a csv log of what= i get: https://www.dropbox.com/s/jr0x1zc4gkhw2om/400908171_portatile-debian.dtn.cs= v Also I'm wondering if there is a way to read the Administrative Record Flag= s of an administrative record defined in the RFC 5050 pag 37. The flag I would like to read is the one that indicates that the record is = relative to a fragmented bundle. I'm working with DTN2.9.0 on debian sid x86_64 With very kind regards Michele _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users From scott.c.burleigh@jpl.nasa.gov Mon Sep 17 16:04:47 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCDE21E8090 for ; Mon, 17 Sep 2012 16:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blnIcije85kG for ; Mon, 17 Sep 2012 16:04:46 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id B448D21E8063 for ; Mon, 17 Sep 2012 16:04:46 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8HN4iHX006127 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 17 Sep 2012 16:04:44 -0700 Received: from AP-EMBX-SP20.RES.AD.JPL ([169.254.8.34]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.211]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 16:04:43 -0700 From: "Burleigh, Scott C (313B)" To: "l.wood@surrey.ac.uk" , "kscott@mitre.org" , "michirod@gmail.com" , "dtn-users@irtf.org" Thread-Topic: [dtn-users] Bundle status report fragment offset and payload length Thread-Index: AQHNki6AFNJn70UjdE+2/x2CeYDHlZeO7nKAgAALO4D//6saoIAAgE05gAAFH4A= Date: Mon, 17 Sep 2012 23:04:43 +0000 Message-ID: References: , <5EE81C5C4CFFF4418C5EAD12F49D64EE0678A515@IMCMBX01.MITRE.ORG> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [dtn-users] Bundle status report fragment offset and payload length X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2012 23:04:47 -0000 True, custody transfer doesn't prompt for retransmission. A more direct an= swer to your original question would have been "it doesn't prompt redeliver= y; it waits until all the other fragments arrive, then delivers the reassem= bled payload. If the rest of the fragments don't arrive prior to bundle ex= piration, the fragments that have arrived are destroyed. Responsibility fo= r ensuring the arrival of the missing fragments rests with the convergence-= layer protocols, possibly backed up by custodial retransmission of the frag= mentary bundles, individually, upon timeout prior to receipt of custody acc= eptance signal." Scott -----Original Message----- From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk]=20 Sent: Monday, September 17, 2012 3:35 PM To: Burleigh, Scott C (313B); kscott@mitre.org; michirod@gmail.com; dtn-use= rs@irtf.org Subject: RE: [dtn-users] Bundle status report fragment offset and payload l= ength I see a problem with the assumption that fragments will simply accumulate u= ntil the tunnelled bundle can be assembled. There's no way to say 'I've got two thirds of this bundle, but just need th= e other third to complete it'. Custody transfer isn't relevant here. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] Sent: 17 September 2012 16:03 To: Wood L Dr (Electronic Eng); kscott@mitre.org; michirod@gmail.com; dtn-= users@irtf.org Subject: RE: [dtn-users] Bundle status report fragment offset and payload l= ength In BP, a "fragment" (or "fragmentary bundle") is not a portion of a bundle = but is rather a bundle whose payload is a portion of the payload of some an= tecedent bundle. Since a fragment is a bundle, all the procedures that app= ly to bundles can be applied to it, including custodial retransmission. The main difference between a fragment and a non-fragmentary bundle is that= the payloads of fragmentary bundles are never delivered. Fragments are ac= cumulated at their destination endpoint until the union of their payloads e= quals the originally transmitted application data unit, at which point a si= ngle bundle with the fully reconstituted payload replaces the accumulated f= ragments and is delivered to the application. Scott -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of l.wood@surrey.ac.uk Sent: Monday, September 17, 2012 6:00 AM To: kscott@mitre.org; michirod@gmail.com; dtn-users@irtf.org Subject: Re: [dtn-users] Bundle status report fragment offset and payload l= ength If a bundle implementation only gets a single fragment, how does it prompt = redelivery? Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: dtn-users-bounces@irtf.org [dtn-users-bounces@irtf.org] On Behalf Of = Scott, Keith L. [kscott@mitre.org] Sent: 17 September 2012 13:19 To: Michele Rodolfi; dtn-users@irtf.org Subject: Re: [dtn-users] Bundle status report fragment offset and payload l= ength Are you saying that the APPLICATION got a bundle with frag_offset and orig_= length fields set? Applications should never receive bundle fragments, onl= y complete bundles. --keith -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of Michele Rodolfi Sent: Friday, September 14, 2012 12:07 AM To: dtn-users@irtf.org Subject: [dtn-users] Bundle status report fragment offset and payload lengt= h Hi all, I'm trying to get infos from the bundle status reports, and I noticed that = in the fields "frag_offset" and " orig_length" in the structure bundle_id r= eferred by the status report I get values that do not make sense. I send bundles with a 50kB payload and receive all the status delivered rep= orts. In the frag_offset there is always the value 1348824164 and in the orig_len= gth the value is variable but anyway too big. I can't understand why i get this behaviour Here there is a csv log of what= i get: https://www.dropbox.com/s/jr0x1zc4gkhw2om/400908171_portatile-debian.dtn.cs= v Also I'm wondering if there is a way to read the Administrative Record Flag= s of an administrative record defined in the RFC 5050 pag 37. The flag I would like to read is the one that indicates that the record is = relative to a fragmented bundle. I'm working with DTN2.9.0 on debian sid x86_64 With very kind regards Michele _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users From f.neves@ua.pt Thu Sep 27 01:39:50 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FAB21F86DE for ; Thu, 27 Sep 2012 01:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mztKjNXPq5EQ for ; Thu, 27 Sep 2012 01:39:49 -0700 (PDT) Received: from mx1.ua.pt (mx1.ua.pt [193.136.173.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA7E21F86E2 for ; Thu, 27 Sep 2012 01:39:48 -0700 (PDT) Received: from SOBREIRO.ua.pt (193.136.172.225) by mx1.ua.pt (193.136.173.5) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 27 Sep 2012 09:39:34 +0100 Received: from [193.136.93.9] (193.136.93.9) by SOBREIRO.ua.pt (193.136.173.7) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 27 Sep 2012 09:39:25 +0100 Message-ID: <506410A1.8070100@ua.pt> Date: Thu, 27 Sep 2012 09:38:57 +0100 From: Filipe Neves User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [193.136.93.9] X-Mailman-Approved-At: Fri, 28 Sep 2012 08:07:39 -0700 Subject: [dtn-users] DTN2 - Dynamic IPs X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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: Thu, 27 Sep 2012 08:58:53 -0000 Hi. First of all I would like to say congratulations to your platform DTN2, I'm starting to work with it and verify which its main advantages, limitations and possible developments / improvements that can be implemented in the coming future. However I have a question not yet solved. With your framework I could communicate between 2 different PCs, but only with static routes and links. My question is if it is possible to communicate PCs but through no static routes (dynamic IPs), that is, imagine a scenario where I know the name of DTN destination that I want to connect but do not know what the IP. Is that possible? I can I configure this on dtn.conf? Thank you very much! Best regards, -- Filipe Neves From ccaini@arces.unibo.it Fri Sep 28 10:46:07 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A8521F84F6 for ; Fri, 28 Sep 2012 10:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQlwxtJf6L7f for ; Fri, 28 Sep 2012 10:46:07 -0700 (PDT) Received: from mail.arces.unibo.it (mail.arces.unibo.it [137.204.143.6]) by ietfa.amsl.com (Postfix) with ESMTP id AF83F21F848B for ; Fri, 28 Sep 2012 10:46:06 -0700 (PDT) Received: from webmail.arces.unibo.it (web.arces.unibo.it [137.204.143.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.arces.unibo.it (Postfix) with ESMTP id 22F4B404857E; Fri, 28 Sep 2012 19:46:02 +0200 (CEST) MIME-Version: 1.0 Date: Fri, 28 Sep 2012 19:46:02 +0200 From: ccaini To: Filipe Neves In-Reply-To: <506410A1.8070100@ua.pt> References: <506410A1.8070100@ua.pt> Message-ID: <2488f830807fd449f45816a39756d941@arces.unibo.it> X-Sender: ccaini@arces.unibo.it User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-Arces-MailScanner-Information: Please contact the ISP for more information X-Arces-MailScanner-ID: 22F4B404857E.0FAC1 X-Arces-MailScanner: Found to be clean X-Arces-MailScanner-From: ccaini@arces.unibo.it Cc: dtn-users@irtf.org Subject: Re: [dtn-users] DTN2 - Dynamic IPs X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2012 17:46:07 -0000 Dear Filipe, Yes you can. At the University of Bologna we have carried out many experiments by using a smartphone (Nokia N900, OS MAEMO, DTN2) as either source or destination of bundles in a DTN networks. The smartphone used the 3G UMTS interface, with a public but dynamic IP address assigned by the 3G cellular network operator. In brief, the IP address of the smartphopne was changed each time the 3G interface was switched off and on. On the node with the dynamic IP yuou should define an ALWAYSON link to a fixed IP (i.e the IP of a DTN node working as a gateway towards the rest of the network), and a route to specify that the bundles to your DTN destination must be routed through this link. For exemple, in the dtn.conf of smartphone.dtn you should add: link add linknameisbill 136.203.45.61 ALWAYSON tcp route add dtn://mydestination.dtn/* linknameisbill Once the 3G interface is switched on, a new IP address is assigned and the TCPCL of the smartphone always tries to establish a new TCP connection to the fixed IP (136.203.45.61) of the DTN gateway. Once established, the two DTN node TCPCLs exchange information about their dtn names, and the DTN gateway adds by itself a new opportunistic link (e.g. link0) to the dynamic IP (note that the TCP connectioopn is bidirectional, thus, although established "to" the gateway can be used also to carry traffic "from" it), and a new route to smartphone.dtn through the opportunistic link0. Note that in this way, not only can you send bundle from a node with a dynamic IP, but you can also send bundles to it. For instance, you can send a bundle to smartphone.dtn when the smartphone is switched off! The bundle will be taken into custody by the gateway and delivered once the smartphone and its 3G interface are switched on and the dynamic IP assigned. Moreover, the same holds true for nodes with an IP natted. It still works, because the "trick" is that thanks to the ALWAYSON command the TCP connection is always established by the node with the dynamic or natted IP, although used "opportunitically" in the reverse direction. Yours sincerely, Carlo Caini On Thu, 27 Sep 2012 09:38:57 +0100, Filipe Neves wrote: > Hi. > > First of all I would like to say congratulations to your platform DTN2, > I'm starting to work with it and verify which its main advantages, > limitations and possible developments / improvements that can be > implemented in the coming future. > > However I have a question not yet solved. With your framework I could > communicate between 2 different PCs, but only with static routes and > links. My question is if it is possible to communicate PCs but through > no static routes (dynamic IPs), that is, imagine a scenario where I know > the name of DTN destination that I want to connect but do not know what > the IP. Is that possible? I can I configure this on dtn.conf? > > Thank you very much! > > Best regards, From lorentze@ibr.cs.tu-bs.de Fri Sep 28 13:39:48 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227DD21F85A3 for ; Fri, 28 Sep 2012 13:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8Db+vm5buje for ; Fri, 28 Sep 2012 13:39:47 -0700 (PDT) Received: from salvator.ibr.cs.tu-bs.de (salvator.ibr.cs.tu-bs.de [IPv6:2001:638:602:1181:21a:64ff:fed3:6c8c]) by ietfa.amsl.com (Postfix) with ESMTP id F263F21F859B for ; Fri, 28 Sep 2012 13:39:46 -0700 (PDT) Received: from [192.168.178.21] (77-21-193-3-dynip.superkabel.de [77.21.193.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lorentze@salvator) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTPSA id 2927C9F18; Fri, 28 Sep 2012 22:39:43 +0200 (CEST) Message-ID: <50660B0E.60201@ibr.cs.tu-bs.de> Date: Fri, 28 Sep 2012 22:39:42 +0200 From: Till Lorentzen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: ccaini References: <506410A1.8070100@ua.pt> <2488f830807fd449f45816a39756d941@arces.unibo.it> In-Reply-To: <2488f830807fd449f45816a39756d941@arces.unibo.it> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at salvator X-Virus-Status: Clean Cc: dtn-users@irtf.org, Filipe Neves Subject: Re: [dtn-users] DTN2 - Dynamic IPs X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2012 20:39:48 -0000 Dear Filipe and Carlo, yes, that is the simplest and fastest way to solve the problem. But with a "little" bit of coding work, there could be another solution. I implemented a UDP DHT based mechanism to resolve a given EID to Convergence Layer Information. It is an C++ library, available on http://git.ibr.cs.tu-bs.de/?p=libdtndht.git;a=summary or on github https://github.com/soneyworld/dtndht . The mechanism has been published at the ACM CHANTS 2012. It is used by the IBRDTN implementation. So if anyone is interested in an integration into DTN2: Feel free to contact me for more details! The main benefit of this approach is a full distributed EID lookup service for direct or maybe also indirect communication between the DTN members. So you will reach the maximum bandwidth between too nodes. And you could also add an intermediate node for store carry and forward. BUT you will get a communication overhead for the DHT. So if your traffic volume is limited on a cellular network, I would use the way, Filipe described. And also, it's lookup speed isn't that fast (worst case ~30 sec) and reliable (worst case ~90% success ratio), as a configured link. But it is a possibility, which comes for free! Best regards, Till Lorentzen Am 28.09.2012 19:46, schrieb ccaini: > Dear Filipe, > Yes you can. At the University of Bologna we have carried out many > experiments by using a smartphone (Nokia N900, OS MAEMO, DTN2) as either > source or destination of bundles in a DTN networks. > The smartphone used the 3G UMTS interface, with a public but dynamic IP > address assigned by the 3G cellular network operator. In brief, the IP > address of the smartphopne was changed each time the 3G interface was > switched off and on. > On the node with the dynamic IP yuou should define an ALWAYSON link to a > fixed IP (i.e the IP of a DTN node working as a gateway towards the rest of > the network), and a route to specify that the bundles to your DTN > destination must be routed through this link. > For exemple, in the dtn.conf of smartphone.dtn you should add: > > link add linknameisbill 136.203.45.61 ALWAYSON tcp > route add dtn://mydestination.dtn/* linknameisbill > > Once the 3G interface is switched on, a new IP address is assigned and the > TCPCL of the smartphone always tries to establish a new TCP connection to > the fixed IP (136.203.45.61) of the DTN gateway. Once established, the two > DTN node TCPCLs exchange information about their dtn names, and the DTN > gateway adds by itself a new opportunistic link (e.g. link0) to the dynamic > IP (note that the TCP connectioopn is bidirectional, thus, although > established "to" the gateway can be used also to carry traffic "from" it), > and a new route to smartphone.dtn through the opportunistic link0. > > Note that in this way, not only can you send bundle from a node with a > dynamic IP, but you can also send bundles to it. For instance, you can send > a bundle to smartphone.dtn when the smartphone is switched off! The bundle > will be taken into custody by the gateway and delivered once the smartphone > and its 3G interface are switched on and the dynamic IP assigned. > Moreover, the same holds true for nodes with an IP natted. It still works, > because the "trick" is that thanks to the ALWAYSON command the TCP > connection is always established by the node with the dynamic or natted IP, > although used "opportunitically" in the reverse direction. > > Yours sincerely, > Carlo Caini > > > > > > > On Thu, 27 Sep 2012 09:38:57 +0100, Filipe Neves wrote: >> Hi. >> >> First of all I would like to say congratulations to your platform DTN2, >> I'm starting to work with it and verify which its main advantages, >> limitations and possible developments / improvements that can be >> implemented in the coming future. >> >> However I have a question not yet solved. With your framework I could >> communicate between 2 different PCs, but only with static routes and >> links. My question is if it is possible to communicate PCs but through >> no static routes (dynamic IPs), that is, imagine a scenario where I know > >> the name of DTN destination that I want to connect but do not know what >> the IP. Is that possible? I can I configure this on dtn.conf? >> >> Thank you very much! >> >> Best regards, > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users >