[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