Subject: [dtn] Forwarding over Unidirectional Links

From: Keith Scott <[email-masked]>
Date: Tue, 29 Mar 2016 12:26:46 -0400

In the bpbis-03 draft, section 5.4(step 6) says that if a bundle that
requests reporting of bundle forwarding and for which the current node is
the custodian (custody acceptance constraint is set) is forwarded to only
nodes that are known to unable to send bundles back tot his node then the
bundle forwarding report should carry the reason code 'forwarded over
unidirectional link'.

Should / could the first bullet under step 6 say:  '...all of the nodes to
which the bundle was forwarded are known to be unable to send bundles to
the report-to endpoint of the bundle, then...'?  ('unable to send bundles
back to this node' seems to have a somewhat ambiguous antecedent -- the
current node or the report-to endpoint)?  Nodes that can reach the current
node might not be able to reach the report-to endpoint, and nodes that can
reach the report-to endpoint might not be able to reach the current node.

The condition is also much stronger than 'forwarded over unidirectional
*link*' -- it's more like 'forwarded over unidirectional path into a black
hole'.  Is it worth trying to come up with a better / more descriptive
reason code?

    --keith

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 29 Mar 2016 18:54:54 +0000

I think the reason (10 years ago, or thereabouts) for saying “back to this node” rather than “to the report-to endpoint of the bundle” was to alert the receiver of this status report that the node(s) to which the bundle was being forwarded would not be able to take custody of the bundle, because no custody acceptance signal could be sent back to the current custodian (the node issuing this status report).

I do not remember why this was judged important enough to merit a special reason code, but I don’t think it had anything to do with subsequent status reports not reaching the report-to node – if it did, then there would be no point in limiting this notice to bundles for which custody had been accepted, right?

The description of the reason code actually seems okay to me, because there’s no reason to assume that the *next* node in the path to the destination (the one after the proximate receiver) and/or other downstream nodes would be unable to send bundles to the current custodian and/or report-to.  It’s not necessarily a black hole.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Keith Scott
Sent: Tuesday, March 29, 2016 9:27 AM
To: [email-masked]
Subject: [dtn] Forwarding over Unidirectional Links

In the bpbis-03 draft, section 5.4(step 6) says that if a bundle that requests reporting of bundle forwarding and for which the current node is the custodian (custody acceptance constraint is set) is forwarded to only nodes that are known to unable to send bundles back tot his node then the bundle forwarding report should carry the reason code 'forwarded over unidirectional link'.
Should / could the first bullet under step 6 say:  '...all of the nodes to which the bundle was forwarded are known to be unable to send bundles to the report-to endpoint of the bundle, then...'?  ('unable to send bundles back to this node' seems to have a somewhat ambiguous antecedent -- the current node or the report-to endpoint)?  Nodes that can reach the current node might not be able to reach the report-to endpoint, and nodes that can reach the report-to endpoint might not be able to reach the current node.
The condition is also much stronger than 'forwarded over unidirectional *link*' -- it's more like 'forwarded over unidirectional path into a black hole'.  Is it worth trying to come up with a better / more descriptive reason code?

    --keith

---

From: Keith Scott <[email-masked]>
Date: Tue, 29 Mar 2016 15:08:42 -0400

OK, so this is saying that if this node has taken custody and forwards to
only nodes that won't be able to tell this node that they have taken
custody, AND if the bundle requests forwarding status reports, then this
node should include in its forwarding report to the report-to eid that the
bundle has been forwarded such that this node is likely to be stuck with
custody until the bundle times out.  I suppose that might be useful for
diagnostics in rare cases.

  --keith

On Tue, Mar 29, 2016 at 2:54 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

> I think the reason (10 years ago, or thereabouts) for saying “back to this
> node” rather than “to the report-to endpoint of the bundle” was to alert
> the receiver of this status report that the node(s) to which the bundle was
> being forwarded would not be able to take custody of the bundle, because no
> custody acceptance signal could be sent back to the current custodian (the
> node issuing this status report).
>
>
>
> I do not remember why this was judged important enough to merit a special
> reason code, but I don’t think it had anything to do with subsequent status
> reports not reaching the report-to node – if it did, then there would be no
> point in limiting this notice to bundles for which custody had been
> accepted, right?
>
>
>
> The description of the reason code actually seems okay to me, because
> there’s no reason to assume that the **next** node in the path to the
> destination (the one after the proximate receiver) and/or other downstream
> nodes would be unable to send bundles to the current custodian and/or
> report-to.  It’s not necessarily a black hole.
>
>
>
> Scott
>
>
>
> *From:* dtn [mailto:[email-masked]] *On Behalf Of *Keith Scott
> *Sent:* Tuesday, March 29, 2016 9:27 AM
> *To:* [email-masked]
> *Subject:* [dtn] Forwarding over Unidirectional Links
>
>
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 29 Mar 2016 19:20:45 +0000

… until the bundle times out *or* it reaches some downstream node that is (somehow) able to send bundles back to the current custodian.  But yes, that sounds like a plausible origin for this clause.

Scott

From: Keith Scott [mailto:[email-masked]]
Sent: Tuesday, March 29, 2016 12:09 PM
To: Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn] Forwarding over Unidirectional Links

OK, so this is saying that if this node has taken custody and forwards to only nodes that won't be able to tell this node that they have taken custody, AND if the bundle requests forwarding status reports, then this node should include in its forwarding report to the report-to eid that the bundle has been forwarded such that this node is likely to be stuck with custody until the bundle times out.  I suppose that might be useful for diagnostics in rare cases.

  --keith

On Tue, Mar 29, 2016 at 2:54 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
I think the reason (10 years ago, or thereabouts) for saying “back to this node” rather than “to the report-to endpoint of the bundle” was to alert the receiver of this status report that the node(s) to which the bundle was being forwarded would not be able to take custody of the bundle, because no custody acceptance signal could be sent back to the current custodian (the node issuing this status report).

Scott

From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Keith Scott
Sent: Tuesday, March 29, 2016 9:27 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn] Forwarding over Unidirectional Links

    --keith

---

From: Keith Scott <[email-masked]>
Date: Wed, 30 Mar 2016 07:54:53 -0400

But if some downstream node can get back to the current node (which is also
a custodian) then one of the next-hop nodes can get to it (by forwarding
through the downstream node)?  But yes, your *OR* works in the case that
there are downstream routing opportunities to get back to the current node
that are unknown to the current node.

I originally interpreted this as trying to tell the current report-to node
that it was unlikely to receive more status reports, as the bundle was
being forwarded across a boundary into an area where the nodes were known
(to the current forwarding node) to not be able to reach the report-to
node.  That might be useful information, but it's not really something the
current node can be expected to know in the general case.

What are we really trying to do with this and is it useful enough to keep?
Seems like it imposes a burden on every custodian forwarding bundles with
report-to EIDs to do the routing check, if nothing else.

    --keith

On Tue, Mar 29, 2016 at 3:20 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

> … until the bundle times out **or** it reaches some downstream node that
> is (somehow) able to send bundles back to the current custodian.  But yes,
> that sounds like a plausible origin for this clause.
>
>
>
> Scott
>
>
>
> *From:* Keith Scott [mailto:[email-masked]]
> *Sent:* Tuesday, March 29, 2016 12:09 PM
> *To:* Burleigh, Scott C (312B) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [dtn] Forwarding over Unidirectional Links
>
>
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 30 Mar 2016 14:52:21 +0000

Sure, I would be fine with losing this; it does impose some cost, and the benefit is not at all clear.  Let’s discuss on Monday and excise it if it has no champions.

Scott

From: Keith Scott [mailto:[email-masked]]
Sent: Wednesday, March 30, 2016 4:55 AM
To: Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn] Forwarding over Unidirectional Links

But if some downstream node can get back to the current node (which is also a custodian) then one of the next-hop nodes can get to it (by forwarding through the downstream node)?  But yes, your *OR* works in the case that there are downstream routing opportunities to get back to the current node that are unknown to the current node.

I originally interpreted this as trying to tell the current report-to node that it was unlikely to receive more status reports, as the bundle was being forwarded across a boundary into an area where the nodes were known (to the current forwarding node) to not be able to reach the report-to node.  That might be useful information, but it's not really something the current node can be expected to know in the general case.

What are we really trying to do with this and is it useful enough to keep?  Seems like it imposes a burden on every custodian forwarding bundles with report-to EIDs to do the routing check, if nothing else.

    --keith

On Tue, Mar 29, 2016 at 3:20 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
… until the bundle times out *or* it reaches some downstream node that is (somehow) able to send bundles back to the current custodian.  But yes, that sounds like a plausible origin for this clause.

Scott

From: Keith Scott [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 29, 2016 12:09 PM
To: Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Forwarding over Unidirectional Links

  --keith

Scott

    --keith

---

From: Carlo Caini <[email-masked]>
Date: Wed, 30 Mar 2016 21:14:11 +0000

Dear Scott and Keith,
     A couple of years ago, a student of TUM (Munich), went in visit to Bologna and actually studied a case where the situation was exactly what Scott has considered after the "or", if I am not wrong. The space asset was node A, which was connected to a terrestrial gateway B via a unidirectional link A->B with a huge bandwidth. B in turn was connected to the MCC C via B-C. the MCC was connected to A via a bidirectional link with very limited bandwidth, so only the direction C->A had to be used. A could not receive the custody acceptance from B directly, as the link A->B was unidirectional. However, it could receive it via C. I cannot remember if there was a report-to or not. In this case it cold have been C. The status report would have informed C that the bundle had been forwarded by A trough a unidirectional link. Being the MCC, C likley was already aware of that...
A and B were aware of the C->A link.
The case was not academic. They had this "problem" in Munich.
Anyway, I agree that it is a bit weird....
Carlo

________________________________________
Da: dtn [[email-masked]] per conto di Burleigh, Scott C (312B) [[email-masked]]
Inviato: mercoledì 30 marzo 2016 16.52
A: Keith Scott
Cc: [email-masked]
Oggetto: Re: [dtn] Forwarding over Unidirectional Links

Scott

    --keith

Scott

  --keith

Scott

    --keith

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