645  Packet Switching and Network Performance

645.1 Learning Objectives

By the end of this section, you will be able to:

  • Explain Packet Switching: Describe how routers examine headers and make independent forwarding decisions
  • Understand Multiplexing: Explain how multiple data streams share a single network link
  • Evaluate Network Resilience: Describe how packet switching enables automatic rerouting around failures
  • Distinguish Performance Metrics: Differentiate between bandwidth, throughput, and goodput
  • Apply to IoT Design: Calculate network capacity and efficiency for IoT deployments

645.2 Prerequisites

Before diving into this chapter, you should be familiar with:

ImportantWhy Packet Switching Matters for IoT

Packet switching makes IoT economically viable. Without it, every sensor would need a dedicated connection to the cloud - impossibly expensive at scale. Packet switching lets millions of devices share network infrastructure, each using resources only when actively transmitting.

645.3 How Packet Switching Works

When a datagram is transmitted, devices along the communication path examine the header and make forwarding decisions based on the destination address.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '13px'}}}%%
graph LR
    Sensor["IoT Sensor<br/>192.168.1.10"]
    R1["Router 1<br/>Examines dest addr"]
    R2["Router 2<br/>Examines dest addr"]
    R3["Router 3<br/>Examines dest addr"]
    Cloud["Cloud Server<br/>54.235.1.100"]

    Sensor -->|Datagram:<br/>Dest: 54.235.1.100| R1
    R1 -->|"Forwards based<br/>on routing table"| R2
    R2 -->|"Next hop<br/>decision"| R3
    R3 -->|Delivers| Cloud

    style Sensor fill:#2C3E50,stroke:#16A085,color:#fff
    style R1 fill:#16A085,stroke:#2C3E50,color:#fff
    style R2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style R3 fill:#16A085,stroke:#2C3E50,color:#fff
    style Cloud fill:#2C3E50,stroke:#16A085,color:#fff

Figure 645.1: Packet switching path from IoT sensor through routers to cloud

{fig-alt=“Packet switching diagram showing datagram traveling from IoT sensor through three routers to cloud server, with each router independently examining destination address and making forwarding decisions”}

Transmitted datagrams effectively “find their own way” across an internetwork because each router independently decides where to forward the datagram based on addressing information.

645.3.1 The Forwarding Process

  1. Packet arrives at router interface
  2. Router examines destination IP address in header
  3. Routing table lookup finds best next-hop
  4. Packet forwarded out appropriate interface
  5. Process repeats at each router until destination reached

Each router makes its decision independently - packets from the same conversation may take different paths through the network.

645.4 Advantages of Packet Switching

645.4.1 Multiplexing

Multiple data streams share a common network link by interleaving datagrams.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '12px'}}}%%
sequenceDiagram
    participant Cam as Camera (Video)
    participant Temp as Temp Sensor
    participant Channel as Shared Network Link
    participant Cloud as Cloud Server

    Note over Channel: Time-multiplexed transmission
    Cam->>Channel: Video Packet 1
    Channel->>Cloud: Video Packet 1
    Temp->>Channel: Temp Reading
    Channel->>Cloud: Temp Reading
    Cam->>Channel: Video Packet 2
    Channel->>Cloud: Video Packet 2
    Temp->>Channel: Humidity Reading
    Channel->>Cloud: Humidity Reading
    Cam->>Channel: Video Packet 3
    Channel->>Cloud: Video Packet 3

Figure 645.2: Time-division multiplexing of video and sensor packets on shared link

{fig-alt=“Sequence diagram showing multiplexing where camera video packets and temperature sensor data packets are interleaved over shared network link in time-division manner”}

IoT Example: A smart home gateway can simultaneously: - Stream security camera footage (video) - Transmit temperature sensor readings (data) - Handle voice assistant commands (audio)

All over the same Wi-Fi connection!

645.4.2 Network Resilience

If one link becomes unavailable, subsequent datagrams are re-routed along other links.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '13px'}}}%%
graph TB
    Sensor["IoT Sensor"]
    R1["Router 1"]
    R2["Router 2"]
    R3["Router 3"]
    Cloud["Cloud Server"]

    Sensor -->|"Normal path"| R1
    R1 -.->|"X Link failure"| R2
    Sensor -->|"Reroute via R3"| R3
    R3 --> R2
    R2 --> Cloud

    style Sensor fill:#2C3E50,stroke:#16A085,color:#fff
    style R1 fill:#E74C3C,stroke:#C0392B,color:#fff
    style R2 fill:#16A085,stroke:#2C3E50,color:#fff
    style R3 fill:#16A085,stroke:#2C3E50,color:#fff
    style Cloud fill:#2C3E50,stroke:#16A085,color:#fff

Figure 645.3: Network resilience with automatic rerouting around failed link

{fig-alt=“Network resilience diagram showing IoT sensor rerouting packets through alternate path via Router 3 when normal path through Router 1 fails”}

IoT Example: An industrial sensor network can maintain communication even if individual network segments fail.

645.5 Packet Switching Process Summary

  1. Data is broken into datagrams with headers
  2. Each datagram is routed independently based on destination address
  3. Many paths may be used for a single communication (no fixed path)
  4. Datagrams are reordered at the destination based on sequence numbers

645.6 Bandwidth, Throughput, and Goodput

These three terms are often confused but have distinct meanings:

Metric Definition Analogy
Bandwidth Maximum theoretical capacity Highway lanes
Throughput Actual measured data rate Real traffic flow
Goodput Usable application data rate Passengers delivered

This variant clarifies the critical difference between these three commonly confused network performance metrics - essential for IoT capacity planning.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'fontSize': '10px'}}}%%
flowchart TB
    subgraph PIPE["100 Mbps Link (Bandwidth)"]
        BW["BANDWIDTH<br/>-----------<br/>100 Mbps<br/>-----------<br/>Theoretical max<br/>capacity of link"]
    end

    subgraph ACTUAL["What You Actually Get"]
        TH["THROUGHPUT<br/>-----------<br/>~70 Mbps<br/>-----------<br/>Measured data rate<br/>including all overhead"]

        GP["GOODPUT<br/>-----------<br/>~60 Mbps<br/>-----------<br/>Usable app data<br/>after removing headers"]
    end

    subgraph LOSSES["What Reduces Efficiency"]
        L1["Protocol Headers<br/>~8% overhead"]
        L2["Congestion/Retries<br/>~12% loss"]
        L3["Processing Delays<br/>~10% reduction"]
    end

    BW --> L1 --> TH
    TH --> L2 --> GP
    L3 --> GP

    style BW fill:#2C3E50,stroke:#16A085,color:#fff
    style TH fill:#E67E22,stroke:#2C3E50,color:#fff
    style GP fill:#16A085,stroke:#2C3E50,color:#fff
    style L1 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style L2 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style L3 fill:#7F8C8D,stroke:#2C3E50,color:#fff

Figure 645.4: Bandwidth vs Throughput vs Goodput - The journey from theoretical capacity to usable application data

IoT Impact: For small IoT packets (50 bytes), protocol overhead can reduce goodput to just 40% of bandwidth. Larger packets improve efficiency significantly.

645.6.1 Real-World Efficiency

Real-world networks typically achieve 60-70% efficiency (goodput / bandwidth):

100 Mbps Link Calculation
Bandwidth 100 Mbps (theoretical maximum)
Throughput ~70 Mbps (after congestion, retries)
Goodput ~60 Mbps (after protocol overhead)

Factors reducing efficiency: - Protocol headers (8-40 bytes per packet) - Network congestion and collisions - Retransmissions for lost packets - Processing delays at each hop

645.7 Packet Size Tradeoffs

WarningTradeoff: Small Frequent Packets vs Aggregated Large Packets

Option A: Send small packets immediately as data is generated - lower latency, simpler device logic, real-time responsiveness

Option B: Aggregate multiple readings into larger packets before transmission - higher protocol efficiency, lower power consumption, reduced network overhead

Decision Factors: Choose small immediate packets for time-critical applications (alarms, real-time control) where latency matters more than efficiency. Choose aggregation for periodic telemetry (temperature, humidity) where 10-60 second delays are acceptable. A 50-byte packet has ~40% efficiency due to fixed 78-byte overhead, while aggregating 10 readings into 500 bytes achieves ~85% efficiency. For battery-powered devices, aggregation can extend battery life 2-3x by reducing radio wake-ups.

645.7.1 Efficiency by Packet Size

Payload Size Total with Overhead Protocol Efficiency
50 bytes 128 bytes 39%
100 bytes 178 bytes 56%
500 bytes 578 bytes 87%
1000 bytes 1078 bytes 93%
1460 bytes 1538 bytes 95%

IoT Recommendation: Aggregate small sensor readings when latency permits. A gateway collecting 50-byte readings from 10 sensors and sending one 500-byte packet is 2x more efficient than 10 individual transmissions.

645.8 Knowledge Check

Scenario: Your manufacturing facility has an aging network infrastructure. Five industrial machines connect via 100BASE-T Ethernet (100 Mbps each) to a central switch. The switch connects to the router through a legacy 10BASE-T link (10 Mbps). The router has a modern 1 Gbps connection to the internet. All five machines simultaneously begin uploading large diagnostic files to the cloud for analysis.

Network path: Machines (100 Mbps) -> Switch -> 10 Mbps link -> Router (1 Gbps) -> Internet

Think about: 1. What is the maximum aggregate throughput that all five machines can achieve when uploading data simultaneously to the cloud? 2. If you had a $5,000 budget to upgrade one network segment, which link should you prioritize upgrading to immediately improve performance?

Key Insight: The bottleneck principle states that “throughput cannot exceed the slowest link” in the data path. Despite each machine having 100 Mbps connections and the router having 1 Gbps internet access, the legacy 10BASE-T link between switch and router becomes a 10 Mbps bottleneck - limiting aggregate throughput to 10 Mbps regardless of faster links before or after it. All five machines must share this 10 Mbps (~2 Mbps each). This is analogous to highway traffic: a 10-lane highway (100 Mbps machine links), then a 1-lane construction zone (10 Mbps bottleneck), then a 10-lane highway (1 Gbps internet) - traffic flows at 1-lane speed. Upgrading the switch-to-router link to 1 Gbps would allow 100 Mbps aggregate throughput (then limited by individual machine links).

Question: A data center has three network segments: Segment A (10 Gbps fiber), Segment B (1 Gbps copper), Segment C (100 Mbps copper). Comparing goodput vs bandwidth, which statement is most accurate?

Explanation: Goodput = usable application-layer data rate after removing protocol overhead, retransmissions, and idle time. Real-world networks typically achieve 60-70% efficiency (goodput / bandwidth). Example calculations: Segment A (10 Gbps): Goodput is approximately 6-7 Gbps. Segment B (1 Gbps): Goodput is approximately 600-700 Mbps. Segment C (100 Mbps): Goodput is approximately 60-70 Mbps. Factors reducing efficiency: Protocol overhead (Ethernet preamble, MAC header, IP header, TCP header, inter-frame gap) = ~78 bytes per 1500-byte packet = 5% overhead for large packets, much higher for small packets. Network congestion = queuing delays, collisions, backoff. Processing delays = time switches/routers spend examining packets. Retransmissions = error recovery overhead.

Question: A network has 3 publishers and 2 subscribers using MQTT (publish-subscribe pattern) vs peer-to-peer architecture. How many connections are needed, and what happens if you add 2 more subscribers in each architecture?

Explanation: MQTT (publish-subscribe): Each device connects once to broker. Initial: 3 publishers + 2 subscribers = 5 connections. Adding 2 subscribers: 3 + 4 = 7 connections (+2 linear scaling). Peer-to-peer: Each publisher must connect to each subscriber. Initial: 3 publishers x 2 subscribers = 6 connections. Adding 2 subscribers: 3 x 4 = 12 connections (+6, quadratic scaling). This dramatic difference demonstrates why publish-subscribe patterns (MQTT, message queues) scale better than peer-to-peer for IoT. The broker decouples publishers from subscribers - they never communicate directly, only through the broker.

645.9 Summary

  • Packet switching lets datagrams find their own paths, with each router making independent forwarding decisions
  • Multiplexing enables multiple data streams (video, sensor data, commands) to share a single network link
  • Network resilience comes from automatic rerouting - if one path fails, packets take alternate routes
  • Bandwidth is theoretical maximum, throughput is measured rate, goodput is usable application data (typically 60-70% of bandwidth)
  • Packet size tradeoffs: Small packets = lower latency but higher overhead; large/aggregated packets = better efficiency but higher latency

645.10 What’s Next

Now that you understand how packets are switched through networks, the next section explores converged networks - how modern infrastructure carries voice, video, data, and IoT traffic on a single unified network. You’ll also learn about channel access mechanisms like CSMA/CA that enable shared wireless communication.

Continue to: Converged Networks and Channel Access