Re: [dtn] New Custody Transfer Spec

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

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