8 Packet Switching and Performance
8.1 Start With Many Small Decisions
Prove the Urgent Packet Survives Shared Traffic
Picture an alarm waiting behind a large device update on the same link. Both flows may arrive eventually while the alarm still misses its useful deadline.
Firmware means the software stored on a device that controls its hardware. Label its update packets separately from alarms, status, and routine data before testing the shared path.
Send quiet, burst, full-queue, dropped-link, and recovery cases. Keep packet identity, address, hop, queue time, drop, retry, arrival, and deadline result so another person can repeat the trace.
This check covers chosen flows and loads, not every network failure. The deeper sections develop forwarding, queues, congestion, ordering, recovery, and service trade-offs.
Packet switching works because a long conversation is split into small pieces that can be forwarded independently. Each hop makes a local decision using addresses, tables, queues, and current load.
For IoT, those small decisions shape reliability and delay. A firmware update, alarm burst, or camera stream can all share a network, but only if the switching path has enough evidence to forward, queue, and recover without hiding failure.
Packet Pete
“A packet you can’t trace is a claim you can’t defend — name the address, the route, and the hop that dropped it.”
Through this chapter, Pete follows each packet hop by hop: the header picks the route; the queue, retry, or drop explains the delay.
8.2 Overview: Shared Links, Independent Packets
Packet switching breaks a message into packets and lets each packet move through the network as its own forwarding unit. A router does not need to know the full application conversation. It reads delivery fields in the packet header, chooses a next hop, and sends the packet onward.
This is why packet switching fits IoT systems. Sensors, cameras, gateways, phones, and cloud services rarely need a private circuit for every conversation. They need a shared network that can carry bursts from many devices, then free the link for the next burst.
The sharing works because most devices are not transmitting at full rate all the time. A sensor may send a few bytes each minute, a camera may burst when motion is detected, and a gateway may forward a short acknowledgement between larger uploads. Packet switching lets those bursts statistically multiplex on the same physical and logical links. It does not promise that every packet will take a different path, and it does not promise instant delivery. It promises that each packet carries enough forwarding information for the next router or gateway to make a local decision when capacity is available.
A useful mental shift is to compare a telephone exchange with a shared packet medium. In the circuit-switched model, a switchboard, crossbar, or central office selects a conversation path and holds that circuit while Alice and Bob talk. In a packet-switched or shared-link model, the medium is not reserved for one pair forever; Bob's packet can occupy the common link for a moment, carry enough addressing information to reach Alice, and then release the capacity for George, Cathy, Doug, a sensor, or a gateway to use next.
Figure 8.1 makes overview: shared links, independent packets inspectable through Packet Switching Path from Sensor to Cloud and path 1. Those diagram labels establish the scope of each router forwards the packet based on header information and its current routing knowledge.
Begin Figure 8.1 with Packet Switching Path from Sensor to Cloud, then distinguish path 1 and path 2. The diagram separates Packet Switching Path from Sensor to Cloud from path 1 within each router forwards the packet based on header information and its current routing knowledge. Keep both distinctions explicit in overview: shared links, independent packets.
Forward by header
The packet header carries addressing and control information. Routers use that metadata to decide the next hop without opening the application payload.
Share by taking turns
Packets from different devices are interleaved on the same link. A camera frame, a thermostat reading, and an acknowledgement can all use the same path at different moments.
Recover by rerouting
Because packets are forwarded independently, later packets can use a different path when routing changes or a link becomes unavailable.
Ground overview: shared links, independent packets with the visual at Figure 8.2. Start from Time-Division Multiplexing on a Shared Link, but keep slot 1 visible while evaluating multiplexing lets several flows share one link instead of reserving a private channel for each device.
Compare Time-Division Multiplexing on a Shared Link with slot 1 inside the visual at Figure 8.2. Next find video, which completes the scope of multiplexing lets several flows share one link instead of reserving a private channel for each device. The decision in overview: shared links, independent packets must preserve that labelled boundary.
To test overview: shared links, independent packets, open the diagram in Figure 8.3. Network Resilience with Automatic Rerouting supplies one named condition; normal supplies the necessary comparison for independent forwarding gives the network room to adapt when a path changes.
Use normal to test Network Resilience with Automatic Rerouting in the diagram at Figure 8.3. Then inspect failed link as the final qualifier on independent forwarding gives the network room to adapt when a path changes. That sequence keeps overview: shared links, independent packets tied to what is visibly labelled.
IoT design habit: treat packet switching as shared infrastructure, not guaranteed private capacity. The packet may arrive, arrive late, arrive out of order, or be dropped. Application behavior should account for those outcomes.
Pete’s Delivery Slip
- Address: the header carries addressing and control; routers forward without opening the payload.
- Route: no reserved circuit — each hop decides locally, and later packets can reroute around a failed link.
- Receipt: none promised; late, out-of-order, or dropped arrivals are the application’s problem to handle.
8.3 Practitioner: Plan for Useful Capacity, Not Just Link Speed
A packet-switched link can look healthy on a spec sheet and still disappoint an IoT workload. The practical question is not only "how fast is the link?" It is "how much useful application data arrives on time while other flows, headers, retries, and queues are present?"
Inspect Figure 8.4 before this decision: Bandwidth vs Throughput vs Goodput must be judged beside From theoretical capacity to usable application data. Together Bandwidth vs Throughput vs Goodput and From theoretical capacity to usable application data bound this claim.
Bandwidth vs Throughput vs Goodput begins the diagram in Figure 8.4; locate Bandwidth vs Throughput vs Goodput, compare From theoretical capacity to usable application data, and verify Bandwidth. Bandwidth vs Throughput vs Goodput states the starting condition; From theoretical capacity to usable application data supplies its counterpart; Bandwidth limits the conclusion; retain its labelled boundary.
Separate small control traffic
Control commands and alarms often need predictable delay more than raw bandwidth. Give them a traffic class, topic, or path that is not buried behind bulk uploads.
Batch only when it helps
Bundling readings can improve goodput by amortizing headers, but it can also increase latency and loss impact. Match batching to the freshness requirement.
Treat queues as evidence
Rising queue depth, delayed acknowledgements, and bursty retries explain many "the link is fast but the app is slow" incidents.
Review question: when a deployment misses a timing target, ask which packets were useful, which were overhead, which were retries, and which waited in a queue. That evidence is more actionable than a bandwidth number alone.
Pete’s Delivery Slip
- Address: commands and alarms get their own traffic class, topic, or path — not buried behind bulk uploads.
- Route: the shared uplink, where camera bursts, headers, retries, and queues contend.
- Receipt: log goodput, retry counts, queue depth, and timestamped send and receive events.
8.4 Under the Hood: Forwarding Is a Series of Local Decisions
Packet switching feels end-to-end from the application view, but the network executes it as a chain of local choices. At each hop, a device receives a packet, checks enough metadata to decide what to do, waits for an output opportunity, and either forwards, marks, delays, or drops the packet.
Those local choices depend on tables and state that are smaller than the full application conversation. A router may use a forwarding table, a neighbor cache, a next-hop record, a hop-limit or TTL update, and optional quality-of-service markings. A constrained gateway may also decide whether a packet should cross from a low-power mesh into Ethernet, Wi-Fi, or a cellular backhaul. None of those devices needs to reconstruct the whole sensor workflow. They need enough header evidence to choose the next interface, enough buffer space to wait safely, and enough policy to reject traffic that should not pass.
Store-and-forward
Many devices receive the complete packet before forwarding it. That gives the device a chance to validate the frame and make a forwarding decision before the next hop sees it.
Queues create variable delay
When an output link is busy, packets wait. The wait changes with burst size, scheduling policy, retransmissions, and the traffic already ahead in the buffer.
Drops are part of the contract
If a buffer is full, a link fails, or a policy rejects a packet, the packet can be discarded. Recovery must come from transport or application behavior.
8.4.1 Edge and Core: Two Different Forwarding Styles
Not every hop makes its local decision the same way. Real networks are usually built in two layers: an edge of Ethernet switches connecting cameras, sensors, gateways, and access points at each site, and a core of IP routers carrying traffic between sites over a backbone. The two layers forward packets by different rules.
Ethernet switches at the edge are plug-and-play. Each device keeps a flat, topology-independent MAC address, and a switch that does not yet know where an address lives falls back to flooding the frame out every port until a reply teaches it the right one. That is simple to deploy but does not scale past one site: flooding traffic across a wide-area backbone would waste most of the link on frames nobody wants. IP routers at the core solve that differently: they build a forwarding table from routing protocol exchanges before traffic ever arrives, so a table lookup replaces a flood. The tradeoff is setup cost. An Ethernet switch needs no configuration to start forwarding; an IP router needs its routing state to be correct before it can look anything up.
For an IoT deployment, this split explains a familiar pattern: local traffic between a gateway and its sensors usually rides flat, self-configuring Ethernet or Wi-Fi, while traffic between sites or up to the cloud crosses a routed IP backbone. A device that behaves correctly on one site's flat network can still need explicit routing to reach another building or a cloud region.
8.4.2 Router Internals: Queues, Backplane, and Planes
A network router is more than one input port and one output port. Physical interfaces receive frames, line cards hold queues and forwarding hardware, and an internal backplane or switch fabric moves packets between those interfaces. A small router may share memory or a bus for this transfer. A high-capacity chassis uses switched fabrics and line cards so several ports can move traffic at once.
Provision that fabric against offered port load rather than naming it merely “fast.” Using the source notation, backplane speedup is the aggregate backplane capacity divided by port capacity; input and output speedup compare their respective backplane-side capacities with the port capacity. Output-only queueing exposes the extreme case: if every input sends to the same output at once, the output side would need speedup equal to the number of ports to absorb the whole burst. Combined input-output queueing reduces that demand and can improve utilisation, but requires harder scheduling and backpressure logic.
A switched backplane behaves like a small point-to-point network inside the router: disjoint input-output pairs can transfer simultaneously. The source fragments packets into fixed-size cells, giving 64 bytes as an example, so the fabric schedules uniform transfer units instead of leaving a cycle partly unused by a short packet. Commercial designs place that forwarding work in dedicated ASICs while a route-processor CPU runs control-plane routing; a PC router instead uses NICs on a PCI bus and performs more of both jobs on a commodity CPU. In a large slotted chassis, line cards and the route-processor card can be replaced for repair or upgrade, including hot-swapping where the platform supports it.
Before router internals: queues, backplane, and planes, inspect Figure 8.5: Typical router architecture must be considered with Sending. That visual pairing grounds input interfaces and output interfaces connect through an internal backplane, which can be shared memory, a shared bus, or a switched bus depending in named evidence.
Locate Typical router architecture on Figure 8.5 before checking Sending. The visual’s third anchor, device, completes input interfaces and output interfaces connect through an internal backplane, which can be shared memory, a shared bus, or a switched bus depending. Carry Typical router architecture into router internals: queues, backplane, and planes; use device as its limiting condition.
Queue placement changes the failure mode. An input-queued router can be simple, but a packet waiting for one busy output can hold packets behind it that were destined for free outputs. That is head-of-line blocking. Output queues avoid that particular block by collecting packets at the egress side, but they require enough fabric and buffer capacity to absorb bursts. Virtual output queues split each input into per-output queues, reducing head-of-line blocking at the cost of more buffer and scheduling complexity.
The visual evidence for router internals: queues, backplane, and planes sits in Figure 8.6. Find Head-of-line blocking beside INPUT QUEUES before interpreting a busy output stalls the head packet in each input queue, blocking packets behind it bound for free outputs; virtual output queues give each input.
Compare Head-of-line blocking with INPUT QUEUES inside the visual at Figure 8.6. Next find one shared FIFO per input, which completes the scope of a busy output stalls the head packet in each input queue, blocking packets behind it bound for free outputs; virtual output queues give each input. The decision in router internals: queues, backplane, and planes must preserve that labelled boundary.
Keep the control plane and data plane separate in incident notes. The control plane computes routes, learns topology, and updates forwarding tables. The data plane applies those tables at line rate: classify, queue, forward, mark, or drop. A route processor or controller can be healthy while one output queue is congested, and an output queue can be empty while the routing table is wrong. Good evidence names which plane made the decision and where the packet waited.
Figure 8.7 makes router internals: queues, backplane, and planes inspectable through Control plane vs. data plane and ROUTE PROCESSOR. Those diagram labels establish the scope of the control plane’s route processor computes and installs the forwarding table; the data plane’s switching fabric and line cards apply that table to.
Use ROUTE PROCESSOR to test Control plane vs. data plane in the diagram at Figure 8.7. Then inspect runs routing protocols as the final qualifier on the control plane’s route processor computes and installs the forwarding table; the data plane’s switching fabric and line cards apply that table to. That sequence keeps router internals: queues, backplane, and planes tied to what is visibly labelled.
Decision record for incidents: capture the path, the queue or radio state at each constrained hop, the retry behavior, and the application freshness requirement. That record connects forwarding mechanics to user-visible performance.
Pete’s Delivery Slip
- Address: the classify step reads destination, protocol, priority marking, and ingress interface.
- Route: the forwarding table maps destination to output interface and next hop, with hop metadata updated.
- Receipt: a full buffer, failed link, or policy drop discards the packet — recovery belongs to transport or application.
8.5 Summary
Packet switching lets many IoT flows share the same network by forwarding independent packets instead of reserving a dedicated circuit for each conversation. Routers make local forwarding decisions from packet headers, while queues, retries, overhead, and path changes determine the performance that applications actually experience.
For design reviews, separate bandwidth, throughput, goodput, delay, and jitter. A link can have enough nominal capacity and still fail a control-loop requirement if useful packets wait behind bulk traffic or spend too much of the budget on overhead and recovery.
8.6 Key Takeaway
Packet switching scales IoT because shared links can carry many bursty flows, but shared links also create queueing, overhead, and loss tradeoffs. Measure useful delivered payload and timing evidence, not just nominal link speed.