Max Polling Time in CoAP

[egekorkan]

Similar to Modbus, some CoAP devices also have a maximum polling time they support due to their resources. This means that the consumers are advised/recommended not to poll more frequently.

The devices in question are using TD 1.1 so it can only be in the CoAP binding. Once the use cases start, I will propose this as a new term for TD.

[egekorkan]

Also related to #215

[JKRhb]

Edit: I marked this comment as outdated as @ektrah provided a better and more accurate response.

I think this use case is probably not as relevant for CoAP as it is for Modbus, as CoAP Observe theoretically only requires one request by the client, for which the server can then send multiple responses. Therefore, no polling by the client is required to receive regular updates in this case, as the server will send a new response once a new value can be reported. If the client is not interested anymore, it can simply ignore the incoming responses or send a deregistration request. See RFC 7641 for more information in this regard.

However, there might be cases where a CoAP server does not implement Observe and actually has to be polled. Maybe you could specify for cases like this in a more general sense that a property is updated in a certain time interval? That would imply that you can send a new request after a certain has passed.

Then again, though, in the case of CoAP you have a Max-Age option at the protocol level which implies that a response can be cached for a certain amount of time (also see the section on caching in the current version of the CoAP Binding Template Document). Therefore, you would not necessarily need this information in the TD, although it might still be useful for a consumer.

[benfrancis]

Related, but in the other direction: Event rate limiting for Webhooks.

[ektrah]

Polling is a valid use case in CoAP, although in many cases Observe offers better performance. (In fact, a typical client implementation is to poll for as long as the client is interested in having a current resource state representation, setting the Observe option each time. As long as the client is receiving notifications, it doesn't need to poll; as soon as the notifications are missing, the client polls again with the Observe option set.)

The freshness of the resource state representations is independent of how often a client polls. For example, if a CoAP resource reflects the current position of a moving aircraft, after less than a second it can no longer be assumed that the aircraft is still in the same position. This means the server would set Max-Age to 0 in the response. Nevertheless, the server may not want the client to request the current position more often than every three seconds.

If a client polls too frequently, a server may send a 4.29 (Too Many Requests) response. This error response is cacheable, with the Max-Age indicating after which time the client is allowed to try again.

I think it makes sense to be able to specify in TDs how frequently a client is allowed to poll a CoAP resource without running into a 4.29 response (for resources for which such a statement can be made).

In other words, the CoAP feature of interest is the 4.29 (Too Many Requests) error response, and the corresponding element in the TD would be the information that saves the client the round trip. I would be in favor of adding that.