Subject: Re: [dtn] Goal of separated CT spec?

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sun, 2 Apr 2017 23:04:34 +0000

FWIW, here is my quick initial cut at splitting CT out into a separate specification – a modified BPbis spec and a new CT spec.  Note that the BPbis spec does NOT yet reflect the decisions on BP modifications that we arrived at in Chicago this week.

Scott

---

From: Keith Scott <[email-masked]>
Date: Mon, 3 Apr 2017 10:56:10 -0400

OK, I see the benefits of segregating CT out into it own specification, and
thanks for taking the time to turn proposed revisions around so quickly.

Your proposed CT spec does not (as I read it) allow a forwarding node to
fragment a bundle without taking custody of it.  The text I proposed last
week is intended to address this by describing the mechanisms whereby the
custodian of a bundle can manage multiple incoming custody signals that
refer to fragments of the custodially-held bundle.  This should be
essentially no more complex than managing bundle reassembly, and will
probably be important in networks where some nodes (source or forwarders)
do not know all of the MTUs in the path(s) that a bundle might traverse.

I think this mechanism is even covered by the current text of 3.2, if the
custodian fragments the custodially-held bundle along boundaries
corresponding to the custody accepted signals of fragments of that bundle.

I think there are some leftover references to bpbis section 5.10(.x) in
several parts of section 6?  Some of these might be removable (e.g. the
reference to reforwarding along a different route -- section 5.4) but some
of the rest look like they're the effect of cut-and-paste from the bpbis
spec.  I suspect all of the latter type can be resolved internally to the
relevant sections of the new CT spec.

Below is a marked-up version of your bpct draft with the intent of allowing
fragmentation of bundles that request custody without taking custody of the
bundle (or the fragments).

  --keith

On Sun, Apr 2, 2017 at 7:04 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

> FWIW, here is my quick initial cut at splitting CT out into a separate
> specification – a modified BPbis spec and a new CT spec.  Note that the
> BPbis spec does NOT yet reflect the decisions on BP modifications that we
> arrived at in Chicago this week.
>
>
>
> Scott
>
>
>
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 3 Apr 2017 15:48:29 +0000

Hi, Keith.  The new procedures you are introducing to deal with fragmentation by non-custodians seem awfully complex to me, but maybe the benefit justifies that complexity.  I have marked in a couple of questions, attached.

One other point occurs to me: would we want to take this opportunity to additionally augment this specification with the Aggregate Custody Signals we’ve been prototyping for the past few years?

Scott

From: Keith Scott [mailto:[email-masked]]
Sent: Monday, April 3, 2017 7:56 AM
To: Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn] Goal of separated CT spec?

OK, I see the benefits of segregating CT out into it own specification, and thanks for taking the time to turn proposed revisions around so quickly.

Your proposed CT spec does not (as I read it) allow a forwarding node to fragment a bundle without taking custody of it.  The text I proposed last week is intended to address this by describing the mechanisms whereby the custodian of a bundle can manage multiple incoming custody signals that refer to fragments of the custodially-held bundle.  This should be essentially no more complex than managing bundle reassembly, and will probably be important in networks where some nodes (source or forwarders) do not know all of the MTUs in the path(s) that a bundle might traverse.

I think this mechanism is even covered by the current text of 3.2, if the custodian fragments the custodially-held bundle along boundaries corresponding to the custody accepted signals of fragments of that bundle.

I think there are some leftover references to bpbis section 5.10(.x) in several parts of section 6?  Some of these might be removable (e.g. the reference to reforwarding along a different route -- section 5.4) but some of the rest look like they're the effect of cut-and-paste from the bpbis spec.  I suspect all of the latter type can be resolved internally to the relevant sections of the new CT spec.

Below is a marked-up version of your bpct draft with the intent of allowing fragmentation of bundles that request custody without taking custody of the bundle (or the fragments).

  --keith

On Sun, Apr 2, 2017 at 7:04 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
FWIW, here is my quick initial cut at splitting CT out into a separate specification – a modified BPbis spec and a new CT spec.  Note that the BPbis spec does NOT yet reflect the decisions on BP modifications that we arrived at in Chicago this week.

Scott

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