Summary

  • The 2 October revision of the NMOP SIMAP concepts draft adds REQ-CONGESTION: a future protocol binding must keep its own traffic from causing persistent congestion. Revision 13 did not contain this named requirement.
  • Congestion-controlled transports such as TCP-based bindings satisfy the draft's transport condition. A binding without transport congestion control, illustrated by UDP, must instead operate in a controlled environment with pre-provisioned or reserved capacity and a bound on server-generated traffic. This is a proposed requirement in an active Internet-Draft, not an approved standard or evidence of an outage.

The promise of a current map creates a less visible dependency. Every refresh, topology request or subscription consumes some of the same network whose condition the map is meant to reveal. If obtaining a better picture worsens the underlying condition, data freshness and operational safety are no longer the same achievement. The latest revision of the Service & Infrastructure Maps, or SIMAP, concepts draft makes that tension explicit.

draft-ietf-nmop-simap-concept-14, dated 2 October 2026, inserts REQ-CONGESTION into section 4.3. A SIMAP protocol binding must ensure its traffic cannot cause persistent congestion. The preceding revision lacked this clause. The new text identifies congestion-controlled transports, including TCP-based bindings, as satisfying the condition at the transport layer. It also describes the more constrained case: if a binding lacks transport congestion control, with UDP given as an example, deployment must be confined to controlled environments with pre-provisioned or reserved capacity, and the server's generated volume must be bounded.

That distinction is narrower than a ban on UDP and broader than a suggestion to make responses small. The draft does not choose one binding, specify a numerical rate cap, or establish that a UDP implementation has been deployed. A TCP-based transport is one example of congestion control, not a certificate that a whole map service is otherwise trustworthy. The clause places responsibility for persistent congestion at the binding and deployment boundary, where bursts, subscriptions and topology size become actual traffic.

The draft already had a separate REQ-PERFORMANCE. It calls for efficient access to large topologies, including incremental, filtered or paginated retrieval and, where appropriate, streaming or subscriptions. Those mechanisms can reduce needless data movement or improve responsiveness. They do not, by themselves, answer whether the traffic pattern respects congestion. A paginated query can still be repeated too aggressively; a stream can still generate more than a reserved path can carry. Treating the old performance language as the new safety requirement would erase the real revision.

RFC 8085 provides the UDP background cited by the draft: UDP does not supply inherent congestion control, so an application using it must take responsibility for appropriate control. The SIMAP addition draws a deployment line for non-congestion-controlled bindings rather than announcing a new version of that RFC. It also says nothing about a live failure, universal capacity floor or approved IETF interoperability test. Those absences matter because the operational decision is not “switch protocols now.” It is to ask what traffic evidence a proposed map binding can supply before the map is treated as safe to rely on.

A useful acceptance record would separate three questions: how fresh the map is, how complete its view is, and what load its queries and updates impose under the expected topology and subscription count. For a binding without transport congestion control, the record should also identify the controlled environment, reserved capacity and enforceable server-output bound. That is an editorial way to apply the proposed requirement, not a named IETF certification procedure. The draft remains an active NMOP working-group Internet-Draft intended to be Informational; Datatracker shows it awaiting AD follow-up, not an approved RFC.

The new clause changes the governance of a map from a data-quality issue to a resource-allocation issue as well. A service can report the network accurately and still lack permission to flood it with observations. The map's own traffic budget is part of the map's credibility.

Sources