On Wed, Jun 10, 2015 at 11:54 AM, Alia Atlas <[email protected]> wrote: > 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. >
OK -- I forgot I2RS clients might be coded to send an edit if they get the notification for "your data was deleted". If 2 with the same priority do that, they will oscillate. NETCONF is more set-it-and-forget-it. Andy >> 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
