Subject: Re: [dtn] Bundle Dispatching and Local Bundle Delivery

From: Lucas Kahlert <[email-masked]>
Date: Thu, 14 Sep 2017 12:04:14 +0200

Hi,

it's me again. I see how a loopback mechanism is provided by the CLA. 
But I have encountered another problem with the current Bundle 
Dispatching specification:

If a bundle is locally delivered in step 1 of "5.3 Bundle Dispatching", 
"5.7 Local Bundle Delivery" does not state that the other steps in 5.3 
should be skipped. Hence, after a local delivery of a bundle, the BPA 
proceeds with step 2 of 5.3, which is continuing with "5.4 Bundle 
Forwarding". And because the bundle is destined for the current node, it 
would be routed and send to the current node again because there is no 
information about a previous delivery (at least not specified in BPbis). 
My question is: when does this process terminate? I see a potential 
infinite loop here.

I have created a flow chart for BPbis [1], you can see the potential 
loop, when the CLA in "5.4 Bundle Forwarding" invokes "5.6 Bundle 
Reception" for a local bundle (loopback).

Regards,
Lucas

[1]: https://upcn.eu/Bundle_Protocol.png

On 28.08.2017 22:43, Burleigh, Scott C (312B) wrote:
> Hi, Lucas.  I think the current text is actually correct here: it is precisely by proceeding directly to 5.4 instead of 5.3 that we support true loopback capability.  The outbound bundle is passed to the forwarding function, which selects a next-hop destination (the local node) and passes the bundle to the convergence-layer adapter for convergence-layer transmission to the next-hop destination; the bundle is then received at the convergence layer at the next-hop destination (the local node) and passed up to the local node's bundle protocol agent; the local node's BPA thereupon invokes 5.3, dispatching and thus delivering the bundle.  If we move directly from 5.2. to 5.3 we bypass all of the BP processing, simulating loopback without actually performing it.
> 
> Scott
> 
> -----Original Message-----
> From: dtn [mailto:[email-masked]] On Behalf Of Lucas Kahlert
> Sent: Monday, August 28, 2017 4:39 AM
> To: [email-masked]
> Subject: Re: [dtn] Bundle Transmission -> Bundle Dispatching
> 
> Hello,
> 
> I come across the following problem as part of a formalization of the Bundle Protocol:
> 
> As I understand: "5.2 Bundle Transmission" is the entry point / interface of the "Bundle Protocol Agent" to the upper layers.
> 
> 5.2 Bundle Transmission states in step 2 to proceed with "5.4 Bundle Forwarding" (already RFC 5050 states to proceed with "Bundle
> Forwarding") but I think the procedure should proceed with "5.3 Bundle Dispatching".
> 
> The motivation is the following use case:
> An "Application Agent" should be able to send bundles to itself (loopback capability). This should be implementation-independent.
> It is required for loopback bundles that a they get dispatched because local delivery is only possible during the "5.3 Bundle Dispatching"
> procedure. If "Bundle Transmission" proceeds directly with "Bundle Forwarding" there is no possibility for local delivery.
> 
> Regards,
> Lucas
> 
> On 23.06.2017 00:34, Burleigh, Scott C (312B) wrote:
>> Hi.  I just posted an updated BPbis specification that I think
>> addresses nearly all of the comments on which we reached consensus,
>> either over email or at IETF 98.  The one exception I can think of is
>> the request to add references to formal definitions for CRC-16-ANSI
>> and CRC-32, which I omitted because on a quick search I wasn't able to
>> find any; if anyone knows where those definitions live, please speak up.
>>
>> I think we may have two quite different approaches on the table for
>> defining custody transfer outside of the BP specification.  I will be
>> posting one of them in a few minutes and hope to post the other
>> sometime tomorrow.
>>
>> Scott
>>
>>
>>
>> _______________________________________________
>> dtn mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dtn
>>
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

---

From: Lucas Kahlert <[email-masked]>
Date: Thu, 14 Sep 2017 13:26:20 +0200

Hi,

in section "5.4.2 Forwarding Failed" step 1 it is stated that the BPA 
may forward the bundle back to the EID specified in the Previous Node Block.

A routing decision has to be made for this Previous Node Block EID but 
the destination EID of the bundle is not changed. This means that the 
routing component of the BPA has to consider a different EID then the 
destination of a bundle.

In the BPbis flow chart [1] I had to introduce a special "$send_to" 
parameter for the "5.2 Bundle Transmission" which is quite confusing.

Another problem: if the forwarding to the previous node fails (which 
means that "5.4.2 Forwarding Failed" is executed) we have a potential loop.

Maybe the specification should describe such a "Send back" mechanism is 
more detail?

Regards,
Lucas

On 23.06.2017 00:34, Burleigh, Scott C (312B) wrote:
> Hi.  I just posted an updated BPbis specification that I think addresses 
> nearly all of the comments on which we reached consensus, either over 
> email or at IETF 98.  The one exception I can think of is the request to 
> add references to formal definitions for CRC-16-ANSI and CRC-32, which I 
> omitted because on a quick search I wasn’t able to find any; if anyone 
> knows where those definitions live, please speak up.
> 
> posting one of them in a few minutes and hope to post the other sometime 
> tomorrow.
> 
> Scott
> 
> 
>

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 18 Sep 2017 05:29:13 +0000 (UTC)

Hi Lucas

from looking at the spec...

the bundle loops until bundle age is considered too old, or until hop count increment
reached the defined threshold. There are in sections 4.3.2 and 4.3.3 of
https://tools.ietf.org/html/draft-ietf-dtn-bpbis-08

though hop count is not mentioned in section 5.5. And whether loopback
increments hop count when forwarding to yourself (i.e. not 'another node'
as the draft states) is not specified; you're not another node,
so don't increment this? So bundle age it has to be,
because hop count isn't considered here, and the hop
count stuff is ambiguous anyway.

Now, section 4.3.1 - previous node - is an obvious way to recognise loopback,
but is not called out in section 5.5 either. So, given
that bundle age is all there is, loop for a week, or a
month, or whatever until the looping ages out, draining
battery as you do.

I'd argue the draft needs reworking in light of these
concerns, though my concerns would not be limited to just
these.

tschuess

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

________________________________
From: Lucas Kahlert <[email-masked]>
To: [email-masked] 
Sent: Thursday, 14 September 2017, 20:05
Subject: Re: [dtn] Bundle Dispatching and Local Bundle Delivery

Hi,

Regards,
Lucas

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 18 Sep 2017 05:35:24 +0000 (UTC)

Oh, and 'prevent routing loops' is still to do, apparently.
But it's a good idea!

https://sourceforge.net/p/ion-dtn/feature-requests/49/
'Routing loops must be avoided in "critical" bundle forwarding as well.' 

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

________________________________
From: Lloyd Wood <[email-masked]>
To: Lucas Kahlert <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, 18 September 2017, 15:29
Subject: Re: [dtn] Bundle Dispatching and Local Bundle Delivery

Hi Lucas

tschuess

Lloyd Wood

Hi,

Regards,
Lucas

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 18 Sep 2017 15:28:04 +0000

Excellent catch, Lucas.  I think the fix for this is to insert the following language at the end of Step 1 of 5.3: "...and for the purposes of all subsequent processing of this bundle the node's membership in the bundle's destination endpoint SHALL be negated."  Good?

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Lucas Kahlert [[email-masked]]
Sent: Thursday, September 14, 2017 4:26 AM
To: [email-masked]
Subject: Re: [dtn] Forwarding Failed and Previous Node

Hi,

Regards,
Lucas

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 18 Sep 2017 15:33:34 +0000

Wups, sorry, this is my proposed fix to your other email, "Re: Bundle Dispatching and Local Bundle Delivery".

For this email ("Forwarding Failed and Previous Node") I again agree that a fix is needed.  Here I would propose to add the following line to the end of Step 1 of section 5.4.2: "This forwarding SHALL be accomplished by performing Step 4 and Step 5 of section 5.4."

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Burleigh, Scott C (312B) [[email-masked]]
Sent: Monday, September 18, 2017 8:28 AM
To: Lucas Kahlert; [email-masked]
Subject: Re: [dtn] Forwarding Failed and Previous Node

Scott

Hi,

Regards,
Lucas

---

From: Lucas Kahlert <[email-masked]>
Date: Sun, 24 Sep 2017 13:59:48 +0200

Hello again :)

The direct jump to step 4 and 5 of section 5.4 solves the issue with the 
loop. Another question: Should Bundle Age and Hop Count blocks 
nonetheless be processed? I think they should.

But there is another problem: The spec assumes in its current form that 
the bundle can directly send back to the previous node. But what if the 
bundle was received over a unidirectional link or the next contact with 
the previous node is in the future? This would require - again - a 
routing decision. How to handle this case?

Regards,
Lucas

---

From: William Ivancic <[email-masked]>
Date: Sun, 24 Sep 2017 21:10:42 -0400

IMHO, I think it is foolish to assume you can send back to a previous node.   In a Disconnected network, that node may no longer be there.  It appears many have different notions of what the concept or concepts of operations and none of these is written down in a DTNWG document.

Will

On 9/24/17, 7:59 AM, "dtn on behalf of Lucas Kahlert" <[email-masked] on behalf of [email-masked]> wrote:

    Hello again :)

    
    Regards,
    Lucas