String or Integer for Subscription ID

[ericvoit]

Reasons for Integer
(1) Speed for notification message processing: Comparing two numbers is magnitudes faster than comparing two strings (representing the same numbers). Because of the sorting and forwarding of incoming messages on the receiver so that they go to the right requesting application.

(2) Size: A subscription id based on characters will be much larger than transport based on integer. We have IoT drafts relating to CBOR.

(3) Segmentation Administration simplicity (1) Configured subscriptions and Dynamic subscriptions share the same identifier space. Split is just the number space.

(4) Easier to generate IDs

Reasons for String
(1) Tradition in YANG for identifiers

(2) Easier to read domain segmentation

[ericvoit]

Updated issues list to mailer:

[A] Integer

---

(A1) Efficiency of notification message processing: Comparing two numbers is magnitudes faster than comparing two strings (representing the same numbers). Sorting and forwarding of incoming messages on the receiver so that they go to the right requesting application will be faster.

(A2) Size: A subscription id based on characters will be larger than transport based on integer. As we have IoT drafts relating to CBOR, we should look at efficiency.

(A3) Easier to automatically generate IDs for dynamic subscriptions. Enables easier conventions for sequential issuance of subscription-ids which can then be interpreted by subscriber

(A4) Can augment (or add now in the base model) a leaf containing a string definition of a configured subscription. This string would be passed as part of the "subscription-started" notification, so there would be no need to query the publisher for a meaning. Greater verbosity and redundancy in text definitions would then both be allowed. This text only need be passed once, and can be safely ignored by the receiver implementations.

(A5) Low power IoT receivers. Many small receivers of the same subscription might consume the same feed with a minimally sized, easier to process header. (Henk can provide sources for the use cases here.)

(A6) Subscription ID in the OpenConfig.yang model is also an integer (uint64) See line 584 of: https://github.com/openconfig/public/blob/master/release/models/telemetry/openconfig-telemetry.yang
Implementations supporting both model exposures will need to worry less about mapping.

[B] String

---

(B1) Easier to read and understand the sub-domain segmentation of the subscription-id space, as well as the creation of new sub-domains

(B2) If Kent's question on the possibility of encoding frequently sent text fields in CBOR as integer comes back as viable, then the Size advantages of [A] go away

[C] union of integer and string.

---

As there are additional processing requirements in the receiver and key issues in the publisher, this would seem to have processing inefficiencies. Does anyone want to argue for this?

[ericvoit]

Per Rob's note, OC-Telemetry.yang actually uses a separate string based key for configured subscriptions. This does complicate life for the receiver.

[ericvoit]

Re-summarizing based on discussions.

[A] Integer

---

(A1) + Efficiency of notification message processing:

(A2) + Message Size:

(A3) + Easier to automatically generate IDs for dynamic subscriptions

(A4) + Addition of a leaf containing an optional string definition of a configured subscription. This string would be passed as part of the "subscription-started" notification.

(A5) + Low power IoT receivers. Many small receivers of the same subscription might consume the same feed with a minimally sized, easier to process header. (Henk can provide sources for the use cases here.)

(A6) - Dividing the integer space in two (can consider Henk's option of moving from uint32 to int32, and requiring configured subscriptions to use negative numbers.)

[B] String

---

(B1) + Easier to read and understand the sub-domain segmentation of the subscription-id space, as well as the creation of new sub-domains

(B2) - Loss of transport efficiencies in IoT as CBOR does not currently support the compression of frequently used strings to integer.

[C] string for config, integer for dynamic, integer on wire

---

(C1) ++++ four of the advantages of [A]: (A1), (A2), (A3), (A5)

(C2) - use of different tables for different object names in receiver

(C3) - automated subscription correlation across different receivers a little more complex as the automatically assigned integer wouldn't be the same across publishers. Could still derive it from "subscription-started" notification.

(C4) - some state change notifications become more complex as they must support different types of subscription ids within the notification (subscription-suspended, subscription-resumed, subscription-terminated, replay-completed.)

(C5) - will still require a separate configuration and operational tree in any NMDA compliant conversion

[ericvoit]

Closed as integer based on rough consensus on the mailing list

[ericvoit]

Note: a question came up from Rob after the issue closure. This was that it is possible to have another option which allows an integer to be assigned from a reserved space only when you need to track that id consistently over time. Otherwise a dynamic id would be assigned. While there are advantages to this, they still hit the issue of a segmentation of reserved integer space. It also still needs a separate configuration tree in an NMDA complaint model. Based on this, that option was not captured in the main options above. But it was considered.