Subject: [dtn] Custody

From: "Will Ivancic" <[email-masked]>
Date: Sat, 21 May 2016 10:29:18 -0400

Food for Thought: Are there any implementations of the bundling protocol that, once they receive a full bundle, DO NOT make every effort to forward that bundle?

Will

---

From: Keith Scott <[email-masked]>
Date: Sat, 21 May 2016 16:41:37 -0400

I think the JDTN implementation doesn't do much (at least an older
implementation didn't).  That's NOT a knock on the guys who did it, or the
implementation (which I like) -- they just saw that the spec didn't require
them to do anything and... didn't.

  --keith

On Sat, May 21, 2016 at 10:29 AM, Will Ivancic <
[email-masked]> wrote:

> Food for Thought: Are there any implementations of the bundling protocol
> that, once they receive a full bundle, DO NOT make every effort to forward
> that bundle?
>
>
>
> Will
>
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>
>

---

From: Eric Travis <[email-masked]>
Date: Sat, 21 May 2016 19:33:54 -0400

Will,

I don't understand what the forwarding the bundle has to do with Bundle
Custody?

I read your query (and chosen discussiion topic) to be asking

"As we expect intermediate bundle nodes to try to do the right thing and
forward bundles using a reliable CL, why is the point of Custody"?

This is an old topic on DTN mailing lists and it is unlikely to be resolved
now.
However the quixotic appeals to me and the weather is dreary:

   - A "successful forwarding" of a bundle provides no guarantee or
   reasonable
   expectation that a bundle has correctly been transferred from the
   STORAGE of
   one bundle entity to the STORAGE of another.  Storage being the real
   endpoints of
   communication. Even if this faulty assumption regarding reliable
   forwarding were true...

   - The bundle protocol's approach to Reliability  is interesting.  It is
   (kind of?) based on NACKs, but the only place that the
   notion of a retransmission timer exists is in regard to custody transfer.

   - From (draft-irtf-dtnrg-bundle-spec-10 Section 5.14)

>       "As soon as a bundle has no remaining retention constraints it may
>    be discarded."
>
     The decision to set the "Forwarding Pending" retention constraint" is
   set upon
     the decision to forward the bundle and cleared in 5.4 Bundle
   Forwarding Step 6:

        Step 6:   When all selected convergence layer adapters have informed
>              the bundle protocol agent that they have concluded their data
>              sending procedures with regard to this bundle:
>
>              *  ...
>
>              *  The bundle's "Forward pending" retention constraint must
>    be
>                 removed.
>

   Reasonable. But,

   The ambiguity of the above does not REQUIRE the CLA to ensure that a
   bundle is
   reliably transferred (just that it completes it's unspecified data
   sending procedure).
   A CLA implementer PROBABLY should ASSUME this means "successful
   completion"
   of reliable transfer to a peer CLA -  this is not a requirement.
   Further, the
   signaling/interaction between a bundle agent and a CLA is basically
   undefined.
   The net result of this is that a bundle CAN fall between the cracks and
   be
   discarded without forwarding despite an effort to forward it.

   - I assume (not good when reading a specification) that if the CLA
   reports a
   problem in forwarding a bundle, a "Forwarding Failure" is somehow
   declared and when this
   happens we turn the crank and do it all again - at least until the
   bundle expires?

   - Even under the best assumed interpretation of successful completion of
   transmission procedures by a CLA does not mean that a bundle was/will be
   declared
   successfully received by the peer bundle agent.  What is the interlock
   mechanism
   preventing a bundle being discarded before this is signaled to the
   forwarded node?

If RFC-5050(bis) were to constrain retention of a bundle UNTIL the
reception of
successful forwarding indication from the target bundle agent - I still
wouldn't
be sympathetic to the assertion that custody transfer is superfluous.

The long wind-up concludes with my direct response to your query being:

"There is no evidence that ANY implementation of RFC5050 makes EVERY effort
to
forward a bundle." That doesn't mean the implementations are flawed - the
specification however...

My assertion is that EVERY effort would include the  attempting to verify
that
the bundle has been successfully STORED at the forwarding destination.

Custody is a separate problem from bundle forwarding. Perhaps it would help
you to
think of Custody as the duct tape and staple-gun component[*]   As
currently specified, Custody Transfer really doesn't improve the above
situation.  Custody is transferred without any verification of the
integrity of stored bundle.  This adds litlle value beyond the
retransmission timer..

Eric

P.S.:

My interpretation of draft RFC-5050s forwarding procedures was done in good
faith.  In the likely event
my interpretations are incorrect, this suggests there is still a need for
clarifying the text.

[*] If Rock-Paper-Scissors gets a lizard and Spock.  Belt ans Suspenders
rates
an expansion too,

---

From: "Will Ivancic" <[email-masked]>
Date: Sat, 21 May 2016 21:46:13 -0400

Allow me to reword.  

Are there any implementations of the bundling protocol that, once they receive a full bundle, DO NOT make every effort to STORE and FORWARD  that bundle?

From: dtn [mailto:[email-masked]] On Behalf Of Eric Travis
Sent: Saturday, May 21, 2016 7:34 PM
To: Will Ivancic <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn] Custody

Will,

I don't understand what the forwarding the bundle has to do with Bundle Custody?

---

From: Eric Travis <[email-masked]>
Date: Sun, 22 May 2016 15:45:26 -0400

Will,

Let's assume the answer is No - what does this mean to you regarding
Custody?

Remember, the Bundle Protocol makes no promises of reliable bundle delivery
without Custodial Transfer,
assuming that concatenated "reliable" forwarding is equivalent to reliable
end-to-end delivery is misguided.

Just as IP routers may discard datagrams, forwarding bundle nodes may
intentionally (or accidentally)
discard non-custodial bundles.

Eric

On Sat, May 21, 2016 at 9:46 PM, Will Ivancic <[email-masked]
> wrote:

> Allow me to reword.
>
>
>
> Are there any implementations of the bundling protocol that, once they
> receive a full bundle, DO NOT make every effort to STORE and FORWARD  that
> bundle?
>
>
>
> *From:* dtn [mailto:[email-masked]] *On Behalf Of *Eric Travis
> *Sent:* Saturday, May 21, 2016 7:34 PM
> *To:* Will Ivancic <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [dtn] Custody
>
>
>
> Will,
>

---

From: Carlo Caini <[email-masked]>
Date: Mon, 23 May 2016 12:13:13 +0200

Dear all,
          I do not want to abuse of your patience, but maybe a
comparison of custody vs reliable CLAs may be useful.
First, let me stress once again  than "full" reliability requires an
ack from the destination; thus a chain of reliable CLAs or a chain of
Custodians (doing re-transmissions and storage in permanent memory)
cannot provide this level of reliability.
Does this mean that a chain of either reliable CLAs or Custodians are
useless? The answer is no. Below a few reasons.
Does a chain of reliable CLAs is equivalent to a custody chain? No again.

I am sorry for the length; I tried hard to be as brief as possible,
but also exhaustive; the topic is intrinsically complex. Last I could
be wrong (the topic is complex). Please, consider all considerations
below as my personal understanding of the topic.

Carlo

Internet
Short delays, continous path between source and destination (no
disruption, no network partitioning), nodes with reasonable
resources, nodes "life expectancy" much longer than RTT, unidrectional links...
There is no point in saving data in intermediate nodes, as
re-transmissions can always be carried out from the source, without
any significant penalty.

Challenged networks
Either long delays, or network partitioning, or nodes with scarce
resources, or that can abruptly leave the network, unidirectional
links, or two of these challenges coupled, are just ALL , if you like
extreme communications!

A sole challenge is enough to prevent you from reliable end-to-end
recovery (or making it the last chance). Let me show a few scenarios,
considering one challenge at a time.

Long delays (interplanetary networking)
You generally have a multihop path from source to destination. Assume
Earth to Mars communications. Re-ransmissions from source, when a
bundle is lost on a Mars-to-Mars hop is possible, but costly. The
Mars gateway acting as custodian can solve the problem in most cases.
As a minimum it can help you saving a lot of very long end-to-end RTTs.

Network partitioning (data mule)
If you want to allow the mule to be switched off (voluntarily to save
batteries) or to be robust against power failures when it has data on
board, you must have the mule acting as custodian with BOTH
retransmissions and permanent memory.

Scarce resources (sensors as sources; IoT)
This is the case recently highlighted in previous e-mails. Your
source has not permanent memory, or simply enough memory
to  store  the bundle. In this case, you can never enforce full
reliability. However, you can achieve a reasonable reliability if the
source can pass the bundle to a Custodian with more memory, better
connections, better batteries, etc.... This is likely essential in IoT.

Source disappearing (voluntarily or not) or even deliberately
canceling the bundle as son as possible
This can be seen as a limit case of a node with scarce resources. The
source may "leave" the network before application ACKs can arrives
from the destination, or just as soon as possible after bundle
sending. It may happen in these circumstances: tactical networks,
VANETs, airborne networks, network of "spies". "To leave the network"
may have a plurality of meanings, such as: to be destroyed by the
enemy (in tactical networks); to physically leave the network (in
VANETs, in airborne networks);  to deliberately cancel any evidence
of the bundle just sent, in order not to be caught with hot stuff in
memory, which is hardly ever on top of a spy's (or a spy drone's)
priority list.

Unidirectional links (a chain of reliable CLAs is impossible, while a
custody chain is)
Let me assume a triangular network, A (source), B (intermediate
node), C (destination). All links are reliable but the B-->C, which
is unidirectional, thus unreliable by definition. All links have a
high bandwidth but A-C, which forces the routing select the two-hop
path A-B->C for big data. The fact that the A-B link is reliable
means nothing, as is the NEXT B->C link is not (and cannot). If B
acts as custodian, you can have automatic re-transmissions from B. B
can still have custody acceptance from C via A.

Raliable CLAs chain vs Custody chain
Reliability of CLAs and Custody are both useful to assure a partial
reliability (i.e. to increase the chances of successful final
delivery without retransmissions from the sources). CLAs reliability
and Custody are different, complementary and not alternative.

The case of unidirectional links shows a situation where a chain of
reliable CLAs is not possible independently from the willingness of
node owners, while a chain of Custodians is.
Last but foremost, unless you have full control of ALL intermediate
nodes (i.e. NEVER but in private networks, which, however,  by
definition do not need standards), you cannot establish a priori a
chain of reliable CLAs, because the choice of CLAs is just not left
to you. E.g. ESA cannot prevent NASA from using UDPCL on Mars if NASA
like, or vice versa.

I suppose that at the origin of so many misunderstandings there is
also the fact that Custody is erroneously assumed to be a
hop-by-hop-mechanism just because it is (generally) not end-to-end.
In fact, DTN has an intermediate case. Between two consecutive
Custodians (the old and the new one), you can have one or more DTN
hops. In the latter case, i.e. when in the middle there is at least
one DTN node that refused the custody, Custody is neither hop-by-hop
nor end-to-end.  By contrast, reliable CLAs operates hop-by-hop only
by definition.

If you assume that Custody is always hop-by-hop, you can move its
"reliability service" from the BP to the CL, which is clearly absurd
once understood that Custody is not hop-by-hop. By the way, the same
would apply to BAB as not all DTN nodes are security nodes, but this
is another topic.

Custody is end-to-end when there is just one hop, i.e. two nodes,
source and destination. This is the only case where a reliable CLAs
provides a reliability close to Custody, although not equivalent.

Custody is hop-by-hop when ALL DTN nodes act as Custodians. A chain
of reliable CLAs, which is always hop-by-hop, is however not
equivalent; e.g. CLAs cannot avoid bundle cancellation on
intermediate nodes with storage on RAM in case of power failures...
Better to have both reliable CLAs and Custody...

Custody is neither end-to-end nor hop-by-hop when some intermediate
nodes do not act as custodians. A chain of reliable CLAs cannot be
equivalent for the very same reasons already mentioned.

Custody can "cover" a chain of reliable and unreliable CLAs.

At 21:45 22/05/2016, Eric Travis wrote:
>Will,
>
>Let's assume the answer is No - what does this mean to you regarding Custody?
>
>Remember, the Bundle Protocol makes no promises of reliable bundle
>delivery without Custodial Transfer,
>assuming that concatenated "reliable" forwarding is equivalent to
>reliable end-to-end delivery is misguided.
>
>Just as IP routers may discard datagrams, forwarding bundle nodes
>may intentionally (or accidentally)
>On Sat, May 21, 2016 at 9:46 PM, Will Ivancic
><<mailto:[email-masked]>[email-masked]> wrote:
>
>Allow me to reword.
>
>
>
>Are there any implementations of the bundling protocol that, once
>they receive a full bundle, DO NOT make every effort to STORE and
>FORWARD  that bundle?
>
>
>
>To: Will Ivancic
><<mailto:[email-masked]>[email-masked]>
>Cc: <mailto:[email-masked]>[email-masked]

5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITÀ DI BOLOGNA
Codice Fiscale: 80007010376

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Mon, 23 May 2016 12:36:57 +0000

First Off, I agree with Carlo’s assessment of Custody vs reliable CLA’s presented in another email.

"Dear all,
          I do not want to abuse of your patience, but maybe a
comparison of custody vs reliable CLAs may be useful.”

The discussion of custody in bpbis is interesting:

3.2<https://tools.ietf.org/html/draft-ietf-dtn-bpbis-03#section-3.2>. Discussion of BP concepts

"The custody transfer mechanism in BP is primarily intended as a
   means of recovering from forwarding failures. …”

“… custody transfer is a less efficient automated
   retransmission mechanism than the reliable transport protocols that
   are typically available at the convergence layer; configuring BPAs
   to use reliable convergence-layer protocols between nodes is
   generally the best means of ensuring bundle delivery at the
   destination node(s).

Regarding Eric’s question.  In line below.

From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Eric Travis <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 22, 2016 at 3:45 PM
To: Will Ivancic <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] Custody

Will,

If hop-by-hop custody is the default.  Are we doing a whole lot of work for nothing?

Is a chain of hop-by-hop custody effectively the same as end-to-end custody?  At least in practice?

Just sayin’

Of course, this paper is just a snapshot of a implementation in time.
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20130000792.pdf

Will

Remember, the Bundle Protocol makes no promises of reliable bundle delivery without Custodial Transfer,
assuming that concatenated "reliable" forwarding is equivalent to reliable end-to-end delivery is misguided.

True but …

Taking custody is no guarantee either.  It is just a warm fuzzy.

See paper referenced above.

Just as IP routers may discard datagrams, forwarding bundle nodes may intentionally (or accidentally)
discard non-custodial bundles.

Or custodial bundles.  See paper as one point of this.

---

From: <[email-masked]>
Date: Mon, 23 May 2016 13:24:47 +0000 (UTC)

"Are we doing a whole lot of work for nothing?"

Well....

Lloyd Wood
http://sat-net.com/L.Wood/dtn

________________________________
From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Monday, 23 May 2016, 22:36
Subject: Re: [dtn] Custody

"Dear all,

The discussion of custody in bpbis is interesting:
3.2. Discussion of BP concepts
"The custody transfer mechanism in BP is primarily intended as a means of recovering from forwarding failures. …”
“… custody transfer is a less efficient automated retransmission mechanism than the reliable transport protocols that are typically available at the convergence layer; configuring BPAs to use reliable convergence-layer protocols between nodes is generally the best means of ensuring bundle delivery at the destination node(s). 

From: dtn <[email-masked]> on behalf of Eric Travis <[email-masked]>
Date: Sunday, May 22, 2016 at 3:45 PM
To: Will Ivancic <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn] Custody

Will, 

Just sayin’

Will

True but …

---

From: Eric Travis <[email-masked]>
Date: Mon, 23 May 2016 12:47:53 -0400

Will,

I'm responding in-line (which never ends satisfactorily for me)

> If hop-by-hop custody is the default.  Are we doing a whole lot of work

I don't follow - the use of "hop-by-hop custody" is confusing me.  Just to
verify - this means custody is taken
by each intermediate node in the path, correct?  This was not the basis
your original question(s).

Why would this be the default?  Custody is always optional and just because
custody is offered doesn't
mean it should be accepted.  Accepting custody is a policy decision
hopefully tied to local resource allocation
policies and locally observed traffic trends.

As to "a whole lot of work for nothing", oddly enough I do agree with you.
Custodial operations
defined by the Bundle Protocol do not consider the integrity of the bundle
payload. Increasing the probability
that the correct amount of bits are delivered rather the correct bits are
delivered is of dubious value.

Weren't you originally advocating that sequential transfers over reliable
transport obviated the need for custodial operations?

> custody?  At least in practice?
Custody is about retransmission.  Generally, moving the point of
retransmission *closer* to the
ultimate destination is better than end-to-end retransmission.  Isn't it?
So, "hop-by-hop custody"
would be better than end-to-end custody...

> http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20130000792.pdf

I have only skimmed the paper so far, but my impression is that congested
networks tend to lose data
and buffering data for retransmission tends to exasperate the congestion.
I've long felt that the choice
to ignore the likelihood of congestion in the Bundle Protocol was not a
great design choice.

It does, however, appear that custody transfer was effective in maximizing
the data returned from Mars.

"It was found that with custody transfer nearly half of the received
bundles were 64 MB, which reflects the sender’s situation.
 Without custody transfer more bundles were received but less than 35
percent of the received bundles were 64 MB."

So, Custodial transfer is not a bad thing, even when abusing the underlying
network...

> See paper referenced above.

 Again, custody is about retransmission.  Retransmission can increase the
probability of delivery.
It's a tool, not 100% effective in all situations, but hardly a warm fuzzy
based on your referenced results.

> Or custodial bundles.  See paper as one point of this.

The lesson is to avoid congesting the network so you do not NEED to delete
bundles

Eric

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Mon, 23 May 2016 20:39:45 +0000

NOT In Line – so it maybe works better.

It appears from my understanding and experience (personal or via contracts) that the default operation for every implementation I am aware is that if a bundle agent that receives a bundle (or for DTN2 TCPCL even a reactive fragment) will store that bundle and do its best to forward that bundle whether or not Custody is requested.   So, this is sort of a default “hop-by-hop” custody even though it was not requested.

Now, if congestion occurs, perhaps custody will help, IF you have a mix of custody and non-custody bundles.  But maybe not.  I suspect that it is highly likely for a space operations that all bundles will be sent requesting custody.

What happens when you have a non-custody bundle with higher priority than a custody bundle?  What is the default?

What happens when your custody bundle has a lifetime of 10 years and your non-custody bundle has a lifetime of one hour and they are the same size and priority?

Hence the question "Are we doing a whole lot of work for nothing?”  Custody adds complexity, but, in the end, does it really buy you anything given the default handling of bundles for all implementations that I am aware of is to make every effort to store and forward the bundle?

IMHO, instead of accepting custody, if bundling where actually to get deployed across network domains (not private network only), rejection of bundles for administrative reasons (custody or not) would be more likely.  And the rejection should be early as possible so one doesn’t waste energy transmitting a bundle that will not be accepted.  IMHO, you really don’t want to transmit an entire MByte bundle over a wireless link only to find out it is rejected.

But this should have been answered in the research group and the charter simply says clean up RFC5050, not redo bundling.

Per Brian’s CL email,  yes we need to identify the requirements of the CL.  Yes, we should be able to reject individual bundles.  And it probably would be useful to know why (e.g.  Out of memory, no service level agreement, Unauthorized source — most likely--, unauthorized sender — maybe useful, but then requires identifying sender rather than source -- , I just plain don’t like you, etc..)

Will

From: Eric Travis <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 23, 2016 at 12:47 PM
To: William Ivancic <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] Custody

Will,

I don't follow - the use of "hop-by-hop custody" is confusing me.  Just to verify - this means custody is taken
by each intermediate node in the path, correct?  This was not the basis your original question(s).

Why would this be the default?  Custody is always optional and just because custody is offered doesn't
mean it should be accepted.  Accepting custody is a policy decision hopefully tied to local resource allocation
policies and locally observed traffic trends.

---

From: "Marc Blanchet" <[email-masked]>
Date: Tue, 24 May 2016 14:41:06 -0400

On 23 May 2016, at 16:39, Ivancic, William D. (GRC-LCA0) wrote:

> It appears from my understanding and experience (personal or via 
> contracts) that the default operation for every implementation I am 
> aware is that if a bundle agent that receives a bundle (or for DTN2 
> TCPCL even a reactive fragment) will store that bundle and do its best 
> to forward that bundle whether or not Custody is requested.   So, this 
> is sort of a default “hop-by-hop” custody even though it was not 
> requested.
>
> Now, if congestion occurs, perhaps custody will help, IF you have a 
> mix of custody and non-custody bundles.  But maybe not.  I suspect 
> that it is highly likely for a space operations that all bundles will 
> be sent requesting custody.
>
> What happens when you have a non-custody bundle with higher priority 
> than a custody bundle?  What is the default?
>
> What happens when your custody bundle has a lifetime of 10 years and 
> your non-custody bundle has a lifetime of one hour and they are the 
> same size and priority?

<to add>
In case of congestion, what happens when the node belongs to 
organisation X and the custody bundles belong to organisation Y and 
other bundles belong to organisation X?

Marc.

>
> Hence the question "Are we doing a whole lot of work for nothing?”  
> Custody adds complexity, but, in the end, does it really buy you 
> anything given the default handling of bundles for all implementations 
> that I am aware of is to make every effort to store and forward the 
> bundle?
>
> IMHO, instead of accepting custody, if bundling where actually to get 
> deployed across network domains (not private network only), rejection 
> of bundles for administrative reasons (custody or not) would be more 
> likely.  And the rejection should be early as possible so one 
> doesn’t waste energy transmitting a bundle that will not be 
> accepted.  IMHO, you really don’t want to transmit an entire MByte 
> bundle over a wireless link only to find out it is rejected.
>
> But this should have been answered in the research group and the 
> charter simply says clean up RFC5050, not redo bundling.
>
> Per Brian’s CL email,  yes we need to identify the requirements of 
> the CL.  Yes, we should be able to reject individual bundles.  And it 
> probably would be useful to know why (e.g.  Out of memory, no service 
> level agreement, Unauthorized source — most likely--, unauthorized 
> sender — maybe useful, but then requires identifying sender rather 
> than source -- , I just plain don’t like you, etc..)
>
> Will
>
>
> From: Eric Travis 
> <[email-masked]<mailto:[email-masked]>>
> To: William Ivancic 
> <[email-masked]<mailto:[email-masked]>>
> I don't follow - the use of "hop-by-hop custody" is confusing me.  
> Just to verify - this means custody is taken

---

From: Carlo Caini <[email-masked]>
Date: Tue, 24 May 2016 21:12:44 +0000

Dear Marc and William,
    Intermediate nodes do have the liberty of accepting or refusing the custody.
The criteria for acceptance or refusal should be left to the organizations to which the nodes belong, and may differ.
I would say that if a node wants to accept the custody of a 10 year lifetime bundle, it must be ready to accept the consequences. If somebody takes a mortgage loan, he takes a long term obligation with the bank. It can be an opportunity but also a risk. In my opinion, it would be foolish for a node to accept a custody even for 10 days...
Regarding Marc's comment, a criterion could be for organization X to take custody only of its own bundles. Another criterion could be to find a (likely win-win) agreement with Y. Airlines largely exploits this kind of agreements by selling in code-sharing the tickets of flights they actually operate singularly. I suppose that NASA could do the same with ESA, just to give you an example.
Organization X could also ask a flat fare for the "Custody service" offered to Y, why not ?

In brief, if on the one hand every organization should be left free of choosing its own criteria for accepting or refusing custody requests, on the other hand custody should be associated to a minimum set of services, because when one node accepts the custody, it also stops the service that is provided by the current custodian. This minimum set of services should be indicated in the specs. This is at least my humble opinion. Of course the final decision is not mine.

Yours,
   Carlo
________________________________________
Da: dtn [[email-masked]] per conto di Marc Blanchet [[email-masked]]
Inviato: martedì 24 maggio 2016 20:41
A: Ivancic, William D.
Cc: [email-masked]
Oggetto: Re: [dtn] Custody

<to add>
In case of congestion, what happens when the node belongs to organisation X and the custody bundles belong to organisation Y and other bundles belong to organisation X?

Marc.

Will

Cc: "[email-masked]<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Will,

dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

---

From: Eric Travis <[email-masked]>
Date: Wed, 25 May 2016 00:46:07 -0400

On Tue, May 24, 2016 at 2:41 PM, Marc Blanchet <[email-masked]>
wrote:

> contracts) that the default operation for every implementation I am aware
> is that if a bundle agent that receives a bundle (or for DTN2 TCPCL even a
> reactive fragment) will store that bundle and do its best to forward that
> bundle whether or not Custody is requested. So, this is sort of a default
> “hop-by-hop” custody even though it was not requested.
>
> Now, if congestion occurs, perhaps custody will help, IF you have a mix of
> custody and non-custody bundles. But maybe not. I suspect that it is highly
> likely for a space operations that all bundles will be sent requesting
> custody.
>
> What happens when your custody bundle has a lifetime of 10 years and your
> non-custody bundle has a lifetime of one hour and they are the same size
> and priority?
>
>
Such an odd strawman...  One has to wonder what misguided policies would
lead to a situation where a node has become so congested that it needs to
purge bundles which it previously accepted custody...

All nodes will almost certainly be forwarding a mix of bundles for which it
is custodian, and those for which it is not.  All that matters is that it
avoid purging nodes of which it has taken custody.  A node *can* forward a
custodial bundle without accepting custody for the bundle, is this really a
point of contention?

So, even if a node's storage is completely full of custodial bundles, it is
unlikely to be custodian of all those bundles.

If a node has previously committed x% of its storage to custodial
obligations, it's local policies *should* prevent it from taking on further
custodial commitments. It can still forward "custodial bundles".  Policies
that allow 100% commitment of resources to custodial delivery are simply
broken.

I am intentionally beating this to death because I want to be sure that it
gets across...

Now, if a congested node is purging bundles and must decide between a
custodial bundle with a lifespan of 10 years and a non-custodial bundle, it
should always purge the custodial bundle, as it will be retransmitted.

Generally speaking, the first bundles to be purged should always be
non-local custodial bundles.  There custodians will eventually be
retransmited.

There is nothing special about a "custodial bundle" to any node except for
the current custodian.

I am completely not understanding the case against custodial transfer, but
I REALLY do want to understand.

<to add>
> In case of congestion, what happens when the node belongs to organisation
> X and the custody bundles belong to organisation Y and other bundles belong
> to organisation X?
>

See above regarding custody - but what about a congested node owned by
Organization X deciding on which bundles to purge...  if a bundle was
sourced by an organization X source but is destined for an Organization Y
node, who "owns" the bundle - the source or the destination?

I would suspect that all metrics being otherwise equal, the spirit of your
question are the fodder for peering agreements between Organization X and
Organization Y. but I don't think custody is a factor in such a decision.

Eric

---

From: Eric Travis <[email-masked]>
Date: Wed, 25 May 2016 00:54:47 -0400

>     Intermediate nodes do have the liberty of accepting or refusing the

Absolutely.

> The criteria for acceptance or refusal should be left to the organizations
> to which the nodes belong, and may differ.
> I would say that if a node wants to accept the custody of a 10 year
> lifetime bundle, it must be ready to accept the consequences. If somebody
> takes a mortgage loan, he takes a long term obligation with the bank. It
> can be an opportunity but also a risk. In my opinion, it would be foolish
> for a node to accept a custody even for 10 days...
>

But an intermediate node can choose to forward the bundle regardless.

> Regarding Marc's comment, a criterion could be for organization X to take
> custody only of its own bundles. Another criterion could be to find a
> (likely win-win) agreement with Y. Airlines largely exploits this kind of
> agreements by selling in code-sharing the tickets of flights they actually
> operate singularly. I suppose that NASA could do the same with ESA, just to
> give you an example.

Correct, details would be spelled out in a peering agreement between ESA
and NASA and be realized a policy on the individual nodes.

>
> In brief, if on the one hand every organization should be left free of
> choosing its own criteria for accepting or refusing custody requests, on
> the other hand custody should be associated to a minimum set of services,
> because when one node accepts the custody, it also stops the service that
> is provided by the current custodian. This minimum set of services should
> be indicated in the specs. This is at least my humble opinion. Of course
> the final decision is not mine.
>
> Yours,
>    Carlo
>

---

From: Rick Taylor <[email-masked]>
Date: Wed, 25 May 2016 15:37:35 +0000

Thank you Carlo,

That's an excellent analysis of the subject.

Would you consider recording that in some kind of document for
posterity/reference as I forsee the custody question being asked
repeatedly?  Perhaps an informational draft?

Cheers,

Rick

---

From: Carlo Caini <[email-masked]>
Date: Wed, 25 May 2016 17:04:13 +0000

Dear Rick,
     Thank you very much for your appreciation. Actually, I had just put down a few points  to make possibly clearer a subject that is intrinsically complex. I have no experience at all of IETF  standardization, but if you deem useful I could try to expand a little the points below in a more formal document. I would also appreciate the help of all other people, included Eric and you, who would like to contribute. Let me know how top proceed.
Yours,
   Carlo

P.S.:
By the way, I forgot to point out that on one point I also agree with Will. It would be a nonsense to take custody of a corrupted bundle, as stressed by Will. Luckily, the new RFC5050bis has introduced optional CRCs on all blocks, thus responding to one of the most discussed objection against BP. While checking these CRCs can always be useful, it should be considered mandatory for custodians. This to prevent the new custodian to save a corrupted version of the bundle, while the old one has a copy whose integrity was successfully verified (again, even CRC is best effort, as multiple errors can always lead to a spurious pass). I would like to thank Will for having reminded me of this important plus of RFC5050bis, whose possible connection with custody I have realized only after reading his comments.
In brief, while a node is generally free of accepting or refusing custody, as custody acceptance also implies the end of services provided by another custodian, we could add that acceptance by a node on an open network should require, as a minimum:
1) the successful verification of all CRCs (if present)
2) the storage of the bundle in permanent memory
3) the willingness of retransmitting the bundle
Should CRCs verification fail, the bundle should be discarded and custody refusal should report the reason to the present custodian.
Should the node lack permanent memory, the bundle should be forwarded as usual but not taken in custody and custody refusal should report the reason.
Again, this is only a first tentative definition of a minimum set of services, nothing more.

________________________________________
Da: Rick Taylor [[email-masked]]
Inviato: mercoledì 25 maggio 2016 17:37
A: [email-masked]; Carlo Caini; [email-masked]
Cc: [email-masked]
Oggetto: Re: [dtn] Custody

Thank you Carlo,

Cheers,

Rick