Juergen: Would Jeff's ephemeral state be a reasonable place to put it.
Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Juergen Schoenwaelder Sent: Sunday, June 14, 2015 8:51 AM To: Alia Atlas Cc: [email protected] Subject: Re: [i2rs] storage of priority and client ID with a node 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
