Subject: [dtn-interest] Question Regarding Custodial Transfer

From: Eric Travis <[email-masked]>
Date: Thu, 12 Jul 2012 02:46:25 -0400

I recently had an extended opportunity to contemplate how a DTN
deployment by my local
electrical provider could have helped locate damaged power lines in a
somewhat rural
area.  It was an interesting diversion and upon revisiting the text of
RFC 5050 leaves me
with some unresolved questions and nascent suggestions for improvement.

The item that has me most perplexed isn't new (it goes back to the
origins of bundling in the
IPN) and it has been asked here before in one form or another - the
resulting discourse
generating far more heat than light.

Had Stephen not floated the possibility of RFC 5050 revision I
wouldn't bother floating this
query - and at this time that is ALL it is; I'll gladly accept
responses on or off-list.

Note - I'm only interested in the engineering rationale behind the
existing design, NOT
opinions supporting an alternative design.  If the need to share those
proves irresistible, it
would be best to create a new message thread.

        What is the reason that custodial transfer operations for the
bundle protocol
        do NOT include an integrity check?  (What makes it unnecessary?)

Thanks!

Eric

([email-masked])

---

From: Daniel Ellard <[email-masked]>
Date: Thu, 12 Jul 2012 06:14:38 -0400

>         do NOT include an integrity check?  (What makes it unnecessary?)

I wasn't involved in the 5050 discussion, but here's what I was told
later:

- It is assumed that the convergence layer adapter or the transport
provides integrity, and therefore if a bundle is received by a node
then its contents are correct

- It is assumed that BPAs won't forge bundles or custody transfer
acknowledgments

If you don't believe that these assumptions hold, then the current
answer is to use the BSP (bundle security protocol) extensions to 5050.

The implications of the first assumption have been the source of a
long-running discussion.

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
Raytheon BBN Technologies
[email-masked]

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 12 Jul 2012 07:27:34 -0500

Eric,

Having to implement BSP just to do integrity check is pretty heavy for a sensor system which is sounds like you may be dealing with.

Just out or curiosity, is time-sync and issue in the contemplated deployment.

- Will
On Jul 12, 2012, at 6:14 AM, Daniel Ellard wrote:

-Dan

--
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
Raytheon BBN Technologies
[email-masked]<mailto:[email-masked]>

_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

---

From: Eric Travis <[email-masked]>
Date: Fri, 13 Jul 2012 00:52:55 -0400

Dan,

Thanks!

While BSP would be a non-starter (key management issues), including
something *similar to* a PIB (payload integrity block) wouldn't be
terrible; My hangup on such approach is that custody transfer can't be
predicated on the new custodian implementing (and thus validating) the
optional integrity check block. It would be better than nothing, until
it wasn't.

Oh well...

Will,

For my scenario, time-sync would be a non-issue.

The lifespan of the bundles would be to some ridiculous (14-28 days?)
value as they need to be considered valid until the problem is
resolved.  If the potential clock drift isn't insignificant compared
to such lifespans then the system is utterly doomed.

Eric

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jul 2012 11:14:07 +0100

> optional integrity check block. It would be better than nothing, until

There was a draft for that [1] but its not progressed and I don't
know of any implementations. The basic idea is sound, though IMO
without all the argumentative bits of the draft it'd much more
likely to be implemented (and a lot shorter;-)

S.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum

---

From: Vint Cerf <[email-masked]>
Date: Fri, 13 Jul 2012 07:30:12 -0400

Eric what about scheduling and antenna pointing? V
On Jul 13, 2012 6:14 AM, "Stephen Farrell" <[email-masked]>

---

From: <[email-masked]>
Date: Fri, 13 Jul 2012 13:23:47 +0100

> I wasn't involved in the 5050 discussion, but here's what I was told

post-hoc justification; I'd guess; my take would be that the design group
simply hadn't heard of the end-to-end principle, or didn't view it as
important.

> then its contents are correct

Explaining the end-to-end principle can be like explaining evolutionary
pressure to a fundamentalist Christian; they're not going to read the
academic literature or be convinced by the actual facts in discussion,
so why bother?

I see that there is recent discussion of corruption that TCP doesn't
catch, which is messing up Akamai caching:
http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0134.html

So they're going to rediscover why the Content-MD5: header is defined
in http, and perhaps independently rediscover the end-to-end principle.
Hurrah!

That's in a reliable terrestrial network. Implications for the
bundle protocol and its environment are left to the reader. After
all, most bundle traffic runs over TCP.

> The implications of the first assumption have been the source of a

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

---

From: <[email-masked]>
Date: Fri, 13 Jul 2012 13:23:47 +0100

http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum 
was adopted as a workgroup draft in September 2007.

(The workgroup did not like the earlier proposed approach in 
http://tools.ietf.org/html/draft-eddy-dtnrg-checksum-00
that we had presented at the July 2007 IETF.)

Comments from the workgroup after being taken up as a workgroup
draft were minimal, as the group focused on new and exciting-to-it
security matters. The workgroup did not progress this draft, much 
as it did not progress the TCP convergence layer, ttl fixes, etc.
Since the draft wasn't getting attention, we wrote our
'A Bundle of Problems' paper, which covered that ground and
more.

We kept the draft alive until May 2011, then gave up.

We spent over four years on this, while demonstrating some
of the problems we explain in experiments on the ground and in space.
(Oh, videos on that at http://sat-net.com/L.Wood/video )

No further work on this effort is planned; fixing the bundle protocol
is not my problem.

(Stephen: your IMO is trolling, not leadership - imo.
 It would be a little late now for constructive edits, though.)

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jul 2012 13:39:08 +0100

Hi Lloyd,

> (Stephen: your IMO is trolling, not leadership - imo.

Well, I guess I was taking a bit of a dig to be fair.
Apologies for any upset. OTOH, that is in the spirit of
the text to which I was referring, so could also be
considered fair;-)

>  It would be a little late now for constructive edits, though.)

Not if there's interest and energy, but I guess we'll
see what comes out of the meeting later this month.

One of the things we want to figure out there is which,
if any, drafts are worth resurrecting. Might be that a
way to handle that is to limit the number to just a few
so we can be a bit more confident that they'll get done
and not just languish, which has happened too often. But
that's a general point, not specific to your draft, e.g.
as you mentioned, the TCP CL one in particular would be
great to get done since its widely used. ("Widely"
meaning for an IRTF research group.)

S.

---

From: <[email-masked]>
Date: Fri, 13 Jul 2012 14:10:56 +0100

One way to encourage focus on that goal is to stop all
security-related work. It's not leading
anywhere, and it will not be used.

Stick to the fundamentals. In this case, security isn't one,
and more than enough time has been spent on security in this group.

(Your year on the IESG should have given you a broader
view of non-security matters, no?)

Lloyd Wood
[email-masked]

Lloyd Wood
[email-masked]

---

From: "Fall, Kevin" <[email-masked]>
Date: Fri, 13 Jul 2012 14:42:55 +0000

Regarding integrity checks, there are a couple of aspects.

1. First, there is the end-to-end version.  Contrary to what Lloyd is
saying below, this was precisely to support the end-to-end priciple which
we were well aware of.  This principle states that only the thing at the
endpoint can knows its necessary delivery semantics.  Indeed the paper
itself discusses 'careful file transfer' and suggests that the endpoint
(which we typically consider to be application in this context) is the one
that needs to make the ultimate determination as to whether the data
communication fabric has done a job adequate for the endpoint.  Hence, no
e2e error detection, [apps may not care if a few bits are corrupted, as
they may wish to use some other form of error control].

2. The hop-by-hop version is perhaps more subtle.  With custody transfer
requested, it is advised to use reliable protocols for each hbh transfer.
Its true that by this doesn't guarantee e2e error free delivery, but given
the consideration of point 1 above, the notion was to have CX 'enhance'
delivery, but not guarantee it.  There are some other more minor but
possibly significant details (e.g., chunks of your bundle go different
ways due to fragmentation, large interruptions, etc).  It was decided to
not include data integrity checks here either (based on the e2e principle).

The particular case that may merit an integrity check is on the meta-data
used to effect the custody transfer itself [or, possibly other bundle
operations].  In that case, one could argue the 'endpoint' in the e2e
argument sense is indeed the protocol (not app) endpoint.  This is a point
for further discussion I think.

- K

---

From: Eric Travis <[email-masked]>
Date: Fri, 13 Jul 2012 13:20:11 -0400

Kevin,

First - thanks for the clear concise rationale.  This is precisely
what I was hoping for to help me understand the design choice.

If I may:

1.  Regarding the relevance of the 'careful file transfer' to
custodial transfer. You get right to the heart of the matter. :)

The true end-to-end path for the file transfer is *not* the
application write and read from the transport API, it is from source
storage to destination storage. [You note this perspective regarding
bundling in the terminus of your reply.]

While the network in between the end-systems is a significant part of
that path, it is not only source for potential data corruption.
Errors introduced before or after the network write() and read() will
not be detected by any network-based mechanism,  For file transfer,
from my experience the way it is done in the careful environment
(archival storage) is to:
            - provide an integrity check with the file(s) to be transferred
            - after the file is completely written to storage,
recompute the integrity check by reading the locally stored content
            - if the integrity check fails, the transfer has failed
and a retransmission of the file is requested
            - once the integrity check succeeds, the source is
informed that the transfer was successful.

When this is put into practice, the usual initial response from those
involved (myself included) is "goodness, what an overkill" - this
changes the first time one sees it catches corrupt files.

This maps directly into the custodial transfer of a bundle.

Consider a bundle path that consists only of 2 nodes - the single
'hop' constitutes the end-to-end path. My concern is that custody
transfer in the bundle protocol ignores the possibility that data
corruption may occur between the creation of the bundle and the
delivery of the bundle payload to the local bundle storage.

An integrity check capability would provide (a greater degree of)
confidence that custody is being accepted for a valid copy of the
bundle payload.  This would be a 'careful end-to-end transfer' between
bundle custodians.

> Hence, no e2e error detection, [apps may not care if a few bits are corrupted, as they may wish to use some other form of error control].

This doesn't change the need for an integrity check for custody
transfer.  Willingly taking custody of a reasonable facsimile of a
bundle seems to degrade the overall service model.

2.  The hop-by-hop version trades a single end-to-end transport
session for a series of concatenated transport sessions with likely
intermediate storage in persistent memory.

Custodial transfer is a trade-off that results in "hopefully
good-enough".  The source trades the possibility for a single true
end-to-end connection for the ability to span paths that may only
exist in a time-disjoint manner.  Custodial transfer moves the
responsibility for reliable transfer from the original data source to
a custodial proxy.  The end-point of communication is being moved
"forward" within the network.  Part of the custodial transfer process
needs to be a high level of confidence that the new custodian has a
valid copy of the data to be transferred.

>It was decided to not include data integrity checks here either (based on the e2e principle).

I know that we disagree here - but based on *an interpretation of* the
e2e principle to a particular service model.

The bundle agents *are* the endpoint for custody transfer operations.
For non-custodial forwarding, it would be nice to use an integrity
check ( why propagate bad data if you have an alternative) but if
corruption occurs between custodians, it can still be detected and
ultimately be corrected via retransmission.

>for further discussion I think.

I haven't been involved in bundling in a large dog's lifetime, but in
this context, the discussion goes back to the very first meeting on
what became bundling - and was consistently tabled so progress could
be made :)

Regardless,  I think it would be beneficial to document the design
rationale underlying RFC 5050 somewhere (as well as the resulting
service model).

Again - thanks for response.

Eric

---

From: Eric Travis <[email-masked]>
Date: Fri, 13 Jul 2012 15:31:11 -0400

Steven,

I actually liked the draft (the reference to "something *similar to* a PIB)
but bolting on an integrity check as an *optional* component to custody
transfer defeats the purpose.

My integrity check problem seems easily solvable but requires a change to
RFC 5050.  I offer this up as discussion fodder for the Mountain View
summit:

       Since the handling of custody transfer and reporting requests
       are optional, why not remove them from the primary bundle block
       and make them extension blocks?  This allows the Primary block
       to be primarily a routing header.

(See block formats below)

Such an approach exploits a nice feature of the bundle protocol design -
the decomposition of functionality into blocks. The custodial and reporting
blocks would be considered fundamental blocks - required to be supported by
every implementation.

Nodes not supporting Custodial or Reporting blocks can simply step over the
blocks once determining their length.

This then allows:
       An optional (to the bundle source) integrity check can be added to
the
       custody handling procedures.  If intermediate nodes choose not to
perform
       the integrity check, they must not take custody of the bundle.

       It also supports the extension of custody handling procedures (say,
experimentation with allowing
       a custodian to define the attributes/policies of a downstream
custodian)

This does not solve all the issues regarding custody transfer and
signaling, but it would be an incremental step forward.

Eric

==========================================================

Primary Block

  ----------------------------------------------------
  |    Version      |     Processing Flags     |
  ----------------------------------------------------
  |              Block Length                          |
  ----------------------------------------------------
  | Destination Length |      Destination    |
  ----------------------------------------------------
  |    Source Length    |       Source          |
  ----------------------------------------------------
  |       Creation Timestamp time             |
  ----------------------------------------------------
  |                 Lifetime                               |
  ----------------------------------------------------
  |            [Fragment Offset ]                    |
  ----------------------------------------------------
  | [ Total application data unit length ]    |
  ----------------------------------------------------

- All fields handled as in RFC 5050
- The bulk of potential compression benefits of omitted dictionary are
  provided by processing flag hints in Custodial and Reporting blocks.

======================================================

Custodial Block
  ---------------------------------------------------------------
  | Block Type = Custody    | Processing Flags *  |
  ---------------------------------------------------------------
  | Block Length                  |       Version *            |
  ---------------------------------------------------------------
  | Custodian Length *        | Current Custodian * |
  ---------------------------------------------------------------
  |  Integrity Length *          |  Integrity Check *     |
  ---------------------------------------------------------------
  | [Fragment Integ Len *]  | [Frag Integ Check *] |
  ----------------------------------------------------------------

* Custodian Length is a SDNV
* When the Current Custodian matches the bundle Source, a processing flag
  indication can save need to include Custodian info here.
* Non-SDNV version number allows incremental refinement of block as
  long as the changes are backward compatible
* Type of check could be signaled within processing flags, choice of:
    - 0 - something weak but relatively cheap (CRC-32)
    - 1 - strong but more resource intense (single, standardized choice)
* Integrity length of 0 indicates integrity check is not required/desired
* If bundle is a fragment, the block will contain a fragment integrity
check to
  be used instead of the primary integrity check

All nodes should honor the non-zero integrity check when handling custodial
transfer.
Non-custodial transfers MAY use the integrity check and refuse bundle
delivery upon failure.

Custody should not be accepted until the bundle is successfully stored
locally as indicated by integrity check.
Reassembled bundles should pass the primary integrity check before assuming
custody.

========================================================

Reporting Block
  ------------------------------------------------------------------
  | Block Type = Reporting  |  Processing Flags *    |
  ------------------------------------------------------------------
  |                    Block Length                                    |
  ------------------------------------------------------------------
  |   [Report To Length *]     |      [  Report To * ]       |
  ------------------------------------------------------------------

* Processing Flags is an SDNV
* If processing flags indicate that "Report To" is Source,
  then Report To Length and Report To fields need not be included
* If processing flags indicate that "Report To" is Current Custodian,
   then Report To Length and Report To fields need not be included

===========================================================

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Fri, 13 Jul 2012 19:55:51 +0000

Eric, I think suggesting changes to RFC 5050 is perfectly reasonable for this Mountain View meeting.  But I don't understand why you're proposing to link integrity checking to custody transfer: although custody transfer certainly has some utility, I think there are plenty of operational scenarios where custody transfer would be neither needed nor wanted, while integrity checking might be quite important.  And vice versa, actually, as Kevin noted.  I'd decompose a little further.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Travis
Sent: Friday, July 13, 2012 12:31 PM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [dtn-interest] Question Regarding Custodial Transfer

Steven,

I actually liked the draft (the reference to "something *similar to* a PIB) but bolting on an integrity check as an *optional* component to custody transfer defeats the purpose.

My integrity check problem seems easily solvable but requires a change to RFC 5050.  I offer this up as discussion fodder for the Mountain View summit:

Such an approach exploits a nice feature of the bundle protocol design - the decomposition of functionality into blocks. The custodial and reporting blocks would be considered fundamental blocks - required to be supported by every implementation.

Nodes not supporting Custodial or Reporting blocks can simply step over the blocks once determining their length.

This then allows:
       An optional (to the bundle source) integrity check can be added to the
       custody handling procedures.  If intermediate nodes choose not to perform
       the integrity check, they must not take custody of the bundle.

       It also supports the extension of custody handling procedures (say, experimentation with allowing
       a custodian to define the attributes/policies of a downstream custodian)

This does not solve all the issues regarding custody transfer and signaling, but it would be an incremental step forward.

Eric

Primary Block

Custodial Block

* If bundle is a fragment, the block will contain a fragment integrity check to

All nodes should honor the non-zero integrity check when handling custodial transfer.
Non-custodial transfers MAY use the integrity check and refuse bundle delivery upon failure.

Custody should not be accepted until the bundle is successfully stored locally as indicated by integrity check.
Reassembled bundles should pass the primary integrity check before assuming custody.

Reporting Block

===========================================================
On Fri, Jul 13, 2012 at 6:14 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

S.

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

---

From: Eric Travis <[email-masked]>
Date: Fri, 13 Jul 2012 23:10:30 -0400

Scott,

The short answer to your question (why couple...) is that it provides the
maximum benefit/utility while suggesting the minimal disruption on the
existing RFC 5050 design and operations.

The longer answer:

If we were discussing an end-to-end integrity check then I can also see
great utility in scenarios with or without intermediate custody transfer.
But an end-to-end integrity check is a different mechanism than a
hop-by-hop (or custodial hop) integrity check.

The end-to-end integrity check would be done by the application entity upon
delivery of the bundle payload.  The Application Agent (?) would facilitate
this by allowing applications to submit an integrity check with the target
bundle payload and returning the same at the remote delivery point.

Adding an end-to-end integrity option to the Application Agent interface
would be a great thing.

With the current set of bundle protocol mechanisms, a hop-wise integrity
check could prevent the propagation of corrupted bundles (the integrity
check fails, the bundle is deleted).  This is no doubt a good thing for
conservation of resources, but...

Custody transfer has the only available feedback mechanism (an unreliable
ACK/NACK in the form of a custody signal) which can begin to effectively
exploit an integrity check.  The current custodian is expected to (do its
best to) maintain the custodial bundle until it gets a custody signal or an
optional timer expires.  With the integrity check, the custody signal can
reject a corrupted bundle causing a re-forwarding of the bundle - possibly
along a different path.

By allowing nodes that have no intention of being custodians check the
integrity it may be possible to cause a quicker re-forwarding of the the
corrupted bundle (via generating a negative custody transfer signal).

With a non-custodial bundle, there is currently no way to signal a
corruption problem so no re-forwarding is possible.  Even if there were an
available signaling mechanism, the bundle agent at the previous hop has
probably deleted the bundle after the convergence layer indicated
successful transfer.

If we keep pulling on this thread, I think one ends up with a design that
introduces reliable inter-node signaling and maintains more inter-node
state than was desired in the existing design.  Again, I don't think that
is a bad thing but suggesting a major redesign of RFC 5050 would be
somewhat rude on my part.

As an aside, if some form of custodial constraints were added to a custody
block then a constraint could be that only the bundle destination may take
custody of the bundle.  A policy were instituted uniformly in the network
that custodial integrity checks must be performed on all forwarded nodes
you could get the integrity without custody service you mention *and* the
originating bundle agent might be informed of corruption if the signal is
successfully delivered.  Such an approach is *well* within Rube Goldberg
territory but could probably be made to work.

Eric

On Fri, Jul 13, 2012 at 3:55 PM, Burleigh, Scott C (313B) <
[email-masked]> wrote:

>  Eric, I think suggesting changes to RFC 5050 is perfectly reasonable for
> this Mountain View meeting.  But I don’t understand why you’re proposing to
> link integrity checking to custody transfer: although custody transfer
> certainly has some utility, I think there are plenty of operational
> scenarios where custody transfer would be neither needed nor wanted, while
> integrity checking might be quite important.  And vice versa, actually, as
> Kevin noted.  I’d decompose a little further.****
>
> ** **
>
> Scott****
>
> ** **
>

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Sat, 14 Jul 2012 19:14:24 +0000

Okay, I think I see what you're getting at.  Certainly, if a bundle-layer integrity check is going to be used to trigger re-forwarding then it has to be used in conjunction with a bundle-layer NACK, i.e., a custody transfer signal.  I was thinking that a bundle-layer integrity check would be useful in non-custodial traffic simply as a mechanism for discarding a corrupt bundle before the network has wasted a lot of energy on forwarding it.

Scott

From: Eric Travis [mailto:[email-masked]]
Sent: Friday, July 13, 2012 8:11 PM
To: Burleigh, Scott C (313B)
Cc: Stephen Farrell; [email-masked]
Subject: Re: [dtn-interest] Question Regarding Custodial Transfer

Scott,

The short answer to your question (why couple...) is that it provides the maximum benefit/utility while suggesting the minimal disruption on the existing RFC 5050 design and operations.

The longer answer:

If we were discussing an end-to-end integrity check then I can also see great utility in scenarios with or without intermediate custody transfer.  But an end-to-end integrity check is a different mechanism than a hop-by-hop (or custodial hop) integrity check.

The end-to-end integrity check would be done by the application entity upon delivery of the bundle payload.  The Application Agent (?) would facilitate this by allowing applications to submit an integrity check with the target bundle payload and returning the same at the remote delivery point.

Adding an end-to-end integrity option to the Application Agent interface would be a great thing.

With the current set of bundle protocol mechanisms, a hop-wise integrity check could prevent the propagation of corrupted bundles (the integrity check fails, the bundle is deleted).  This is no doubt a good thing for conservation of resources, but...

Custody transfer has the only available feedback mechanism (an unreliable ACK/NACK in the form of a custody signal) which can begin to effectively exploit an integrity check.  The current custodian is expected to (do its best to) maintain the custodial bundle until it gets a custody signal or an optional timer expires.  With the integrity check, the custody signal can reject a corrupted bundle causing a re-forwarding of the bundle - possibly along a different path.

By allowing nodes that have no intention of being custodians check the integrity it may be possible to cause a quicker re-forwarding of the the corrupted bundle (via generating a negative custody transfer signal).

With a non-custodial bundle, there is currently no way to signal a corruption problem so no re-forwarding is possible.  Even if there were an available signaling mechanism, the bundle agent at the previous hop has probably deleted the bundle after the convergence layer indicated successful transfer.

If we keep pulling on this thread, I think one ends up with a design that introduces reliable inter-node signaling and maintains more inter-node state than was desired in the existing design.  Again, I don't think that is a bad thing but suggesting a major redesign of RFC 5050 would be somewhat rude on my part.

As an aside, if some form of custodial constraints were added to a custody block then a constraint could be that only the bundle destination may take custody of the bundle.  A policy were instituted uniformly in the network that custodial integrity checks must be performed on all forwarded nodes you could get the integrity without custody service you mention *and* the originating bundle agent might be informed of corruption if the signal is successfully delivered.  Such an approach is *well* within Rube Goldberg territory but could probably be made to work.

Eric

On Fri, Jul 13, 2012 at 3:55 PM, Burleigh, Scott C (313B) <[email-masked]<mailto:[email-masked]>> wrote:
Eric, I think suggesting changes to RFC 5050 is perfectly reasonable for this Mountain View meeting.  But I don't understand why you're proposing to link integrity checking to custody transfer: although custody transfer certainly has some utility, I think there are plenty of operational scenarios where custody transfer would be neither needed nor wanted, while integrity checking might be quite important.  And vice versa, actually, as Kevin noted.  I'd decompose a little further.

Scott

---

From: <[email-masked]>
Date: Sun, 15 Jul 2012 02:01:50 +0100

On 14 Jul 2012, at 13:10, Eric Travis wrote:
[..]
> By allowing nodes that have no intention of being custodians check the integrity it may be possible to cause a quicker re-forwarding of the the corrupted bundle (via generating a negative custody t…

..and there's a worked example of this in our 'A Bundle of Problems' paper.

http://dx.doi.org/10.1109/AERO.2009.4839384
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf

> If we keep pulling on this thread, I think one ends up with a design that introduces reliable inter-node signaling and maintains more inter-node state than was desired in the existing design.  Agai…

Reliable inter-node signalling would be in accordance with the end-to-end principle (increase performance where possible) and analogous to what MAC layers do across single links, e.g. the Ethernet CRC wrapper on IP packets.

In a disconnected/disrupted network, there are multiple per-hop control loops - and the end-to-end principle applies to each one, as well as to the overall connectivity between source and destination.

Lloyd Wood
[email-masked]

Lloyd Wood
[email-masked]

---

From: <[email-masked]>
Date: Mon, 16 Jul 2012 08:45:02 +0100

> the text to which I was referring, so could also be

Have you actually read
http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum
? (recently?) Some tutorial content seemed unavoidable,
given the intended audience.

> see what comes out of the meeting later this month.

Perhaps the energy could be increased by appointing a fourth chair?

> meaning for an IRTF research group.)

...that isn't HIPRG.