Re: [dtn] New Custody Transfer Spec

[Keith Scott <[e-mail]>]

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) <
[e-mail]> 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).
>
> 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
>