Translation capacity is a tuple and state budget

A TCP flow is commonly identified by protocol and source/destination address-port pairs. A translator rewrites the internal source address and port to an external pair and retains enough state to translate replies back to the correct internal endpoint. Two internal clients can use the same local source port because their internal addresses differ. When both contact the same remote address and port through one external address, the translated flows need distinguishable external source ports in the simple model used here.

Mapping and filtering behavior must be distinguished by protocol. An endpoint-independent mapping can reuse an external pair for the same internal endpoint across different remotes. That differs from simultaneous port overloading between distinct internal endpoints, which RFC 5382 forbids for TCP. Therefore 65,536 port values are neither a universal usable pool nor a universal global connection ceiling. Reserved ranges, configured limits, per-subscriber port blocks, collision handling, and quotas can reduce the effective budget. Inspect the documented behavior and actual allocation counters.

Translation state has a lifecycle. Active connections, half-open attempts, recently closed TCP state, and idle UDP mappings can remain allocated according to protocol and implementation rules. A burst of short-lived requests can therefore consume many more mappings than the application's instantaneous active-request count suggests. Longer retention protects delayed traffic and protocol correctness, while shorter retention can cause premature reuse or lost replies. Do not treat indiscriminate timer reduction as a free capacity improvement.

Under a stable arrival process, Little's law relates average retained mapping count to allocation rate times mean retention time, provided the counting boundaries match. Count mappings, not packets, and include the whole measured residence interval. If one application request reuses a connection, several requests may share one mapping; if one request fans out, it may allocate many. Connection pooling can lower allocation churn but introduces its own concurrency and idle-lifetime choices. Validate the effective mapping demand instead of assuming a fixed requests-to-ports ratio.

Port pressure often first appears as connection-establishment failure or delay, while existing connections continue. Collect allocation failures by external address, destination tuple, protocol, and tenant, alongside state-table occupancy and interface throughput. A large aggregate free count can conceal a saturated per-destination or per-subscriber pool. Packet captures on both sides of the translator can distinguish a request that never received a mapping from a reply that was translated incorrectly or filtered. Return routing also matters because stateful translation expects replies to encounter the appropriate state.

In the queue lab, interpret arrivals and service as abstract mapping-allocation and release work. For each separate comparison, press Reset, set both λ and μ, predict the direction of the normalized fluid backlog, then Play or Step. The display starts with four work units; it has no port identifiers, protocol states, reuse rules, or finite capacity ceiling. Its backlog is not a NAT occupancy forecast. Use the illustration to distinguish arrival/release imbalance from bandwidth, then use measured retention distributions and the actual tuple-allocation rules for production capacity planning.