Hi Andy, On Wed, Jun 10, 2015 at 1:15 PM, Andy Bierman <[email protected]> wrote:
> 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. > [Alia] Sure - but doing "first wins" in the event of the same priority ensures that it won't oscillate. Doing "last arrival time" lets it oscillate. 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. [Alia] Agreed - IMHO, a network operator would assign different priorities to each client so that the conflicts with the same priority don't happen. I can see different clients managing different services or such. > > 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. > [Alia] I agree that last one wouldn't require saving the client - but it also wouldn't prevent oscillations if there were two clients fighting over writing their state. 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. > Agreed that saving the client can be useful for filtering or monitoring apps. > > 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 > > > > > 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
