<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)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:12.0pt;
font-family:"Times New Roman",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:131679668;
mso-list-type:hybrid;
mso-list-template-ids:395637450 -1321410572 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
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:;
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:;
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:;
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:;
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:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:144208569;
mso-list-template-ids:-894024812;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:1172187444;
mso-list-template-ids:-1135553632;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level3
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level4
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level6
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level7
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level9
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
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=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'>I believe Scott’s analysis below succinctly articulates the difference between the two approaches and I agree that they should be kept separate. For my intended use cases, approach 1 (BIBE/BPARQ?) is what I would need to use. I’ll be happy to contribute to this approach and prototype.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Best<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>mehmet<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-family:"Calibri",sans-serif;color:black'>From: </span></b><span style='font-family:"Calibri",sans-serif;color:black'>SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> on behalf of "sburleig.sb--- via SIS-DTN" <sis-dtn@mailman.ccsds.org><br><b>Reply-To: </b><sburleig.sb@gmail.com><br><b>Date: </b>Friday, March 25, 2022 at 10:07 AM<br><b>To: </b>"'Sipos, Brian J.'" <Brian.Sipos@jhuapl.edu>, <Felix.Flentge@esa.int>, <dtn@ietf.org>, <sis-dtn@mailman.ccsds.org><br><b>Subject: </b>Re: [Sis-dtn] [dtn] [EXT] Re: Bundle custody transfer and reliable CLs<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Hi, Brian. Actually I think Felix’s analysis is pretty much spot-on. We really are talking about two different behaviors, which respond to two different sets of requirements.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The “custody transfer” procedures that I proposed in the BIBE draft are very specifically aimed at defining a reliable convergence-layer adapter that happens to use BP as its underlying convergence-layer protocol. There is a requirement for this capability: Keith Scott has often pointed out that there are scenarios in which reliable transmission between nodes is required but no reliable transmission protocol is available, e.g., when the sender’s communication capability is temporarily unidirectional. These are not hypothetical; MITRE’s customers must at times operate in such environments, and some space flight missions and other IoT systems could be similarly constrained. Under these conditions, the mechanism by which NAKs and ACKs are returned to the sender may function at a later time and/or be unrelated to the mechanism by which the sender transmitted the data. There might be better standardized protocols than BP for supporting these kinds of scenarios, but none leap to mind.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The ”custody transfer” procedures for which Felix proposes requirements are different. Since there is no need for timeout-triggered retransmission (retransmission is instead triggered by command or by negative acknowledgment), there is no need for accurate estimation of the round-trip time; therefore there is no need for the sender to know which node will issue the responding (positive) custody acknowledgment, exactly as required. I think of it as a resource management system rather than an ARQ system. A mechanism very much like BPv6 custody transfer will work fine.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I would propose that we term the latter procedures “custody transfer” and proceed to standardize them, while renaming the former something like “BPARQ”.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I don’t think there’s any need to impose any additional requirements on CL protocols, TCPCL or other, to satisfy the requirements. These are separate things. Let’s keep them separate and support them separately and clearly.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Scott<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><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><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> dtn <dtn-bounces@ietf.org> <b>On Behalf Of </b>Sipos, Brian J.<br><b>Sent:</b> Friday, March 25, 2022 4:46 AM<br><b>To:</b> Felix.Flentge@esa.int; dtn@ietf.org; sis-dtn@mailman.ccsds.org<br><b>Subject:</b> Re: [dtn] [EXT] Re: Bundle custody transfer and reliable CLs<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Felix,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Thank you for this feedback. There is a misinterpretation of what I (and maybe also Scott via BIBE) am suggesting about what happens during reliable reception. The idea isn’t that two different things happen, it’s that it’s the same BP agent custody acceptance criteria just that some CLs can provide intrinsic signaling of that acceptance while other CLs have no means to signal that specific feedback.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>While IETF doesn’t (normally) specify internal APIs, the CCSDS documents do and this can help here. Currently 734.2-B-1 does not actually define a BPA—CLA interface API, but it seems like the rough interface looks like:<o:p></o:p></span></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='color:#1F497D;margin-left:0in;mso-list:l0 level1 lfo3'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Send.request to the CLA<o:p></o:p></span></li><li class=MsoListParagraph style='color:#1F497D;margin-left:0in;mso-list:l0 level1 lfo3'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Send.response from the CLA<o:p></o:p></span></li><li class=MsoListParagraph style='color:#1F497D;margin-left:0in;mso-list:l0 level1 lfo3'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Receive.indication from the CLA<o:p></o:p></span></li></ul><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>What I am suggesting is that the Receive side could be changed from the asynchronous “I just got this transfer. Here it is, thanks.” to a synchronous “I just got this transfer. Will you accept it?” similar to:<o:p></o:p></span></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='color:#1F497D;margin-left:0in;mso-list:l0 level1 lfo3'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Receive.indication from the CLA<o:p></o:p></span></li><li class=MsoListParagraph style='color:#1F497D;margin-left:0in;mso-list:l0 level1 lfo3'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Receive.response to the CLA<o:p></o:p></span></li></ul><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>The TCPCL and LTPCL already provide the negative response over-the-wire (TCPCL reception can send XFER_REFUSE at any time before the END ACK, and LTPCL can send “Cancel from the block receiver” similarly) there is currently just no specific formal definition of what, from the BPA side, the positive acknowledgement is required to mean. For example “If the transfer is not canceled by the receiver and the final ACK is sent, the transferred bundle SHALL be completely and positively received within the BP agent’s forwarding or delivery queue.” <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>As Scott mentioned earlier, custody isn’t an anthropomorphization of the BPA, it’s a specific behavior, and it seems like by acknowledging that the bundle was received into the queue for delivery/forwarding the agent has “accepted” it. If the intent of custody is that it’s a more restricted/reserved resource pool (e.g. my forwarding queue is size X but of that only Y (with Y<X) is reserved for bundles over which I have custody) then that’s a local agent management issue, not an over-the-wire signaling issue. The BPA has still positively accepted the bundle and some CLAs can communicate this back to the sending agent synchronously.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Thanks for any further clarification,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Brian S.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> dtn <<a href="mailto:dtn-bounces@ietf.org">dtn-bounces@ietf.org</a>> <b>On Behalf Of </b><a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a><br><b>Sent:</b> Friday, March 25, 2022 6:11 AM<br><b>To:</b> <a href="mailto:dtn@ietf.org">dtn@ietf.org</a>; <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br><b>Subject:</b> [EXT] Re: [dtn] Bundle custody transfer and reliable CLs<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>(cross-posting to CCSDS DTN mailinglist as it seems to be of high relevance to the on-going discussions in the DTN WG).</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>I think we clearly need to distinguish between (at least) two different types of 'custody transfer' according to where it is implemented:</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>(a) BPv6 - like custody transfer which has been a function of the BPA / AA Administrative element</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>(b) BIBE-like custody transfer which is implemented in the CLA</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>The main differences I see are:</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>- In (a) the decision whether to take custody or not can be taken on more available information, eg timely availability of a route toward a next hop, available storage, policies (eg, checking Bundle Integrity Blocks), ... In (b), the CLA may accept custody and the BPA would just decide to discard the bundle for whatever reason (of course, there could be interfaces to make such information available to the CLA but this would somehow 'blur' the architecture.</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>- In (b), the node to take custody needs to be explicitly addressed (it's the BIBE destination) while in (a) any node could take custody.</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Requirements regarding custody transfer I would see for space missions are:</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>1) Assertion of a high probability that a bundle will reach its destination once a hop has accepted custody (which would allow the forwarding node to release storage).</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>The meaning of 'high probability' does really depend on the mission data return requirements. While for some missions it may be close to 100%, other mission may be ready to accept higher data loss in favour of timeliness (eg, certain types of Earth Observation missions).</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>2) Forwarding bundles without knowing which node will take custody.</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>In particular with high data rates and optical direct-to-Earth downlinks we may have situations where the spacecraft may not know the actual next hop is sending to but may want to get a confirmation that the bundle has been received on ground. With high-data rates, bundles might already be prepared and encoded in frames and be sitting in some buffers within optical terminal because the data rates on the on-board buses would not allow to generate and send in real time. Use of optical direct-to-Earth links may be opportunistic and we may not know in advance how much data will go down. So, addressing a specific DTN node in a ground station becomes unpractical (if DTN nodes in ground station would share the same anycast eID it may be possible but BIBE is currently limited to singleton endpoints).</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>It is clear that these requirements cannot be solved by protocol specification as Scott pointed out below but will also require that implementing nodes conform to certain behaviours. This will not be possible for an open, Internet-like DTN network (where we can only try to take defensive actions). For space missions I would still expect limited, tightly-controlled network for some time to come (maybe becoming 'trusted zones' in a larger network). For these, we should have protocol mechanism which can support above requirements (while being aware that some of these mechanisms will not work in a fully open DTN).</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Finally, 'custody transfer' seems to be always related to timer-base re-transmission. However, I think there are other options as well, like:</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>- command-based re-transmission: an explicit command is sent to a DTN node to re-transmit all bundles for which custody has been requested but no signal has been received</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>- sequence-based re-transmission: in some situations it might be possible (using additional extension blocks) to detect which bundles have not been received by inspecting the received custody signals and re-send the ones for which no custody signal have been received</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Again, this would likely not work in an open DTN but only in (very) limited, controlled networks. But this doesn't make such mechanisms less useful (although I would prefer to have something more generic if possible) and we should address it in the IETF (if there is general interest) and/or the CCSDS (if it is for near-to-medium term space mission use cases only). </span><br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Regarding reliable CLs: I currently don't see the point of a reliable CL taking custody because it would be (only) type (b) custody which is basically just a confirmation that the bundle has been received and this can already be assumed by the fact that it is a reliable CL.</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Regards,</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Felix</span> <br><br><br><br><br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>From: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"William Ivancic" <</span><a href="mailto:ivancic@syzygyengineering.com"><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>ivancic@syzygyengineering.com</span></a><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>To: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'><</span><a href="mailto:sburleig.sb@gmail.com"><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>sburleig.sb@gmail.com</span></a><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>>, "'Sipos, Brian J.'" <</span><a href="mailto:Brian.Sipos@jhuapl.edu"><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>Brian.Sipos@jhuapl.edu</span></a><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>>, <</span><a href="mailto:dtn@ietf.org"><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>dtn@ietf.org</span></a><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Date: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>25/03/2022 01:16</span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Subject: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>Re: [dtn] Bundle custody transfer and reliable CLs</span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Sent by: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"dtn" <</span><a href="mailto:dtn-bounces@ietf.org"><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>dtn-bounces@ietf.org</span></a><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>></span> <o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=0 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><p style='margin:0in'>“Custody” is a bundle level concept, not transport. Way back when, “Custody” meant that the node taking “Custody” would try it’s best to ensure the bundle was forwarded either to another “Custody” node or to eventually the destination node. The idea, as I recall, was this would allow the original bundle source to clear its memory of that bundle. <o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>For space operations, I don’t think the operations people were ever comfortable with this concept.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>//Will<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'><b>From: </b>dtn <<a href="mailto:dtn-bounces@ietf.org">dtn-bounces@ietf.org</a>> on behalf of <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>><b><br>Date: </b>Thursday, March 24, 2022 at 6:04 PM<b><br>To: </b>"'Sipos, Brian J.'" <<a href="mailto:Brian.Sipos@jhuapl.edu">Brian.Sipos@jhuapl.edu</a>>, <<a href="mailto:dtn@ietf.org">dtn@ietf.org</a>><b><br>Subject: </b>Re: [dtn] Bundle custody transfer and reliable CLs<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Brian, there was some further discussion of custody transfer in this morning’s meeting of the CCSDS Space Internetworking Systems DTN Working Group as well. A couple of notes:<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>It’s important to remember that we are talking about state machines here, not people. Anthropomorphizing the DTN architecture is tempting but treacherous. BP nodes have no will; they cannot take responsibility; they cannot promise to do anything. All they do is behave, ideally in a fashion that conforms to the protocol specifications to which they were allegedly developed.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Also, any given node may have been designed with malign intent or implemented with errors. Stating a requirement in a protocol specification does not ensure its satisfaction; what it does is give a node’s human (maybe eventually AI) network operators a means of assessing the behavior of another node and possibly taking some sort of out-of-band administrative action in defense against that behavior as needed.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>You’re right, the term “custody” is not defined for BPv7. It is still widely used to refer to some behavior that future users of DTN for space flight operations state will be very important, but for which the requirements are not yet clearly established. It is starting to look like the BP-based ARQ in the most recent BIBE draft, while needed (I think), is not exactly what people mean by “custody transfer.” So it may become useful to define an additional BP extension (TBD) that we label with this term.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>TCPCL enhancements along the lines you propose here may very well be valuable; I don’t know, need to think about them some more. But I would say the BPv7 specification already contains language (in 5.4, Step 5 and the following two paragraphs, and in 7.2, second bullet point) constraining the sort of convergence-layer reliability that I think is indispensable, regardless of what we call it.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Scott<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'><b>From:</b> dtn <<a href="mailto:dtn-bounces@ietf.org">dtn-bounces@ietf.org</a>> <b>On Behalf Of </b>Sipos, Brian J.<b><br>Sent:</b> Thursday, March 24, 2022 1:39 PM<b><br>To:</b> <a href="mailto:dtn@ietf.org">dtn@ietf.org</a><b><br>Subject:</b> [dtn] Bundle custody transfer and reliable CLs<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>All,<o:p></o:p></p><p style='margin:0in'>There was some brief discussion during the BIBE presentation about custody transfer concept and CL mechanisms. This is also an open topic in the CCSDS drafting of BPv7 standardization. I would like to add some additional points for thought in how a reliable convergence layer can relate to the concept of custody transfer for agents on either side of the transfer.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Overall, there still seems to be some vagueness about what “custody” means (in the sense of a service level agreement) between peers exchanging bundles. My understanding is that “custody” means the custodial node is willing to make some kind of effort to keep the bundle moving toward its destination until the bundle lifetime expires.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>The current RFC 9174 document is silent about what exactly an XFER_ACK segment with END flag set (an END ACK) means from the perspective of the BP agent and what is guaranteed about the transferred bundle. This provides an opportunity for a follow-on clarification of END ACK semantics for the TCPCL entity and for the BP agent. Two potential ways of making the behavior more well-defined:<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>1. A network-specific profile of TCPCL could simply mandate that any node accepts custody by sending an END ACK. This would simply be a condition of conformance to the profile in a controlled network. This could be done immediately without any change elsewhere, but needs out-of-band coordination.<o:p></o:p></p><p style='margin:0in'>2. One or more (quite simple) extension types can be defined for TCPCL to allow an entity to expose its END ACK behavior (RX) and desire (TX):<o:p></o:p></p><p style='margin:0in'>a. A session extension can allow an entity to assert what its sent END ACK means for received transfers. The value in this is to allow the peer entity to adjust behavior depending on the capability (e.g. use BIBE if the next-hop doesn’t take END ACK custody), including possibly refusing to establish a session with (or refusing to send bundles to) a peer that does not take custody via END ACK.<o:p></o:p></p><p style='margin:0in'>b. Additionally, a transfer extension can allow a sender to assert its custody desire on a per-bundle basis (signaling that some bundles need custody transfer while others do not). The value in this is to allow the receiving entity to optimize its behavior based on whether or not custody is needed for a bundle; though I don’t know how much benefit this would be.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>The possible values enumerated by the session extension would be something like:<o:p></o:p></p><p style='margin:0in'><span style='font-family:Symbol'>· </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span>Custody is not taken at END ACK<o:p></o:p></p><p style='margin:0in'><span style='font-family:Symbol'>· </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span>Custody is taken at END ACK<o:p></o:p></p><p style='margin:0in'>And if there is a transfer extension defined, a the session extension could indicate:<o:p></o:p></p><p style='margin:0in'><span style='font-family:Symbol'>· </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span>Reception behavior is unconditional<o:p></o:p></p><p style='margin:0in'><span style='font-family:Symbol'>· </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span> <span style='font-family:Symbol'> </span>Reception behavior can be overridden per-transfer based on the sender’s desire<o:p></o:p></p><p style='margin:0in'>These changes would all be backward compatible in the sense that a default policy would be in place in the absence of this extension item. And all of this is an independent mechanism from BIBE for a custody transfer to take place; both this mechanism and BIBE have their own costs, benefits, and side effects of such a transfer.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Trying to make almost-there-already capabilities more obvious,<o:p></o:p></p><p style='margin:0in'>Brian S.<o:p></o:p></p><p style='margin:0in'>_______________________________________________ dtn mailing list <a href="mailto:dtn@ietf.org">dtn@ietf.org</a> <a href="https://www.ietf.org/mailman/listinfo/dtn">https://www.ietf.org/mailman/listinfo/dtn</a> <tt><span style='font-size:10.0pt'>_______________________________________________</span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>dtn mailing list</tt><br></span><a href="mailto:dtn@ietf.org"><span style='font-size:10.0pt;font-family:"Courier New"'>dtn@ietf.org</span></a><span style='font-size:10.0pt;font-family:"Courier New"'><br></span><a href="https://www.ietf.org/mailman/listinfo/dtn"><tt><span style='font-size:10.0pt'>https://www.ietf.org/mailman/listinfo/dtn</span></tt></a><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>_______________________________________________ SIS-DTN mailing list SIS-DTN@mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn <o:p></o:p></span></p></div></body></html>