Subject: [dtn] New Custody Transfer Spec

From: Keith Scott <[email-masked]>
Date: Mon, 3 Apr 2017 16:32:27 -0400

[Changing subject to better match thread.]

Scott,

Thanks for your comments on my proposed methods.  I think I've addressed
these in the attached document, with the differences summarized as:

   - Changed 'cover' to 'include' for payload ranges.  In cases where set
   theoretic A covers B was needed, I use text like "the union of all payload
   ranges meeting criteria XYZ includes range B'.
   - I originally removed the encapsulation text, but added back a version
   that references the note in section 3.2 of BPBIS -- not sure if the NOTE is
   'spec-y' enough to reference or not -- what do you think?
   - Changed all the 'custody signal information associated with a bundle'
   to the simpler: Store all received custody signals that are applicable to
   custodially-held bundles (where 'applicable to' is add to the
   definitions).  It's not as clean from the standpoint of how I'd want to
   implement things, but its easier to describe.

The main difference between these and your original proposed text is that
these allow for a node to fragment a bundle that requests custody without
taking custody of it.  I think that would be very useful in situations
where nodes do not know the 'CL MTUs' of all links that a bundle might
traverse.  Without these mechanisms, if a node takes custody of a bundle
and all the next hops through which the bundle might travel would need to
fragment it, the bundle will be stuck and have to expire at the custodian.

An alternative mechanism might be the CT equivalent of ETOOBIG -- a signal
sent to the current custodian that a bundle needs to be fragmented to size
X before it can be forwarded.  That would have the advantage of reducing
complexity and processing at the expense of efficiency (since the entire
bundle WOULD have to be fragmented by the current custodian(s?) and
re-forwarded.

Anyone have comments on an ETOOBIG equivalent vs. being able to fragment
bundles without taking custody of them?

    --keith

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 3 Apr 2017 21:51:08 +0100

> bundles without taking custody of them?

I still need to review the resulting text to see if it addresses
the issues in my review of bpbis.

One thought though - custody and fragmentation seems to me to be
the kind of things that'd be well suited for an experimental RFC.
I don't feel strongly about that, but it may allow the WG to be
a bit more flexible and reach consensus quicker on those aspects
of the BP.

Cheers,
S.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 3 Apr 2017 21:03:20 +0000

Stephen, as I noted in my email yesterday, the BPbis spec explicitly does NOT yet reflect the decisions on BP modifications that we arrived at in Chicago this week.  All I was trying to do in this quick trial balloon was demonstrate what it could look like to split custody transfer out of the bundle protocol specification.

One other point: bundle fragmentation is mature and is clearly and comprehensively defined in the BPbis spec.  The adaptations Keith is proposing for dealing with fragmentation in custody transfer are new and might be a candidate for an experimental RFC; I don't yet have any very strong opinion on this.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, April 3, 2017 1:51 PM
To: Keith Scott <[email-masked]>; Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: Re: [dtn] New Custody Transfer Spec

On 03/04/17 21:32, Keith Scott wrote:
> Anyone have comments on an ETOOBIG equivalent vs. being able to 
> fragment bundles without taking custody of them?

I still need to review the resulting text to see if it addresses the issues in my review of bpbis.

One thought though - custody and fragmentation seems to me to be the kind of things that'd be well suited for an experimental RFC.
I don't feel strongly about that, but it may allow the WG to be a bit more flexible and reach consensus quicker on those aspects of the BP.

Cheers,
S.

---

From: Carlo Caini <[email-masked]>
Date: Tue, 4 Apr 2017 12:28:22 +0200

Dear Keith and Scott,
    I have added a few comments to the document in attachment, 
essentially to stress that there are now 3 options: acceptance, 
refusal and delegation. I hope they may be of some help, but feel 
absolutely free of dropping them.
Yours,
   Carlo

At 22:32 03/04/2017, Keith Scott wrote:
>Thanks for your comments on my proposed methods.  I think I've 
>addressed these in the attached document, with the differences summarized as:
>
>    * Changed 'cover' to 'include' for payload ranges.  In cases 
> where set theoretic A covers B was needed, I use text like "the 
> union of all payload ranges meeting criteria XYZ includes range B'.
>    * I originally removed the encapsulation text, but added back a 
> version that references the note in section 3.2 of BPBIS -- not 
> sure if the NOTE is 'spec-y' enough to reference or not -- what do you think?
>    * Changed all the 'custody signal information associated with a 
> bundle' to the simpler: Store all received custody signals that are 
> applicable to custodially-held bundles (where 'applicable to' is 
> add to the definitions).  It's not as clean from the standpoint of 
> how I'd want to implement things, but its easier to describe.
>The main difference between these and your original proposed text is 
>that these allow for a node to fragment a bundle that requests 
>custody without taking custody of it.  I think that would be very 
>useful in situations where nodes do not know the 'CL MTUs' of all 
>links that a bundle might traverse.  Without these mechanisms, if a 
>node takes custody of a bundle and all the next hops through which 
>the bundle might travel would need to fragment it, the bundle will 
>be stuck and have to expire at the custodian.
>
>An alternative mechanism might be the CT equivalent of ETOOBIG -- a 
>signal sent to the current custodian that a bundle needs to be 
>fragmented to size X before it can be forwarded.  That would have 
>the advantage of reducing complexity and processing at the expense 
>of efficiency (since the entire bundle WOULD have to be fragmented 
>by the current custodian(s?) and re-forwarded.
>
>Content-Type: 
>application/vnd.openxmlformats-officedocument.wordprocessingml.document;
>         name="draft-ietf-dtn-bpct-00_fragEnabled.SB1_KLS2.docx"
>Content-Disposition: attachment;
>         filename="draft-ietf-dtn-bpct-00_fragEnabled.SB1_KLS2.docx"
>X-Attachment-Id: f_j12kno700
>
>_______________________________________________
>dtn mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dtn

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 7 Apr 2017 21:37:13 +0000

I started on another iteration of the CT book but on reflection I think I want to hold off on that for a moment and spend some time talking about the new stuff.

The fundamental problem, as I understand it, is that a non-custodial node - possibly even a non-CT-aware node, whose implementation does not conform to any of the CT specification requirements at all (as in fact any node might be) - might fragment a bundle for which an upstream node has taken custody.

Currently, a custody signal is applied only to the bundle that it pertains to, as identified by source node, creation timestamp, and the offset and length of the payload (within the application data unit that formed the payload of the original bundle before initial fragmentation).

Since in this case none of the fragments will have the same offset and length as the bundle for which custody was taken, no downstream node that accepts (or refuses) custody of any such fragment can cause the custodian to release custody of (or retransmit) the bundle of which it has custody.  All such custody signals have to be ignored and discarded.

So that bundle's retransmission timer will eventually expire and that (unfragmented) bundle will be retransmitted, perhaps unnecessarily, perhaps back to the same fragmenting non-CT node.  Custody transfer for that unfragmented bundle is no longer working properly.

Given this, I don't think the ETOOBIG concept helps: the node that fragments the bundle might not conform to the CT spec and therefore might not know about sending ETOOBIG.

In which case I am beginning to think that the only solution is to relax the principle that a custody signal is applied only to the identified bundle.  Instead, a custody signal is applied to the bundle(s) for which the receiving node has taken custody, for which source node and creation timestamp match those specified in the custody signal.

If the custody signal is Acceptance then all bytes in the intersections of the payload ranges of the custody signal and each such custodial bundle must be considered payload for which custody transfer has succeeded.

If the custody signal is Refusal then all bytes in the intersections of the payload ranges of the custody signal and each such custodial bundle must be considered payload for which custody transfer has failed.

When custody transfer has succeeded for ALL bytes in the payload range of a custodial bundle then we can process custody transfer success for that bundle.

When custody transfer has failed for ALL bytes in the payload range of a custodial bundle then we can process custody transfer failure for that bundle.

For each custodial bundle whose retransmission timer expires prior to either of those two outcomes, we retransmit the bundle.  Maybe fragment it and retransmit only the portions for which custody has not yet been accepted?

And maybe do a similar thing when it has been determined that, for each byte in the payload range of a given custodial bundle, custody has been either accepted or refused.  That is, fragment the bundle appropriately and release custody of the accepted portion(s) but retransmit the refused portion(s).

The bookkeeping is a little complex, but I don't see a good alternative.  Any ideas?

Scott

-----Original Message-----
From: Carlo Caini [mailto:[email-masked]] 
Sent: Tuesday, April 4, 2017 3:28 AM
To: Keith Scott <[email-masked]>; Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: Re: [dtn] New Custody Transfer Spec

Dear Keith and Scott,
    I have added a few comments to the document in attachment, essentially to stress that there are now 3 options: acceptance, refusal and delegation. I hope they may be of some help, but feel absolutely free of dropping them.
Yours,
   Carlo

At 22:32 03/04/2017, Keith Scott wrote:
>    * Changed 'cover' to 'include' for payload ranges.  In cases  where 
>set theoretic A covers B was needed, I use text like "the  union of all 
>payload ranges meeting criteria XYZ includes range B'.
>version that references the note in section 3.2 of BPBIS -- not  sure 
>if the NOTE is 'spec-y' enough to reference or not -- what do you think?
>applicable to custodially-held bundles (where 'applicable to' is  add 
>to the definitions).  It's not as clean from the standpoint of  how I'd 
>want to implement things, but its easier to describe.
>that these allow for a node to fragment a bundle that requests custody 
>without taking custody of it.  I think that would be very useful in 
>situations where nodes do not know the 'CL MTUs' of all links that a 
>bundle might traverse.  Without these mechanisms, if a node takes 
>custody of a bundle and all the next hops through which the bundle 
>might travel would need to fragment it, the bundle will be stuck and 
>have to expire at the custodian.
>
>fragmented to size X before it can be forwarded.  That would have the 
>advantage of reducing complexity and processing at the expense of 
>efficiency (since the entire bundle WOULD have to be fragmented by the 
>current custodian(s?) and re-forwarded.
>

---

From: Keith Scott <[email-masked]>
Date: Tue, 11 Apr 2017 07:53:32 -0400

Scott,

Yes, I concur that the current definition of 'bundle' as (source EID,
sending timestamp [, fragment offset, fragment length]) is wrong, and that
the unique identifier should go back to (source EID, sending timestamp)*.
I *believe* this was the original notion but at some point in the past we
made the switch and I don't think it has served us well.

If one equates (source EID, sending timestamp) to 'IPID' for IP, then we
have a unique token that identifies 'the bundle' to which the fragment(s)
apply, and can manage custody accordingly.

Since what you describe is what I proposed in my email of April 3, I'm for
it.

  --keith

On Fri, Apr 7, 2017 at 5:37 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

> I started on another iteration of the CT book but on reflection I think I
> want to hold off on that for a moment and spend some time talking about the
> new stuff.
>
> The fundamental problem, as I understand it, is that a non-custodial node
> - possibly even a non-CT-aware node, whose implementation does not conform
> to any of the CT specification requirements at all (as in fact any node
> might be) - might fragment a bundle for which an upstream node has taken
> custody.
>
> Currently, a custody signal is applied only to the bundle that it pertains
> to, as identified by source node, creation timestamp, and the offset and
> length of the payload (within the application data unit that formed the
> payload of the original bundle before initial fragmentation).
>
> Since in this case none of the fragments will have the same offset and
> length as the bundle for which custody was taken, no downstream node that
> accepts (or refuses) custody of any such fragment can cause the custodian
> to release custody of (or retransmit) the bundle of which it has custody.
> All such custody signals have to be ignored and discarded.
>
> So that bundle's retransmission timer will eventually expire and that
> (unfragmented) bundle will be retransmitted, perhaps unnecessarily, perhaps
> back to the same fragmenting non-CT node.  Custody transfer for that
> unfragmented bundle is no longer working properly.
>
> Given this, I don't think the ETOOBIG concept helps: the node that
> fragments the bundle might not conform to the CT spec and therefore might
> not know about sending ETOOBIG.
>
> In which case I am beginning to think that the only solution is to relax
> the principle that a custody signal is applied only to the identified
> bundle.  Instead, a custody signal is applied to the bundle(s) for which
> the receiving node has taken custody, for which source node and creation
> timestamp match those specified in the custody signal.
>
> If the custody signal is Acceptance then all bytes in the intersections of
> the payload ranges of the custody signal and each such custodial bundle
> must be considered payload for which custody transfer has succeeded.
>
> If the custody signal is Refusal then all bytes in the intersections of
> the payload ranges of the custody signal and each such custodial bundle
> must be considered payload for which custody transfer has failed.
>
> When custody transfer has succeeded for ALL bytes in the payload range of
> a custodial bundle then we can process custody transfer success for that
> bundle.
>
> When custody transfer has failed for ALL bytes in the payload range of a
> custodial bundle then we can process custody transfer failure for that
> bundle.
>
> For each custodial bundle whose retransmission timer expires prior to
> either of those two outcomes, we retransmit the bundle.  Maybe fragment it
> and retransmit only the portions for which custody has not yet been
> accepted?
>
> And maybe do a similar thing when it has been determined that, for each
> byte in the payload range of a given custodial bundle, custody has been
> either accepted or refused.  That is, fragment the bundle appropriately and
> release custody of the accepted portion(s) but retransmit the refused
> portion(s).
>
> To: Keith Scott <[email-masked]>; Burleigh, Scott C (312B) <
> [email-masked]>; [email-masked]
>     I have added a few comments to the document in attachment, essentially
> to stress that there are now 3 options: acceptance, refusal and delegation.
> I hope they may be of some help, but feel absolutely free of dropping them.
> Yours,
>    Carlo
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 11 Apr 2017 21:36:42 +0000

Hmmm.  I don't think I said that the current definition of bundle ID is wrong, and I don't think it is.  Given that a fragment is a bundle and all fragments of the same original bundle have the same source ID and timestamp, source ID and timestamp doesn't uniquely identify a bundle - and for some purposes I think we do need to be able to identify bundles uniquely, to distinguish this fragment from that fragment.

What source ID and timestamp *DOES* uniquely identify is a bundle transmission request, and I think we can use that "bundle transmission request ID" for management of custody as we have discussed.  I think we pretty much have to, in fact.

Scott
________________________________
From: Keith Scott [[email-masked]]
Sent: Tuesday, April 11, 2017 4:53 AM
To: Burleigh, Scott C (312B)
Cc: Carlo Caini; [email-masked]
Subject: Re: [dtn] New Custody Transfer Spec

Scott,

Yes, I concur that the current definition of 'bundle' as (source EID, sending timestamp [, fragment offset, fragment length]) is wrong, and that the unique identifier should go back to (source EID, sending timestamp)*.  I *believe* this was the original notion but at some point in the past we made the switch and I don't think it has served us well.

If one equates (source EID, sending timestamp) to 'IPID' for IP, then we have a unique token that identifies 'the bundle' to which the fragment(s) apply, and can manage custody accordingly.

Since what you describe is what I proposed in my email of April 3, I'm for it.

  --keith

On Fri, Apr 7, 2017 at 5:37 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
I started on another iteration of the CT book but on reflection I think I want to hold off on that for a moment and spend some time talking about the new stuff.

Scott

-----Original Message-----
From: Carlo Caini [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, April 4, 2017 3:28 AM
To: Keith Scott <[email-masked]<mailto:[email-masked]>>; Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] New Custody Transfer Spec

Dear Keith and Scott,

At 22:32 03/04/2017, Keith Scott wrote:
>[email-masked]<mailto:[email-masked]>