Alia, thinks for a very useful message that answered several of my questions. I hope the reasoning can be captured somewhere.
/js On Wed, Jun 10, 2015 at 12:15:46PM -0400, Alia Atlas 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. > > 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. > > 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. > > Thanks, > Alia > </no-hat> > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
