Re: [dtn] A cut at Custody Transfer

[Keith Scott <[e-mail]>]

Carlo,

thanks.

Yes, I'm very interested in counterexamples that would cause the proposed
method to fail.

One complication is what to do with multiple custody deferral signals from
different nodes, and how to actually USE that information at the current
custodian.  The information in the various deferral signals could be
contradictory (e.g. if a custodial bundle is forwarded through multiple
nodes that don't take custody).  I think that's saved by the fact that how
the current custodian uses any of the custody deferral information is
implementation-specific.

    --keith


On Fri, Mar 31, 2017 at 4:59 AM, Carlo Caini <[e-mail]> wrote:

> Dear Keith,
>      After reading the proposed text and having found it very clear thanks
> also to the excellent example, I am definitively in favor of your proposal
> of including it in the current BP5050bis.
> CT is in my opinion a fundamental feature, and not an ancillary one, of
> DTN, and it is strongly interlaced with a lot (the majority?) of other
> procedures. This because the concept of custody is intrinsically and
> logically linked with all aspects of bundle processing. To recognize it, it
> is enough to carry out a search of the "custody" word in the current
> document version.
> Although to write a separate document  is possible, the logical merge
> would be hard for experts and likely beyond the capabilities of normal
> readers, for whom RFCs should be intended.
> Maybe there are other peculiar cases, not covered yet. I would kindly
> invite who has already discovered them to make the mailing list know, to
> see if they can be timely and effectively tackled, as in this case.
> Yours,
>    Carlo
>
>
>
>
> At 22:31 30/03/2017, Keith Scott wrote:
>
>> Below is my first cut at what would need to be done to custody transfer
>> to make it work in conjunction with fragmentation, together with an example
>> of how I think it should work.  I think that what's below allows both
>> custody transfer and fragmentation to peacefully coexist, and I don't think
>> there are any issues with CT and security per se.  The cross-product of
>> security and fragmentation may still be an issue.
>>
>> Comments welcome -- ESPECIALLY if anyone can provide details on the
>> discussion Tuesday night that resulted in the desire to move CT to another
>> document.
>>
>> I favor inclusion of something like what's below into the CURRENT
>> 5050bis, as I think it would make implementing CT much easier than trying
>> to meld two documents (given 5050bis' procedural structure).
>>
>>
>>
>>
>> NOTE: The custody acceptance procedure in 5050bis-06 deletes all current
>> custodians when a new node takes custody (5.10.1).  I haven't run this to
>> ground yet, but does that square with a bundle possibly having multiple
>> current custodian blocks?  Not sure it matters much...?
>>
>>
>>
>> In general the notion would be to logically merge what's below with the
>> existing CT text in 5050bis, whether it ends up part of 5050bis or
>> separate.  That is, what's below describes the changes from / additions to
>> what is currently in 5050bis to accommodate combinations of custody
>> transfer, fragmentation, and encryption.
>>
>> Custody transfer as defined in 5050bis and here still only applies to
>> bundles with singleton EIDs (and identified as such in the bundle
>> processing control flags).
>>
>> =============
>> Modifications
>> =============
>>
>> Remove the restriction in 5050bis-06 section 5.8 that bundles with
>> custodians MUST NOT be fragmented.  The procedures below allow for
>> fragmenting bundles that contain current custodian blocks, whether or not
>> the receiving node takes custody of the bundle.
>>
>> ======
>>
>> The 'Block must be replicated in every fragment' flag in the Block
>> Processing Control Flags of Current Custodian Blocks MUST be set to 1.
>>
>>
>> ========================================
>> Management of Custody Signal Information
>> ========================================
>> On receipt of a custody signal of type 0 (custody acceptance) or type 2
>> (custody delegation) a node SHOULD record the data contained in the custody
>> signal and associate it with all bundles currently stored at the current
>> node that meet all of the following criteria:
>> - The node previously accepted custody of the bundle;
>> - The stored bundle's source EID and sending timestamp match the source
>> EID and sending timestamp of the bundle identified in the custody signal;
>> - The stored bundle's payload range intersects the payload range in the
>> custody signal (as identified by the combination of the fragment offset and
>> payload fragment length) .  If such a range is not present in the custody
>> signal then the range of the signal MUST be assumed to coincide with the
>> entire orignal bundle payload range and this condition MUST be assumed to
>> be met.
>>
>> If no bundles stored at the current node meet all of the criteria above,
>> then the information in the custody signal SHOULD be discarded.
>>
>> For custody acceptance signals, the data recorded MUST include the range
>> of payload bytes for which custody acceptance has been asserted.
>>
>> For custody delegation signals, the data recorded MUST include the range
>> of payload bytes for which custody delegation has been asserted together
>> with the next node to which the bundle will be forwarded and the estimate
>> of the interval that will elapse between when the bundle was received and
>> the time at which it will be forwarded.
>>
>> It may be possible to merge received information with information already
>> associated with a particular bundle or fragment.  For example, if two
>> custody acceptance signals are received with overlapping but unique payload
>> ranges, they might be combined into a single entry referencing the union of
>> the ranges.
>>
>> The information obtained from received custody signals associated with a
>> given bundle or fragment SHOULD be released when custody of that bundle or
>> fragment is released.
>>
>>
>> ========================
>> Fragmentation Procedures
>> ========================
>> When fragmenting a bundle for which the local node is the current
>> custodian, the local node MUST follow the procedures in [5050bis-06 section
>> 5.8].  In addition, the local node SHOULD copy all data recorded from
>> received custody acceptance and custody delegation signals associated with
>> the bundle to those fragments whose ranges intersect the ranges in the
>> records.
>>
>> Notes on the use of the data in received custody signals:
>> The ranges in received custody acceptance signals can be used to release
>> custody of those portions of stored bundles whose payload ranges are
>> completely covered by the custody transfer success signals.  The current
>> node could for example fragment a custodially-held  bundle so that the
>> fragment boundaries coincide with the boundaries of received custody
>> acceptance signals in order to release custody of those fragments.
>> Similarly, received custody delegation signals might be used by the current
>> custodian of a bundle to inform fragmentation of the bundle and revision of
>> the fragments' custody retransmission timeout values.
>>
>>
>> ========================
>> Encapsulation Procedures
>> ========================
>> If a node encapsulates a bundle that requests custody transfer in another
>> bundle without taking custody of it, the node SHOULD send a custody signal
>> of type 2 (custody delegation) to the current custodian of the bundle
>> listing the tunnel destination as the next hop to which the bundle will be
>> forwarded.
>>
>>
>> =====
>> NOTES
>> =====
>> The extent of a bundle's payload bytes is always determinable at any node
>> in the network.  Neither the fragment offset in the primary block (if
>> present) nor the length value of the payload block is affected by security
>> mechanisms [[BPSec ref]]
>>
>>
>> ===========================================
>> Fragmentation with Custody Transfer Example
>> ===========================================
>>
>> Example: A node receives a non-fragmented bundle (or fragment) with a
>> 1,000-byte payload extent, custody transfer requested, and a single current
>> custodian block.  The node does not take custody of the bundle, and
>> fragments the bundle before forwarding it.
>> - The current custodian block is is copied into each of the fragments per
>> the 'Block must be replicated in every fragment' flag.
>> - The custodian of the bundle may receive multiple custody transfer
>> signals referencing various payload ranges of the bundle.  Because these
>> all reference fragments of a single original bundle, each signal will
>> reference the same source EID and sending timestamp, and so the ranges of
>> payload bytes for which custody transfer success is asserted will be
>> associated with the custodially-held bundle at the custodian.
>>
>> If the custodian receives custody acceptance signals covering the entire
>> received bundle payload extent before its custodial retransmission timer
>> expires, it releases custody of the bundle and discards all of the
>> accumulated custody signal information.
>>
>> If the custodian receives some combination of custody acceptance signals
>> covering bytes 0--99 and 300-999 of the bundle and no custody delegation
>> signals before the bundle's custodial retransmission timer expires, the
>> node could:
>> - retransmit the entire bundle
>> - fragment the bundle, forming fragments with payload ranges 0--99,
>> 100--299, and 300-999; assert successful custody transfer of the fragments
>> with payload ranges 0--99 and 300-999, releasing custody of those
>> fragments; retransmit the fragment with payload range 100--299.
>>
>> _______________________________________________
>> dtn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtn
>>
>
>