Re: [dtn-users] MSFC DTN2 Patches - 2016-02-29

"Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <david.a.zoller@nasa.gov> Mon, 14 March 2016 11:38 UTC

Return-Path: <david.a.zoller@nasa.gov>
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 2044312DA12 for <dtn-users@ietfa.amsl.com>; Mon, 14 Mar 2016 04:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level:
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5c3GiRD5wh7 for <dtn-users@ietfa.amsl.com>; Mon, 14 Mar 2016 04:38:30 -0700 (PDT)
Received: from ndmsvnpf101.ndc.nasa.gov (NDMSVNPF101.ndc.nasa.gov [198.117.0.151]) by ietfa.amsl.com (Postfix) with ESMTP id D3DA412D9C8 for <dtn-users@irtf.org>; Mon, 14 Mar 2016 04:38:29 -0700 (PDT)
Received: from ndmsppt102.ndc.nasa.gov (ndmsppt102.ndc.nasa.gov [198.117.0.67]) by ndmsvnpf101.ndc.nasa.gov (Postfix) with ESMTP id 7029340049D9; Mon, 14 Mar 2016 06:38:29 -0500 (CDT)
Received: from NDMSCHT112.ndc.nasa.gov (ndmscht112-pub.ndc.nasa.gov [198.117.0.212]) by ndmsppt102.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u2EBcTxl016926; Mon, 14 Mar 2016 06:38:29 -0500
Received: from NDMSMBX404.ndc.nasa.gov ([169.254.1.231]) by NDMSCHT112.ndc.nasa.gov ([198.117.0.212]) with mapi id 14.03.0266.001; Mon, 14 Mar 2016 06:38:29 -0500
From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <david.a.zoller@nasa.gov>
To: "nikansell00@gmail.com" <nikansell00@gmail.com>
Thread-Topic: [dtn-users] MSFC DTN2 Patches - 2016-02-29
Thread-Index: AdFzYQGjf4RQfVtBSbiruXOz6QW2lgAsD8cAAAs3OIACFfpFgABSeDDQ
Date: Mon, 14 Mar 2016 11:38:28 +0000
Message-ID: <94CFB3711B4CAE4DBFC5BEB3374BF0C62ECA4F@NDMSMBX404.ndc.nasa.gov>
References: <94CFB3711B4CAE4DBFC5BEB3374BF0C62E813F@NDMSMBX404.ndc.nasa.gov> <CAKLzrV_3gkfAdbB2up7qGHamEEC3MFbnbscCKKm0JWL=AtvOtQ@mail.gmail.com> <94CFB3711B4CAE4DBFC5BEB3374BF0C62E8396@NDMSMBX404.ndc.nasa.gov> <CAKLzrV_KDuzt_yY00=VAXUz7n_6cWxKG0xHTUd8kuamCsobNYw@mail.gmail.com>
In-Reply-To: <CAKLzrV_KDuzt_yY00=VAXUz7n_6cWxKG0xHTUd8kuamCsobNYw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [198.119.225.186]
Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C62ECA4FNDMSMBX404ndcnasa_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-14_04:, , signatures=0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dtn-users/bOLkjPgWAjvft8kfyhsmHmHVbAM>
Cc: "dtn-users@irtf.org" <dtn-users@irtf.org>
Subject: Re: [dtn-users] MSFC DTN2 Patches - 2016-02-29
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." <dtn-users.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-users>, <mailto:dtn-users-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn-users/>
List-Post: <mailto:dtn-users@irtf.org>
List-Help: <mailto:dtn-users-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2016 11:38:33 -0000

Hi Nik,
Thanks for the update and for catching the typo in the instructions. I have added a comment on the patch page and updated my original document.

A rule of thumb is that the LTPUDP retransmit interval should be the Round Trip Time plus an extra second or two to allow for processing time at both ends. You could probably tighten up the retransmit in the 20s latency test to 21 or 22 seconds. The default configuration is the set of values we are using with the ISS which has a RTT of about 700ms and  the transmitter would be canceling before the 20s RTT.

The LTP protocol errors are actually Cancel Ack segments that Wireshark is not handling properly. The uploaded dissectors can be used if you would like to update and build from the Wireshark source code which is pretty easy under Linux and a bit more involved for Windows. I could send you an updated Windows version if desired.
Best regards,
DZ


From: Nik Ansell [mailto:nikansell00@gmail.com]
Sent: Saturday, March 12, 2016 7:33 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Cc: dtn-users@irtf.org
Subject: Re: [dtn-users] MSFC DTN2 Patches - 2016-02-29

Hi David,

I found some time earlier to test the MSFC patches and LTPUDP on my Pi test bed, info below.

Installation / Patching:
Everything installed and patched fine using the instructions in the documentation.
There was one very small modification required to apply the arm patch:

patch –p 1 –i atomic-armv7.patch

should be:

patch –p 1 –i atomic_armv7.patch

General feedback:
- Configuration file is easy to understand and use
- I like the option to automatically rotate log files and also stop the db logs from filling up /tmp
- It seems to make good use of available RAM/CPU automatically using the default configuration
- Previously using DTN2/LTPlib, I needed to add a pause between bundle transmissions to achieve 100% delivery ratio, however I did not need to do that with any of my tests using LTPUDP

Experiments carried out:
I sent 100 x 63K bundles from tx to rx, under various simulated network conditions.
The default configuration parameters worked well for all simulations apart from those with long latency and high loss.

In one scenario I apply an 11% loss over a 20s latency, with the rate limited to 4Mbit. In this scenario, using the default config (below), I observed a lot of cancellation segments and also some LTP Protocol errors in the network captures.
It may have achieved 100% delivery ratio eventually, but I cut it short as it seemed to be taking too long.

set remote_rate 0
inact_intvl=30
retran_intvl=3
retran_retries=3
seg_size=16000
agg_size=64000

I then applied the following config changes:

set remote_rate 4000000
inact_intvl=60
retran_intvl=30
retran_retries=10
seg_size=1400
agg_size=65000

The above changes resulted in much faster delivery, a 100% delivery ratio, much fewer cancellation segments and no LTP protocol errors.

In the next wave of experiments I will be gathering more detailed info, but thought you might like this info now.

Kind Regards,
Nik

On Tue, Mar 1, 2016 at 10:08 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] <david.a.zoller@nasa.gov<mailto:david.a.zoller@nasa.gov>> wrote:
Hi Nik,
Thanks for giving it a spin and I’m glad to hear that it patched and built successfully from the tip. My past experience has been that if I upload a patch then that same night changes get applied that break it which is why I provided a link to download the proper revision just in case. I look forward to learning of your results in the Pi test-bed.
Best regards,
DZ

From: Nik Ansell [mailto:nikansell00@gmail.com<mailto:nikansell00@gmail.com>]
Sent: Tuesday, March 01, 2016 11:23 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Cc: dtn-users@irtf.org<mailto:dtn-users@irtf.org>
Subject: Re: [dtn-users] MSFC DTN2 Patches - 2016-02-29

Hi David,

This looks like a very interesting release.

I did some quick tests using my Ubuntu 15.10 VMs running on VMWare Fusion and thought I'd report back on progress so far.

I did a "make clean" of all previous oasys, dtn2 and (in my case) LTPlib installations, then downloaded, patched and installed dtn2 and oasys without any issues. I did deviate slightly from the build instructions as I used hg clone the latest builds:
hg clone http://hg.code.sf.net/p/dtn/DTN2 dtn2
hg clone http://hg.code.sf.net/p/dtn/oasys oasys
The following tests completed successfully without any issues. (There were no network simulations between the nodes): UDPCL (100 x 63k bundles), TCPDL (100 x 1M bundles), LTPUDP (100 x 63K bundles).
I used the default settings for all LTPUDP link parameters and it seemed very fast.
I will run the same tests through some network simulations on my Pi test-bed at some point soon and report back how I get on.

Kind Regards,
Nik

On Tue, Mar 1, 2016 at 6:34 AM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] <david.a.zoller@nasa.gov<mailto:david.a.zoller@nasa.gov>> wrote:
Greetings all,
I have uploaded a new set of DTN2 patches to the Sourceforge site:
https://sourceforge.net/p/dtn/patches/8/

These patches contain the modifications used in operations at Marshall Space Flight Center (MSFC) in support of the International Space Station and several recent additions that will be rolled into it in the future. MSFC hosts a DTN2 based gateway node on the ground that communicates via LTP over UDP with an onboard ION gateway node to provide DTN capabilities to payloads.
Included are:

•         Performance improvements

•         IPN Scheme support fixes and enhancements

•         LTP over UDP (LTPUDP) Convergence Layer

•         LTPUDP with LTP Authentication extensions

•         STCP Convergence Layer (ION innovation)

•         External Router enhancements and our EHS Router

•         Extended Class of Service support (only EHS Router makes use of it for routing decisions)

•         Aggregate Custody Signal support

•         Delay Tolerant Payload Conditioning

Also included in this release are updates to the DTN and LTP Wireshark dissectors. The updated dissectors are uploaded here for those that would like to build from the Wireshark source code. They will also be uploaded to wireshark.org<http://wireshark.org> soon.

Thanks for giving them a try and please let me know if you run into any issues,
DZ

David Zoller
COLSA Corporation
Marshall Space Flight Center


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