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

From: Nik Ansell <[email-masked]>
Date: Tue, 1 Mar 2016 21:22:42 +0400

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] <[email-masked]> 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 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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-users
>
>

---

From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Tue, 1 Mar 2016 18:08:08 +0000

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:[email-masked]]
Sent: Tuesday, March 01, 2016 11:23 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Cc: [email-masked]
Subject: Re: [dtn-users] MSFC DTN2 Patches - 2016-02-29

Hi David,

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] <[email-masked]<mailto:[email-masked]>> 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

_______________________________________________
dtn-users mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/dtn-users

---

From: Nik Ansell <[email-masked]>
Date: Sat, 12 Mar 2016 17:33:17 +0400

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] <[email-masked]> 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:[email-masked]]
> *Sent:* Tuesday, March 01, 2016 11:23 AM
> *To:* Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
> *Cc:* [email-masked]
> *Subject:* Re: [dtn-users] MSFC DTN2 Patches - 2016-02-29
>
>
>
> Hi David,
>
>
>

---

From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Mon, 14 Mar 2016 11:38:28 +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:[email-masked]]
Sent: Saturday, March 12, 2016 7:33 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Cc: [email-masked]
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:

should be:

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

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] <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 01, 2016 11:23 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-users] MSFC DTN2 Patches - 2016-02-29

Hi David,

Kind Regards,
Nik

David Zoller
COLSA Corporation

---

From: Nik Ansell <[email-masked]>
Date: Tue, 15 Mar 2016 03:59:10 +0000

Hi David,

Thanks for the additional info regarding the reTX interval. The latency I
apply is actually OWLT, so based on your comments the ideal setting in my
20s latency scenario will probably be 42-44s.

Ah, I wondered what the "LTP Protocol Error" was, as I have seen this a few
times previously.
I saw lots of generic UDP/IP fragments and presumed the updated dissectors
only provided info for these. I think adding the new dissectors will be
useful and I'll give it a go sometime over the next few days. I capture
using tshark on Linux, then analyse using Wireshark on Mac, which will make
compiling a little more interesting...

BTW, I did some more experiment runs last night and captured more detailed
info.LTPUDP seems to handle loss very well.
I observed only a very small increase in duration and tx/rx packets as I
ramped up the loss over a series of experiments.
On my test-bed using a high-loss lunar scenario, LTPUDP was able to achieve
over double the Goodput KB/s of the DTN2/LTPlib combination, this was using
the default configuration too, so potentially could be improved further.

Kind Regards,
Nik

On Mon, Mar 14, 2016 at 3:38 PM Zoller, David A. (MSFC-EO50)[HOSC SERVICES
CONTRACT] <[email-masked]> wrote:

> 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
>
>
>
>
>
> *Sent:* Saturday, March 12, 2016 7:33 AM
>
>
> 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] <[email-masked]> wrote:
>
> Hi Nik,
>
-- 

Kind Regards, Nik