On Wed, Jun 10, 2015 at 9:15 AM, Alia Atlas <[email protected]> wrote: > <no-hat> > As I mentioned in the virtual interim, I'd like to explain a little further > about what I see as semantics and desired behavior around the storing and > managing of priority and client ID. > > First, the priority mechanism is intended to handle "error cases of > colliding writes" in a predictable way that results in a consistent > mechanism. It is true that the same mechanism could be used if they weren't > considered "errors". I think this is a nice property - but it is also > important to minimize the impact of the priority mechanism. > > Second, if there is a priority conflict where both clients (Client_A and > Client_B) share the same priority, the client that wrote first wins. This > is to avoid network oscillation if two clients are "fighting" over writing > the same state. When there are multiple clients and the time arrival of the > messages may not be predictable (network transit differences, which socket > is read, software differences), basing state on last arrival time doesn't > give consistent and predictable behavior. >
Neither does "first wins". It is just as arbitrary and based on the same unpredictable network. I think the "higher priority wins" could be useful for I2RS where multiple applications are touching the same RIB data structures. This is a new twist -- competing configuration management apps don't usually occur so it has not been an issue for NETCONF. > That gives behavior as in the following time-line: > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_B attempts to write X=K with priority 10 and is rejected > Time_3: Client_A writes X=P with priority 10 and succeeds > > For the I2RS Agent to properly handle these actions, it is necessary to know > that X is owned by Client_A. Priority alone is not sufficient because the > basis for rejecting Client_B's write but accepting Client_A's write is that > Client_A is the owner. > > Thus, I believe that it is necessary to store the Client Identity with the > nodes that it owns. > This could be in an I2RS-specific overlay that is only used by the I2RS > agent and only contains the nodes that have been written by I2RS. > IMO a tie is an error (as Joel put it). First one in a tie or last one in a tie is just as arbitrary and unpredictable. Last one does not require saving the client. First one does. But IMO it is useful to save the client so it can be returned in meta-data or filtered (e.g. GET(all-for-client-A)), so first-one wins is not a big deal to support. > Third, a question has come up regarding what the behavior of priority is if > a client's priority changes and whether priority needs to be stored with > each node when that node is written. > > In my "keep-it-simple" perspective, priority is associated with a Client and > is only used on a conflict. This would mean that priority isn't stored with > a node when that node is written. Instead, the Client Identity is stored > with the node and the Client's priority is looked up in a client table that > the I2RS Agent can access. That client table could be populated via > configuration, via a AAA protocol, via NACM, etc. > > The semantic implications are as follows: > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 > * Time_3: Client_B writes X=K with priority 8 (succeeds since 8 > 6) > * Time_4: Client_A attempts to write X=N with priority 6 (fails b/c 8 >> 6) > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 > Time_6 Client_B writes X=P with priority 7 and succeeds (same owner, > no priority check) > > The alternate approach would have store the priority with which a node was > written. That is more like a priority lock that could only be changed by a > client with higher priority or by the same client, regardless of priority. > This approach would require storing a priority per node and the semantic > implications would be as follows: > > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 > * Time_3: Client_B attempts to write X=K with priority 8 and fails (10 >> 8) > * Time_4: Client_A writes X=N with priority 6 & succeeds (same owner, > no priority check) > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 > Time_6 Client_B writes X=P with priority 7 and succeeds (7 > 6) > > The behavior for these two models is different at Time_3 and Time_4. > > I'd like to see if there's agreement that the first model (priority stored > with client) is acceptable or if the second model (priority stored with > node) is necessary. I think the first model is OK. > > Thanks, > Alia > </no-hat> > > Andy > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
