[Sis-dtn] ION and in-order delivery

Keith Scott keithlscott at gmail.com
Thu Feb 15 19:59:24 UTC 2024


I ran a quick test with a 3-node ION network A-B-C where for the first
minute A is connected to B (via LTP) and B is connected to C (via TCP).
After that the topology repeats every two minutes; during the first minute
A is connected to B and during the second B is connected to C.  At t=540s
full connectivity (A-B and B-C) is restored for one minute.  There is no
artificially induced loss in this scenario.  The max aggregation size for
LTP was 100kbytes and the max aggregation time was 1s, e.g.:
*    a span 2 10 10 64000 100000 1 'udplso 10.44.3.2:1113
<http://10.44.3.2:1113> 1000000'*


[image: image.png]

I ran bping (will do a unidirectional test later).  The chart below shows
the received bping sequence number as a function of the order in which
bpings were received.

[image: image.png]

So yeah, it looks like ION will occasionally misorder bundles.  I think
that's not ideal, but I strongly believe that it is compliant with both the
spec and the intent of the service (bundle delivery) BP purports to
provide.  (And most bundles were in order, which is a feat considering that
between 60 and 540s the network is never end-to-end connected).

    --keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240215/70f735de/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 48080 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240215/70f735de/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 79905 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240215/70f735de/attachment-0003.png>


More information about the SIS-DTN mailing list