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

[[e-mail]]

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]>
To:     "[e-mail]" <[e-mail]>, "[e-mail]" 
<[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]> On Behalf Of [e-mail]
Sent: Friday, May 21, 2021 1:55 AM
To: [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]
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]).