Subject: [core] FW: #281: Safe-to-forward options (correction)

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 19 Feb 2013 02:16:51 +0000

"It seems that taking account of the token this the problem would be similar."

should have been

"It seems that without taking account of the token the problem would be similar."

---

Hi Esko, Klaus, Robert, all,

As I understand this, tokens and sequence numbers are independent. This means that the server could maintain a single counter for all resources, or maybe one counter per resource, or maybe one counter per resource per subscriber. It is up to the server implementation how to maintain the counters, as long as they are monotonically increasing except for the carry around 2^24.

The current proposal is to use the tokens as part of the identifier for the observation relationship, so the tuple (ip, port, token, resource) describes this. To change this observation relationship, the same token should be used. Another token would identify another observation relationship.

Indeed if the server reboots and looses state, it would restart counting and the ordering could be messed up. However, since the server lost its state, it is likely that the server will not send any more observation notifications. When the client realises this, it can re-establish the observation relationship, with a token as it prefers.

There indeed is a small chance that the client does not realise something happened to the server (e.g. reboot) that messed up the sequence numbers. I guess the only time that this is a problem is, when the client wants to modify the observation relationship without knowledge about the server's reboot. In this case, the client could send a GET with observe option and the previous token. Instead of modifying the non-existent observation relationship, the server establishes a new observation relationship. This may lead, depending on the server's implementation, to a restart of the counter and discontinuity in monotonically increase.

But does this have anything to do with adding token to the tuple? It seems that without taking account of the token the problem would be similar.

Corner case? If not, one could consider adding the last received sequence number to the observe request too, such that the server has knowledge about the last sequence number the client has received, and send some error when it is inconsistent. I am not sure if it is worth the complexity though.

What do you think?

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: 14 February 2013 17:41
To: Dijk, Esko
Cc: [email-masked] WG
Subject: Re: [core] #281: Safe-to-forward options

Esko Dijk wrote:
>> No. The token functions as a generation identifier for the sequence numbers, so you always need
>> to use a new token if you want to refresh an existing observation.
>
> To me it's not yet clear why the sequence numbers need to be "reset" by the server upon refresh (i.e. new generation). Couldn't it just keep counting on? In any case, there's no requirement for the server to start at a specific number, or not? If so it could just keep counting.

Yes, the server could keep counting on; then it wouldn't be a problem.
But currently the server is *not required* to keep counting on. The
client must use a token to give the server the freedom of choosing
between whether it counts on or not. Counting on may be difficult if
the server reboots and loses state.

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