Networking, from wire to teleop

A visual primer. A working mental model of how packets actually move, from the cable in the wall up to the protocols that ship a Quest controller pose to a robot in another country.

00Why this matters

You can't reason about teleop latency, jitter, or reliability without a real model of what the network is doing. "It feels laggy" is not a diagnosis. To know whether to fix the Wi-Fi, the codec, the protocol, or the operating system, you need to see the layers underneath.

This tab builds that mental model from the bottom up. Most sections include an interactive demo. Drag the sliders, click the buttons. Intuition is what we're after.

01The layered model

Networking works because it is split into independent layers, each only doing one job and trusting the layer below to do its job. The classic model has seven layers (OSI), but in practice four are enough:

Mental model

Each layer wraps the one above it like an envelope. By the time your bytes hit the cable, your "Hello" has been wrapped in a TCP envelope, then an IP envelope, then an Ethernet envelope. The router that gets the frame opens the Ethernet envelope, reads the IP envelope, decides which neighbor to forward to, re-wraps it in a fresh Ethernet envelope, and sends it on. The TCP envelope is never touched in transit.

Demo: encapsulation

02Link layer: Ethernet, Wi-Fi, cellular

The link layer is the physical reality. It defines what "a packet" means on this particular medium and how two devices on the same wire or airwave talk. Critically, the link layer only delivers between directly connected devices, your laptop and the Wi-Fi access point, or the access point and the next router. To go further, the network layer takes over.

Why the link layer matters for teleop

If your operator-to-robot path includes one Wi-Fi hop, your latency floor is set by Wi-Fi, no matter how clever your protocol is. The biggest single thing you can do to improve teleop responsiveness is often: replace a Wi-Fi link with a cable. Software-level optimization is rounding error compared to that.

03LAN vs WAN

These are not different protocols, they're descriptions of scale:

• LAN (Local Area Network): one administrative domain. Your house, your lab, your office. You control the switches and APs. Latency is sub-millisecond, loss is essentially zero, bandwidth is gigabits.
• WAN (Wide Area Network): spans ISPs, continents. You don't control most of the path. Latency is set by the speed of light (you can't beat ~5 ms per 1000 km of fiber even in theory) plus router queueing.

"The internet" is just the loose interconnection of every WAN. When you ping 1.1.1.1, your packet hops through 10 to 20 routers, each owned by someone else, queuing behind everyone else's traffic. None of those routers care that your packet is "important" unless you've paid for that.

04IP addresses & routing

Every device gets an IP address. IPv4 (192.168.1.42) is 32 bits, IPv6 (2001:db8::1) is 128 bits. Two flavors:

• Private addresses: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Used inside LANs. Not routable on the public internet.
• Public addresses: globally routable. Your home router gets one from your ISP; your devices behind it do not.

A subnet mask like /24 (a.k.a. 255.255.255.0) splits the address into "network part" and "host part". Two devices on the same subnet talk directly via the link layer; cross-subnet, the packet must go through a router. The router has a routing table, a list of "for destinations like X, send to next hop Y", and that table is built either statically or dynamically by routing protocols like BGP (between ISPs) or OSPF (inside a network).

05Ports

An IP address gets you to the right machine. A port gets you to the right program on that machine. Ports are 16-bit (0 to 65535). The OS demultiplexes incoming packets to whichever process is bound to that port.

A connection is fully identified by the 5-tuple: (protocol, src_ip, src_port, dst_ip, dst_port). Two TCP connections from the same browser to example.com:443 have different source ports, which is how the OS tells them apart.

Common conventions: 22 SSH, 53 DNS, 80 HTTP, 443 HTTPS, 5432 Postgres, 8765 your WebSocket, 5000 the Quest UDP CSV. Below 1024 = "well-known" ports, traditionally root-only.

06NAT

Your home network has many devices but typically one public IP. Network Address Translation (NAT) is the trick: when your laptop sends a packet from 192.168.1.5:51234 to 1.1.1.1:443, the router rewrites the source to your-public-ip:51234, remembers the mapping, and rewrites the reply on the way back.

This works fine for outbound connections. It breaks down for inbound connections, there's nobody home to map them to. That's why hosting a server at home requires port forwarding, and why peer-to-peer protocols like WebRTC need STUN (discover your public IP+port) and sometimes TURN (relay through a public server when direct doesn't work). Tailscale solves NAT traversal by acting as a TURN-like relay plus WireGuard tunneling.

07DNS

Humans use names; computers use IPs. DNS (Domain Name System) is the translation layer. When you type github.com, your computer asks a DNS resolver, which asks the root servers, which delegate to .com's servers, which delegate to GitHub's servers, which return an IP. Results get cached aggressively: a single DNS hit then reuses the IP for thousands of TCP connections.

DNS is one of the few core protocols that runs primarily over UDP (port 53), because lookups are tiny and a one-shot query/response doesn't need TCP's machinery. Modern variants (DoH = DNS over HTTPS, DoT = DNS over TLS) wrap it for privacy.

08UDP User Datagram Protocol

UDP is the simplest possible thing on top of IP. You give the OS a chunk of bytes plus a destination IP+port; it slaps an 8-byte UDP header on it and sends. There is no connection, no acknowledgment, no retransmission, no ordering, no congestion control. If the network drops it, you don't find out. If two arrive out of order, you get them out of order.

UDP header (8 bytes total)
+----------------+----------------+
|   src port     |   dst port     |
+----------------+----------------+
|   length       |   checksum     |
+----------------+----------------+
|   your bytes (up to ~65 KB)     |
+---------------------------------+

This sounds bad. It is also exactly what you want when:

• Data has a short useful lifetime (a 50 ms-old joint command is worse than no command).
• You will send a fresh value soon anyway (state at 30 Hz, video frames at 60 fps).
• You'd rather know about loss immediately than have the OS hide it from you.

Your Quest UDP CSV is UDP. So is DNS, NTP, most VoIP, and the media half of WebRTC. Modern protocols like QUIC are also built on UDP, just with reliability features they implement themselves.

09TCP Transmission Control Protocol

TCP gives you a connection: a reliable, ordered, congestion-controlled byte stream between two endpoints. It does this on top of unreliable IP by:

1. Three-way handshake to establish the connection: SYN, then SYN-ACK, then ACK.
2. Sequence numbers on every byte sent. The receiver acknowledges back which bytes it has.
3. Retransmission: if a packet isn't ACK'd in time, the sender resends.
4. Flow control: receiver tells sender how much buffer it has free.
5. Congestion control: sender slows down when it detects loss, ramps up when things are flowing. Algorithms like Cubic, Reno, BBR.

10Head-of-line blocking, the killer flaw

Because TCP gives you an ordered byte stream, if packet #100 is lost, the OS at the receiver holds back packets #101 to #150 from your application until #100 is retransmitted and arrives. They're sitting in the kernel buffer, perfectly intact, but you can't have them yet.

For control loops or video streams, this is catastrophic: a single lost packet can stall everything for an entire RTT (the round trip needed to detect loss and retransmit), then dump the backlog on you all at once.

Demo: TCP vs UDP under packet loss

11TLS, encryption you can build on

TLS (Transport Layer Security, the modern name for SSL) sits between the transport and the application, encrypting and authenticating everything that flows. It does three things:

• Confidentiality: nobody on the path can read your bytes.
• Integrity: nobody can tamper with bytes in flight without it being detected.
• Authentication: the server proves who it is via a certificate (signed by a trusted CA). Optionally the client too (mutual TLS / mTLS).

TLS over TCP is the classic combination. DTLS is "TLS, but for UDP", same crypto, with extra machinery to handle reordering and loss. WebRTC's media (SRTP) uses DTLS-derived keys.

12HTTPS

HTTPS is just HTTP over TLS over TCP. There is nothing more to it. The "S" is the TLS layer. When you visit https://example.com:

1. Your browser opens a TCP connection to example.com:443.
2. It does a TLS handshake over that connection: certificate verification, key exchange.
3. It sends an HTTP request inside the now-encrypted tunnel.
4. The server replies, also encrypted, also inside the tunnel.

HTTP/2 reuses one TCP+TLS connection for many parallel requests, multiplexed by stream ID. This works most of the time but inherits TCP's head-of-line blocking: one lost packet stalls every stream sharing the connection. HTTP/3 fixes this by running over QUIC instead.

13VPNs and WireGuard (and Tailscale)

A VPN encapsulates your packets inside another encrypted packet, so they look like one big tunnel to the network. Two main flavors:

• Traditional VPNs (OpenVPN, IPsec): often run over TCP, complex configs, sometimes slow.
• WireGuard: modern, runs over UDP, ~4000 lines of kernel code, fast, hard to misconfigure.

Tailscale wraps WireGuard with a coordination service that handles key exchange, NAT traversal, and ACLs. Devices appear as if on the same private LAN regardless of physical location. This is exactly what you're using to bridge your two PCs, and for a small fleet, it's a respectable choice that the pros also reach for.

14WebSockets

WebSocket is a long-lived, bidirectional, message-framed channel that runs over a single TCP connection (typically TLS-protected, wss://). It starts life as an HTTP request that asks to "upgrade" the connection, then HTTP gets out of the way and you have a raw bidirectional pipe.

WebSockets are great when:

• You want server-pushed messages without polling.
• You need to traverse corporate firewalls (port 443 looks like normal HTTPS).
• You don't have hard latency requirements.

They are not great for control loops because they inherit all of TCP's head-of-line problems. The atlas codebase uses WebSockets for the React frontend to orchestrator at 5 Hz, exactly the right place for them.

15QUIC UDP-based, multiplexed, encrypted

QUIC is the lessons of 30 years of TCP, redone on top of UDP. It is what HTTP/3 runs on. Its big wins:

• Multiple independent streams in one connection. A stuck packet in stream A doesn't block stream B.
• Mandatory TLS 1.3 baked in, handshake and crypto are part of the protocol, not bolted on.
• 0-RTT resumption: a returning client can send data in its very first packet.
• Connection IDs instead of 5-tuples, connection survives an IP change (Wi-Fi to cellular).
• All implemented in user space, so it can be upgraded without kernel changes.

For teleop, the per-stream isolation is the headline feature: you can run a control stream and a video stream in the same QUIC connection without one being able to block the other.

16WebRTC video + audio + data, peer-to-peer

WebRTC is not one protocol, it's a bundle of about a dozen, designed to make real-time peer-to-peer media work in any browser through any NAT.

This complexity is the price for "press a button, see low-latency video from anywhere on Earth, in any browser, including a Quest's." For a teleop product targeting customers, this is what you ship. For a research setup with two known machines, it's overkill.

17XML-RPC request/reply over HTTP

A 1998-era remote procedure call protocol. Function call → XML body → HTTP POST → XML response. Same idea as REST or JSON-RPC, older serialization. It refuses to die in robotics: Fairino's FR-series collaborative arms expose every motion, IO, and gripper command over XML-RPC on port 20003, and ROS 1's Master (covered next) uses XML-RPC for the discovery handshake before nodes switch to TCPROS for the actual data. A long tail of other industrial arms (Aubo, Elite, JAKA on earlier firmware) ship the same way, because the protocol is stateless, language-agnostic, and free to implement on top of any HTTP stack.

What it looks like on the wire. Calling MoveL(...) with twelve doubles serializes to about 700 bytes of XML:

POST /RPC2 HTTP/1.1
Content-Type: text/xml

<?xml version="1.0"?>
<methodCall>
  <methodName>MoveL</methodName>
  <params>
    <param><value><array><data>
      <value><double>1.0</double></value>
      <value><double>2.0</double></value>
      ...
    </data></array></value></param>
  </params>
</methodCall>

The response is more XML wrapping a single typed return value or a fault. Supported types are int, double, string, boolean, array, struct, dateTime, base64. That is the entire protocol.

125 Hz control loops run over XML-RPC just fine on a wired LAN. ~700 bytes per request × 125 Hz is ~87 KB/s, trivial bandwidth on any modern link. The constraint is per-call latency: every request is a TCP round-trip plus an XML parse on both ends, typically 1–3 ms on a switched LAN. That fits comfortably in the 8 ms budget at 125 Hz, and we have measured it holding 124.8 Hz against the Fairino simulator with zero overruns. Above ~200–300 Hz the per-call overhead eats the whole budget, which is why vendors that support kHz-rate streaming usually offer a separate UDP-transparent path (Fairino calls theirs cmdType=1) that skips both the XML parser and the TCP handshake.

Where it breaks down

Verbose on the wire, fine for control at teleop rates over wired or low-jitter wireless, useless for high-rate streaming, and miserable over a lossy WAN where every retransmit adds an RTT. For anything past a single LAN, treat XML-RPC as the configuration channel and put real-time data on a different transport.

18ROS 1 networking

ROS 1 is a centralized publish/subscribe system organized around a special process called roscore:

1. roscore runs at a known address. It hosts a registry (the "Master") via XML-RPC.
2. Every node, on startup, talks to roscore to register what topics it publishes/subscribes.
3. The Master tells subscribers about matching publishers.
4. Subscribers then connect directly to publishers, usually over TCPROS, sometimes UDPROS for low-latency or lossy data.

So the Master is in the discovery path but not the data path. Drawbacks: single point of failure (no Master, no graph), all nodes need direct TCP/UDP reachability to all others (bad over WAN/NAT), no QoS controls, no discovery without the Master.

19ROS 2 / DDS / RTPS

ROS 2 throws out the Master. Instead it uses DDS (Data Distribution Service), an industrial pub/sub middleware standardized for years in defense and aerospace. The on-the-wire protocol is RTPS (Real-Time Publish-Subscribe).

How it discovers peers without a master: when a node starts, it sends UDP multicast "hello, I'm here, I publish topic X" announcements on a known multicast group. Other nodes listening on the same group hear them and reply. After discovery, data flows directly, peer-to-peer, over UDP.

Each topic also has a QoS profile: reliability (best-effort vs reliable), durability, deadline, history depth, lifespan. You pick per-topic. Sensor streams might be best-effort, command topics reliable.

DDS gotcha for WAN

Multicast doesn't traverse the public internet. ROS 2 over WAN needs a bridge: Zenoh, FastDDS Discovery Server, or DDS Router, to translate the discovery and forward the data. This is the main reason ROS 2 is great on a robot or a single LAN, and a project to deploy across continents.

20ZeroMQ

ZeroMQ is a messaging library, not a protocol. It gives you composable patterns:

• PUB/SUB: one-to-many fanout (the RemoteRobotClient uses this).
• REQ/REP: synchronous request/reply.
• PUSH/PULL: pipeline / load balancer.
• ROUTER/DEALER: more flexible request/reply.

By default ZMQ runs over TCP, with optional in-memory queues per socket. Two important traps for teleop:

• The default is to queue on the SUB socket. If the WAN hiccups for a second, you'll later drain a backlog of stale states. Set ZMQ_CONFLATE=1 to keep only the newest message, almost always what you want for live state.
• Auth ("CurveZMQ") works but is obscure. Don't expose ZMQ to the open internet without a VPN/Tailscale wrapper.

21Deploying for real: routers, switches, access points

So far this primer has been about packets and protocols. None of that helps you decide where to mount four pieces of hardware in a warehouse so a fleet of robots stays online. This section is the practical bridge between the abstractions and the concrete plant: what a "router" actually contains, why one box does not scale to a fleet, how VLANs keep robot traffic out of office traffic's way, what Wi-Fi 6 versus 7 actually gives you, how many bytes you can really push through the air, and what the gear costs.

What a "router" actually contains

The thing you call "the router" in your home is really three devices in one case. A WAN router/firewall handles the link to your ISP, runs NAT and DHCP, and decides what is allowed in. A switch fans out a handful of Ethernet ports for wired devices. An access point is a radio that broadcasts Wi-Fi. The consumer or ISP combo box (a Fios gateway, an Eero, a Verizon BGW320) packages all three behind one MAC address and one IP block. That works fine for a house with ten devices in a 200 m² envelope.

A warehouse needs all three jobs done by separate, sized-up boxes. One gateway/firewall at the network edge. One (or more) PoE switches to power and uplink the APs over a single Ethernet run each. Several access points placed for coverage and roaming overlap. A controller, cloud or local, that coordinates channel selection, transmit power, and roaming across every AP from one place.

AP density is the part most people guess wrong. The rule "one AP per 2500 to 4000 sq ft" works for open offices but underbuilds for racked warehouses. Steel shelving is opaque to Wi-Fi, robots sit 30 to 60 cm off the floor where signal is worst, and overlap is required for clean roaming. For a real warehouse, plan one AP per aisle, mounted 4 to 6 m up with the antenna pointed down the aisle.

VLANs and traffic isolation

A VLAN is a 12-bit tag that switches and APs attach to Ethernet frames so the same physical wire carries multiple logical networks. Devices on VLAN 20 cannot see devices on VLAN 30 unless the router between them is explicitly configured to route across. For a robot fleet this gives you three things at once. Isolation: a compromised IoT camera cannot reach the robot control plane. QoS: you can mark every frame on the robot SSID WMM Voice and DSCP EF without affecting office traffic. Separate failure domains: a broadcast storm on the office VLAN does not drown the robots.

Each VLAN gets its own SSID on the APs and its own subnet on the router. The router decides which VLAN can reach which. Robot control traffic on VLAN 20 typically gets a dedicated SSID on 6 GHz only, so it shares the air with nothing legacy.

Wi-Fi 6, 6E, 7, and which band the robots live on

For a robot warehouse in 2026 there are three live Wi-Fi standards on the floor; Wi-Fi 5 is legacy at this point and Wi-Fi 7 is what new builds buy.

The interesting decision is which band the robots live on, not which standard. 5 GHz is crowded everywhere: every existing AP in the warehouse, every neighboring tenant, every smart-TV in the office. Of its 25 channels, 16 require DFS, meaning the AP must vacate within 10 s on a radar detection and stay off the channel for 30 min. On a robot fleet, a single radar event silences an AP and forces a fleet-wide roam. The 6 GHz band, opened by the FCC in 2020 and used by Wi-Fi 6E and 7, is brand new, has no DFS, has roughly three times the spectrum, and is essentially empty in industrial sites today. The right move for a robot warehouse is to put the robot SSID on 6 GHz only.

Why not just always buy Wi-Fi 7

The 4096-QAM bump in Wi-Fi 7 is conditional. Both the AP and the client NIC must support it, and a robot sitting at an aisle endpoint with marginal SNR will fall back to 1024-QAM anyway. The real Wi-Fi 7 wins are 320 MHz channels (only in 6 GHz) and MLO, where a client aggregates a 5 GHz radio and a 6 GHz radio into one logical link. For most robot fleets, Wi-Fi 6E hits the right point on the cost curve at about half the gear price.

Airtime budget: what actually fits on the wire

PHY rates are bigger than what you actually get. The MAC layer (ACKs, beacons, retries, CSMA contention) burns airtime, and the realistic application-layer throughput is 50 to 65 percent of the PHY rate, shared across every client of that AP on that radio. Bytes per second, not megabits, is usually the right unit when you are budgeting camera streams against control plane.

Numbers in the right column are sum of upstream + downstream per AP per radio, shared across all clients on that radio. For a Wi-Fi 6E AP on a 160 MHz 6 GHz channel that is about 180 MB/s shared. Four robots streaming 10 Mbps of teleop video plus 200 KB/s of control state consume under 10 MB/s combined; that fits comfortably with room for retries and bursts. A single robot dumping raw 4K camera at 100 MB/s would consume more than half the cell on its own. Design rule: budget 30 to 50 MB/s of usable bidirectional throughput per robot on a 6E 160 MHz cell with up to four robots per AP. For sustained raw camera or lidar above 100 Mbps per robot, go Wi-Fi 7 with 320 MHz, or limit the streams.

Roaming for moving robots

When a robot drives from AP-1 to AP-2, the default re-association takes 300 to 500 ms, which on a 100 Hz control loop is 30 to 50 missed ticks. Three 802.11 amendments help, and all three should be on for any robot deployment:

• 802.11k (Neighbor Reports): the current AP tells the client which other APs and channels are nearby, so the client does not have to do a full scan. Enable everywhere.
• 802.11v (BSS Transition Management): the AP can suggest "you should roam to AP-7 now." Polite, depends on the client honoring it. Enable everywhere.
• 802.11r (Fast BSS Transition): the cryptographic handshake is pre-cached across APs, so the new association completes in 20 to 50 ms instead of 300 to 500 ms. Critical for teleop. Enable in FT-over-DS if the controller supports it, otherwise FT-over-air.

Some older NICs and some MediaTek modules misbehave with 802.11r; test before fleet rollout. For sub-10 ms handoff (truly seamless mid-control-loop), Wi-Fi alone is not enough. You either accept short gaps, use Wi-Fi 7 MLO so the second radio link carries traffic during the roam, or move to a proprietary make-before-break mesh (Cisco URWB, Cambium Fluidmesh, Rajant, and similar).

Vendor options and approximate pricing

Three tiers. Within each, the products are roughly interchangeable on capability; the choice is mostly about which management UI you prefer and which vendor's firmware you trust to age gracefully. Prices below are 2025 to 2026 USD street, approximate. Tier 3 list prices are MSRP or CDW list; real quoted prices typically run 20 to 45 percent lower at any reasonable order size.

Tier 1: prosumer and small business (starter under $1k)

A typical Tier 1 starter (gateway + 24-port PoE switch + 4 APs) lands at $900 to $1,500. Good for a single small workshop or a pilot deployment, not for a multi-aisle fleet.

Tier 2: SMB and commercial ($1k to $5k starter)

Tier 2 buildout (gateway + 24-port PoE+ switch + 6 to 10 APs) lands at $2,500 to $5,000. Full VLAN, RADIUS, 802.11 k/v/r support, no recurring per-AP license. The sweet spot for a 10 to 50 robot warehouse.

Tier 3: enterprise and industrial ($5k+ starter, $15k to $50k for a real warehouse)

Tier 3 picks up at multi-site fleets, deterministic roaming over an enterprise WLC, and contractual SLAs. The hardware can be 4x the price of Tier 2 with comparable RF performance at small scale; the value is in the controller, the support, and the multi-site management.

Recommendation for a teleop fleet

For a single warehouse with up to about 50 robots, Tier 2 with UniFi or Omada Wi-Fi 6E or Wi-Fi 7 is the right pick: $4,000 to $8,000 of one-time hardware, full VLAN, RADIUS, 802.11 k/v/r, MLO support, no per-AP cloud licenses. One AP per aisle, mounted at 4 to 6 m. Robot SSID on 6 GHz, VLAN-isolated, WMM Voice with DSCP EF, FT (802.11r) enabled. Move to Tier 3 only when you have multi-site fleets or contractual support requirements that justify per-AP licensing.

22Demo: end-to-end teleop latency simulator

Pull together everything we've covered. Here's a model of one full teleop loop. Adjust each segment and see whether the loop closes safely.

23Decision matrix: what to use, when

Final intuition

The protocol you pick is mostly a way of saying which problems you want to be solved for you, and which you'll handle yourself. UDP gives you nothing and asks nothing. TCP gives you reliability at the cost of latency. QUIC gives you TCP's reliability without the head-of-line tax. WebRTC gives you all of that plus codec negotiation and NAT traversal. The right choice is whichever bundles exactly the guarantees your use case needs, and no more.