<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=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Gulim;
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:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Gulim";
panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
{font-family:"Malgun Gothic";
panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
{font-family:"\@Malgun Gothic";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Gulim",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:12.0pt;
font-family:"Gulim",sans-serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:3.0cm 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:34082034;
mso-list-type:hybrid;
mso-list-template-ids:1740000870 134807567 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Wow,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">I am impressed by the lively discussion (although I have expected some objections as I initially have not been a fan of the proposed changes myself).
I will try to address some of the concerns:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Purpose of the sequence number is the distinction of bundles with the same creation time<br>
For this distinction the creation time stamp has to be anyway qualified with the source node id. So, I don’t see an issue for the case where we use individual sequence numbers per source node ID. The case of using individual sequence numbers per destination
ID can be problematic this is why I have added the note. If this is not sufficient, we could also drop this option. I think it is not strictly required but would offer some flexibility (without, one would need to use different source node ID to distinguish
between bundle flows to different destination endpoints). Certainly, this option cannot be supported in case of the ‘0’ timestamp.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Gaps in the sequence numbers – yes, this can happen if you use the same source node id to
sent to different destination endpoint ids and there is a need to ‘design’ your data flows in a way that this is not happening (or you qualify by destination entity id). But it is affecting only the communication endpoints which you typically have some control
over (see Jonathan’s use cases).<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Guessing of sequence numbers – I don’t see how this makes the current situation worse; currently,
I could just guess e.g. DTN_Time.0 as next bundle creation time; obviously, I should protect the primary block by a BIB and it may be an advantage of the proposed approach that the ‘sequence number’ is automatically protected as well (ok, I could also target
a specific extension block in addition).<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Impact on existing implementations – I don’t see how this would impact existing implementations
forwarding bundles which make use of the new feature. Of course, source and destination node need to implement it to make use of it. For forwarding nodes, the creation timestamp would just look normal. However, I must admit that strictly speaking the use of
the sequence number in the indicated way is not RfC 9171 compliant as it may validate the requirement ‘The second item of the array, termed the creation timestamp's "sequence number", SHALL be the latest value (as of the time at which the transmission request
was received) of a monotonically increasing positive integer counter …’. However, for intermediate nodes this is irrelevant as re-ordering may have appeared anyway.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Proposed use of sequence number only useful for certain kind of applications – true, but
it seems to be an important use case (at least for space missions). I believe we must address specific use cases and need to accept that there are often no solutions which fit all possible uses.<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Having said all this, I also agree that the functionality may be implemented as part of an extension block. Actually, the current CBR proposal includes
such sequence numbers already (it does not include information about max length – we can discuss if this is useful) and it allows adding a CREB without actually requesting reports but just for the purpose of providing sequence numbers.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">However, what we should avoid by all means is that we end-up in the first programs making really use of DTN to rely on some ‘private hacks’ because
there is a big risks that these will stay there forever. So, no matter what we do (use of the sequence number in the primary header – signalled or managed, extension block), we should a) agree on something and b) have this at least halfway formally defined
somewhere.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Felix<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">
</span><span style="font-size:11.0pt;font-family:"Malgun Gothic",sans-serif">구철회</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <chkoo@kari.re.kr>
<br>
<b>Sent:</b> Thursday, August 10, 2023 6:05 AM<br>
<b>To:</b> 'Keith Scott' <keithlscott@gmail.com>; 'Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC <jonathan.j.wilmot@nasa.gov>; 'Gao, Jay L (JPL-332C)[JPL Employee]' <jay.l.gao@jpl.nasa.gov>; 'Carlo Caini' <carlo.caini@unibo.it>; Felix Flentge <Felix.Flentge@esa.int>;
'Dr. Keith L Scott via SIS-DTN' <sis-dtn@mailman.ccsds.org>; 'Singh, Somendra {Simon} (GSFC-5820)' <simon.singh@nasa.gov>; 'Birrane, Edward J. (GSFC-460.0)[Johns Hopkins University Applied Physics Lab]' <edward.j.birrane@nasa.gov><br>
<b>Cc:</b> sis-dtn@mailman.ccsds.org<br>
<b>Subject:</b> Re: [Sis-dtn] [EXTERNAL] R: Special use of sequence number in bundle creation time stamp<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p style="margin-left:36.0pt"><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">Dear All,<br>
<br>
I think the timestamp and the sequence number in a Primary block will work in a way of mutually exclusive rather than reciprocally cooperative.<br>
<br>
Sequence number certainly seems to serve well at a certain situation and application as Jonathan commented.<br>
However, IMHO, complexities can be expected when bundles are fragmented into small one with much multiple bundles, or aggregated into larger and fewer blocks. I think in that case, sequence number would be source of confusion or increasing overhead.<br>
<br>
Blame for any lost events during DTN transactions will be attributed to LTP, not BP. While I may have missed something in our discussions with Scott and Keith, I believe that BP is not designed to handle missing bundles; instead, it focuses on combining ragged
bundle fragments and reassembling them.<br>
<br>
Blame for any lost events during DTN transactions will be attributed to LTP, not BP. I can miss something here, however I think, BP is not designed to handle missing bundles; instead, it focuses on combining and reassembling ragged bundle during transaction.<br>
<br>
If a mechanism of sequence number in bundle is important for some reasons, someone wants to use an extension block, as suggested by Scott and Keith, because when bundle structure is highly compromised (severely fragmented or aggregated) intermediate node can
easily modify the sequence number according to situation to compensate the discontinuity of sequence number while sequence number in the Primary block can't be easily handled.<br>
<br>
I hope I didn't miss something.<br>
<br>
Best,<br>
Cheol<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 9 Aug 2023 14:42:22 -0700<br>
From: <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>><br>
To: "'Keith Scott'" <<a href="mailto:keithlscott@gmail.com">keithlscott@gmail.com</a>>, "'Wilmot, Jonathan J.<br>
\(GSFC-580.0\)[VANTAGE SYSTEMS INC]'" <<a href="mailto:jonathan.j.wilmot@nasa.gov">jonathan.j.wilmot@nasa.gov</a>><br>
Cc: "'Gao, Jay L \(JPL-332C\)[JPL Employee]'"<br>
<<a href="mailto:jay.l.gao@jpl.nasa.gov">jay.l.gao@jpl.nasa.gov</a>>, "'Carlo Caini'" <<a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>>,<br>
"'Felix Flentge'" <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>, "'Dr. Keith L Scott via<br>
SIS-DTN'" <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>>, "'Singh, Somendra {Simon}<br>
\(GSFC-5820\)'" <<a href="mailto:simon.singh@nasa.gov">simon.singh@nasa.gov</a>>, "'Birrane, Edward J.<br>
\(GSFC-460.0\)[Johns Hopkins University Applied Physics Lab]'"<br>
<<a href="mailto:edward.j.birrane@nasa.gov">edward.j.birrane@nasa.gov</a>><br>
Subject: Re: [Sis-dtn] [EXTERNAL] R: Special use of sequence number in<br>
bundle creation time stamp<br>
Message-ID: <<a href="mailto:03fb01d9cb0a$6320dd70$29629850$@gmail.com">03fb01d9cb0a$6320dd70$29629850$@gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I really think that</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">’</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">s best; simpler, more powerful, much easier to standardize.<br>
<br>
<br>
<br>
Scott<br>
<br>
<br>
<br>
From: Keith Scott <<a href="mailto:keithlscott@gmail.com">keithlscott@gmail.com</a>><br>
Sent: Wednesday, August 9, 2023 2:17 PM<br>
To: Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC] <<a href="mailto:jonathan.j.wilmot@nasa.gov">jonathan.j.wilmot@nasa.gov</a>><br>
Cc: Gao, Jay L (JPL-332C)[JPL Employee] <<a href="mailto:jay.l.gao@jpl.nasa.gov">jay.l.gao@jpl.nasa.gov</a>>;
<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; Carlo Caini <<a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>>; Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>; Dr. Keith L Scott via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>>;
Singh, Somendra {Simon} (GSFC-5820) <<a href="mailto:simon.singh@nasa.gov">simon.singh@nasa.gov</a>>; Birrane, Edward J. (GSFC-460.0)[Johns Hopkins University Applied Physics Lab] <<a href="mailto:edward.j.birrane@nasa.gov">edward.j.birrane@nasa.gov</a>><br>
Subject: Re: [Sis-dtn] [EXTERNAL] R: Special use of sequence number in bundle creation time stamp<br>
<br>
<br>
<br>
I'm all for the capability, but an extension block seems the way to go. I think either SIS-DTN, or even SOIS, could do this (and/or in conjunction with the IETF), and get the extension block registered with IANA for all to use. In the meantime, it seems like
it's something that's only used at the endpoints, so you could just use one of the private block types until the block is registered, then switch to the allocated type number.<br>
<br>
<br>
<br>
--keith<br>
<br>
<br>
<br>
<br>
<br>
On Wed, Aug 9, 2023 at 10:19</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Cambria Math",serif;mso-fareast-language:KO"> </span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">PM Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS
INC] via SIS-DTN <sis-dtn@mailman.ccsds.org <<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>> > wrote:<br>
<br>
All,<br>
<br>
<br>
<br>
The primary purpose of the proposed Source timestamp sequence number is to indicate if DTN lost anything between the source and destination. Not being able to tell a user of your network if you dropped any of their data is an issue with many in the science
community. What they put in the bundle or how they sequence it is not a DTN problem.<br>
<br>
<br>
<br>
We are trying to infuse DTN into a very conservative community. We should include mechanisms to determine where things may have gone wrong.<br>
<br>
<br>
<br>
Kind regards,<br>
<br>
<br>
<br>
Jonathan Wilmot<br>
<br>
<br>
<br>
CCSDS SOIS Area Director<br>
<br>
GSFC DTN Systems Engineer<br>
<br>
cFS Architecture<br>
<br>
Cell 301-751-2658<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
From: Gao, Jay L (US 332C) <jay.l.gao@jpl.nasa.gov <<a href="mailto:jay.l.gao@jpl.nasa.gov">mailto:jay.l.gao@jpl.nasa.gov</a>> ><br>
Sent: Wednesday, August 9, 2023 3:49 PM<br>
To: <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com">mailto:sburleig.sb@gmail.com</a>> ; 'Carlo Caini' <carlo.caini@unibo.it <<a href="mailto:carlo.caini@unibo.it">mailto:carlo.caini@unibo.it</a>> >; 'Felix
Flentge' <Felix.Flentge@esa.int <<a href="mailto:Felix.Flentge@esa.int">mailto:Felix.Flentge@esa.int</a>> >; 'Dr. Keith L Scott via SIS-DTN' <sis-dtn@mailman.ccsds.org <<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>> >; Wilmot,
Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC] <jonathan.j.wilmot@nasa.gov <<a href="mailto:jonathan.j.wilmot@nasa.gov">mailto:jonathan.j.wilmot@nasa.gov</a>> ><br>
Cc: Birrane, Edward J. (GSFC-460.0)[Johns Hopkins University Applied Physics Lab] <edward.j.birrane@nasa.gov <<a href="mailto:edward.j.birrane@nasa.gov">mailto:edward.j.birrane@nasa.gov</a>> >; Singh, Somendra {Simon} (GSFC-5820) <simon.singh@nasa.gov <<a href="mailto:simon.singh@nasa.gov">mailto:simon.singh@nasa.gov</a>>
><br>
Subject: Re: [Sis-dtn] [EXTERNAL] R: Special use of sequence number in bundle creation time stamp<br>
<br>
<br>
<br>
All,<br>
<br>
<br>
<br>
The proposed use of the sequence number seems to suggest it is design only for a kind of application that simply streams data.<br>
<br>
<br>
<br>
If you have an application that runs on top of BP that implements any kind of interactive messages as well as data. Then the sequence number is no longer a valid gap detector because not all bundles carries in-order data payload.<br>
<br>
<br>
<br>
I am not sure we try to standardize a new use of the sequence numbers to fit only a specific type of application that could be supported over BP.<br>
<br>
<br>
<br>
Jay<br>
<br>
<br>
<br>
Jay L. Gao<br>
_____________________________________________<br>
Communications and Architecture Research Section Jet Propulsion Laboratory<br>
4800 Oak Grove Drive<br>
M/S: 238-343<br>
Pasadena, CA 91109<br>
<a href="mailto:Jay.L.Gao@jpl.nasa.gov">Jay.L.Gao@jpl.nasa.gov</a> <<a href="mailto:Jay.L.Gao@jpl.nasa.gov">mailto:Jay.L.Gao@jpl.nasa.gov</a>><br>
TEL: 818-354-9528<br>
<br>
_____ <br>
<br>
From: SIS-DTN <sis-dtn-bounces@mailman.ccsds.org <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">mailto:sis-dtn-bounces@mailman.ccsds.org</a>> > on behalf of Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC] via SIS-DTN <sis-dtn@mailman.ccsds.org <<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>>
><br>
Sent: Wednesday, August 9, 2023 10:16 AM<br>
To: <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com">mailto:sburleig.sb@gmail.com</a>> <sburleig.sb@gmail.com <<a href="mailto:sburleig.sb@gmail.com">mailto:sburleig.sb@gmail.com</a>> >; 'Carlo Caini'
<carlo.caini@unibo.it <<a href="mailto:carlo.caini@unibo.it">mailto:carlo.caini@unibo.it</a>> >; 'Felix Flentge' <Felix.Flentge@esa.int <<a href="mailto:Felix.Flentge@esa.int">mailto:Felix.Flentge@esa.int</a>> >; 'Dr. Keith L Scott via SIS-DTN' <sis-dtn@mailman.ccsds.org
<<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>> ><br>
Cc: Birrane, Edward J. (GSFC-460.0)[Johns Hopkins University Applied Physics Lab] <edward.j.birrane@nasa.gov <<a href="mailto:edward.j.birrane@nasa.gov">mailto:edward.j.birrane@nasa.gov</a>> >; Singh, Somendra {Simon} (GSFC-5820) <simon.singh@nasa.gov <<a href="mailto:simon.singh@nasa.gov">mailto:simon.singh@nasa.gov</a>>
><br>
Subject: Re: [Sis-dtn] [EXTERNAL] R: Special use of sequence number in bundle creation time stamp<br>
<br>
<br>
<br>
Scott,<br>
<br>
<br>
<br>
There seems to be some pros and cons in play that we have not documented well. I will create some material for a future DTN WG (week or two) to discuss and include the security aspects as Vint commented.<br>
<br>
<br>
<br>
Just want to ensure we all are on the same page, and we base a forward path on documented analysis.<br>
<br>
<br>
<br>
<br>
<br>
Kind regards,<br>
<br>
<br>
<br>
Jonathan Wilmot<br>
<br>
<br>
<br>
CCSDS SOIS Area Director<br>
<br>
GSFC DTN Systems Engineer<br>
<br>
cFS Architecture<br>
<br>
Cell 301-751-2658<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
From: <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com">mailto:sburleig.sb@gmail.com</a>> <sburleig.sb@gmail.com <<a href="mailto:sburleig.sb@gmail.com">mailto:sburleig.sb@gmail.com</a>> ><br>
Sent: Wednesday, August 9, 2023 12:53 PM<br>
To: Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC] <jonathan.j.wilmot@nasa.gov <<a href="mailto:jonathan.j.wilmot@nasa.gov">mailto:jonathan.j.wilmot@nasa.gov</a>> >; 'Carlo Caini' <carlo.caini@unibo.it <<a href="mailto:carlo.caini@unibo.it">mailto:carlo.caini@unibo.it</a>>
>; 'Felix Flentge' <Felix.Flentge@esa.int <<a href="mailto:Felix.Flentge@esa.int">mailto:Felix.Flentge@esa.int</a>> >; 'Dr. Keith L Scott via SIS-DTN' <sis-dtn@mailman.ccsds.org <<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>>
><br>
Cc: Singh, Somendra {Simon} (GSFC-5820) <simon.singh@nasa.gov <<a href="mailto:simon.singh@nasa.gov">mailto:simon.singh@nasa.gov</a>> >; Birrane, Edward J. (GSFC-460.0)[Johns Hopkins University Applied Physics Lab] <edward.j.birrane@nasa.gov <<a href="mailto:edward.j.birrane@nasa.gov">mailto:edward.j.birrane@nasa.gov</a>>
><br>
Subject: RE: [EXTERNAL] R: [Sis-dtn] Special use of sequence number in bundle creation time stamp<br>
<br>
<br>
<br>
<br>
CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC.<br>
<br>
<br>
<br>
Jonathan, it sounds to me like the core issue here is whether to add all of this bundle labeling and sequence checking functionality to the existing requirements on primary block processing or to instead define it rigorously in an extension block and leave
primary block processing alone.<br>
<br>
<br>
<br>
If the additional processing requirements are imposed on primary block processing, then all deployments of all implementations of BPv7 are affected, including those for whom none of this functionality is needed in any way. They will of course not recognize
the new bundle processing control flags and will ignore them, but bundle uniqueness will routinely be lost unaccountably if (for example) bundle creation time is zero and bundle sequence numbers roll over at 2^16 per sequence number length flag values 01.<br>
<br>
<br>
<br>
It may be possible to constrain the required supplementary BPv7 specification in a way that shields existing BPv7 users from its impact. But I believe that will be a difficult specification to write and the cost of getting it wrong will be significant.<br>
<br>
<br>
<br>
I think it would be a much better use of SCaN</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">’</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">s DTN resources to draft a clean extension block specification.
At the data rates being contemplated here, I think the small increment in bundle size should be an acceptable price to pay for these capabilities.<br>
<br>
<br>
<br>
Scott<br>
<br>
<br>
<br>
From: Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC] <jonathan.j.wilmot@nasa.gov <<a href="mailto:jonathan.j.wilmot@nasa.gov">mailto:jonathan.j.wilmot@nasa.gov</a>> ><br>
Sent: Wednesday, August 9, 2023 9:20 AM<br>
To: Carlo Caini <carlo.caini@unibo.it <<a href="mailto:carlo.caini@unibo.it">mailto:carlo.caini@unibo.it</a>> >; 'Felix Flentge' <Felix.Flentge@esa.int <<a href="mailto:Felix.Flentge@esa.int">mailto:Felix.Flentge@esa.int</a>> >; 'Dr. Keith L Scott via SIS-DTN'
<sis-dtn@mailman.ccsds.org <<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>> >;
<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com">mailto:sburleig.sb@gmail.com</a>><br>
Cc: Singh, Somendra {Simon} (GSFC-5820) <simon.singh@nasa.gov <<a href="mailto:simon.singh@nasa.gov">mailto:simon.singh@nasa.gov</a>> >; Birrane, Edward J. (GSFC-460.0)[Johns Hopkins University Applied Physics Lab] <edward.j.birrane@nasa.gov <<a href="mailto:edward.j.birrane@nasa.gov">mailto:edward.j.birrane@nasa.gov</a>>
><br>
Subject: RE: [EXTERNAL] R: [Sis-dtn] Special use of sequence number in bundle creation time stamp<br>
<br>
<br>
<br>
Carlo,<br>
<br>
<br>
<br>
For the use cases that we are considering, any time a source node sends the same bundle to two or more destinations it uses Scott</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">’</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">s
proposed multi-destination protocol. If a node wants to send different bundles to different destinations, then they are different services. (org.node.service) In our flight system data model source
</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">“</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">.service</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">”</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">
is a discriminator for different bundle types/ADU. NASA.PACE.QuickLookScience is one service and NASA.PACE.BulkData is another.<br>
<br>
<br>
<br>
I can see an issue with the set of common </span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">“</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">service</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">”</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">
numbers, but maybe those are in the destination EID not the source.<br>
<br>
<br>
<br>
I agree we don</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">’</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">t want to break the original use case.<br>
<br>
<br>
<br>
Kind regards,<br>
<br>
<br>
<br>
Jonathan Wilmot<br>
<br>
<br>
<br>
CCSDS SOIS Area Director<br>
<br>
GSFC DTN Systems Engineer<br>
<br>
cFS Architecture<br>
<br>
Cell 301-751-2658<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
From: Carlo Caini <carlo.caini@unibo.it <<a href="mailto:carlo.caini@unibo.it">mailto:carlo.caini@unibo.it</a>> ><br>
Sent: Wednesday, August 9, 2023 11:50 AM<br>
To: 'Felix Flentge' <Felix.Flentge@esa.int <<a href="mailto:Felix.Flentge@esa.int">mailto:Felix.Flentge@esa.int</a>> >; 'Dr. Keith L Scott via SIS-DTN' <sis-dtn@mailman.ccsds.org <<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>>
>; <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com">mailto:sburleig.sb@gmail.com</a>><br>
Cc: Singh, Somendra {Simon} (GSFC-5820) <simon.singh@nasa.gov <<a href="mailto:simon.singh@nasa.gov">mailto:simon.singh@nasa.gov</a>> >; Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC] <jonathan.j.wilmot@nasa.gov <<a href="mailto:jonathan.j.wilmot@nasa.gov">mailto:jonathan.j.wilmot@nasa.gov</a>>
><br>
Subject: [EXTERNAL] R: [Sis-dtn] Special use of sequence number in bundle creation time stamp<br>
<br>
<br>
<br>
<br>
CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC.<br>
<br>
<br>
<br>
I fully agree with Scott on his comments and suggestions. More generally, I would avoid, whenever possible, the use of a parameter designed to a specific end, such as timestamp sequence number here, to different purposes. However, appealing it may be on a short
term, it is looking for troubles on the long term.<br>
<br>
Specifically, the timestamp sequence number is not the same as an hupothetical bundle sequence number, as pointed out by Scott. Moreover, if we assume that a source generates bundles to a give destination to specific rate, e.g. one bundle per second, the sequence
number increment between two consecutive bundles of this flow may be larger than one. For example, the first sequence number of the bundle flow could be 1 and the second 5. It is enough that the same source generates in the meantime other 3 bundles to different
destinations.<br>
<br>
Yours,<br>
<br>
Carlo<br>
<br>
<br>
<br>
_____ <br>
<br>
Da: SIS-DTN <sis-dtn-bounces@mailman.ccsds.org <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">mailto:sis-dtn-bounces@mailman.ccsds.org</a>> > per conto di sburleig.sb--- via SIS-DTN <sis-dtn@mailman.ccsds.org <<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>>
><br>
Inviato: mercoledì 9 agosto 2023 17:31<br>
A: 'Felix Flentge' <Felix.Flentge@esa.int <<a href="mailto:Felix.Flentge@esa.int">mailto:Felix.Flentge@esa.int</a>> >; 'Dr. Keith L Scott via SIS-DTN' <sis-dtn@mailman.ccsds.org <<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>>
><br>
Cc: 'Singh, Somendra {Simon} (GSFC-5820)' <simon.singh@nasa.gov <<a href="mailto:simon.singh@nasa.gov">mailto:simon.singh@nasa.gov</a>> >; 'Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC]' <jonathan.j.wilmot@nasa.gov <<a href="mailto:jonathan.j.wilmot@nasa.gov">mailto:jonathan.j.wilmot@nasa.gov</a>>
><br>
Oggetto: Re: [Sis-dtn] Special use of sequence number in bundle creation time stamp<br>
<br>
<br>
<br>
Hi, Felix. One thing to keep in mind is that the purpose of the sequence number in the bundle creation timestamp is to distinguish among bundles that have the same bundle creation time. This can occur when bundles are created at a very high rate or when bundle
creation time is zero due to the absence of an accurate clock.<br>
<br>
<br>
<br>
I would suggest that using bundle creation timestamp sequence numbers for other purposes makes it more difficult to use those numbers for their original purpose.<br>
<br>
<br>
<br>
If sequence numbering of bundles in these various ways is important, I think it would be better to encode those numbers (and the flags describing their significance) in an immutable extension block, i.e., an extension block that is one of the additional targets
of a block integrity block covering the primary block.<br>
<br>
<br>
<br>
Scott<br>
<br>
<br>
<br>
From: SIS-DTN <sis-dtn-bounces@mailman.ccsds.org <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">mailto:sis-dtn-bounces@mailman.ccsds.org</a>> > On Behalf Of Felix Flentge via SIS-DTN<br>
Sent: Wednesday, August 9, 2023 7:43 AM<br>
To: Dr. Keith L Scott via SIS-DTN <sis-dtn@mailman.ccsds.org <<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>> ><br>
Cc: Singh, Somendra {Simon} (GSFC-5820) <simon.singh@nasa.gov <<a href="mailto:simon.singh@nasa.gov">mailto:simon.singh@nasa.gov</a>> >; Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC] <jonathan.j.wilmot@nasa.gov <<a href="mailto:jonathan.j.wilmot@nasa.gov">mailto:jonathan.j.wilmot@nasa.gov</a>>
><br>
Subject: [Sis-dtn] Special use of sequence number in bundle creation time stamp<br>
<br>
<br>
<br>
Dear All,<br>
<br>
<br>
<br>
I think we have had some initial exchange on the use of the sequence number in the bundle creation timestamp some time ago. Meanwhile, we had a number of side meetings with Jonathan, Simon and others to further discuss the topic of
</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">‘</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">flows</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">’</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">,
compressed bundle reporting and network management.<br>
<br>
<br>
<br>
We have arrived at a point where we think that it makes sense to allow using the sequence number in the primary header for identifying gaps in sequences of bundles or to even allow for in-sequence delivery.<br>
<br>
<br>
<br>
The basic idea is that the sequence number does not get reset to zero but is incrementing by one until a specified maximum. Further we might use different, individual sequence numbers per source node ID or per destination endpoint ID. Such a behaviour might
be governed by policy or even indicated in the Primary Block</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">’</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO">s Processing Control Flags, like<br>
<br>
<br>
<br>
1. Use two bits to specify whether the creation timestamp sequence number is used in special way:<br>
<br>
<br>
<br>
* 00 </span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">–</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO"> single sequence number - no specific usage<br>
* 01 </span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">–</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO"> an individual sequence number is used per source node id<br>
* 10 </span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">–</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO"> an individual sequence number is used per destination endpoint id<br>
* 11 </span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">–</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO"> reserved (until we find a good usage; maybe individual sequence number per next hop)<br>
<br>
<br>
<br>
In case 10 with different destination endpoint IDs, the BPA has to guarantee that the same values can only appear with different bundle creation times!<br>
<br>
<br>
<br>
2. Use of two bits to indicate the maximum length of the sequence number (00 above) or individual sequence numbers (01 and 10 above):<br>
<br>
* 00 - sequence numbers are assigned somehow (reset to zero, randomly, ..)<br>
* 01 - increasing sequence number up to 2^16-1<br>
* 10 - increasing sequence number up to 2^32-1<br>
* 11 - increasing sequence number up to 2^64-1<br>
<br>
My main questions:<br>
<br>
1. Does it make sense to use flags in the primary header for this purpose or is it sufficient to document that sequence numbers can be used in that way and leave it up to policy to specify certain behaviours? I have a slight preference for using the BPCF
as it seems more formal and could ease interoperability (and the sequence number is in the primary header, so why not indicate it there).<br>
2. If we want to use BPCF, what is the way to specify this? Should we / do we need to go IETF or could CCSDS be sufficient (to start with)? Ideally we would use some of the reserved first 16 bits (e.g. Bit 7
</span><span lang="KO" style="font-size:10.0pt;mso-fareast-language:KO">–</span><span lang="EN-US" style="font-size:10.0pt;mso-fareast-language:KO"> 10)<br>
3. No matter whether we want to use BCPF or not, I think something should end up in the CCSDS BB as soon as possible. So, maybe there is a chance for a late RID (if it does not delay the overall publication process). We should start discussing (maybe tomorrow).<br>
<br>
<br>
<br>
Regards,<br>
<br>
Felix<br>
<br>
<br>
<br>
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify
the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (<a href="mailto:dpo@esa.int">dpo@esa.int</a> <<a href="mailto:dpo@esa.int">mailto:dpo@esa.int</a>>
).<br>
<br>
_______________________________________________<br>
SIS-DTN mailing list<br>
<a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a> <<a href="mailto:SIS-DTN@mailman.ccsds.org">mailto:SIS-DTN@mailman.ccsds.org</a>><br>
<a href="https://protect2.fireeye.com/v1/url?k=98396698-c7a20c90-983c1716-ac1f6bdccbcc-63b6194f7c9906e1&q=1&e=3d39dcda-65de-405e-9e3a-61fcbc61796c&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn">https://protect2.fireeye.com/v1/url?k=98396698-c7a20c90-983c1716-ac1f6bdccbcc-63b6194f7c9906e1&q=1&e=3d39dcda-65de-405e-9e3a-61fcbc61796c&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://protect2.fireeye.com/v1/url?k=fcd6ff0f-a34d9507-fcd38e81-ac1f6bdccbcc-f789aea30b0c4c85&q=1&e=3d39dcda-65de-405e-9e3a-61fcbc61796c&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20230809%2Ffb6930a0%2Fattachment.htm">https://protect2.fireeye.com/v1/url?k=fcd6ff0f-a34d9507-fcd38e81-ac1f6bdccbcc-f789aea30b0c4c85&q=1&e=3d39dcda-65de-405e-9e3a-61fcbc61796c&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20230809%2Ffb6930a0%2Fattachment.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
SIS-DTN mailing list<br>
<a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a><br>
<a href="https://protect2.fireeye.com/v1/url?k=2f74107c-70ef7a74-2f7161f2-ac1f6bdccbcc-5969faf9889f0ff0&q=1&e=3d39dcda-65de-405e-9e3a-61fcbc61796c&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn">https://protect2.fireeye.com/v1/url?k=2f74107c-70ef7a74-2f7161f2-ac1f6bdccbcc-5969faf9889f0ff0&q=1&e=3d39dcda-65de-405e-9e3a-61fcbc61796c&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 146, Issue 16<br>
****************************************</span><span lang="EN-US" style="mso-fareast-language:KO"><o:p></o:p></span></p>
</div>
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify
the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</body>
</html>