Subject: Re: [dtn] [EXTERNAL] draft-ietf-dtn-bibect-03 issues

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 4 Jun 2021 14:52:30 +0000

Felix, thanks for these.  I'm working on the next edition of this draft and have modified it per your points 1(b) and 2.

I think the language you object to in 1(a) is pretty close to correct, though.  "Instantiation" is the construction of the node's initial state.  The state of the node might or might not reside in some genuinely non-volatile medium, such as disk storage.  If it does, then restarting the node would mean resuming operation of the node starting from its current state as retrieved from that non-volatile medium; in this case, the CTCs would be elements of node state and custodial transmission counting would correctly resume from the current value.  If not - that is, if the node is truly re-instantiated - then there is no way to retain the values of the CTCs from the moment at which the node was stopped; the counts must be initialized to zero.  Do you see an alternative?

Scott

From: dtn <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, May 21, 2021 1:55 AM
To: [email-masked]
Subject: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues

Hi,

I have spotted two issues in draft 3 of the Bundle-In-Bundle Encapsulation:

1)  Custodial Transmission Count

The CTC is defined in 3.2 as:

     1. A "custodial transmission count" (CTC).  A CTC is a
        monotonically increasing integer indicating the number of
        custodial BPDUs that have been issued to this BIBE node by the
        local node since instantiation of the local node.

a) To have the CTC as the number of BPDUs since the instantiation of the local node might be problematic in cases where the local node is re-started because the CTC is later used as 'Transmission ID' which should be unique over some time frame.

b) In the definition above, the CTC is defined per custodial node. However, later it is stated:

"The transmission ID for a BPDU for which custody transfer IS
   requested SHALL be the current value of the local node's custodial
   transmission count, plus 1."

To me, this seems to indicate a single CTC per local node.

Scott confirmed that the first interpretation is correct (one CTC per custodial node), so this text should be updated. It may still make sense to require increasing of the transmission id by 'plus 1' only as this allows more efficient custody signals.

2) Section 3.4 defines:

A  "custody transfer status report" is a bundle status report with the "reporting node attempted custody transfer" flag set to 1.

This flag and issuing this status report is described nowhere. I assume this section should be removed.

Regards,
Felix

_________________________________________
ESA - European Space Agency
Dr. Felix Flentge
Software Engineer, OPS-GSB
Ground Systems Engineering Department
Directorate of Operations
ESA - ESOC
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany
Phone: +49 6151 90 4075 | Email: [email-masked]<mailto:[email-masked]>

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or

protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received

this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect

personal data, in case of data privacy queries, please contact the ESA Data Protection Officer ([email-masked]<mailto:[email-masked]>).

---

From: [email-masked]
Date: Tue, 8 Jun 2021 10:07:16 +0200

Scott, two thoughts on this:

1) Actually, the term "instantiation" might not be precise enough. I have 
checked the BPv7 specification and found:

In the most familiar case, a bundle node is instantiated as a single
process running on a general-purpose computer, but in general the
definition is meant to be broader: a bundle node might alternatively
be a thread, an object in an object-oriented operating system, a
special-purpose hardware device, etc.

>From that I understood "instantiation" as "creation of an instance of a 
process/thread/object/etc". 
So, restarting a bundle node process would count as 'instantiation of the 
local node' (a new process is created) and I would have to reset the CTC 
to zero. 

2) If we cannot resume from the 'current value', re-starting from zero 
might be the best option in most cases. However, there may be some cases 
where we would like to initiatialise the CTC differently, eg:
- we can use DTN Time mod x in cases where we know to have low bundle 
rates (ie less then 1 bundle/second)
- if we receive a custody signal for a bundle which we don't have in our 
CTDB (because we reset to zero), we might want to set the CTC to the 
largest Transmission ID in the scope of the report plus some offset

Maybe we should clearly separate between the CTC as a counter and the 
Transmission ID. The Transmission ID shall be unique per destination node 
for the lifetime of the encapsulating bundle (there are cases where this 
cannot be guaranteed). I think we might not even have to require that it 
is always increased by one. It's just that the whole custody signalling 
would become less efficient. Also, I might jut want to maintain a single 
transmission ID counter if I know I will be only communication to a single 
destination entity for some time and then to another one. So, these 
entities might see 'gaps' in the Transmission IDs but that would be fine.

Felix

From:   "Burleigh, Scott C (US 312B)" <[email-masked]>
To:     "[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Date:   04/06/2021 16:52
Subject:        RE: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues

Felix, thanks for these.  I?m working on the next edition of this draft 
and have modified it per your points 1(b) and 2.
 
I think the language you object to in 1(a) is pretty close to correct, 
though.  ?Instantiation? is the construction of the node?s initial state. 
The state of the node might or might not reside in some genuinely 
non-volatile medium, such as disk storage.  If it does, then restarting 
the node would mean resuming operation of the node starting from its 
current state as retrieved from that non-volatile medium; in this case, 
the CTCs would be elements of node state and custodial transmission 
counting would correctly resume from the current value.  If not ? that is, 
if the node is truly re-instantiated ? then there is no way to retain the 
values of the CTCs from the moment at which the node was stopped; the 
counts must be initialized to zero.  Do you see an alternative?
 
Scott

Hi, 

I have spotted two issues in draft 3 of the Bundle-In-Bundle 
Encapsulation: 

a) To have the CTC as the number of BPDUs since the instantiation of the 
local node might be problematic in cases where the local node is 
re-started because the CTC is later used as 'Transmission ID' which should 
be unique over some time frame. 

b) In the definition above, the CTC is defined per custodial node. 
However, later it is stated: 

Scott confirmed that the first interpretation is correct (one CTC per 
custodial node), so this text should be updated. It may still make sense 
to require increasing of the transmission id by 'plus 1' only as this 
allows more efficient custody signals. 

2) Section 3.4 defines: 

A  "custody transfer status report" is a bundle status report with the 
"reporting node attempted custody transfer" flag set to 1. 

This flag and issuing this status report is described nowhere. I assume 
this section should be removed. 

Regards, 
Felix 

_________________________________________ 
ESA - European Space Agency 
Dr. Felix Flentge 
Software Engineer, OPS-GSB 
Ground Systems Engineering Department 
Directorate of Operations 
ESA - ESOC 
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany 
Phone: +49 6151 90 4075 | Email: [email-masked]
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer ([email-masked]).

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 8 Jun 2021 19:51:10 +0000

Hi, Felix.  I will agree that there is some infelicity in language here, but the problem is the use of "instantiated" in the sentence you quote.  A BP node is explicitly expected to be able to retain outbound protocol data units in some sort of storage medium while awaiting a transmission opportunity; these retained bundles are elements of the node's state.  A BP implementation that discarded all node state upon the termination of a single process or thread would be a fragile and generally useless implementation.

I think it would be more accurate to say that a bundle node is a data structure, instantiated within some storage medium, that is animated by the spawning of a process or group of processes, or a thread or group of threads, etc.  The temporary cessation of the node's active operation should not cause the node's state to be discarded, and the subsequent re-animation of the node is very different from re-instantiation.

It's a little bit like a Starbucks franchise.  A Starbucks might be instantiated as a store front, a kiosk, a lunch counter inside a bookstore, etc.  When you instantiate your Starbucks, you sign a lease, purchase equipment and supplies, and hire staff.  When you animate it, you invite customers and your staff begin taking and filling orders.  At night you close - de-animate - the shop: the lights are turned off and the staff go home.  The next morning the shop is re-animated, not re-instantiated.

So restarting a bundle node process might indeed be a re-instantiation of that node, resetting the CTC to zero, but such an implementation of BP might not attract many users.

Scott

From: [email-masked] <[email-masked]>
Sent: Tuesday, June 8, 2021 1:07 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]
Subject: RE: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues

1) Actually, the term "instantiation" might not be precise enough. I have checked the BPv7 specification and found:

>From that I understood "instantiation" as "creation of an instance of a process/thread/object/etc".
So, restarting a bundle node process would count as 'instantiation of the local node' (a new process is created) and I would have to reset the CTC to zero.

2) If we cannot resume from the 'current value', re-starting from zero might be the best option in most cases. However, there may be some cases where we would like to initiatialise the CTC differently, eg:
- we can use DTN Time mod x in cases where we know to have low bundle rates (ie less then 1 bundle/second)
- if we receive a custody signal for a bundle which we don't have in our CTDB (because we reset to zero), we might want to set the CTC to the largest Transmission ID in the scope of the report plus some offset

Maybe we should clearly separate between the CTC as a counter and the Transmission ID. The Transmission ID shall be unique per destination node for the lifetime of the encapsulating bundle (there are cases where this cannot be guaranteed). I think we might not even have to require that it is always increased by one. It's just that the whole custody signalling would become less efficient. Also, I might jut want to maintain a single transmission ID counter if I know I will be only communication to a single destination entity for some time and then to another one. So, these entities might see 'gaps' in the Transmission IDs but that would be fine.

Felix

From:        "Burleigh, Scott C (US 312B)" <[email-masked]<mailto:[email-masked]>>
To:        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:        04/06/2021 16:52
Subject:        RE: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues
________________________________

Scott

From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, May 21, 2021 1:55 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues

Hi,

2) Section 3.4 defines:

Regards,
Felix