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

[Nik Ansell <[e-mail]>]

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] <[e-mail]> 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
>
>
>
>
>
> *From:* Nik Ansell [mailto:[e-mail]]
> *Sent:* Saturday, March 12, 2016 7:33 AM
>
>
> *To:* Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
> *Cc:* [e-mail]
> *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] <[e-mail]> 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:[e-mail]]
> *Sent:* Tuesday, March 01, 2016 11:23 AM
> *To:* Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
> *Cc:* [e-mail]
> *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] <[e-mail]> 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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-users
>
>
>
>
>
-- 

Kind Regards, Nik