Summary

  • The IETF CoAP multicast Observe draft, revision 17, dated 2 November 2026, proposes sending one notification to a group observing the same resource. It remains an active Internet-Draft.
  • Its Feedback-Divider option draws replies from a random fraction of interested clients. Each client replies with probability 1 / 2^Q; the server receives R confirmations and computes the indicator E = R × 2^Q.
  • The draft's example begins with an estimated 32 observers. Eighteen are actually active; five decide to answer and one response is lost. Four arrivals produce an indicator of 16 and, with the example's dampener set to one, a new estimated count of 16. That is a calculation in the draft, not a measured network.

Picture a broker publishing a change to one resource watched by dozens of small devices. Under CoAP Observe, RFC 7641, each client can register to receive updates. Sending a separate response to each listener makes the sender's work grow with the audience. The new draft gives the server another choice: group those listeners and send one multicast notification. The saving is obvious. Less obvious is what the sender now knows about its crowd.

The proposal uses a shared Token for the group observation. The server creates a phantom Observe request locally to anchor that group state; no ghost device sends it across the network. Interested clients learn the group parameters and listen for notifications. A sent packet is one event at the server. It is not a roll call at every receiver. The server therefore maintains an observer counter as a rough estimate and may use that number when deciding whether it is still worth keeping the group observation alive.

The answer comes from a sample, not a head count

Section 8 of revision 17 describes its way to ask the crowd whether it remains. A multicast notification carries Feedback-Divider with value Q. Each client that supports the option and wants to continue draws a random integer from zero up to, but excluding, 2^Q. Only a zero draw causes a unicast Observe registration back to the server, after a random delay. The option avoids a storm in which every receiver answers the same broadcast at once.

The server counts replies that arrive and qualify as confirmations, calling the number R. It multiplies R by 2^Q to form E. If one quarter of interested clients were invited to answer, four received replies suggest sixteen clients; they do not certify sixteen. Some invited clients may not reply, and some replies may disappear in transit. The draft says packet loss skews the estimate. Even a perfect random draw produces sampling variation. The server trades exact per-client feedback for lower traffic and an approximate denominator.

The counter has another moving part. New clients may join while the feedback round runs. The draft takes the current counter COUNT', compares the newly inferred E with the earlier estimate N, and adjusts by (E − N) / D, where D is a positive integer dampener. It requires the update to be atomic with respect to new registrations. Otherwise, the server could erase a new listener while correcting an old estimate. The formula is an operating rule for an estimate, not a receipt that any client received the notification that carried it.

The draft's numerical example makes the uncertainty concrete. The server believes 32 observers are active and chooses Q=2, so each has a one-in-four chance to answer. Eighteen clients are actually active. Five draw a reply, but one reply is lost. The server receives four, extrapolates to 16 and moves its counter from 32 to 16 when D=1. It keeps the group active. The true 18 in that example belongs to the author of the illustration; an operating server would have only the four arrivals and its assumptions.

A cheaper notification creates a different control problem

The server can set Q=0, inviting all active clients to confirm. That spends more reply traffic and still leaves packet loss. It can ask less often, accept a noisier counter and save network capacity. It can apply a larger dampener to move the estimate more slowly. The application sets the policy for when to ask again and when to cancel group observation. Those are product and operational choices with a visible consequence: cancel too early and a listener expecting shared notifications may need another path; keep an empty group alive and the network saving shrinks.

RFC 7252 defines the CoAP message machinery underneath. The proposed multicast extension changes the economics of distributing Observe updates, while its count estimates interest rather than receipt. For a temperature dashboard, approximate audience size might be enough to choose a transport. For an emergency instruction, a sampled interest counter cannot establish which device accepted, processed or acted on a particular message. An operator should name that difference before using the same mechanism for both jobs.

The official packet has no measured deployment showing how the estimate behaves under a real loss pattern. A controlled test would record actual active clients, selected replies, lost replies and delivered notifications on the same timeline. It would then test the cancellation threshold against those records. The protocol's bargain is already legible: one alert for everyone saves traffic; the server's knowledge of “everyone” comes back by lottery.

CoAP multicast Observe draft · Datatracker record · RFC 7641 · RFC 7252