<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ks_c_5601-1987">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:±¼¸²;
panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"\@±¼¸²";
panose-1:2 11 6 0 0 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:±¼¸²;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:±¼¸²;}
span.EmailStyle19
{mso-style-type:personal-compose;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:3.0cm 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="KO" link="blue" vlink="purple">
<div class="WordSection1">
<p><span lang="EN-US" style="font-size:10.0pt">Hi, Keith.<br>
<br>
I think that's the normal operational behavior in LTP and TCPCL even in the absence of packet loss during connection because there are discontinuity events between A-B and B-C.<br>
<br>
When a discontinuity event occurs during a transaction of a LTP session, the LTP session could possibly not be ended successfully and may pause to await the Report segment from the receiving entity. Upon reconnecting, the affected LTP session must resume interrupted
session processing (e.g., RS-DS retransmit-RS-RAS), while other LTP sessions can continue smoothly.<br>
<br>
Considering that an LTP session typically holds a bundle, in this scenario, out-of-order bundle delivery can occur even without packet loss. *NOTE* Discontinuity effectively simulates packet loss. TCPCL just acts like LTPCL. I think you could check it in a
wireshark captured packet by seeing a Report segment.<br>
<br>
In your scenario, discontinuity events occurred 8 times (4 times for A-B, 4 times for B-C). I can observe 8 times of bundle arrival fluctuation events in the figure.<br>
<br>
Maybe there could be other issues originating this phenomenon, but above is my thought. HTH.<br>
<br>
Best,<br>
Cheol<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 15 Feb 2024 20:59:24 +0100<br>
From: Keith Scott <keithlscott@gmail.com><br>
To: sis-dtn@mailman.ccsds.org<br>
Subject: [Sis-dtn] ION and in-order delivery<br>
Message-ID:<br>
<CAHdkBBmXz6sQrY50p6Ob3ThO005132Ph9KZOiSgW+=C-8J5Y0w@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
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).<br>
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.:<br>
* a span 2 10 10 64000 100000 1 'udplso 10.44.3.2:1113<br>
<<a href="https://protect2.fireeye.com/v1/url?k=ce37f0ae-91ac9aa6-ce328120-ac1f6bdccbcc-797d3695053eff4c&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2F10.44.3.2%3A1113%2F">https://protect2.fireeye.com/v1/url?k=ce37f0ae-91ac9aa6-ce328120-ac1f6bdccbcc-797d3695053eff4c&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2F10.44.3.2%3A1113%2F</a>>
1000000'*<br>
<br>
<br>
[image: image.png]<br>
<br>
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.<br>
<br>
[image: image.png]<br>
<br>
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).<br>
<br>
--keith<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://protect2.fireeye.com/v1/url?k=f133e8de-aea882d6-f1369950-ac1f6bdccbcc-aa39b8d587d0d7dd&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20240215%2F70f735de%2Fattachment.htm">https://protect2.fireeye.com/v1/url?k=f133e8de-aea882d6-f1369950-ac1f6bdccbcc-aa39b8d587d0d7dd&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20240215%2F70f735de%2Fattachment.htm</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: image.png<br>
Type: image/png<br>
Size: 48080 bytes<br>
Desc: not available<br>
URL: <<a href="https://protect2.fireeye.com/v1/url?k=5a238e22-05b8e42a-5a26ffac-ac1f6bdccbcc-ee06a4af1da35812&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20240215%2F70f735de%2Fattachment.png">https://protect2.fireeye.com/v1/url?k=5a238e22-05b8e42a-5a26ffac-ac1f6bdccbcc-ee06a4af1da35812&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20240215%2F70f735de%2Fattachment.png</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: image.png<br>
Type: image/png<br>
Size: 79905 bytes<br>
Desc: not available<br>
URL: <<a href="https://protect2.fireeye.com/v1/url?k=c83cc342-97a7a94a-c839b2cc-ac1f6bdccbcc-17dd8d887bfde0f4&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20240215%2F70f735de%2Fattachment-0001.png">https://protect2.fireeye.com/v1/url?k=c83cc342-97a7a94a-c839b2cc-ac1f6bdccbcc-17dd8d887bfde0f4&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20240215%2F70f735de%2Fattachment-0001.png</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
SIS-DTN mailing list<br>
SIS-DTN@mailman.ccsds.org<br>
<a href="https://protect2.fireeye.com/v1/url?k=ac25f3ab-f3be99a3-ac208225-ac1f6bdccbcc-2472f80e5d5dbacd&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn">https://protect2.fireeye.com/v1/url?k=ac25f3ab-f3be99a3-ac208225-ac1f6bdccbcc-2472f80e5d5dbacd&q=1&e=3ae2454f-c7be-47fb-9265-5a883d8026a6&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn</a><br>
<br>
<br>
------------------------------<br>
<br>
End of SIS-DTN Digest, Vol 152, Issue 3<br>
***************************************</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
</body>
</html>