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

["Burleigh, Scott C (US 312B)" <[e-mail]>]

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: [e-mail] <[e-mail]>
Sent: Tuesday, June 8, 2021 1:07 AM
To: Burleigh, Scott C (US 312B) <[e-mail]>
Cc: [e-mail]
Subject: RE: [EXTERNAL] [dtn] draft-ietf-dtn-bibect-03 issues

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)" <[e-mail]<mailto:[e-mail]>>
To:        "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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



From: dtn <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, May 21, 2021 1:55 AM
To: [e-mail]<mailto:[e-mail]>
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: [phone] | Email: [e-mail]<mailto:[e-mail]>

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 ([e-mail]<mailto:[e-mail]>).