Real-time communication across the modern Internet requires transporting high-definition audio, video streams, and arbitrary binary data between web browsers with glass-to-glass latencies strictly under 200 milliseconds. For decades, telecommunications and web architectures relied on centralized, client-server models where all client traffic traversed intermediate streaming media gateways. While conceptually simple, centralized architectures introduce severe bandwidth costs, single points of failure, geographic network routing inefficiencies, and heightened privacy vulnerabilities.
WebRTC (Web Real-Time Communication), standardized jointly by the W3C and the IETF, fundamentally transforms this paradigm by establishing direct, bidirectional, peer-to-peer (P2P) media and data channels natively inside web browsers without external plugins or proprietary runtimes. However, establishing a direct socket connection between two arbitrary consumer endpoints over the public Internet is extraordinarily difficult. Because the global IPv4 address space is exhausted, nearly all consumer devices reside behind enterprise firewalls and Network Address Translators (NATs) that actively block unsolicited inbound connections.
This guide provides an exhaustive, university-grade examination of peer-to-peer communication architecture. We explore the structural limitations of traditional client-server media delivery, dissect the mechanics of Network Address Translation (NAT) and Port Address Translation (PAT), analyze the formal four-fold taxonomy of NAT behaviors, derive the mathematics of UDP hole punching, and evaluate the transport-layer protocol stack powering WebRTC.
Client-Server vs. Peer-to-Peer Communication Topology#
To understand the architectural necessity of WebRTC, we contrast the bandwidth, latency, and operational dynamics of centralized client-server networks with decentralized peer-to-peer topologies.
+---------------------------------------------------------------------------------------------------+
| Client-Server vs. Peer-to-Peer Topologies |
+---------------------------------------------------------------------------------------------------+
| 1. Centralized Client-Server Relay Architecture |
| Peer A (Sydney) -----------> [ Central Media Server (Virginia) ] -----------> Peer B (Melbourne)
| Latency: RTT(Sydney -> Virginia) + RTT(Virginia -> Melbourne) ≈ 380 ms |
| Server Bandwidth: 2 · Bitrate (Server pays egress and ingress bandwidth) |
| |
| 2. Direct Peer-to-Peer (WebRTC) Architecture |
| Peer A (Sydney) <=======================================================> Peer B (Melbourne) |
| Latency: Direct Geographical Route (Sydney -> Melbourne) ≈ 15 ms |
| Server Bandwidth: 0 bytes/sec (Server handles only tiny initial signaling setup) |
+---------------------------------------------------------------------------------------------------+The Client-Server Bottleneck#
In a traditional client-server model (e.g., RTMP, HLS, or early VoIP systems):
- Bandwidth Explosion: The central server infrastructure must ingest every participant's audio and video stream and duplicate it to all receiving peers. For a platform serving millions of simultaneous calls, cloud egress bandwidth costs scale linearly with active minutes:
Bandwidth = ∑ [calls] Bitrate · Participants. - Path Stretch Latency: If two users in the same office building in Tokyo initiate a video call, but the central media server is deployed in North Virginia (
us-east-1), packets must travel across trans-Pacific undersea fiber-optic cables twice. The round-trip time (RTT) spikes from < 5 ms locally to over 300 ms, destroying conversational fluidity. - Privacy Exposure: Because the server terminates transport connections, unencrypted or server-decrypted media frames reside in server memory, exposing conversations to eavesdropping, regulatory inspection, and subpoena risks.
The Peer-to-Peer Advantage#
WebRTC establishes an encrypted direct socket between Peer A and Peer B:
- Zero Infrastructure Media Cost: Audio and video packets flow directly across peering Internet Service Providers (ISPs), completely bypassing application servers.
- Minimal Physical Latency: Packets traverse the shortest geographical BGP routing path between endpoints.
- End-to-End Cryptographic Privacy: Media is encrypted directly on the client workstation using DTLS/SRTP; no intermediate third party can intercept the raw plaintext media stream.
The IPv4 Exhaustion Crisis & The Rise of NAT#
The fundamental barrier to direct peer-to-peer networking is the architectural structure of the Internet itself. When the Internet Protocol Version 4 (IPv4) was formalized in 1981 (RFC 791), its 32-bit address space yielded a theoretical maximum of 2^32 = 4,294,967,296 unique addresses—vastly inadequate for the billions of smartphones, laptops, servers, and IoT devices connected today.
RFC 1918 Private IP Address Spaces#
To conserve public addresses, the Internet Engineering Task Force (IETF) reserved three blocks of IPv4 address space exclusively for private local area networks (LANs):
- Class A Private Range:
10.0.0.0to10.255.255.255(10.0.0.0/8, 16,777,216 addresses) - Class B Private Range:
172.16.0.0to172.31.255.255(172.16.0.0/12, 1,048,576 addresses) - Class C Private Range:
192.168.0.0to192.168.255.255(192.168.0.0/16, 65,536 addresses)
Routers on the public Internet backbone are explicitly configured to drop any packet destined for or originating from an RFC 1918 private address.
Network Address Translation (NAT / NAPT)#
To enable devices on a private LAN to communicate with the public Internet, residential routers and enterprise gateways implement Network Address and Port Translation (NAPT):
[ Private LAN: 192.168.1.0/24 ] [ Public Internet ]
Laptop (Private IP: 192.168.1.50:48201) Web Server (Public IP: 93.184.216.34:443)
| ^
v |
+------------------------------------------+ |
| NAT Gateway Router (Public IP: 198.51.100.25) |
| NAT State Translation Table: | |
| Internal IP:Port <-> External IP:Port | |
| 192.168.1.50:48201 <-> 198.51.100.25:52000 | -----------------------+
+------------------------------------------+- Outbound Packet Rewriting: When Laptop
192.168.1.50opens a socket on port48201destined for web server93.184.216.34:443, the packet hits the local NAT gateway. - Translation Entry Allocation: The NAT allocates an unused ephemeral public port (e.g.,
52000), creates an entry in its internal translation state table, rewrites the packet header's Source IP and Source Port to198.51.100.25:52000, recomputes the IP/TCP checksums, and forwards the packet onto the public Internet. - Inbound Reply Demultiplexing: When the web server replies to
198.51.100.25:52000, the NAT inspects its table, translates the destination back to192.168.1.50:48201, and forwards it across the local Ethernet/Wi-Fi subnet.
The Fundamental P2P Dilemma: The End-to-End Principle Breakdown#
The NAT architecture functions seamlessly for client-server web browsing because all connections are initiated outbound from behind the NAT.
However, consider two WebRTC peers:
- Peer A: Laptop sitting behind Home Router A (
Internal IP: 192.168.1.50,Public NAT IP: 198.51.100.25). - Peer B: Laptop sitting behind Home Router B (
Internal IP: 10.0.0.12,Public NAT IP: 203.0.113.88).
Peer A cannot simply send a packet to 10.0.0.12 because 10.0.0.12 is non-routable on the public Internet. Nor can Peer A send a packet to Router B's public address 203.0.113.88:48201, because Router B's NAT translation table contains zero entries for Peer A; Router B's firewall will immediately drop the unsolicited inbound packet as potentially malicious port scanning!
The Four-Fold Taxonomy of NAT Behaviors#
To solve the P2P connection problem, the IETF rigorously classified NAT implementations based on how they allocate external mapping ports and how strictly they filter inbound packets (RFC 3489, RFC 4787, and RFC 5389).
+----------------------------------------------------------------------------------------------------+
| NAT Behavioral Classification Matrix |
+-------------------+----------------------------+-----------------------------+---------------------+
| NAT Type | Mapping Allocation Rule | Inbound Packet Filtering | P2P Hole Punching |
+-------------------+----------------------------+-----------------------------+---------------------+
| Full-Cone NAT | 1 External Port for all | Any external host/port | Trivial (100% |
| (One-to-One) | destinations | can send once opened | success rate) |
| Restricted-Cone | 1 External Port for all | Inbound allowed ONLY from | High success rate |
| (Address-Restricted)| destinations | IP addresses previously sent| |
| Port-Restricted | 1 External Port for all | Inbound allowed ONLY from | High success rate |
| Cone NAT | destinations | exact IP AND Port sent to | |
| Symmetric NAT | Fresh random External Port | Inbound allowed ONLY from | Fails between two |
| (Destination-Dep) | for EVERY distinct dest | exact destination host/port | symmetric NATs |
+-------------------+----------------------------+-----------------------------+---------------------+1. Full-Cone NAT (One-to-One Mapping)#
Once an internal endpoint (IP_int:Port_int) sends an initial packet to any external destination, the NAT allocates a permanent public mapping (IP_pub:Port_pub).
- Filtering Rule: Any external host on the Internet can subsequently send packets to
(IP_pub:Port_pub), and the NAT will faithfully forward them to(IP_int:Port_int). - Full-Cone NATs represent the most permissive NAT topology, commonly found in residential routers with DMZ (Demilitarized Zone) enabled.
2. Restricted-Cone NAT (Address-Restricted)#
Like Full-Cone NAT, all outbound packets from (IP_int:Port_int) are mapped to the identical external (IP_pub:Port_pub), regardless of destination.
- Filtering Rule: An external host
(IP_ext:Port_ext)can send packets to(IP_pub:Port_pub)if and only if the internal host has previously sent an outbound packet toIP_ext(any port on that IP address). - Packets originating from uncontacted IP addresses are silently dropped.
3. Port-Restricted Cone NAT#
A more stringent variation of Restricted-Cone NAT, ubiquitous in consumer home Wi-Fi routers.
- Filtering Rule: An external host
(IP_ext:Port_ext)can send packets to(IP_pub:Port_pub)if and only if the internal host has previously sent an outbound packet to the exactIP_extandPort_ext. - If Peer A sends a packet to Peer B's port 5000, Peer B can reply from port 5000, but cannot send from port 5001.
4. Symmetric NAT (Enterprise / Mobile 4G/5G)#
Symmetric NAT is the most restrictive NAT implementation, universal in enterprise corporate firewalls, university networks, and mobile carrier-grade NAT (CGNAT) environments.
- Mapping Rule: The NAT does not reuse the same public port mapping across different destinations!
* Outbound to Server S1 (198.51.100.1:3478) -> Mapped to (203.0.113.25:40001).
* Outbound to Peer B (203.0.113.88:5000) -> Mapped to (203.0.113.25:40002).
- Because the external port changes dynamically for every distinct destination IP:Port combination, an external host cannot predict which port the symmetric NAT will assign.
UDP Hole Punching Mechanics#
UDP Hole Punching is the foundational algorithmic technique that enables two endpoints sitting behind NATs to establish a direct bidirectional socket without administrative firewall reconfiguration.
+---------------------------------------------------------------------------------------+
| UDP Hole Punching Flow |
+---------------------------------------------------------------------------------------+
| Peer A (Port-Restricted NAT A) Peer B (Port-Restricted NAT B)
| [ Private: 192.168.1.10:4000 ] [ Private: 10.0.0.5:5000 ] |
| [ Public: 198.51.100.25:61001 ] [ Public: 203.0.113.88:62002 ]
| \ / |
| \ 1. Query STUN: "Who am I?" / |
| v v |
| +-------------------------------------------------------------+ |
| | STUN Server (Public Internet) | |
| +-------------------------------------------------------------+ |
| | | |
| | 2. STUN replies with Public Reflexive Endpoints | |
| v v |
| +-------------------------------------------------------------+ |
| | Signaling Channel (WebSocket Server) | |
| | 3. Peers exchange public endpoints: | |
| | Peer A gets (203.0.113.88:62002) | |
| | Peer B gets (198.51.100.25:61001) | |
| +-------------------------------------------------------------+ |
| | | |
| | 4. Peer A sends UDP to 203.0.113.88:62002 | |
| | - NAT A creates outbound translation entry | |
| | - Packet hits NAT B and is DROPPED (Hole punched in A)| |
| | | |
| | 5. Peer B sends UDP to 198.51.100.25:61001 | |
| | - NAT B creates outbound translation entry | |
| | - Packet hits NAT A: MATCHES existing state! | |
| v - Packet passes through to Peer A! v |
| +=========================================================+ |
| | DIRECT BIDIRECTIONAL P2P SOCKET OPENED! | |
| +=========================================================+ |
+---------------------------------------------------------------------------------------+Step-by-Step Traversal Protocol#
- Reflexive Address Discovery: Both Peer A and Peer B send an initial UDP probe to an external public STUN server. The STUN server reflects back their public IP and Port addresses:
* Peer A: 198.51.100.25:61001
* Peer B: 203.0.113.88:62002
- Out-of-Band Signaling Exchange: Peers exchange these reflexive candidates via a central signaling server (e.g., via WebSockets).
- Simultaneous Punch Initiation:
Peer A sends a UDP packet from its local socket to Peer B's public endpoint `203.0.113.88:62002`. When this packet exits NAT A, NAT A records an outbound state: outbound traffic to 203.0.113.88:62002 is authorized; allow inbound replies from this exact address. When the packet arrives at NAT B, NAT B drops it because NAT B has not yet registered outbound traffic to Peer A. However, the hole in NAT A is now open*.
* Simultaneously, Peer B sends a UDP packet from its local socket to Peer A's public endpoint 198.51.100.25:61001. NAT B creates its corresponding state table entry.
* When Peer B's packet arrives at NAT A, NAT A inspects its state table, recognizes 203.0.113.88:62002 as an authorized source, and permits the packet to pass directly to Peer A!
* Peer A receives the packet and replies. NAT B now permits Peer A's reply.
Bidirectional peer-to-peer communication is fully established!*
Why Symmetric-to-Symmetric Hole Punching Fails#
If Peer A is behind a Symmetric NAT:
- When Peer A contacted the STUN server, NAT A allocated port
61001. - When Peer A subsequently attempts to send a packet to Peer B, NAT A sees a new destination IP:Port and allocates a new, different port (e.g.,
61002). - Peer B attempts to send packets to
61001(the port learned from STUN), which is closed or bound only to the STUN server. - If both peers reside behind Symmetric NATs, direct hole punching is mathematically impossible without brute-force port scanning (which firewalls actively block). In such scenarios (approximately 10% to 15% of all connections globally), WebRTC falls back to an intermediary TURN Relay Server.
The WebRTC Transport Protocol Architecture#
WebRTC does not use HTTP or raw TCP for real-time media. Instead, it builds upon a sophisticated, multi-layered protocol stack engineered specifically for ultra-low latency, encryption, and congestion control over UDP.
+---------------------------------------------------------------------------------------+
| The WebRTC Protocol Stack |
+---------------------------------------------------------------------------------------+
| WebRTC APIs: MediaStream (Audio/Video) | RTCDataChannel |
+------------------------------------+--------------------------------------------------+
| Audio / Video Codecs: | Non-Media Data: |
| Opus, VP8, VP9, H.264, AV1 | Arbitrary binary payloads, JSON, WebSockets |
+------------------------------------+--------------------------------------------------+
| SRTP (Secure Real-time Transport) | SCTP (Stream Control Transmission Protocol) |
+------------------------------------+--------------------------------------------------+
| DTLS (Datagram Transport Layer Security) |
+---------------------------------------------------------------------------------------+
| ICE (Interactive Connectivity Establishment) |
| STUN (Session Traversal Utilities for NAT) |
| TURN (Traversal Using Relays around NAT) |
+---------------------------------------------------------------------------------------+
| UDP (User Datagram Protocol) |
+---------------------------------------------------------------------------------------+
| IP (Internet Protocol: IPv4 / IPv6) |
+---------------------------------------------------------------------------------------+Why TCP Is Unsuitable for Real-Time Media (Head-of-Line Blocking)#
Traditional web applications rely on TCP because it guarantees reliable, in-order packet delivery via sequence numbers and automated retransmissions.
However, in real-time video conferencing, TCP's reliability becomes a fatal flaw due to Head-of-Line (HoL) Blocking:
- If Packet 3 in a video frame sequence is dropped by network congestion, TCP pauses delivery of all subsequent packets (Packets 4, 5, 6, 7) until Packet 3 is retransmitted and acknowledged.
- In real-time video running at 30 frames per second, a frame is valid for only 33 milliseconds. A retransmitted packet that arrives 250 milliseconds later is completely useless—the user has already moved on. The resulting multi-second video freeze and buffer backlog destroys conversation.
- WebRTC uses UDP: If a video packet drops, WebRTC drops the corrupted macroblock or requests an immediate intra-frame (keyframe) refresh, continuing forward without pausing playback.
Security & Multiplexing: DTLS, SRTP, and BUNDLE#
- SRTP (Secure Real-time Transport Protocol, RFC 3711): Encrypts media payloads using AES-128 or AES-256 in Counter Mode (AES-CM), providing authentication and anti-replay protection with minimal CPU overhead.
- DTLS (Datagram Transport Layer Security, RFC 6347): Implements TLS over datagrams. During the initial ICE connection, peers execute a DTLS handshake to authenticate each other's cryptographic self-signed certificate fingerprints (exchanged via signaling) and derive ephemeral SRTP session keys.
- BUNDLE & RTCP-Mux: Historically, VoIP systems opened 4 distinct UDP ports per call (Audio RTP, Audio RTCP, Video RTP, Video RTCP). WebRTC mandates BUNDLE and RTCP Multiplexing (rtcp-mux): all audio, video, RTCP telemetry, and SCTP data channels are multiplexed over a single UDP 5-tuple (Source IP:Port, Dest IP:Port, Protocol), drastically reducing NAT binding overhead and firewall traversal complexity.
Checkpoint Practice Problems#
Problem 1 (Symmetric NAT Port Guessing Probability & Birthday Paradox): Two peers reside behind Symmetric NATs. Direct STUN reflexive addresses fail. Peer A attempts to establish a connection to Peer B by brute-force sending UDP probes to randomly guessed external ports on Peer B's public IP.
Peer B's NAT allocates ephemeral ports uniformly at random across the standard dynamic range:
N_ports = 65,535 - 10,240 = 55,296 candidate ports.
If Peer A transmits k = 500 rapid UDP probes to distinct randomly guessed ports on Peer B's IP before Peer B's NAT mapping state times out:
- Compute the probability P_fail that all 500 probes fail to hit the single active external port allocated by Peer B's NAT.
- Compute the success probability P_success = 1 - P_fail that Peer A successfully punches the hole.
- If both peers concurrently guess with k = 500 probes each, compute the joint collision probability using the Birthday Paradox approximation:
P_collision ≈ 1 - exp( - (k^2) / (2 · N_ports) ).
Solution:
- Single-probe failure probability:
```
P(1 fail) = (N_ports - 1) / N_ports = 55,295 / 55,296
P_fail = [ (55,295) / (55,296) ]^500
```
Using the approximation (1 - 1/N)^k ≈ exp(-k / N):
```
k / N = 500 / 55,296 ≈ 0.009042
P_fail ≈ exp(-0.009042) ≈ 0.9910
```
- Success probability for Peer A alone:
```
P_success = 1 - 0.9910 = 0.0090 (0.90%)
```
A 0.90% success rate is completely unacceptable for consumer telecommunications.
- Joint Birthday Paradox collision probability (both peers sending k = 500 probes):
```
Exponent = - (500^2) / (2 · 55,296) = - 250,000 / 110,592 ≈ - 2.26056
P_collision ≈ 1 - exp(-2.26056) ≈ 1 - 0.10429 = 0.8957 (89.57%)
```
While joint scanning yields an 89.6% theoretical probability, modern enterprise firewalls detect rapid port bursts as malicious UDP port-scanning attacks, rate-limiting or blacklisting the peer's IP within milliseconds. Thus, symmetric-to-symmetric connections must reliably utilize TURN relay servers.
Problem 2 (P2P Mesh vs. Client-Server Bandwidth Scaling Analysis): A multi-party video conference has N = 6 participants. Each participant publishes an audio/video stream requiring an upload bitrate of B = 2.0 Mbps and consumes streams from all other participants.
- Under Architecture 1 (Full P2P Mesh): Every participant establishes an independent direct peer connection with every other participant, uploading their stream separately to each peer.
- Under Architecture 2 (Centralized SFU Media Server): Every participant uploads their stream once (2.0 Mbps) to the central server, and downloads N - 1 streams from the server.
Calculate:
- The total upload bandwidth required on an individual client's home connection under Architecture 1.
- The total upload bandwidth required on an individual client's home connection under Architecture 2.
- The total aggregate bandwidth handled across the entire network (sum of all uploads and downloads) under Architecture 1.
- Explain why Full P2P Mesh breaks down for conference rooms with N > 5 participants.
Solution:
- Client upload in Full Mesh (Architecture 1):
Each client must transmit their stream to N - 1 other peers:
```
Upload_mesh = (N - 1) · B = (6 - 1) · 2.0 Mbps = 5 · 2.0 Mbps = 10.0 Mbps
```
- Client upload with SFU (Architecture 2):
Each client uploads exactly once to the central server:
```
Upload_SFU = 1 · B = 2.0 Mbps
```
- Total aggregate network bandwidth in Mesh:
* Total connections in a full mesh of N nodes:
C = N · (N - 1) / 2 = 6 · 5 / 2 = 15 bidirectional links.
* Each link carries stream from A to B (2 Mbps) and B to A (2 Mbps) = 4 Mbps per link.
Total aggregate traffic = 15 · 4.0 Mbps = 60.0 Mbps*.
- Architectural breakdown of Mesh:
In a Full Mesh, client upload bandwidth scales quadratically with participants: O(N) per client, and total network traffic scales as O(N^2). Consumer home broadband connections (e.g., ADSL or cable) possess highly asymmetric bandwidth (e.g., 100 Mbps download but only 10 Mbps upload). At N = 6, the required 10 Mbps upload saturates the client's upstream pipe, causing packet drops, freezing, and browser CPU exhaustion (encoding 5 separate video streams). For N > 5, a Selective Forwarding Unit (SFU) is strictly required.
Problem 3 (TCP Head-of-Line Blocking vs. UDP Packet Loss Latency): A real-time video stream transmits frames at 30 frames per second (frame interval T_frame = 33.3 ms). The round-trip time between endpoints is RTT = 80 ms.
Packet 12 is lost in transit over a congested router.
- If streaming over TCP, compute the minimum latency delay introduced before Packet 13 can be delivered to the application layer (assuming immediate duplicate ACK detection triggering Fast Retransmit, requiring 1 RTT).
- How many frames are delayed or frozen during this TCP retransmission interval?
- If streaming over WebRTC (UDP with SRTP), explain how the receiver handles the missing Packet 12 without pausing rendering of subsequent frames.
Solution:
- TCP Retransmission Latency:
When Packet 12 is lost, the receiver buffers subsequent packets (13, 14, 15) but cannot release them to the decoder due to in-order TCP delivery constraints.
* Fast Retransmit requires detecting 3 duplicate ACKs (~0.5 RTT) plus the retransmission packet transit time (~0.5 RTT):
T_retransmit = 1.0 · RTT = 80.0 milliseconds.
- Frames delayed:
```
Frames Delayed = T_retransmit / T_frame = 80.0 ms / 33.3 ms ≈ 2.4 frames
```
The video display freezes for at least 80 ms (spanning 2 to 3 frames), introducing jitter and audio desynchronization.
- WebRTC UDP Handling:
Under WebRTC, UDP provides unconstrained out-of-order datagram delivery:
* When Packet 12 drops, Packets 13, 14, and 15 are immediately delivered to the video jitter buffer.
* If Packet 12 belonged to a non-reference frame, the video decoder conceals the macroblock or skips to the next frame with zero latency penalty.
* If Packet 12 contained a critical reference frame, the receiver transmits an RTCP Picture Loss Indication (PLI) message requesting a keyframe, while continuing to play real-time audio smoothly.
Problem 4 (NAT Mapping Timeout & STUN Keep-Alive Sizing): Enterprise stateful firewalls and NAT gateways evict idle translation table mappings after a timeout period to reclaim memory:
- UDP state timeout:
T_timeout = 30 seconds. - If no traffic flows through the mapped port for 30 seconds, the NAT closes the external port.
- To maintain the hole open, the WebRTC implementation sends periodic STUN Binding Indication keep-alive packets.
- Each STUN keep-alive packet has a total IP/UDP packet size of
S_pkt = 64 bytes.
- To guarantee the NAT mapping never expires with a safety factor of 1.5, what is the maximum permissible keep-alive ping interval T_ping?
- Over a 1-hour idle audio call, how many keep-alive packets must be transmitted?
- Compute the total keep-alive bandwidth overhead (in kilobytes) consumed over the 1-hour period.
Solution:
- Compute Keep-Alive Ping Interval:
```
T_ping = T_timeout / 1.5 = 30 seconds / 1.5 = 20.0 seconds
```
A ping interval of 20 seconds ensures that even if one ping packet is dropped in transit, the next ping arrives at second 40 (well before standard 60-second timeouts).
- Total pings in 1 hour (3,600 seconds):
```
Pings_per_hour = 3,600 s / 20.0 s = 180 packets
```
- Total bandwidth overhead:
```
Total Bytes = 180 packets · 64 bytes/packet = 11,520 bytes
In Kilobytes = 11,520 bytes / 1,000 ≈ 11.52 KB per hour (or ~25.6 bits per second)
```
A negligible bandwidth overhead of ~25.6 bps keeps the bidirectional NAT mapping permanently alive.