<span style=" font-size:10pt;font-family:sans-serif">I think we should

distinguish between the signalling, the re-transmission and (maybe) custody:</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">1) CBR (or whatever

better name we can come up with)</span>

<br><span style=" font-size:10pt;font-family:sans-serif">If a node implement

CBR, it just means that it is able to send compressed status reports if

requested by a specific extension block. This is about defining an extension

block and administrative records.</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">2) CBR-R (CBR-based

re-transmission)</span>

<br><span style=" font-size:10pt;font-family:sans-serif">It would mean

the a node receiving CBR status reports implements a mechanism to re-send

bundles for which it did not receive a reception report (this is basically

Keith's 'SHALL NOT release resources part'). This is about defining node

behaviour and there could be different variants (sequence-based, timer-based,

command-based, ...)</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">3) CBR-C (CBR-based

Custody Transfer)</span>

<br><span style=" font-size:10pt;font-family:sans-serif">Not sure, whether

we would require this. The difference to 2) could be that a receiving node

would also be able to send a custody signal (if requested in the extension

block) in addition to the reception signal. The meaning of the custody

signal could be beyond the reception signal, eg:</span>

<br><span style=" font-size:10pt;font-family:sans-serif">- the bundle is

sitting safely in bundle storage</span>

<br><span style=" font-size:10pt;font-family:sans-serif">- the receiving

node is implementing CBR-R and will add/replace the CBR extension block

by a new one where it will request custody for the next hop</span>

<br><span style=" font-size:10pt;font-family:sans-serif">- based on local

information, the receiving node will be able to forward the bundle towards

its destination (there is/will be a contact to a next hop)</span>

<br><span style=" font-size:10pt;font-family:sans-serif">- ...</span>

<br>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">Regards,</span>

<br><span style=" font-size:10pt;font-family:sans-serif">Felix</span>

<br>

<br>

<br>

<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:

       </span><span style=" font-size:9pt;font-family:sans-serif"><sburleig.sb@gmail.com></span>

<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:

<span style=" font-size:9pt;font-family:sans-serif">"'Dr.

Keith L Scott'" <kscott@mitre.org>, <Felix.Flentge@esa.int></span>

<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:

       </span><span style=" font-size:9pt;font-family:sans-serif">"'Sipos,

Brian J.'" <Brian.Sipos@jhuapl.edu>, <dtn@ietf.org>, "'dtn'"

<dtn-bounces@ietf.org>, "'Sanchez Net, Marc\(JPL-332H\)[JPL

Employee]'" <marc.sanchez.net@jpl.nasa.gov>, "'Chaoua,

Rachid\(GSFC-4500\)'" <rachid.chaoua@nasa.gov></span>

<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:

       </span><span style=" font-size:9pt;font-family:sans-serif">31/03/2022

19:05</span>

<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:

       </span><span style=" font-size:9pt;font-family:sans-serif">RE:

[dtn] [EXTERNAL] Re: [Sis-dtn] [EXT] Re: Bundle custody transfer and reliable

CLs</span>

<br>

<hr noshade>

<br>

<br>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Fine

with me.  I wanted not to over-constrain the idea at this early stage

of definition, but if that sort of mandate is okay with everybody I am

for it.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Scott</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>

Dr. Keith L Scott <kscott@mitre.org> <b><br>

Sent:</b> Thursday, March 31, 2022 9:25 AM<b><br>

To:</b> sburleig.sb@gmail.com; Felix.Flentge@esa.int<b><br>

Cc:</b> 'Sipos, Brian J.' <Brian.Sipos@jhuapl.edu>; dtn@ietf.org;

'dtn' <dtn-bounces@ietf.org>; 'Sanchez Net, Marc(JPL-332H)[JPL Employee]'

<marc.sanchez.net@jpl.nasa.gov>; 'Chaoua, Rachid(GSFC-4500)' <rachid.chaoua@nasa.gov><b><br>

Subject:</b> Re: [dtn] [EXTERNAL] Re: [Sis-dtn] [EXT] Re: Bundle custody

transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">I

think I agree, with the possible extension that if #3 is postulating some

sort of custody signal the “If…does not release resources” can be strengthened

a bit if we so choose.  That is, if we define how the extra signaling

works, we have the opportunity to define / constrain behaviors of implementations

that implement that signaling.  So if we define some sort of BP-layer

signaling for ‘custody’ (using compressed bundle reports or otherwise),

we might say that nodes implementing that signaling SHALL NOT release resources

until (receipt of a positive custody signal OR  appropriate rules

to address the case that no other node in the system implements the signaling,

etc.).</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> 

        --keith</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"><b>From:

</b>"</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt;font-family:Calibri">"

<</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>

Date: </b>Thursday, March 31, 2022 at 11:19 AM<b><br>

To: Keith Scott <<a href=mailto:kscott@mitre.org><span style=" font-size:12pt;color:blue;font-family:Calibri">kscott@mitre.org</a><span style=" font-size:12pt;font-family:Calibri">>,

Felix Flentge <</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>

Cc: "'Sipos, Brian J.'" <<a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue;font-family:Calibri">Brian.Sipos@jhuapl.edu</a><span style=" font-size:12pt;font-family:Calibri">>,

"</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt;font-family:Calibri">"

<</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt;font-family:Calibri">>,

'dtn' <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:12pt;font-family:Calibri">>,

"'Sanchez Net, Marc(JPL-332H)[JPL Employee]'" <</span><a href=mailto:marc.sanchez.net@jpl.nasa.gov><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>marc.sanchez.net@jpl.nasa.gov</u></span></a><span style=" font-size:12pt;font-family:Calibri">>,

"'Chaoua, Rachid(GSFC-4500)'" <</span><a href=mailto:rachid.chaoua@nasa.gov><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>rachid.chaoua@nasa.gov</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>

Subject: </b>RE: [dtn] [EXTERNAL] Re: [Sis-dtn] [EXT] Re: Bundle custody

transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Sorry,

I just realized that the “if not” clause in #1 below could be ambiguous.

 What I meant there was “if the sending node does not try again.”</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Scott</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>

</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:11pt;font-family:Calibri">

<</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:11pt;font-family:Calibri">>

<b><br>

Sent:</b> Thursday, March 31, 2022 8:10 AM<b><br>

To:</b> 'Dr. Keith L Scott' <</span><a href=mailto:kscott@mitre.org><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>kscott@mitre.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">>;

</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:11pt;font-family:Calibri"><b><br>

Cc:</b> 'Sipos, Brian J.' <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:11pt;font-family:Calibri">>;

</span><a href=mailto:dtn@ietf.org><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>dtn@ietf.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">;

'dtn' <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">>;

'Sanchez Net, Marc(JPL-332H)[JPL Employee]' <</span><a href=mailto:marc.sanchez.net@jpl.nasa.gov><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>marc.sanchez.net@jpl.nasa.gov</u></span></a><span style=" font-size:11pt;font-family:Calibri">>;

'Chaoua, Rachid(GSFC-4500)' <</span><a href=mailto:rachid.chaoua@nasa.gov><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>rachid.chaoua@nasa.gov</u></span></a><span style=" font-size:11pt;font-family:Calibri">><b><br>

Subject:</b> RE: [dtn] [EXTERNAL] Re: [Sis-dtn] [EXT] Re: Bundle custody

transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">I

think we are converging on a few principles:</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">1.

       </span><span style=" font-size:11pt;font-family:Calibri">If

all of the CLAs (usually only one, but there could be parallel transmissions)

report to the BPA that forwarding failed, then the sending node may or

may not try again, possibly on a different path and/or relying on different

CLA support; if not, it may or may not release the retransmission resources

occupied by the bundle.  This is a matter for implementation decision,

which might vary depending on the size, QoS, time-to-live, etc. of the

bundle.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">2.

       </span><span style=" font-size:11pt;font-family:Calibri">If

successful forwarding is reported from the convergence layer, then at that

time the sending node may or may not release retransmission resources occupied

by the bundle.  This is again a matter for implementation decision,

which might vary depending on the size, QoS, time-to-live, etc. of the

bundle.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">3.

       </span><span style=" font-size:11pt;font-family:Calibri">If,

following the reporting of successful or unsuccessful forwarding results

from the convergence layer, the sending node does not release the retransmission

resources occupied by the bundle, then that release of resources may (or

may not) instead occur upon reception of a Compressed Bundle Report (or

whatever we decide to call it; effectively, a custody signal) from the

receiving node or from some other node further downstream, in the event

that the bundle was flagged for this behavior.  The absence of such

an acknowledgment may or may not result in either automatic (timeout-driven)

or managed re-forwarding of the bundle.  Again these are implementation

matters.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">4.

       </span><span style=" font-size:11pt;font-family:Calibri">If

all else fails, expiration of the bundle’s time-to-live will eventually

and unconditionally result in the release of the retransmission resources

occupied by the bundle.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">What

we’ve currently got in the BPv7 specification already supports all of

the above except #3; I think that new flagging/signaling mechanism is the

augmentation that we need to focus on.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Scott</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>

Dr. Keith L Scott <</span><a href=mailto:kscott@mitre.org><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>kscott@mitre.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">>

<b><br>

Sent:</b> Thursday, March 31, 2022 5:24 AM<b><br>

To:</b> </span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:11pt;font-family:Calibri">;

</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:11pt;font-family:Calibri"><b><br>

Cc:</b> 'Sipos, Brian J.' <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:11pt;font-family:Calibri">>;

</span><a href=mailto:dtn@ietf.org><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>dtn@ietf.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">;

dtn <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">>;

'Sanchez Net, Marc(JPL-332H)[JPL Employee]' <</span><a href=mailto:marc.sanchez.net@jpl.nasa.gov><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>marc.sanchez.net@jpl.nasa.gov</u></span></a><span style=" font-size:11pt;font-family:Calibri">>;

'Chaoua, Rachid(GSFC-4500)' <</span><a href=mailto:rachid.chaoua@nasa.gov><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>rachid.chaoua@nasa.gov</u></span></a><span style=" font-size:11pt;font-family:Calibri">><b><br>

Subject:</b> Re: [dtn] [EXTERNAL] Re: [Sis-dtn] [EXT] Re: Bundle custody

transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">I

do think the kernel of the issue under discussion is whether the rover

is willing to release resources based on a reliable CLA confirming receipt,

or if it (the rover) should wait for some signaling from the BP layer.

 The former implies an assumption that successful receipt by the (reliable)

CLA </span><span style=" font-size:11pt;font-family:Wingdings">�</span><span style=" font-size:11pt;font-family:Calibri">

“custody transfer” to the receiving node and that the receiving node

will hold onto the bundle until it can be reliably transferred (via a reliable

CLA) to the next hop.  Without the assumption that every node takes

custody, BP is a best-effort service and I think that’s too loose a service

for what we want in space.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">The

way I read RFC9171, a bundle node that attempts to send a bundle that results

in one or more of the CLAs reporting failure to forward MAY attempt to

retransmit the bundle (or, presumably, it MAY not).  [The text after

step 5 in section 5.4].  Depending on settings, some sort of signal

SHOULD / could be generated noting the deletion of the bundle, but it would

be lost regardless.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">So,

even if forwarding is attempted over a reliable CLA (e.g. TCPCLv4), if

that fails for some reason, bundles can be lost.  Even if the space

community modifies the processing rules to mandate that bundles that fail

CLA forwarding ARE retransmitted, such a change can only apply to the portion

of the path that we control.  If we end up buying commercial DTN routers

for use in the ground, they could very well stick to the MAY clause and

drop bundles for which the initial CLA transmission failed (I think).</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">To

signaling (or at least being able to signal) all sorts of interesting events

per Felix’s email: yeah, we should be able to do that.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> 

        --keith</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"><b>From:

</b>Felix Flentge <</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>

Date: </b>Thursday, March 31, 2022 at 4:37 AM<b><br>

To: </b><</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>

Cc: "'Sipos, Brian J.'" <<a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue;font-family:Calibri">Brian.Sipos@jhuapl.edu</a><span style=" font-size:12pt;font-family:Calibri">>,

<</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt;font-family:Calibri">>,

dtn <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:12pt;font-family:Calibri">>,

Keith Scott <<a href=mailto:kscott@mitre.org><span style=" font-size:12pt;color:blue;font-family:Calibri">kscott@mitre.org</a><span style=" font-size:12pt;font-family:Calibri">>,

"'Sanchez Net, Marc(JPL-332H)[JPL Employee]'" <</span><a href=mailto:marc.sanchez.net@jpl.nasa.gov><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>marc.sanchez.net@jpl.nasa.gov</u></span></a><span style=" font-size:12pt;font-family:Calibri">>,

"'Chaoua, Rachid(GSFC-4500)'" <</span><a href=mailto:rachid.chaoua@nasa.gov><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>rachid.chaoua@nasa.gov</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>

Subject: </b>Re: [dtn] [EXTERNAL] Re: [Sis-dtn] [EXT] Re: Bundle custody

transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">Well,</span><span style=" font-size:11pt;font-family:Calibri">

<br>

</span><span style=" font-size:10pt;font-family:Arial"><br>

I would say all a reliable CLA would do is to confirm to the forwarding

CLA that it has received all data that has been forwarded. I wouldn't expect

the CLA to check whether this data is a bundle or something else.</span><span style=" font-size:11pt;font-family:Calibri">

</span><span style=" font-size:10pt;font-family:Arial"><br>

This data will be provided to the BPA. Now:</span><span style=" font-size:11pt;font-family:Calibri">

</span><span style=" font-size:10pt;font-family:Arial"><br>

a) if it is corrupted, the bundle node may not be able to do anything with

it and just delete it.</span><span style=" font-size:11pt;font-family:Calibri">

</span><span style=" font-size:10pt;font-family:Arial"><br>

b) the bundle node might be able to read correct bundles --> in this

case we might want to report reception</span><span style=" font-size:11pt;font-family:Calibri">

<br>

</span><span style=" font-size:10pt;font-family:Arial"><br>

After this:</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>

c) the bundle node may forward the bundle --> we might want to report

forwarding</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>

d) the bundle node delivers the bundle --> we might want to report delivery</span><span style=" font-size:11pt;font-family:Calibri">

</span><span style=" font-size:10pt;font-family:Arial"><br>

e) the bundle node deletes the bundle (expired, security checks fail, no

storage, ...) --> we might want to report deletion</span><span style=" font-size:11pt;font-family:Calibri">

<br>

</span><span style=" font-size:10pt;font-family:Arial"><br>

(The Compressed Bundle Reporting mechanism is about making these reporting

more efficient.)</span><span style=" font-size:11pt;font-family:Calibri">

<br>

</span><span style=" font-size:10pt;font-family:Arial"><br>

The report receiving node may do something wrt to the reports received

(delete data, re-transmit data, ...). This might be application specific

or we might want to specify some behaviour (which could be a re-transmission

mechanism). </span><span style=" font-size:11pt;font-family:Calibri"><br>

</span><span style=" font-size:10pt;font-family:Arial"><br>

Having said this, I agree that re-transmission at the convergence layer

is the preferred mechanism if possible (eg, for bi-directional links) and

that bundle re-transmission should only happen in exceptional (whatever

this means) cases, e..g. if we have reliable convergence layers but maybe

loose a bundle at the end of a contact.</span><span style=" font-size:11pt;font-family:Calibri">

<br>

</span><span style=" font-size:10pt;font-family:Arial"><br>

Regards,</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>

Felix</span><span style=" font-size:11pt;font-family:Calibri"> <br>

<br>

<br>

<br>

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

From:        </span><span style=" font-size:9pt;font-family:Arial"><</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

To:        <span style=" font-size:9pt;font-family:Arial">"'Chaoua,

Rachid\(GSFC-4500\)'" <<a href=mailto:rachid.chaoua@nasa.gov><span style=" font-size:9pt;color:blue;font-family:Arial">rachid.chaoua@nasa.gov</a><span style=" font-size:9pt;font-family:Arial">>,

"'Sanchez Net,  Marc\(JPL-332H\)[JPL Employee]'" <</span><a href=mailto:marc.sanchez.net@jpl.nasa.gov><span style=" font-size:9pt;color:blue;font-family:Arial"><u>marc.sanchez.net@jpl.nasa.gov</u></span></a><span style=" font-size:9pt;font-family:Arial">>,

<</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:9pt;font-family:Arial">>,

"'Dr. Keith L Scott'" <</span><a href=mailto:kscott@mitre.org><span style=" font-size:9pt;color:blue;font-family:Arial"><u>kscott@mitre.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

Cc:        <span style=" font-size:9pt;font-family:Arial">"'Sipos,

Brian J.'" <<a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:9pt;color:blue;font-family:Arial">Brian.Sipos@jhuapl.edu</a><span style=" font-size:9pt;font-family:Arial">>,

</span><a href=mailto:dtn@ietf.org><span style=" font-size:9pt;color:blue;font-family:Arial"><u>dtn@ietf.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

Date:        </span><span style=" font-size:9pt;font-family:Arial">30/03/2022

19:52</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

Subject:        <span style=" font-size:9pt;font-family:Arial">Re:

[dtn] [EXTERNAL] Re: [Sis-dtn] [EXT] Re: Bundle custody transfer and reliable

CLs</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

Sent by:        </span><span style=" font-size:9pt;font-family:Arial">"dtn"

<</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">

</span></p>

<div align=center>

<hr noshade></div>

<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Hi,

Rachid.  Confirming that the next BP node in the end-to-end path –

the next bundle hop (bop) – has received a bundle is precisely what a

reliable convergence-layer protocol does.  Now, it may be the case

that the received bundle will not be forwarded any further:</span></p>

<ul>

<li><span style=" font-size:11pt;font-family:Calibri">The bundle may be

malformed or otherwise corrupted, therefore deleted. </span>

<li><span style=" font-size:11pt;font-family:Calibri">The bundle may be

too large to fit into available storage, therefore dropped.</span></ul><span style=" font-size:11pt;font-family:Calibri">In

a well-managed network these errors will be rare, but I agree that for

critical transmissions they need to be reported.  That is why I fully

endorse Felix’s concept of adding to BP a mechanism for sending aggregated

bundle acknowledgments.  But that mechanism is not a substitute for

a technically sound retransmission protocol at the convergence layer, for

reasons we’ve already discussed at length; it’s an augmentation. </span>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">I

also agree that reliance on BIBE ARQ will work only on nodes that support

BIBE ARQ.  Similarly, reliance on custody transfer – aggregated bundle

acknowledgments at the bundle layer – will work only on nodes that support

custody transfer.  This is a deficiency that is common to all protocols

that I know of.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Scott</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:</b>

Chaoua, Rachid (GSFC-4500) <</span><a href=mailto:rachid.chaoua@nasa.gov><span style=" font-size:12pt;color:blue"><u>rachid.chaoua@nasa.gov</u></span></a><span style=" font-size:12pt">>

<b><br>

Sent:</b> Wednesday, March 30, 2022 9:39 AM<b><br>

To:</b> </span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt">;

Sanchez Net, Marc (JPL-332H)[JPL Employee] <</span><a href=mailto:marc.sanchez.net@jpl.nasa.gov><span style=" font-size:12pt;color:blue"><u>marc.sanchez.net@jpl.nasa.gov</u></span></a><span style=" font-size:12pt">>;

</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">;

'Dr. Keith L Scott' <</span><a href=mailto:kscott@mitre.org><span style=" font-size:12pt;color:blue"><u>kscott@mitre.org</u></span></a><span style=" font-size:12pt">><b><br>

Cc:</b> 'Sipos, Brian J.' <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:12pt">>;

</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt"><b><br>

Subject:</b> RE: [dtn] [EXTERNAL] Re: [Sis-dtn] [EXT] Re: Bundle custody

transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Marc’s

statement “the rover unequivocally knows that a complete data product

has made it to the orbiter” reflects the sentiments I’ve heard within

the Near Space Network when discussing DTN and Bundle Protocol. It is a

core requirement for GSFC to confirm the next hop (bop) has custody of

a data payload prior to that data being released from the source (or previous

bop). This is requirement for certain data flow types not all. </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Regarding

the statement (the LTP part), “Why are people in MRN opposed to using

LTP”. Our (NSN/GSFC) stance (captured in the Draft LunaNet Interoperability

Specification, <a href="https://esc.gsfc.nasa.gov/static-files/Draft%20LunaNet%20Interoperability%20Specification%20Final.pdf"><span style=" font-size:12pt;color:blue">https://esc.gsfc.nasa.gov/static-files/Draft%20LunaNet%20Interoperability%20Specification%20Final.pdf</a><span style=" font-size:12pt">,

p.10) is that we will initially support various CLAs: TCPCL, UDPCL, LTPCL,

or Encapsulation (future CLAs will be assessed and supportability determined

by the NSN). Since we are planning on using various service providers,

we are leaving the CLs used up to them. Regardless of the CL implemented,

there is a need for a custody transfer option at the bundle layer. Relying

on BIBE CL only works on nodes that support BIBE CL.  That gives me

some concern. </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Cheers!</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:</b>

dtn <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:12pt;color:blue"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:12pt">>

<b>On Behalf Of </b></span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt"><b><br>

Sent:</b> Tuesday, March 29, 2022 7:22 PM<b><br>

To:</b> Sanchez Net, Marc (JPL-332H)[JPL Employee] <</span><a href=mailto:marc.sanchez.net@jpl.nasa.gov><span style=" font-size:12pt;color:blue"><u>marc.sanchez.net@jpl.nasa.gov</u></span></a><span style=" font-size:12pt">>;

</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">;

'Dr. Keith L Scott' <</span><a href=mailto:kscott@mitre.org><span style=" font-size:12pt;color:blue"><u>kscott@mitre.org</u></span></a><span style=" font-size:12pt">><b><br>

Cc:</b> 'Sipos, Brian J.' <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:12pt">>;

</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt"><b><br>

Subject:</b> Re: [dtn] [EXTERNAL] Re: [Sis-dtn] [EXT] Re: Bundle custody

transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Marc,

I certainly agree that this is a serious problem, but I don’t agree that

it motivates development of a reliability mechanism above the CLA.  (I

believe a number of other requirements do that.)  Prox-1 may be technically

a reliable CLA, but since it routinely misses data it’s apparently not

the right one to use for this environment.  Why are people in MRN

opposed to using LTP, which is a CCSDS standard that has been in continuous

operational use in low Earth orbit (on ISS) since 2016?</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Sorry,

this discussion is likely not of general interest to DTN WG; we should

take it to another thread.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Scott</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:</b>

Sanchez Net, Marc (US 332H) <</span><a href=mailto:marc.sanchez.net@jpl.nasa.gov><span style=" font-size:12pt;color:blue"><u>marc.sanchez.net@jpl.nasa.gov</u></span></a><span style=" font-size:12pt">>

<b><br>

Sent:</b> Tuesday, March 29, 2022 1:09 PM<b><br>

To:</b> </span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt">;

</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">;

'Dr. Keith L Scott' <</span><a href=mailto:kscott@mitre.org><span style=" font-size:12pt;color:blue"><u>kscott@mitre.org</u></span></a><span style=" font-size:12pt">><b><br>

Cc:</b> 'Sipos, Brian J.' <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:12pt">>;

</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt"><b><br>

Subject:</b> RE: [EXTERNAL] Re: [Sis-dtn] [dtn] [EXT] Re: Bundle custody

transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">I

also agree that having reliability mechanisms above the CLA is necessary.

For example, the Mars Relay Network (MRN) uses the Prox-1 protocol on the

proximity links, which has a built-in Go-Back-N ARQ mechanism, so it is

technically a reliable CLA. Yet, they routinely miss data on the return

direction and both the relay orbiter and rover missions have accountability

mechanisms that look for missing data.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">When

I talk to people in the MRN, their biggest desire from DTN is to avoid

the problem above. In their words, they want a mechanism so that the rover

unequivocally knows that a complete data product has made it to the orbiter.

</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">-----------------------------------------------------------------------------------------------------------------------</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Marc

Sanchez Net</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;color:#808080">Telecommunications

Engineer</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;color:#808080">Jet

Propulsion Laboratory</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;color:#808080">Office:</span><span style=" font-size:10pt;color:#2f2f2f;font-family:Arial">

</span><a href="tel:(818)%20393-5840" target=_blank><span style=" font-size:10pt;color:#0082bf;font-family:Arial"><u>(818)

354-1650</u></span></a><span style=" font-size:10pt;color:#0082bf;font-family:Arial">

</span><span style=" font-size:10pt;color:#808080">|</span><span style=" font-size:10pt;color:#0082bf;font-family:Arial">

</span><span style=" font-size:10pt;color:#808080">Email:</span><span style=" font-size:10pt;color:#2f2f2f;font-family:Arial">

</span><a href=mailto:marc.sanchez.net@jpl.nasa.gov><span style=" font-size:10pt;color:blue;font-family:Arial"><u>marc.sanchez.net@jpl.nasa.gov</u></span></a></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">-----------------------------------------------------------------------------------------------------------------------</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:</b>

SIS-DTN <</span><a href="mailto:sis-dtn-bounces@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">>

<b>On Behalf Of </b>sburleig.sb--- via SIS-DTN<b><br>

Sent:</b> Monday, March 28, 2022 11:44 AM<b><br>

To:</b> </span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">;

'Dr. Keith L Scott' <</span><a href=mailto:kscott@mitre.org><span style=" font-size:12pt;color:blue"><u>kscott@mitre.org</u></span></a><span style=" font-size:12pt">><b><br>

Cc:</b> 'Sipos, Brian J.' <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:12pt">>;

</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">;

</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt"><b><br>

Subject:</b> [EXTERNAL] Re: [Sis-dtn] [dtn] [EXT] Re: Bundle custody transfer

and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">I

agree with everything Felix says here (except perhaps abandonment of the

term “custodial”, which seems to have a lot of resonance in the DTN community).</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">It

is true that computed retransmission timeout intervals will not necessarily

be absolutely accurate even in BIBE/CT, but at least there are ways to

limit the error.  Methods for bundle delivery time estimation based

on contact plan analysis were studied in detail and published almost 10

years ago: given known source and destination node ID and a bundle origination

time and bundle size, we can estimate the time of arrival of the original

bundle and consequently the time of arrival of its acknowledgment bundle,

even over asymmetric paths.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Certainly

we don’t have the final answer to BP node congestion.  QoS may well

play a role, and we are starting to think about that in DTN WG.  BPv7

does support the concept of “paring” excessive traffic by imposing lifetime

overrides that result in immediate bundle expiration, a somewhat manageable

mechanism for dropping bundles as necessary.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">But

I don’t think we need to give up on flow control altogether.  When

TCP is used at the convergence layer, a receiving node that is facing congestion

can simply stop reading on the socket and let TCP flow control back-propagate.

 When LTP is used at the convergence layer, a receiving node that

is facing congestion can begin canceling sessions; this will result in

CL protocol failure at the sender, bouncing the affected bundles back up

to the BPA where reforwarding procedures can be initiated (admittedly an

implementation matter, at least for now).  Neither entails bundle

reception that requires the receiving BPA to make a decision.  Personally,

I think building on these kinds of capabilities to address congestion at

the convergence layer would be more powerful than demanding more functionality

from custody transfer.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Scott</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:</b>

</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">

<</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">>

<b><br>

Sent:</b> Monday, March 28, 2022 7:54 AM<b><br>

To:</b> Dr. Keith L Scott <</span><a href=mailto:kscott@mitre.org><span style=" font-size:12pt;color:blue"><u>kscott@mitre.org</u></span></a><span style=" font-size:12pt">><b><br>

Cc:</b> 'Sipos, Brian J.' <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:12pt">>;

</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt">;

Mehmet Adalier <</span><a href=mailto:madalier@antarateknik.com><span style=" font-size:12pt;color:blue"><u>madalier@antarateknik.com</u></span></a><span style=" font-size:12pt">>;

</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt">;

</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt"><b><br>

Subject:</b> Re: [Sis-dtn] [dtn] [EXT] Re: Bundle custody transfer and

reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">Yes,

I do think there is a need for reliability mechanisms above the CLA Layer.

BIBE as a generic reliable CLA allows to address the case of reliability

for uni-directional links (although in this case the setting of the timers

may already get difficult) but it is currently not addressing:</span><span style=" font-size:12pt">

</span><span style=" font-size:10pt;font-family:Arial"><br>

- non-timer based re-transmission (which might be very specific to a certain

node and deployment and therefore might be better addressed as part of

the BPA / AA)</span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:Arial"><br>

- forwarding a bundle without explicitly addressing a (singleton) next

hop (eg, an opportunistic downlink where some signal about reception or

delivery is uplinked at some later time).</span><span style=" font-size:12pt">

</span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

I agree that we somehow can consider all received bundles as 'custodial'

as a node should attempt to store and forward them. I also think that the

typical use of custody transfer for BPv6 has been probably more to be informed

about the reception (or deletion) of a bundle then whatever (additional

???) responsibility would be taken by the receiving node. So, maybe we

should abandon the term 'custody' altogether. However, there are certainly

situations where a sending node would like to get information about reception/delivery/deletion/forwarding

of a bundle at another node in an operationally viable and efficient way

(so, not using the current Bundle Status Reports).</span><span style=" font-size:12pt">

</span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

Regards,</span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:Arial"><br>

Felix</span><span style=" font-size:12pt"> <br>

<br>

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

<br>

From:        <span style=" font-size:9pt;font-family:Arial">"Dr.

Keith L Scott" <</span><a href=mailto:kscott@mitre.org><span style=" font-size:9pt;color:blue;font-family:Arial"><u>kscott@mitre.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt">

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

To:        </span><span style=" font-size:9pt;font-family:Arial">"Mehmet

Adalier" <<a href=mailto:madalier@antarateknik.com><span style=" font-size:9pt;color:blue;font-family:Arial">madalier@antarateknik.com</a><span style=" font-size:9pt;font-family:Arial">>,

"</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:9pt;font-family:Arial">"

<</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:9pt;font-family:Arial">>,

"'Sipos, Brian J.'" <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:9pt;font-family:Arial">>,

"</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:9pt;font-family:Arial">"

<</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:9pt;font-family:Arial">>,

"</span><a href=mailto:dtn@ietf.org><span style=" font-size:9pt;color:blue;font-family:Arial"><u>dtn@ietf.org</u></span></a><span style=" font-size:9pt;font-family:Arial">"

<</span><a href=mailto:dtn@ietf.org><span style=" font-size:9pt;color:blue;font-family:Arial"><u>dtn@ietf.org</u></span></a><span style=" font-size:9pt;font-family:Arial">>,

"</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">"

<</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt">

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

Date:        </span><span style=" font-size:9pt;font-family:Arial">28/03/2022

15:11</span><span style=" font-size:12pt"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

Subject:        <span style=" font-size:9pt;font-family:Arial">Re:

[Sis-dtn] [dtn] [EXT] Re: Bundle custody transfer and reliable CLs</span><span style=" font-size:12pt">

</span></p>

<div align=center>

<hr noshade></div>

<p style="8�U
.�U
�.�;margin-Bottom:3600px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">The

question remains: do we need some form of reliability above the CLA layer?

 As Scott points out, BIBE is ‘just’ a reliable CLA that uses bundles

as its transport mechanism.  That allows BIBE to function as a reliable

CLA in environments where other CLAs that require bidirectional connectivity

cannot, but viewed from the standpoint of the sending and receiving BIBE

endpoints, it’s just another reliable CLA.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">The

not-often-stated assumption here is that bundle nodes that receive bundles

via reliable CLAs do in fact take on the responsibilities of what was traditionally

referred to as ‘custody transfer’ – i.e. following whatever procedures

are necessary to ensure that the received bundle reaches its destination

(e.g. store it until a forward path becomes available, attempt retransmission

to the next hop until there’s an indication that the next hop has (via

a reliable CLA in this context) received the bundle, etc.).  I.e.

this approach assumes that receipt of a bundle </span><span style=" font-size:12pt;font-family:Wingdings">�</span><span style=" font-size:12pt">

accepting ‘custody’ of it.  Without this assumption, the service

provided by BP is essentially the same best-effort service that IP provides,

which I think is less than what we want, particularly for space missions.

So I think that in the BPv7 context, all bundles are considered ‘custodial’.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">If

we consider cases where there may be congestion (contention for storage

space at nodes), this means that when congestion happens at a node, the

only course of action available to the node will be to refuse new incoming

bundles (presumably because the receiving CLAs stop accepting them).  </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">There

are at least two things to consider here:</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial"><br>

1.        </span><span style=" font-size:12pt">What

if I have a bundle node that is capable of forwarding but that has quite

minimal storage?  By receiving a bundle, this node is committing to

storing that bundle until it can be reliably forwarded.  It seems

like there could be cases where this is really inefficient, especially

if the reliable forwarding is over something like BIBE where the RTT to

get an acknowledgement could be high.  In BPv6, such a node could

simply forward a custody-requesting bundle without actually taking custody,

sort of like a ‘transit node’ in a BIBE tunnel.  In this case, it

might be able to achieve a higher throughput at the expense of NOT accepting

the storage requirements from the current custodians. </span><span style=" font-size:10pt;font-family:Arial"><br>

2.        </span><span style=" font-size:12pt">Even

if a congested node has a lot of storage (but still becomes congested),

in BPv6 there was the notion that the node could drop (probably lower-priority)

non-custodial bundles in favor of (probably higher-priority) custodial

bundles.  We don’t currently have any notion of priority in BPv7,

but if we ever want to admit the possibility that a bundle node might drop

a bundle due to congestion, it seems like the assumption that receipt </span><span style=" font-size:12pt;font-family:Wingdings">�</span><span style=" font-size:12pt">

‘custodial’ acceptance constrains us.  In the BPv7 ‘receipt is

(custody) acceptance’ model, the node would have to refuse new bundles.

</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">This

might be right thing for some CONOPS.  It would impose backpressure

(at DTN timescales) on the network, eventually to the bundle sources.  The

same thing would happen with BPv6 and custodial bundles, the difference

being that a BPv6 node would have the option of dropping non-custodial

bundles to accommodate newer (again, presumably higher-priority) bundles.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">I’ll

readily admit that calculating a (good) retransmission timer value in the

case where a node does NOT know if the proximate (or even which) downstream

node will take custody is difficult or impossible for some networks.  BIBE

still has a bit of this problem, especially if the path to the BIBE destination

is long, as the sender won’t necessarily know the path the BIBE bundles

will take, but it is at least more constrained than the completely open

case.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">If

we want to have the option of dropping lower-priority bundles that have

already been received and are being stored at a node, we’ll need an extension

block to mark priority, fine.  We could then create rules that operate

at the BP layer to drop bundles when congestion occurs according to their

priority markings and address #2 above. I suppose in this case the ‘reliability’

is still at the CLA layer and the decision-making process on whether or

not to drop an incoming bundle is at the BP layer.  </span></p>

<ul>

<li><span style=" font-size:11pt;font-family:Calibri">That might not address

#1 above but maybe #1 is sufficiently rare (or non-existent) that we decide

to ignore it.</span><span style=" font-size:12pt;font-family:Calibri">

</span>

<li><span style=" font-size:11pt;font-family:Calibri">Regardless, this

has the disadvantage that the transmitting node would believe that the

bundle was accepted (because it would have been, by the receiving CLA)

event though it then got dropped by the BP layer at the receiving node.</span></ul><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri">

</span>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> 

        --keith</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:

</b>"</span><a href="mailto:sis-dtn-bounces@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">"

<</span><a href="mailto:sis-dtn-bounces@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">>

on behalf of "</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">"

<</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">><b><br>

Reply-To: </b>Mehmet Adalier <</span><a href=mailto:madalier@antarateknik.com><span style=" font-size:12pt;color:blue"><u>madalier@antarateknik.com</u></span></a><span style=" font-size:12pt">><b><br>

Date: </b>Friday, March 25, 2022 at 1:21 PM<b><br>

To: </b>"</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt">"

<</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt">>,

"'Sipos, Brian J.'" <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:12pt">>,

Felix Flentge <<a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue">Felix.Flentge@esa.int</a><span style=" font-size:12pt">>,

"</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt">"

<</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt">>,

"</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">"

<</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">><b><br>

Subject: </b>Re: [Sis-dtn] [dtn] [EXT] Re: Bundle custody transfer and

reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Best</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">mehmet</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:

</b>SIS-DTN <</span><a href="mailto:sis-dtn-bounces@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">>

on behalf of "sburleig.sb--- via SIS-DTN" <</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">><b><br>

Reply-To: </b><</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt">><b><br>

Date: </b>Friday, March 25, 2022 at 10:07 AM<b><br>

To: "'Sipos, Brian J.'" <<a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue">Brian.Sipos@jhuapl.edu</a><span style=" font-size:12pt">>,

<</span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">>,

<</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt">>,

<</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">><b><br>

Subject: </b>Re: [Sis-dtn] [dtn] [EXT] Re: Bundle custody transfer and

reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">I

would propose that we term the latter procedures “custody transfer” and

proceed to standardize them, while renaming the former something like “BPARQ”.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Scott</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:</b>

dtn <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:12pt;color:blue"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:12pt">>

<b>On Behalf Of </b>Sipos, Brian J.<b><br>

Sent:</b> Friday, March 25, 2022 4:46 AM<b><br>

To:</b> </span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt">;

</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt">;

</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt"><b><br>

Subject:</b> Re: [dtn] [EXT] Re: Bundle custody transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">Felix,</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">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:</span></p>

<ul>

<li><span style=" font-size:11pt;color:#004080;font-family:Calibri">Send.request

to the CLA</span><span style=" font-size:12pt;font-family:Calibri"> </span>

<li><span style=" font-size:11pt;color:#004080;font-family:Calibri">Send.response

from the CLA</span><span style=" font-size:12pt;font-family:Calibri"> </span>

<li><span style=" font-size:11pt;color:#004080;font-family:Calibri">Receive.indication

from the CLA</span></ul><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri">

</span>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">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:</span></p>

<ul>

<li><span style=" font-size:11pt;color:#004080;font-family:Calibri">Receive.indication

from the CLA</span><span style=" font-size:12pt;font-family:Calibri"> </span>

<li><span style=" font-size:11pt;color:#004080;font-family:Calibri">Receive.response

to the CLA</span></ul><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri">

</span>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">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.” </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">Thanks

for any further clarification,</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">Brian

S.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:</b>

dtn <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:12pt;color:blue"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:12pt">>

<b>On Behalf Of </b></span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:12pt;color:blue"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:12pt"><b><br>

Sent:</b> Friday, March 25, 2022 6:11 AM<b><br>

To:</b> </span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt">;

</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:12pt"><b><br>

Subject:</b> [EXT] Re: [dtn] Bundle custody transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">(cross-posting

to CCSDS DTN mailinglist as it seems to be of high relevance to the on-going

discussions in the DTN WG).</span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

I think we clearly need to distinguish between (at least) two different

types of 'custody transfer' according to where it is implemented:</span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

(a) BPv6 - like custody transfer which has been a function of the BPA /

AA Administrative element</span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

(b) BIBE-like custody transfer which is implemented in the CLA</span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

The main differences I see are:</span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

- 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><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

- 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><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

Requirements regarding custody transfer I would see for space missions

are:</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

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><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

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><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

2) Forwarding bundles without knowing which node will take custody.</span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

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><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

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><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

Finally, 'custody transfer' seems to be always related to timer-base re-transmission.

However, I think there are other options as well, like:</span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

- 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><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

- 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><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

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).

<br>

<br>

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><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

<br>

Regards,</span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:10pt;font-family:Arial"><br>

Felix</span><span style=" font-size:12pt;font-family:Times New Roman">

<br>

<br>

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

<br>

<br>

From:        </span><span style=" font-size:9pt;font-family:Arial">"William

Ivancic" <</span><a href=mailto:ivancic@syzygyengineering.com><span style=" font-size:9pt;color:blue;font-family:Arial"><u>ivancic@syzygyengineering.com</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

To:        <span style=" font-size:9pt;font-family:Arial"><<a href=mailto:sburleig.sb@gmail.com><span style=" font-size:9pt;color:blue;font-family:Arial">sburleig.sb@gmail.com</a><span style=" font-size:9pt;font-family:Arial">>,

"'Sipos, Brian J.'" <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:9pt;font-family:Arial">>,

<</span><a href=mailto:dtn@ietf.org><span style=" font-size:9pt;color:blue;font-family:Arial"><u>dtn@ietf.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

Date:        </span><span style=" font-size:9pt;font-family:Arial">25/03/2022

01:16</span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

Subject:        <span style=" font-size:9pt;font-family:Arial">Re:

[dtn] Bundle custody transfer and reliable CLs</span><span style=" font-size:12pt;font-family:Times New Roman">

</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>

Sent by:        </span><span style=" font-size:9pt;font-family:Arial">"dtn"

<</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">

</span></p>

<div align=center>

<hr noshade></div>

<p style="8�U
.�U
�.�;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman">“</span><span style=" font-size:12pt">Custody</span><span style=" font-size:12pt;font-family:Times New Roman">”</span><span style=" font-size:12pt">

is </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">a

bundle level concept, not transport. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">Way

back when, </span><span style=" font-size:12pt;font-family:Times New Roman">“</span><span style=" font-size:12pt">Custody</span><span style=" font-size:12pt;font-family:Times New Roman">”</span><span style=" font-size:12pt">

meant that the node taking </span><span style=" font-size:12pt;font-family:Times New Roman">“</span><span style=" font-size:12pt">Custody</span><span style=" font-size:12pt;font-family:Times New Roman">”</span><span style=" font-size:12pt">

would try it</span><span style=" font-size:12pt;font-family:Times New Roman">’</span><span style=" font-size:12pt">s

best to ensure the bundle was forwarded either to another </span><span style=" font-size:12pt;font-family:Times New Roman">“</span><span style=" font-size:12pt">Custody</span><span style=" font-size:12pt;font-family:Times New Roman">”</span><span style=" font-size:12pt">

node or to eventually the destination node. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">The

idea, as I recall, was this would allow the original bundle source to clear

its memory of that bundle. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">For

space operations, I don</span><span style=" font-size:12pt;font-family:Times New Roman">’</span><span style=" font-size:12pt">t

think the operations people were ever comfortable with this concept.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">//Will</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:

</b>dtn <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:12pt;color:blue"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:12pt">>

on behalf of <</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt">><b><br>

Date: </b>Thursday, March 24, 2022 at 6:04 PM<b><br>

To: "'Sipos, Brian J.'" <<a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue">Brian.Sipos@jhuapl.edu</a><span style=" font-size:12pt">>,

<</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt">><b><br>

Subject: </b>Re: [dtn] Bundle custody transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Brian,

there was some further discussion of custody transfer in this morning</span><span style=" font-size:12pt;font-family:Times New Roman">’</span><span style=" font-size:12pt">s

meeting of the CCSDS Space Internetworking Systems DTN Working Group as

well. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">A

couple of notes:</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">It</span><span style=" font-size:12pt;font-family:Times New Roman">’</span><span style=" font-size:12pt">s

important to remember that we are talking about state machines here, not

people. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">Anthropomorphizing

the DTN architecture is tempting but treacherous. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">BP

nodes have no will; they cannot take responsibility; they cannot promise

to do anything. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">All

they do is behave, ideally in a fashion that conforms to the protocol specifications

to which they were allegedly developed.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Also,

any given node may have been designed with malign intent or implemented

with errors. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">Stating

a requirement in a protocol specification does not ensure its satisfaction;

what it does is give a node</span><span style=" font-size:12pt;font-family:Times New Roman">’</span><span style=" font-size:12pt">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">You</span><span style=" font-size:12pt;font-family:Times New Roman">’</span><span style=" font-size:12pt">re

right, the term </span><span style=" font-size:12pt;font-family:Times New Roman">“</span><span style=" font-size:12pt">custody</span><span style=" font-size:12pt;font-family:Times New Roman">”</span><span style=" font-size:12pt">

is not defined for BPv7. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">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. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">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 </span><span style=" font-size:12pt;font-family:Times New Roman">“</span><span style=" font-size:12pt">custody

transfer.</span><span style=" font-size:12pt;font-family:Times New Roman">”</span><span style=" font-size:12pt">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">So

it may become useful to define an additional BP extension (TBD) that we

label with this term.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">TCPCL

enhancements along the lines you propose here may very well be valuable;

I don</span><span style=" font-size:12pt;font-family:Times New Roman">’</span><span style=" font-size:12pt">t

know, need to think about them some more. </span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Scott</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:</b>

dtn <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:12pt;color:blue"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:12pt">>

<b>On Behalf Of </b>Sipos, Brian J.<b><br>

Sent:</b> Thursday, March 24, 2022 1:39 PM<b><br>

To:</b> </span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt"><b><br>

Subject:</b> [dtn] Bundle custody transfer and reliable CLs</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">All,</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Overall,

there still seems to be some vagueness about what </span><span style=" font-size:12pt;font-family:Times New Roman">“</span><span style=" font-size:12pt">custody</span><span style=" font-size:12pt;font-family:Times New Roman">”</span><span style=" font-size:12pt">

means (in the sense of a service level agreement) between peers exchanging

bundles. My understanding is that </span><span style=" font-size:12pt;font-family:Times New Roman">“</span><span style=" font-size:12pt">custody</span><span style=" font-size:12pt;font-family:Times New Roman">”</span><span style=" font-size:12pt">

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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">1.

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">2.

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

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):</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">a.

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

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</span><span style=" font-size:12pt;font-family:Times New Roman">’</span><span style=" font-size:12pt">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">b.

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt">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</span><span style=" font-size:12pt;font-family:Times New Roman">’</span><span style=" font-size:12pt">t

know how much benefit this would be.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">The

possible values enumerated by the session extension would be something

like:</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Symbol">�

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt">Custody is not taken at END ACK</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Symbol">�

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt">Custody is taken at END ACK</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">And

if there is a transfer extension defined, a the session extension could

indicate:</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Symbol">�

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt">Reception behavior is unconditional</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Symbol">�

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:12pt;font-family:Symbol">

</span><span style=" font-size:12pt">Reception behavior can be overridden

per-transfer based on the sender</span><span style=" font-size:12pt;font-family:Times New Roman">’</span><span style=" font-size:12pt">s

desire</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Trying

to make almost-there-already capabilities more obvious,</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Brian

S.</span></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">_______________________________________________

dtn mailing list </span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt">

</span><a href="https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn__%3B!!PvBDto6Hs4WbVuu7!epFXV3_S7aEW7PDxgWNBW8LKuki9s1NTL4sa8CVsC2thPyLbcOdehXgutIckCym6WUzbi2bq%24&data=04%7C01%7Crachid.chaoua%40nasa.gov%7C5d5bb21035074c676e4608da11db3786%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637841930483903637%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=k%2F3uv%2B8kTA25lenkOtDhpbQxi43lX30qVx%2BdyjkZHVk%3D&reserved=0"><span style=" font-size:12pt;color:blue"><u>https://www.ietf.org/mailman/listinfo/dtn</u></span></a><span style=" font-size:12pt">

</span><span style=" font-size:10pt;font-family:Courier New">_______________________________________________<br>

dtn mailing list</span><span style=" font-size:12pt;color:blue"><u><br>

</u></span><a href=mailto:dtn@ietf.org><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt;color:blue"><u><br>

</u></span><a href="https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn__%3B!!PvBDto6Hs4WbVuu7!epFXV3_S7aEW7PDxgWNBW8LKuki9s1NTL4sa8CVsC2thPyLbcOdehXgutIckCym6WUzbi2bq%24&data=04%7C01%7Crachid.chaoua%40nasa.gov%7C5d5bb21035074c676e4608da11db3786%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637841930483903637%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=k%2F3uv%2B8kTA25lenkOtDhpbQxi43lX30qVx%2BdyjkZHVk%3D&reserved=0"><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>https://www.ietf.org/mailman/listinfo/dtn</u></span></a></p>

<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">_______________________________________________

SIS-DTN mailing list </span><a href="mailto:SIS-DTN@mailman.ccsds.org"><span style=" font-size:12pt;color:blue"><u>SIS-DTN@mailman.ccsds.org</u></span></a><span style=" font-size:12pt">

</span><a href="https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn__%3B!!PvBDto6Hs4WbVuu7!epFXV3_S7aEW7PDxgWNBW8LKuki9s1NTL4sa8CVsC2thPyLbcOdehXgutIckCym6Wcylx8mv%24&data=04%7C01%7Crachid.chaoua%40nasa.gov%7C5d5bb21035074c676e4608da11db3786%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637841930483903637%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gkjxxJBrXxMT2YODEHEErMPPkwa0WmljSO7Y4Z%2Bcius%3D&reserved=0"><span style=" font-size:12pt;color:blue"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</u></span></a><span style=" font-size:12pt">

</span><span style=" font-size:10pt;font-family:Courier New">_______________________________________________<br>

dtn mailing list</span><span style=" font-size:10pt;color:blue;font-family:Courier New"><u><br>

</u></span><a href=mailto:dtn@ietf.org><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt;color:blue"><u><br>

</u></span><a href=https://www.ietf.org/mailman/listinfo/dtn><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>https://www.ietf.org/mailman/listinfo/dtn</u></span></a></p>

<p style="margin-top:0px;margin-Bottom:0px"></p>

<p style="margin-top:0px;margin-Bottom:0px"></p>