Need more specific details of TARGET_DEFINED mode

[ashu-ciena]

As per the spec, the definition of target defined mode is as follows:

Target Defined (TARGET_DEFINED) - when a client creates a subscription specifying the target defined mode, the target MUST determine the best type of subscription to be created on a per-leaf basis. That is to say, if the path specified within the message refers to some leaves which are event driven (e.g., the changing of state of an entity based on an external trigger) then an ON_CHANGE subscription may be created, whereas if other data represents counter values, a SAMPLE subscription may be created.

Question 1: If the target decides, that the mode of subscription should be sample, where is the sample interval coming from?

Question 2: If the target decides the sample interval as well for the sample mode of subscription, does the sample interval need to remain constant throughout the life of the subscription ? Or it can be escalated to a new higher value to slow down streaming when the CPU/memory load on the target is high? and bring back to original number when target settles down to normal values?

Question 3: If the change in sample interval during live subscription violates the spec and the load on the target is high, can we skip streaming data on that sample timer expiry and resume as soon as target recovers from shortage of resources?

Question 4: Is it advisable to send gRPC status code RESOURCE_EXHAUSTED / DATA_LOSS on those sample timer expiry when the target is going through high CPU load and streaming the data with in the sample interval is not feasible.  I believe, the session should remain alive from target side even after sending gRPC status code to the client. Some implementation prefer to terminate the RPC session, not sure if it is right or wrong as it is not clear in the gnmi spec as well.

Question 5: Can the approach in Q3 and Q4 be taken in case of non target defined mode (normal sample subscription) as well?

Question 6: Once I had an email exchange with @gcsl on target defined behavior, he indicated the objective is to send the subscribe response as soon as possible. Does that translate to varying sample interval in a, "as fast as possible delivery"  manner?

Question 7: If Q (2) is true where in target decides the sample interval as well, can we keep it higher enough so that in future, on addition of new subscription, this value need not change? Also, can we restrict new subscription to subscribe only on same or higher sample interval value to protect ourselves (target) from going out of service?

[earies]

IMO it is worth raising the question if TARGET_DEFINED should be deprecated as-is. If anything, this should not have been in the initial spec until thorough discussion and analysis had been done from both consumers and implementors (which was not done).

As a client, this mode is so loose that there is no longer an understood contract and there is currently no means in which one can determine expected behaviors or runtime adjustments.

[ashu-ciena]

@dplore
Can we discuss this in the Thursday call of OpenConfig Community meeting? When can this be included in the agenda?

[earies]

@dplore Can we discuss this in the Thursday call of OpenConfig Community meeting? When can this be included in the agenda?

Suggest adding to the agenda for the next mtg here:

https://docs.google.com/document/d/11sXUF2zujhbPs_bt-RFJhh2DcIbEvnOpd9GypE-u3cc/edit?tab=t.0#heading=h.xzit9nc89pp

[dplore]

Q1: The target defines this, the client has no control or expectation of what the interval must be. (idea: an interval could be configured through configuration, but there are not any leaves specifically defined today to do this. load-interval comes to mind as similar to this)

Q2: The target may change the interval without notifying the client.

Q3,4: The target defines this behavior. No error is required to be emitted if there are issues in meeting the subscription during the TARGET_DEFINED description.

Q5: in SAMPLE mode, if the interval is not supported, the specification requires sending a gRPC error (invalid argument)

Q6: The target defines when the samples will be sent, so not necessarily as fast as possible. The subscribe response should be sent to ack the request quickly.

Q7: In TARGET_DEFINED, the target may change it's interval dynamically. In SAMPLE mode, the target must not change the interval. However, it's noted if the SAMPLE interval cannot be met temporarily, data loss should be expected.

[dplore]

Closing this issue as I think the question are answered? Note that @ashu-ciena volunteered to submit a PR to elaborate on the gnmi specification for ON_CHANGE.

[ashu-ciena]

The PR is raised for the documentation change - openconfig/reference#227