Each client can count q up to half(?) the q limit as an optimization

[rikard-sics]

As suggested during the CoRE interim. This works fine with responses with no partial IV since they will be counted in that senders q counter. Each request can only have max one response without PIV. For Observe notifications they will have a PIV (except maybe the first).

[rikard-sics]

"Pure" servers do not need to count q, since the client will count for them? Server only needs to count responses with Partial IV? Ask Christian to clarify.

[rikard-sics]

Do we even need to halve q?

[rikard-sics]

Savings is that server does not need to count q for responses without Partial IV? So SSN can be used directly on server.

[rikard-sics]

Also need to look at SSN + replay window (received requests implying responses sent without partial IV)

[rikard-sics]

Revisit this with Christian

Point is that counting up to half q means counting your own messages with PIV and the other parties messages without PIV. So the client and server counts each other's messages without PIV.

No messages should be missed in the counting. (Whether they are observations or not.)

Cases: Observation Echo procedure

[rikard-sics]

Needs further discussion.

[rikard-sics]

The point is you don't even need a count_q, just use your SSN?

[rikard-sics]

https://hackmd.io/sOliRiyGQT-OmjxbprN9XA
(see Efficient counting of ‘q’ for OSCORE AEAD limits)

[rikard-sics]

What is the maximum overestimation for the solution in the HackMD? Feedback from Göran during the CoRE interim on April 28 was 2x (double), which makes sense to me also.

[rikard-sics]

Summarized and added in new issue about optimizations: #19