Subject: [i2rs] storage of priority and client ID with a node

From: Alia Atlas <[email-masked]>
Date: Wed, 10 Jun 2015 12:15:46 -0400

<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>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jun 2015 10:15:57 -0700

On Wed, Jun 10, 2015 at 9:15 AM, Alia Atlas <[email-masked]> wrote:
> 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.
>
> 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.

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.

> 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.
>

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.

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.

> 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.

>       Time_6   Client_B writes X=P with priority 7 and succeeds (same owner,
> no priority check)
>
>  *    Time_3:  Client_B attempts to write X=K with priority 8  and fails (10
>> 8)

I think the first model is OK.

> </no-hat>

Andy

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 10 Jun 2015 14:54:11 -0400

Hi Andy,

On Wed, Jun 10, 2015 at 1:15 PM, Andy Bierman <[email-masked]> wrote:

> weren't
> the

[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.

> 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.

> know

[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.

> or filtered (e.g. GET(all-for-client-A)), so first-one wins is not

Agreed that saving the client can be useful for filtering or monitoring
apps.

> and
> owner,
> (10

 Thanks,
Alia

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jun 2015 13:19:36 -0700

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 14 Jun 2015 14:51:03 +0200

Alia,

thinks for a very useful message that answered several of my
questions. I hope the reasoning can be captured somewhere.

/js

-- 
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/>

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 14 Jun 2015 14:59:10 -0400

Juergen: 

Would Jeff's ephemeral state be a reasonable place to put it. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Sunday, June 14, 2015 8:51 AM
To: Alia Atlas
Cc: [email-masked]
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.
> 
> weren't considered "errors".  I think this is a nice property - but it 
> is also important to minimize the impact of the priority mechanism.
> 
> 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.
> 
> 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 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:
> 
> 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>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Jun 2015 14:38:10 -0400

> Would Jeff's ephemeral state be a reasonable place to put it. 

The ephemeral state draft is one possibility.  A second one would be a
standalone draft meant to serve as an appendix on this point for the
architecture.

-- Jeff