Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 10 Jun 2016 20:57:31 +0000

I agree. Keith did a very good job with the write up and explaining
custody.

Now consider we have five nodes A, B, C, D and E. A wishes to send a
bundle to E. All transmission to E must pass through D.  A sends to  B
with custody requested. B accepts custody and receives the bundle. B

On 6/10/16, 4:47 PM, "dtn on behalf of Carlo Caini" <[email-masked]
on behalf of [email-masked]> wrote:

>Dear Keith and Scott,
>    it seems to me that after a thorough discussion of both thesis and
>antithesis, we eventually arrived at a perfect synthesis!
>Really well done!
>Yours,
>   Carlo
>
>
>________________________________________
>
>Custody transfer in BP provides a means of reliable data transmission via
>a coarse-grained retransmission mechanism.  When a node takes custody of
>a bundle it commits to taking responsibility for moving that bundle
>toward its destination (in terms of some routing metric at the node),
>possibly retransmitting the bundle if it believes that the bundle has
>been lost or corrupted in transit. ...

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 13 Jun 2016 17:38:08 +0000

In 5.12, I think we now need to distinguish between the two custody transfer failure cases.  In the case of reception of a Custody Refused signal, I think the action to be taken should remain implementation-specific per the discussion given in that text.  In the case of expiration of a custodial retransmission timer, I agree that the resulting re-forwarding should now be MUST rather than SHOULD (which would be in agreement with the text I think we’ve settled on for 3.2).  I don’t think we need an additional custody refusal signal, though.  In the case of reception of a Custody Refused signal the applicable reason code would already be present; in the case of a timeout, trying to re-forward on the same path again seems to me to be the right decision.

In section 5.10.1, I am fine with the proposed change but I would additionally want to change the second MAY in that paragraph to MUST.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Keith Scott
Sent: Monday, June 13, 2016 15:37
To: Scott C Burleigh (313B)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

So I think this flows through into 5.12, where the action to be taken on expiration of a custody timer is currently implementation-specific.  I think for both rerouting and reliability, the action taken on determination of custody transfer is now 'attempt to re-forward'.  We might want to define a custody failure reason of 'can't route through me' to ensure that the custodian doesn't just try the same path again?  Maybe this isn't needed; if a node simply forwards without taking custody, nothing goes to the current custodian (though such a signal (optional on the part of the sender) could really help the current custodian adjust any countdown timer it might have set).  Would you be amenable to adding such an optional informative signal (possibly as an additional custody refusal reason code)?

In 5.10.1 (Custody Acceptance) where it says "The bundle protocol agent MAY set a custody transfer countdown timer for this bundle;..." would people be amenable to "If the value of a custody transfer countdown timer for this bundle can be calculated with operationally satisfactory accuracy, the bundle protocol agent SHOULD set a custody transfer countdown timer for this bundle;..."

  --keith

On Sun, Jun 12, 2016 at 5:33 PM, Keith Scott <[email-masked]<mailto:[email-masked]>> wrote:

Works for me!

  Keith
On Jun 12, 2016 5:32 PM, "Burleigh, Scott C (312B)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Keith.  Sure, let’s change that second SHOULD to MUST.  If the node isn’t able to re-forward the bundle then it shouldn’t have taken custody in the first place.

On the other question, yes, I see your point.  I’d like to keep the first sentence as is, so how about changing that last clause to “in such environments the use of reliable convergence-layer protocols wherever possible can minimize the incidence of data loss but bundle delivery at the destination node cannot be ensured”?

Scott

From: Keith Scott [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, June 12, 2016 6:37 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Scott,

Awesome.  I particularly like the 'the node SHOULD (if it reasonably can) set a retransmission timer' and then SHOULD, on timer expiration or refusal signal, re-forward the bundle.  I wonder why that second isn't a MUST (re-forward)?  If a node receives a custody refused signal (as in your routing failure example), shouldn't it *have* to do something to recover?  If the node cannot set a retransmission timer (because it's just too difficult / complicated) then it only then HAS to respond to a custody refusal.

For the 'Delivery of the bundle at the destination node' bullet, the 'contraindicated' seems a bit strong.  I realize that it applies to 'on all segments' but it can be read as "If you cant' use reliable CLAs everywhere, give up on it".  Maybe something like:

If all segments of the end-to-end path support reliable convergence layers, then delivery of the bundle at the destination node can be ensured by utilizing the reliable convergence-layer protocols on all segments of the end-to-end path.  This approach may make more efficient use of links than custody transfer because a convergence-layer protocol may perform finer-grained retransmission than custody transfer does, retransmitting only the specific portions of a transmitted bundle that were not received, rather than the entire bundle.  However, in some environments there may be segments of the end-to-end path for which no reliable convergence-layer protocol is available; in such environments reliable convergence-layer protocols SHOULD be used when available.

-or-

The probability of delivery of the bundle at the destination node can be greatly increased by using reliable convergence-layer protocols between neighbors whenever possible. This approach may make more efficient use of links than custody transfer because a convergence-layer protocol may perform finer-grained retransmission than custody transfer does, retransmitting only the specific portions of a transmitted bundle that were not received, rather than the entire bundle.  However, in some environments there may be segments of the end-to-end path for which no reliable convergence-layer protocol is available; in such environments reliable convergence-layer protocols SHOULD be used when available and other segments MAY use unreliable (convergence-layer) protocols.

-or- if you want to keep the first sentence as is, maybe change the phase after the semi-colon to

 ";in such environments the use of reliable convergence-layer protocols between all segments of the end-to-end path is not possible, but nodes SHOULD use reliable CLAs when possible." or some such?

  --keith

On Fri, Jun 10, 2016 at 5:19 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
Okay, negotiating, how about this?

The custody transfer mechanism in BP serves two purposes.

First, it provides a means of ensuring bundle delivery at the destination node.  When the custodian of a bundle forwards that bundle it SHOULD set a retransmission timer; upon expiration of that timer, absent reception of a responding custody acceptance or refusal signal from a downstream node, the custodian SHOULD re-forward the bundle.  Computation of the timeout interval for a bundle’s custodial retransmission timer (i.e., determination of the moment at which a responding custody signal is expected) is an implementation matter.  In some environments it may be impossible to compute this interval with operationally satisfactory accuracy; in such environments the use of custody transfer to ensure bundle delivery at the destination node is contraindicated.

Second, it provides a means of optimizing recovery from forwarding failures.  When a bundle for which custody has been taken arrives at a node from which it must be forwarded, but forwarding is impossible, the receiving node SHOULD send a custody refusal signal to the current custodian node, causing the custodian to re-forward the bundle on a different path.

Alternatively, when custody transfer for a given bundle is not requested:

•         Delivery of the bundle at the destination node can be ensured by utilizing reliable convergence-layer protocols between neighbors on all segments of the end-to-end path.  This approach may make more efficient use of links than custody transfer because a convergence-layer protocol may perform finer-grained retransmission than custody transfer does, retransmitting only the specific portions of a transmitted bundle that were not received, rather than the entire bundle.  However, in some environments there may be segments of the end-to-end path for which no reliable convergence-layer protocol is available; in such environments the use of reliable convergence-layer protocols between neighbors on all segments of the end-to-end path to ensure bundle delivery at the destination node is contraindicated.

•         Recovery from a forwarding failure can be accomplished by "returning" the bundle back toward some node for forwarding along some other path in the network.

Scott

From: Keith Scott [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, June 10, 2016 1:00 PM

To: Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Custody transfer in BP provides a means of reliable data transmission via a coarse-grained retransmission mechanism.  When a node takes custody of a bundle it commits to taking responsibility for moving that bundle toward its destination (in terms of some routing metric at the node), possibly retransmitting the bundle if it believes that the bundle has been lost or corrupted in transit.  It is strongly recommended that nodes that are capable of taking custody of bundles do so, as it is difficult to find good values for retransmission timers in the general case.

On attempting to transmit a bundle for which the node is a custodian, it SHOULD set a retransmission timer whose expiration (in the absence of a custody acceptance signal from a downstream node) will cause the bundle to be re-forwarded.  The correct value for such a timer is impossible to calculate in general, and is an implementation matter.  However in many cases implementations should be able to make reasonable assumptions about when they should expect to receive custody signals and hence what the values for retransmission timers should be. For example, in a network with scheduled connectivity, a node should be able to estimate the path the forwarded bundle will take and the times at which custody signals might be returned based on the 1st, 2nd, etc. downstream node electing to take custody, and could choose to retransmit the bundle if it is indicated that no other node has taken custody of the bundle for e.g. three downstream hops.

If a bundle arrives at a node from which it must be forwarded, but forwarding is impossible, BP must recover from this error. BP can "return" the bundle back along the path on which it was received for eventual re-forwarding along some other path in the network, or else it can instead send a small "signal" bundle back to the custodian which can re-forward the bundle without receiving a copy.  This method of re-routing sharply reduces the network traffic required for recovery from forwarding failures, at the cost of increased buffer occupancy and state management at the custodial nodes.

Because custody transfer’s only remedy for loss of any part of a bundle is the re-forwarding of the entire bundle (not just the lost portion), 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 most efficient means of ensuring bundle delivery at the destination node(s).  However, requiring the use of reliable convergence-layer protocols on all segments of the end-to-end path may be an unacceptable constraint in some environments, in which case BP custody transfer may be the best way to achieve reliable bundle delivery.

  --keith

On Fri, Jun 10, 2016 at 11:51 AM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
Or how about this?

The custody transfer mechanism in BP provides a means of recovering from forwarding failures.  When a bundle arrives at a node from which it must be forwarded, but forwarding is impossible, BP must recover from this error. BP can "return" the bundle back toward some node for forwarding along some other path in the network, or else it can instead send a small "signal" bundle back to such a node, in the event that this node has retained a copy of the bundle ("taken custody") and is therefore able to re-forward the bundle without receiving a copy.  Custody transfer sharply reduces the network traffic required for recovery from forwarding failures, at the cost of increased buffer occupancy and state management at the custodial nodes.

Note that custodial re-forwarding can also be initiated by expiration of a timer prior to reception of a custody acceptance or refusal signal.  Since the absence of a custody acceptance signal might be caused by failure to receive the bundle, rather than only a disinclination to take custody, custody transfer can additionally serve as an automated retransmission mechanism in environments in which the moment at which a responding custody signal is expected can be determined with operationally satisfactory accuracy, by means that are beyond the scope of this specification.

Because custody transfer’s only remedy for loss of any part of a bundle is the re-forwarding of the entire bundle (not just the lost portion), 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 most efficient means of ensuring bundle delivery at the destination node(s).  However, requiring the use of reliable convergence-layer protocols on all segments of the end-to-end path may be an unacceptable constraint in some environments, in which case BP custody transfer may be the best way to achieve reliable bundle delivery.

Scott

From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Burleigh, Scott C (312B)
Sent: Tuesday, June 7, 2016 8:54 AM
To: Keith Scott <[email-masked]<mailto:[email-masked]>>

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Keith, let’s take a step back.  I’m fine with to retaining BP custody transfer as DTN’s reliable delivery mechanism, coarse-grained as it is, if it can be defined in such a way that it works.  In order for custody transfer to work as a reliable delivery mechanism, the sender (current custodian) of each bundle must be able to set a timer upon the expiration of which (absent a custody signal) it will reforward the bundle.  If you can give me text that describes how the timeout interval for that timer is determined in all cases, then I will happily insert that into the bpbis specification.

But if there are conditions under which that interval cannot be determined, then at minimum we have to say in the bpbis specification what those conditions are and what BP is supposed to do instead to ensure delivery (or else say that reliable delivery cannot be ensured under those conditions).

In particular, we at minimum need to address cases in which:

•         It is certain that the next custodian in the path will be a known BP neighbor reachable over Internet links.

•         It is certain that the next custodian in the path will be a known BP neighbor reachable over a space link.

•         It is certain that the next custodian in the path will be the next BP neighbor that forms an opportunistic contact with the current custodian, whenever that happens.

•         It is certain that the next custodian in the path will be a known BP node that is not a neighbor, reachable only via relay by a non-custodial BP node that is reachable by Internet links and that will reach the next custodian by Internet links.

•         It is certain that the next custodian in the path will be a known BP node that is not a neighbor, reachable only via relay by a non-custodial BP node that is reachable by a space link and that will reach the next custodian by Internet links.

•         It is certain that the next custodian in the path will be a known BP node that is not a neighbor, reachable only via relay by a non-custodial BP node that is reachable by Internet links and that will reach the next custodian by a space link.

•         It is certain that the next custodian in the path will be a known BP node that is not a neighbor, reachable only via relay by a non-custodial BP node that is reachable by a space link and that will reach the next custodian by a space link.

•         It is certain that the next custodian in the path will be a known BP node that is not a neighbor, reachable only via relay by N non-custodial BP nodes (where N is known) that are mutually reachable by some known sequence of Internet and space links.

•         It is certain that the next custodian in the path will be a known BP node that is not a neighbor, reachable only via relay by some unknown number of non-custodial BP nodes that form opportunistic contacts among themselves.

•         It is unknown which BP node will be the next custodian in the path, but it’s certain that all links through non-custodial relays to that node will be Internet links.

•         It is unknown which BP node will be the next custodian in the path, but it’s certain that all links through non-custodial relays to that node will be space links.

•         It is unknown which BP node will be the next custodian in the path, but it’s certain that all links through non-custodial relays to that node will be either Internet links or space links.

•         It is unknown which BP node will be the next custodian in the path, and all candidate future custodians are reachable only via relay by some unknown number of non-custodial BP nodes that form opportunistic contacts among themselves.

And there are certainly many more variations, as there are link environments that are neither Internet nor space links.

I know how to achieve reliable delivery in all of these cases if reliable convergence-layer adapters are used throughout.  I don’t know how to do that if all I’ve got is custody transfer as currently defined.

Scott

From: Keith Scott [mailto:[email-masked]]
Sent: Monday, June 6, 2016 5:20 PM
To: Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

I don't think that the current specification of custody transfer is generally useful.  If we want reliable delivery, let's decide how to do it and make it so.  If it's custody transfer, good.  If it's a chain of reliable CL's, good.  If it's end-to-end retransmission from DTPC, fine.  But let's NOT invoke a bunch of machinery that sort of, almost, maybe could provide reliability, but doesn't really.  In that sense (that it's a bunch of complexity that, if we don't use it to provide reliability, serves no purpose) I think it is (ok, slightly) harmful.

Your recollection is faulty.  Custody transfer was always a reliability mechanism and was never intended as signaling to recover from faulty routing.

To be clear, I am NOT in favor of the chain of reliable CLAs model to provide reliability.  I think the constraints it places on the system (that all nodes take custody and that we can only operate in environments where we can provide reliable link layers) are too ... constraining.  I'll admit that requiring all nodes to take custody, and piggy-backing custody acceptance signals on notification of successful CLA reception provides a crude version of what the original custody transfer was intended to provide.

  --keith

On Mon, Jun 6, 2016 at 11:39 AM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
Keith, I agree, that is exactly the crux of the issue.

My own feeling is that what the bpbis draft says now (which is pretty similar to what RFC 5050 said) about custody transfer is somewhat useful and generally harmless.

My recollection may be faulty, but I think way back at the dawn of time we originally devised custody transfer to accomplish exactly what it currently does very well: optimize recovery from reaching a dead end in a forwarding path.  That explains why we go into a lot of detail on the reason codes for custody refusals; it explains why the remedy for any failure in custody transfer is the reforwarding of the entire bundle (no incremental retransmissions); it explains why there are no negative acknowledgments in BP custody transfer.  (Custody refusal is not a negative acknowledgment: it doesn’t say “I didn’t get X, please retransmit”, it says “I got X but I don’t want it, send it somewhere else.”)  In general, it explains why custodial retransmission is such a lame ARQ system.  Custody transfer wasn’t designed to do ARQ.

Since custody signals themselves couldn’t be send custodially, BP couldn’t rely on their arrival; that’s why a timer was needed.  And then, since we had to have a retransmission timer to recover from custody signal loss anyway, it dawned on us that the retransmission timer could also be used to recover from bundle loss.  Presto, custodial retransmission.

Optimizing recovery from reaching a dead end in a forwarding path is somewhat useful and custodial retransmission is generally harmless, so I don’t mind leaving the text as is.  But I would strongly object to making custodial retransmission out to be any more effectual than it is.

The rationale for elevating custodial retransmission that you give here is not new, so I won’t try to counter-argue.  The draft text that you cite is language that you and I arrived at together in a long email exchange several months ago; I was (and am) still willing to go with it, although I personally have yet to see a use case in which custodial retransmission is really more cost-effective than biting the bullet and engineering a CLA that properly addresses the topology.

But if you really want to say something unequivocal about reliable forwarding in BP then I am with you.  Your formulation seems pretty much spot-onto me: all bundles requesting reliable delivery must be sent only over reliable CLAs, and bundle nodes must continue to try to forward such bundles (possibly making multiple attempts over different convergence layers, multiple paths, whatever) until they receive (CLA) acknowledgement that the bundle has made it to the next hop.  The “reliable” and “best-efforts” flags in the ECOS extension block were intended to provide exactly the “please don’t drop me” signaling you refer to here; we could repurpose the “custody transfer requested” bit to do the same thing, but since we’ve decided to move all QoS signaling in BP to a TBD extension block it probably should be moved to that block.

Scott

From: Keith Scott [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, June 5, 2016 7:03 PM
To: Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>

Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

And this is exactly the crux of the issue: is reliability provided by:  1) Reliable CLAs  2) Custody Transfer   3) Some other part of the DTN architecture?  This is exactly the topic on which I would like to gain consensus.

I have always argued that convergence layers (or CLAs) cannot provide reliability to the (end-to-end) bundle protocol because they are single-(bundle-)hop mechanisms and one might traverse a CL that was not reliable and, if there's even the chance of that happening in the path, you can't assert the 'CLA reliability' chain (as opposed to the 'custody transfer reliability' chain).  BP, as the 'end-to-end' mechanism was (in my argument) the right place to put reliability as a service.

I don't think that the chain of reliable CLAs is a good model because: 1) it forces every node in the path to effectively take custody of bundles that need reliable delivery, instead of it being a choice   2) it imposes the reliability requirement on CLAs that in turn means that you can't operate in environments where you can't close that loop.  The current draft even has text supporting this last point, stating: "But there are some use cases (typically involving unidirectional links) in which custody transfer in BP may be a more cost-effective solution for reliable transmission between two BP agents than invoking retransmission protocols at the convergence layer."

But, if we all agree that option 1 (reliable CLAs) is the way we want to provide reliability (and there does seem to be consensus that reliability is a service that the DTN architecture should provide to DTN applications) then we need to say that all convergence layers must be reliable (or rather that all bundles requesting reliable delivery be sent only over reliable CLAs) and that bundle nodes must continue to try to forward such bundles (possibly making multiple attempts over different convergence layers, multiple paths, whatever) until they receive (CLA) acknowledgement that the bundle has made it to the next hop.  I think that then we have a system that is functionally equivalent to every node taking custody.  We can then rename the 'custody transfer requested' bit to the 'please don't drop me when not in transit' bit to differentiate reliable bundles from best effort ones.

Maybe the cases where you can't use a reliable CLA are all too 'corner' to be of use, though I thought NASA had situations where some ground stations might be able to receive but not transmit.  In the reliable CLAs model that would mean either not using those stations or closing the CLA somewhere past the ground station (where you could provide reliability).

The reliable CLAs model will of course work, and it does support the 'fire and forget' notion for applications that don't want to keep local copies of data for reliable delivery.

I believe that the original intent of RFC4838 and even RFC5050 was #2 (custody transfer provided reliability) but that that notion has been subtly altered over the intervening time without any formal discussion and widespread agreement.  Maybe I'm wrong, but it's that discussion, or at least acknowledgement / consensus that I'd like to see before 5050bis moves forward in the IETF.

    --keith

On Sun, Jun 5, 2016 at 5:37 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
But Keith, if we’re not arguing the mechanics then I don’t think we’re talking about anything at all.

I believe strongly that DTN should provide 'reliable transmission' services to BP applications, for exactly the reason you state.  But DTN is not Bundle Protocol; DTN is an architecture of which BP is a key element.

The ability to send data and “immediately” remove it from memory (immediately upon receipt of a positive acknowledgment; in the custody transfer case, a Custody Accepted signal) is not exclusively provided by custody transfer.  You can just as easily – and far more efficiently – achieve this effect by using a reliable convergence-layer adapter and providing the CLA with a means of telling BP that the bundle has been received at the neighboring node.  ION has been doing this for many years.

If, in addition, you want the greater safety of an end-to-end acknowledgment, okay, we’ve addressed that as well.  Delay-Tolerant Payload Conditioning (a CCSDS standard) provides exactly this, along with a number of other services that are potentially very valuable in some environments but not in others.

Lumping all important services into a single protocol to make everything “simpler” is exactly where CCSDS originally went wrong with CFDP.  We have now repaired that error, by (in effect) breaking the store-and-forward procedures out into BP and breaking the acknowledged transmission procedures out into LTP; CFDP now makes sense.  I think it would be unfortunate if we made the same mistake in BP.

Scott

From: Keith Scott [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, June 5, 2016 1:47 PM
To: Eric Travis
Cc: Burleigh, Scott C (312B); Brian Sipos; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-03.txt

Without arguing the mechanics at the moment, I still believe strongly that the Bundle Protocol should provide 'reliable transmission' services to BP applications.  Without such a service, every application that wants reliable delivery will have to implement it independently (end-to-end) and forego some of the 'benefits' that have been used to promote BP (like allowing applications to send data using custody transfer and then immediately remove it from memory).  So for the space case, a lander will have to keep a copy of data it sends (if it wants to ensure delivery) until it receives confirmation that the data has been delivered.

    --keith

On Sat, Jun 4, 2016 at 2:45 AM, Eric Travis <[email-masked]<mailto:[email-masked]>> wrote:
Scott,

On Thu, Jun 2, 2016 at 4:35 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
Eric, I think the definition of the CL service interface is actually very clear already.  What it is not is exhaustive (as stated).  If we want to impose further requirements on CL adapters then yes, we would want to hold up 5050bis until that is done.  But it’s not at all obvious to me that this is necessary or indeed desirable, any more than it’s necessary or desirable for the IP specification to impose stringent requirements on underlying link-layer protocols.

The invoking of the IP specification and link-layer entities was terrific.  Unfortunately it is a faulty equivocation.  You are comparing the
interaction of two stateless entities with that of two stateful entities.  If the nature of BP-CLA interactions were as clean and simple at that of IP-Link entities, then I would absolutely agree with you.

The definition of the CL service interface is concise and the text is clear - my position is that it is incomplete.  This is based on the content
of RFC-5050bis.  There are general requirements that are not reflected in the service definition.  When I suggested "clarifying the Services Required of the Convergence Layer", it was related to codifying those requirements already identified in RFC5050bis,
not limited to:

  *   Section 5.4 Bundle Forwarding (Step 5)

First bullet - The CLA needs to provide a mechanism for the bundle protocol to fiddle with
the ordering of CLA transmission queue

Second bullet - The CLA needs to provide a mechanism to allow bundle age values to be modified
"at the last possible moment before the  CLA initiates conveyance of the bundle node via the CL protocol".
The inclusion of the word 'node' confuses me, but I interpret the intent to mean updated the bundle age while
the bundle is enqueued for transmission  within the CLA.

  *   Section 5.4 Bundle Forwarding (Step 6)

This imposes a requirement on the CLA to signal information to the bundle
protocol - I don't care how - the nature of the signal  content is important though.

How to identify a particular bundle, whether the sending procedures were  successful or not, etc.
Presumably, the Bundle protocol also needs to be signaled by the CLA when its status changes to/from
disconnected and probably some information about the connection (to what node, expected volume of
bundles that can be handled, duration if known)

What requires clarification is the NATURE of the required interactions of the BPA and CLA.

In the spirit of RFC5050bis, the content above is non-exhaustive and not providing any restrictions or guidance on
implementation or policies.  The CLA service interface expected by the bundle protocol specification is richer and more
complex than the text provided in Section 7.2 "Summary of Convergence Layer Services"
The BP also relies on a fair amount of omniscience and magic (in the sense of Clark's Third Law) that is probably considered to be provided by an eventual routing infrastructure that certainly require participation of the CLAs  - imposing more requirements on the
CLA service interface.
Hence, my belief the CLA service interface requires further clarification. If we still disagree, it simply doesn't matter as the RFC5050bis Last Call is done.

My response below is ultimately completely pointless - I am NOT advocating any modifications to RFC-5050bis.  I do want to respond to what I consider incorrect assertions as to what is possible in general terms.  If you wish to disagree or explore the content further, that is fine.  If not, that is equally fine.

It is entirely reasonable for a (possibly large) subset of DTN users to demand reliable end-to-end data delivery, while others do not.  What is not reasonable, I think, is to demand that the Bundle Protocol itself bear responsibility for this reliable delivery, since the end-to-end path may span any number of wildly different network environments: BP is designed to be compatible with all such environments, which means the CL operating characteristics it can rely on can only the intersection of the operating characteristics of them all, a vanishingly small set.  BP itself has got almost nothing to work with, which is why the custody transfer mechanism as defined in the specification (in RFC 5050 as well as in the current draft) is of such limited capability.

The bundle protocol is an overlay.  The disparate nature of the underlying environments is not really relevant.  I don't see this as a strong argument as to why it is unreasonable to want (require is your word) a reliable bundle delivery service. RFC5050bis makes no attempt to
provide such a service making it i(the BP) ncrementally less useful than it could be.  No terrific loss from my perspective.

Custody transfer in BP is consequently of very little value as a means of ensuring reliable end-to-end data delivery, for several reasons:

 Custody transfer in BP is of little value period.  I am in complete agreement with you.
It could, however, be of great utility if that were the desire.

•         Positive acknowledgments are bundles, which can range in size up to hundreds of bytes.  If the transmitted data bundles are small and numerous, you end up spending nearly as much bandwidth for CT acknowledgments as for data transmission.

There is a lot to unpack here.

RFC5050(bis) goes to great lengths to specify status reporting of dubious value.  Why is it positive acknowledgments should be much larger?  Would be impossible to "bundle" acknowledgements with the current reporting bundles?
What would prevent nodes from providing "bundled" positive acknowledgments (one bundle, many acknowledgements).
The same mechanism is applicable for all status reporting between the same node pairs?  Aggregation is a great antidote to header overhead,

Your statement appears to be rationalizing the current design decisions  and makes assumptions about the nature and volume of what
the traffic desiring reliability is...   If one has a data source that is highly redundant (it's dark and 50C), those samples - in a rational configuration - would be send unreliably.  When a sample (it is quite bright and 150C) is remarkable, it would be preferable to TRY and send *that* sample reliably.  But as you indicate above - not a job suitable for RFC5050xxx.

One would think that the content of small bundles from a source to the same destination would be BUNDLED together into a single protocol data unit - maybe creating an eponymous bundle?  Seems like a design principle that could be exploited.  Smaller bundles
might increase the probability that something gets delivered, but maybe not. Fodder for experimentation, but that ship has sailed.

The barriers to positive acknowledgements are design decisions made to (prematurely) optimize traffic flow without really knowing what the nature of traffic flow was likely to be...

•         There is no partial retransmission: if even a single bit is flipped in transmission, you have to retransmit the entire bundle.
Yes - a sound reason to verify the payload integrity as one moves the retransmission point forward.

•         There are no negative acknowledgments, so the only way retransmission can be initiated is by expiration of a timer.  But computing the correct interval for that timer is, in the general case, impossible:
Kind of like trying to compute a useful lifespan of a bundle, but that is an exercise REQUIRED for every bundl;e by RFC5050(bis)
The lack of any *loose* coordination between neighboring nodes was a design decision - never vetted by any testing or engineering analysis. So, impossible by design, not by nature.

o   Different environments require very different methods of computing this interval: one-way light time is needed for LTP, round-trip time history is needed for TCP, etc.  No single mechanism can be defined for custody transfer.
Computing this interval between bundle nodes involves the aggregate of these and the queuing time at each hop. These values can be observed and used for estimators.  Sure there may be a high variance for most paths, but that doesn't mean the mechanism for doing this can't be generalized or that it is impossible to develop usable estimators.
You are being overly dismissive of possibilities.  In fact, for the highly curated environments likely to dominate RFC5050bis deployments, it is probably quite doable.

o   But this doesn’t matter, because the round-trip time to the next node that will take custody is unknowable anyway – because not all nodes are required to take custody.  The sending node has no way of knowing (a) which node will next take custody of the bundle or (b) how much time will be required for the bundle to get to that node, forwarded through an unknown number of non-custodial nodes, and then for the custody acceptance signal to be returned via the same series of forwarders.
Unknowable does NOT mean impossible to estimate.  Every custody transfer signal provides fodder for an adaptive estimate for custody transfer timers.

•         This means that custodial retransmission is, in the general case, guaranteed to occur either too late (imposing additional end-to-end delivery latency and wasting storage resources at the sender) or too early (wasting bandwidth by retransmitting data that were already successfully received).
"Too late" for what?

As for "too early", spurious retransmissions could decrease goodput but how bad this would be could have been a
useful research effort in a research group.. One would expect that retransmission timers would be set conservatively based on the estimator variances.

If I am to accept your arguments, then relying on custody transfer to recover from routing into a cul-de-sac is equally hopeless.
Based on your explanation, why does RFC5050bis include custody mechanisms (other than as a relic from an ancient design)?
Best to purge it now before they become a useless appendage on a proposed protocol standard. [Never mind, I was not going to make any suggestions regarding RFC5050bis.]

The way to provide reliable end-to-end data delivery in DTN is to configure appropriately the DTN stacks (BP, CL adapters, and underlying CL protocols) of all nodes on the path.  This is not “leaving it up to the implementation”; it is leaving it up to the engineering of the network.

Sigh...
For a "Disruption Tolerant Network" it *is* not only possible but *is* currently done as a matter of course for very high data volumes.
The frustrating thing is the bundle protocol might have been a nice clean way of providing this service but that isn't what RFC5050 was building.

Even for a "Delay Tolerant Network" it is possible (effective but not optimal).  Retransmission timer calculations are NOT impossible if you want to support them.

Eric

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

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

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

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