Open ektrah opened 5 years ago
There is text in the LWIG-COAP document. To be determined how this is referenced or moved to the corr/clar document. Start at a random point, not always at zero. Server still needs to be prepared to get random MIDs.
The LWIG-CoAP cabo mentioned has some text currently in 2.3.3 on MID "relaxation on the server". We might want to expand a bit on how "designed with idempotent operations only and makes good use of the If-Match/If-None-Match options" works in practice; not sure where that can go and whether normative IETF documents or tutorial-/FAQ-style texts are the right place for this. (Especially, idempotency in presence of multiple client interactions like in the last paragraph of one mail in the linked thread may need some illustrative examples)
The "sequential MIDs" are outlined in section 3.5, including a recommendation that clients produce sequential MIDs, and are largely aligned with what Marian has suggested but keep it at a recommendation level. The text is a bit incomplete IMO, but that's not for here to discuss but for https://github.com/lwig-wg/coap/issues/4.
"Where the text lives"-wise, I think LWIG is still suitable due to its implementation-guidance character, but it might be a good idea to pull "RECOMMEND that CoAP endpoint implementers employ the “sequential MID” scheme if there are no reasons to prefer another scheme" into Corrections, and have Clarifications point towards LWIG a la "Devices of Class 1 often do not need to exercise message deduplication, as their applications are usually designed to have idempotent requests; see LWIG-CoAP Section 2.3.3. If deduplication is still unavoidable, they may want to optimize for sequential MIDs as per LWIG-CoAP Section 3.5".
within EXCHANGE_LIFETIME MUST be strictly ascending (wrapping around at a value of 65535)
If the MUST includes the 65536
, I object to comply with 8.1. Multicast CoAP -
Messaging Layer some implementations use reserved special ranges. So I would prefer no fixed upper border.
Good point.
Though it raised again in the e-mail list:
Additionally, two subsequently send Message IDs to the same endpoint SHOULD have a difference of at most 16.
Assuming, that some peers give up after some retries without having the message with the MID delivered, this may also be too strict. Maybe adding a "time range" for that will help to fix it. Anyway, even if I see the benefit, such a feature would in my opinion be more something for CoAP v2 ;-).
If we consider this optimization, I guess we need to consider core-wg/corrclar#15 as relaxing variant as well.
Errata ID: 5429 Type: Technical Reported By: Marian Buschsieweke Date Reported: 2018-07-18
Section 4.4 says/should say:
Without any restrictions on how Message IDs are generated, an implementation of CoAP duplication detection must be prepared to receive a random sequence of Message IDs. One simple implementation strategy would be to store the received Message IDs along with a timestamp when they were received.
If a 16 bit time stamp would be used, 4 Bytes per tracked Message ID would be required. If additionaly a CoAP server expects requests to be received at a rate of 1 message per second, at least 247 * 4 Byte or approximately 1 KiB have to be allocated per client. A class 1 (see RFC 7228 Section 3) server could handle at most 10 clients in parallel, if anything apart duplicate detection could be implemented without using any memory at all.
If instead Message IDs have to be generated by incrementing a (global or per endpoint/network prefix/...) counter variable, duplicate detection can be implemented in a time and memory efficient way without limiting the rate of the message exchange between to nodes.