<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
