<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=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:Webdings;
panose-1:5 3 1 2 1 5 9 6 7 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:880748343;
mso-list-type:hybrid;
mso-list-template-ids:-1540876688 1113649170 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1035665523;
mso-list-type:hybrid;
mso-list-template-ids:-306696652 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-GB">Switching email so I can post… My comments are inlined.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>
<br>
<b>Sent:</b> Tuesday, February 14, 2023 4:32 PM<br>
<b>To:</b> <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; 'Sanchez Net, Marc (US 332H)' <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>;
<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>; Jeremy Pierce Mayer <<a href="mailto:jpmayer@gmv.com">jpmayer@gmv.com</a>><br>
<b>Subject:</b> RE: [Sis-dtn] Notes from the NASA DTN F2F Meeting<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-GB">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Thanks for the detailed notes. I’ll try to add some comments / answers below<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Felix<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>sburleig.sb--- via SIS-DTN<br>
<b>Sent:</b> 13 February 2023 19:19<br>
<b>To:</b> 'Sanchez Net, Marc (US 332H)' <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>;
<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> Re: [Sis-dtn] Notes from the NASA DTN F2F Meeting<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">Marc, thanks for sending this on. A couple of thoughts in-line below.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Scott<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>Sanchez Net, Marc (US 332H) via SIS-DTN<br>
<b>Sent:</b> Monday, February 13, 2023 9:10 AM<br>
<b>To:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> [Sis-dtn] Notes from the NASA DTN F2F Meeting<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Hi All,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Here are the notes/questions for the SIS-DTN WG that I recorded at the NASA DTN face-to-face meeting.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>BPv7<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Leigh Torgerson pointed out that in the assumptions of the proposed RTP book there is the following statement: “<i>arbitrary bundle sizes—the multicast mechanism must not impose arbitrary limits that are less than the maximum
bundle size on the size of bundles.”</i>. The question then becomes whether having a bundle size (10 MB) in the spec restricts other specifications in any way.
<b>JPM: I don’t think it does; the intent of that comment was to prevent implementers from adding a “BP over multicast UDP” CLA with a 64k bundle limit and calling it bundle multicast.
</b><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Should we add a requirement (maybe a “should” rather than a “shall”) for CLAs to notify BP when transmission with that CLA is possible? This would provide minimal indication of whether transmission via a CLA is possible.<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo4">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">Ø<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Would this be a requirement that implementations would have to satisfy in order to be considered BPv7 compliant? Isn’t it strictly an implementation consideration? How would it contribute to interoperability?<br>
<b><span style="color:#70AD47">FF: What would be the exact semantics of ‘transmission is possible’? It may depend on the implementation and the specific CLA. It could mean, I am ready to take it into an internal queue, I actually have already established a
connection (for connection-oriented CLA), I take it and sent it but there is no guarantee, …<br>
Although it seems useful, it might be difficult to define it in a generic way and certainly implementations may have their own strategies (eg., we have a ready to send flag but also activation and connection states and can report when a bundle left the full
stack). So, I would currently treat it as an implementation matter.</span></b><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Compressed Bundle Reporting:<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:2.0in;text-indent:-.25in;mso-list:l1 level3 lfo2">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">§<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>How that CBR handle bundle fragmentation?<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo4">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">Ø<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>I would think that fragmentary bundles are simply bundles; they should be reported to the nodes that created them, that is, the nodes that generated the fragments.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><b><span style="color:#70AD47">FF: 1. We should avoid fragmentation as much as possible! For CREB I would specify that the block has to be replicated in *one* fragment and set the block processing control flags
to not replicate in each fragment. Thus, reporting can only happen once the complete bundle is re-assembled. Independent CREB can be inserted into the fragments themselves but these are completely independent from the CREBs in the unfragmented bundle (everything
else seem to get very ugly and comples).<o:p></o:p></span></b></p>
<p class="MsoListParagraph" style="margin-left:2.0in;text-indent:-.25in;mso-list:l1 level3 lfo2">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">§<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Why do we need CBR to define a new extension block with the FSN and flow sequence? PACE is using the service numbers in the transmit EID as the FSN, so they are able to uniquely identify flows and bundles within the flow without
having an extension block.<br>
<b><span style="color:#70AD47">FF: Maybe Flow ID is not a good term but we need something like this for flexibility. The Flow ID can be used to enable efficient reporting in specific network set-ups. E.g., if you would just use the service number and you would
have two destinations with different node numbers but same service number and would send alternating to both of them, the reports would not compress well (or you would need to add node numbers); you could have similar situations in case you would sent to different
next hops at the same time and want to have reception reporting from those. Service numbers are more an E2E thing.</span></b><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:2.0in;text-indent:-.25in;mso-list:l1 level3 lfo2">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">§<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Should we have a dedicated reporting mechanism for bundle expiration?<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:2.0in"><span style="color:#70AD47">FF: We have bundle deletion; this covers it (+ maybe next answer).<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:2.0in;text-indent:-.25in;mso-list:l1 level3 lfo2">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">§<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Can we make bundle reporting extensible so that missions have the ability to have their reporting reasons?<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:2.0in"><b><span style="color:#70AD47">FF: I guess we could simply add an optional text string to each report array. However, I would not standardize the content and it would be mission (or Agency specific). I would hope
that we could get some interoperable failure reporting via Network Management.<o:p></o:p></span></b></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><b><span style="color:#70AD47">LTPv2 (FF: <a id="OWAAM740D41DDDAE84D149B7E185CEC010CC5" href="mailto:jpmayer@gmv.com">
<span style="font-family:"Calibri",sans-serif;text-decoration:none">@Jeremy Pierce Mayer</span></a>: Please correct me if I am wrong).</span><o:p></o:p></b></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Will LTPv2 have a way to signal to the receiver the size of the LTP block? This would facilitate memory allocation at the receiver.<br>
<b><span style="color:#70AD47">FF: Yes, block size included in all segment.</span> JPM: Imagine TCP, we use almost exactly the same mechanism for offset & size reporting, since it facilitates linear memory allocation at the receiver.</b><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Will LTPv2 have a “hook” to get notified when the underlying link is down. This can be used to pause timers, etc.<br>
<b><span style="color:#70AD47">FF: Yes, similar to Rx/Tx Opportunity Windows in CFDP I would propose.</span> JPM: The external interface for LTPv2 is identical(ish) to that of LTP, so it’s possible.
</b><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Will LTPv2 have a way to aggregate report segments and report segment acknowledgements to reduce overhead?
<b>JPM: Yes, part of the notion of moving everything to extensions was to allow this srotf of behaviour.. There’s one new “hook” for uplink availability. If that’s used, then the receiver will aggregate the various acknowledgements until it can transit.
</b><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Will LTPv2 have a ping mechanism for the tx/rx engines to assess whether the link is running?<br>
<b><span style="color:#70AD47">FF: No, I think the Opportunity Window mechanism should be enough and that should be fed by ‘the environment’ (e.g if there is bitlock).</span></b><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Will LTPv2 have a concept of transmission deadline, which causes the tx to stop sending a block if it is not available at the destination by a certain moment? This could be used in conjunction with the bundle lifetime to cancel
LTPv2 sessions proactively.<br>
<b><span style="color:#70AD47">FF: No, but cancel can be requested. </span></b><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>APL has reported the following issues related to LTP that we way want to consider in LTPv2<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:2.0in;text-indent:-.25in;mso-list:l1 level3 lfo2">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">§<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Unspecified behavior that allows a memory leak and provide a method of denial-of-service attack. See
<a href="https://urldefense.com/v3/__https:/eur05.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fnasa*2FHDTN*2Fissues*2F19&data=05*7C01*7CFelix.Flentge*40esa.int*7C508617eb5c734acb263308db0deedf7c*7C9a5cacd02bef4dd7ac5c7ebe1f54f495*7C0*7C0*7C638119091828391986*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=jCGSrsoYTmFb0wmdoW3ZupiFnvtv3NQ8WyPUWl2IfR0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MvyJQugb!FzPGizF1--jqsL0mUohErAQiPkisMu0JuSQzn1819g_vrvbMm2B7ebiBR8LwUPc9DCx3VOlFqkLu1wrsZsiZOA$">
https://github.com/nasa/HDTN/issues/19</a><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:2.0in"><b><span style="color:#70AD47">FF: Yes, we should have session timeouts.</span> JPM: we have session timeouts based on time since last reception/acknowledgement. For unreliable sessions, we wait until that timer
expires and dump the data as-is. <o:p></o:p></b></p>
<p class="MsoListParagraph" style="margin-left:2.0in;text-indent:-.25in;mso-list:l1 level3 lfo2">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">§<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>LTP should guarantee that a reception report is sent when all data is received, not necessarily in response to a checkpoint. See
<a href="https://urldefense.com/v3/__https:/eur05.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fnasa*2FHDTN*2Fissues*2F23&data=05*7C01*7CFelix.Flentge*40esa.int*7C508617eb5c734acb263308db0deedf7c*7C9a5cacd02bef4dd7ac5c7ebe1f54f495*7C0*7C0*7C638119091828391986*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=tIX8*2B*2B4h1JdcDDFg5*2FP7Q8WPc6gHUgqIhXOVZifGjqg*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MvyJQugb!FzPGizF1--jqsL0mUohErAQiPkisMu0JuSQzn1819g_vrvbMm2B7ebiBR8LwUPc9DCx3VOlFqkLu1wo1XJF6eg$">
https://github.com/nasa/HDTN/issues/23</a> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:2.0in"><b><span style="color:#70AD47">FF: OK, I know we discussed session close behavior which should cover this (Jeremy to confirm).</span> JPM: Yes, the protocol supports an “ASYNC ACK” behaviour which can be sent if
a session closure notification is received and unacknowledged data exists. <span style="color:#70AD47">
<o:p></o:p></span></b></p>
<p class="MsoListParagraph" style="margin-left:2.0in;text-indent:-.25in;mso-list:l1 level3 lfo2">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">§<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>LTP should allow the transmit engine to delay sending data segments or reports long enough to receive out-of-order segments that would affect the retransmission behavior. See
<a href="https://urldefense.com/v3/__https:/eur05.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fnasa*2FHDTN*2Fissues*2F22&data=05*7C01*7CFelix.Flentge*40esa.int*7C508617eb5c734acb263308db0deedf7c*7C9a5cacd02bef4dd7ac5c7ebe1f54f495*7C0*7C0*7C638119091828391986*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=BVeStvbQqGJTIq7VPqCA4INB6GVh5z6K*2FlsTqBwwGUw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MvyJQugb!FzPGizF1--jqsL0mUohErAQiPkisMu0JuSQzn1819g_vrvbMm2B7ebiBR8LwUPc9DCx3VOlFqkLu1wrxilpfaQ$">
https://github.com/nasa/HDTN/issues/22</a> and <a href="https://urldefense.com/v3/__https:/eur05.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fnasa*2FHDTN*2Fissues*2F24&data=05*7C01*7CFelix.Flentge*40esa.int*7C508617eb5c734acb263308db0deedf7c*7C9a5cacd02bef4dd7ac5c7ebe1f54f495*7C0*7C0*7C638119091828391986*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=iZD*2FsgFPBgcSIAo206ZmG6GNJxKpwGiC0y12UQsr2r4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MvyJQugb!FzPGizF1--jqsL0mUohErAQiPkisMu0JuSQzn1819g_vrvbMm2B7ebiBR8LwUPc9DCx3VOlFqkLu1wrhjJEvJQ$">
https://github.com/nasa/HDTN/issues/24</a>. <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:2.0in"><b><span style="color:#70AD47">FF: Yeah, I see similar issues with CFDP (in particular, if we use different bands). Not sure whether we should have this as part of the standard or keep it as implementation matter
(like currently for CFDP). At least, we could put corresponding notes in the standard (it may not even be based on timeouts but also other mechanisms).</span> JPM: This is an implementation matter, honestly, but could be accomplished with a delayed transition
to the retransmission state. <o:p></o:p></b></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Others wishes from the community<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>DTN multicast<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Provide mechanisms for in-order delivery, lack of gaps, and lack of duplicates (similar to DTPC, but more modular, any possibly not end-to-end)<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo4">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">Ø<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Having more options on the DTPC feature menu has been an open item for many years. DTPC is just a prototocol that ought to be stackable like any other protocol. If the DTPC spec says that the layer above it can only be the end-to-end
user application, then the spec should be revised.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.75in"><b><span style="color:#70AD47">FF: We should also analyse what could be achieved with CBR Delivery Reports.<o:p></o:p></span></b></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Standard CCSDS format for contact plans<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><b><span style="color:#70AD47">FF: Can we build on existing standards like the simple schedule format?<o:p></o:p></span></b></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>DNS-like service to avoid having to manually rely on IANA/SANA registries.<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Stream of video/voice via DTN. KPLO used a non-standard version of BSSP and yet SIS-MIA might be working on RTP over DTN.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><b><span style="color:#70AD47">FF: I am not a fan of the ‘unreliable / reliable’ channel approach in BSSP. We are looking into doing something like this just using LTP red. Without errors, we should have the data
as fast as with green (no need to close the session before presenting it); if there are errors, we are protected by re-transmission (and would just store and not present). Out-of-order can be detected by bundle timestamps. One disadvantage may be that it is
tight to LTP (so, even for terrestrial use) but I would not see an issue with just using LTP/UDP. Bundle streaming over LTP should even be fine for multi-hop if we can define bundle priorities (another wish).</span><o:p></o:p></b></p>
<p class="MsoNormal"><b> JPM: Wearing my SIS-MIA hat, we are. However, we ensured that we don’t require BSSP, since I’m not a huge fan of it.
<o:p></o:p></b></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Thanks,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Marc Sanchez Net (332H)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;color:gray">Telecommunications Engineer</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;background:white"><span style="font-size:10.0pt;color:gray">Jet Propulsion Laboratory<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;background:white"><span style="font-size:10.0pt;color:gray">Cell:</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222"> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><a href="mailto:(617)%20953-7977">(617)
953-7977</a></span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0">
</span><span style="font-size:10.0pt;color:gray">|</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0">
</span><span style="font-size:10.0pt;color:gray">Email:</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222"> </span><span style="color:black"><a href="mailto:marc.sanchez.net@jpl.nasa.gov"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:blue">marc.sanchez.net@jpl.nasa.gov</span></a></span><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:#222222"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-GB">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>).
<br>
</span><span lang="EN-GB" style="font-size:18.0pt;font-family:Webdings;color:green">P
</span><span lang="EN-GB" style="font-size:7.0pt;font-family:"Arial",sans-serif;color:green">Please consider the environment before printing this e-mail.</span><span lang="EN-GB">
<o:p></o:p></span></p>
</div>
</body>
</html>