> Susan Hares, June 01, 2016 12:04 PM > > I2RS WG: > > Two replacements for Ephemeral-REQ-05: > > Option 1: > I2RS pub-sub, logging, RPC or other mechanisms may lead to undesirable or > unsustainable resource consumption on a system implementing an I2RS Agent. > It is RECOMMENDED that mechanisms be made available to permit prioritization > of I2RS operations, when appropriate, to permit implementations to shed work > load when operating under constrained resources. An example of such a work > shedding mechanism is rate-limiting. > > Option 2: > Ephemeral state handling, notifications, and OAM could increase the data flow > rates across transport, or the rate of publication of data in a > subscription, or logging needed for traceability. It is RECOMMENDED that > the I2RS Agent should have the ability to limit, prioritize or split data > flows in the > I2RS protocol. > > Any feedback?
In the Yang-push and Event notification technology drafts being worked in NETCONF we have mechanisms to accomplish the functions in both Options 1 & 2 (except for the splitting of data flows, which perhaps might be addressable in the transport layer). These mechanisms include: (1) negotiation of subscription parameters (2) relative prioritization for dequeuing of subscription updates as well as absolute prioritization of one subscription relative to another for dequeuing of subscription updates (direct match to mechanisms of HTTP2) (3) DSCP by subscription, which could be used for selecting which subscriptions prioritize across a device should processing resources reach some limit. (4) notification to a subscriber of suspension of push updates for a subscription (as well as resumption of updates) Looking at the thread, we likely should include optional parameters in (4) which so that the notification indicates that the suspension occurred due to resource exhaustion. This would allow the subscriber to select whether it wishes to re-enter the negotiation phase for push updates in a way that might consume fewer resources. This renegotiation would occur in parallel to the existing push update process. Eric > Sue > > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Jeffrey Haas > Sent: Wednesday, June 01, 2016 12:05 PM > To: [email protected] > Subject: [i2rs] draft-ietf-i2rs-ephemeral-state-09, Ephemeral-REQ-05 > > As per the interim, here is some suggested text changes: > > Existing text: > > Ephemeral-REQ-05: Ephemeral state handling and notifications could > increase need for CPU processing, data flow rates across a transport, > or the rate of publication of data in a subscription or the logging > for traceability. The I2RS Agent SHOULD have the ability to > constraints for OAM functions operating to limit CPU processing, data > rate across a transport, the rate of publication of data in a > subscription, and logging rates; and the I2RS Agent SHOULD have the > ability to prioritize some of the management data flows between the > I2RS Agent and I2RS Client. In order to constrain resources needed, > the I2RS Agent MAY also schedule data flows or split data flows unto > multiple data flow streams. > > Suggested new text: > > I2RS pub-sub, logging, RPC or other mechanisms may lead to undesirable or > unsustainable resource consumption on a system implementing an I2RS Agent. > It is RECOMMENDED that mechanisms be made available to permit prioritization > of I2RS operations, when appropriate, to permit implementations to shed work > load when operating under constrained resources. An example of such a work > shedding mechanism is rate-limiting. > > ----- > > Note that Subscription QoS in the pub-sub requirements provides for this type > of > behavior in that context. > > -- Jeff > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
