Re: [dtn] New Custody Transfer Spec

["Burleigh, Scott C (312B)" <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, April 4, 2017 3:28 AM
To: Keith Scott <[e-mail]>; Burleigh, Scott C (312B) <[e-mail]>; [e-mail]
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:
>[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
>
>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dtn