Guide a data packet from source to destination in this interactive game, making routing decisions across three network environments. Apply OSI layer knowledge, select correct protocols, and overcome real-world challenges like congestion, node failures, and firewalls while learning packet encapsulation and forwarding mechanics.
By the end of this chapter, you will be able to:
This interactive game lets you experience networking by playing the role of a data packet traveling through a network. You will make decisions about routing, deal with congestion, and learn how real networks work—all through a fun, game-based experience that requires no prior technical knowledge.
“This is so cool—you get to BE a data packet!” exclaimed Sammy the Sensor. “You travel through the network, hopping from router to router, making decisions at every stop!”
“At each hop, you have to choose the right path,” explained Max the Microcontroller. “Take the wrong route and you might hit congestion, a firewall, or a failed node. It is like a maze where you need to apply everything you know about network layers and routing.”
Lila the LED was already playing. “I just learned that picking UDP instead of TCP at the transport layer makes my packet faster but riskier—no retransmission if I get lost! And at each router, I need to check the routing table to find the best next hop.”
“The game has three levels that get harder,” said Bella the Battery. “Level 1 is a simple home network, Level 2 is a campus with multiple subnets, and Level 3 is a full internet journey with firewalls and NAT. See how many packets you can deliver without losing any lives!”
Time: ~20 min | Difficulty: Intermediate | Unit: P07.C15.U10
Guide a data packet from source to destination across three increasingly complex network environments. Make correct routing decisions, apply the right protocols at each layer, and overcome network challenges like congestion, failures, and firewalls.
Every routing choice in the game changes end-to-end delay.
\[ T_{end\text{-}to\text{-}end} = \sum_{i=1}^{h} t_i + N_{retry}\times t_{retry} \]
Worked example: Suppose a packet crosses 5 hops with per-hop delays of \([1,3,5,2,4]\) ms and one retry penalty of \(3\) ms:
\[ T = (1+3+5+2+4) + 1\times 3 = 18\text{ ms} \]
If a congested route causes three retries instead, delay becomes:
\[ T = 15 + 3\times 3 = 24\text{ ms} \]
That 6 ms increase is a 33% latency jump, which is why low-loss paths usually beat “short-looking” but unstable routes.
viewof hops_per_hop = Inputs.range([1, 10], {value: 5, step: 1, label: "Number of hops (h)"})
viewof avg_hop_delay = Inputs.range([1, 100], {value: 3, step: 1, label: "Average per-hop delay (ms)"})
viewof n_retry = Inputs.range([0, 10], {value: 1, step: 1, label: "Number of retries (N_retry)"})
viewof retry_penalty = Inputs.range([1, 500], {value: 3, step: 1, label: "Retry timeout penalty (ms)"}){
const sumHops = hops_per_hop * avg_hop_delay;
const retryTotal = n_retry * retry_penalty;
const total = sumHops + retryTotal;
const baseTotal = sumHops; // no retries
const pctIncrease = baseTotal > 0 ? ((total - baseTotal) / baseTotal * 100).toFixed(1) : 0;
return html`<div style="background:#f0f7f4; padding:1rem; border-radius:8px; border-left:4px solid #16A085; margin-top:0.5rem; font-family:system-ui,sans-serif;">
<p style="margin:0 0 0.5rem 0; color:#2C3E50;"><strong>Hop propagation total:</strong> ${hops_per_hop} × ${avg_hop_delay} ms = <strong style="color:#16A085;">${sumHops} ms</strong></p>
<p style="margin:0 0 0.5rem 0; color:#2C3E50;"><strong>Retry penalty total:</strong> ${n_retry} × ${retry_penalty} ms = <strong style="color:#E67E22;">${retryTotal} ms</strong></p>
<p style="margin:0 0 0.5rem 0; color:#2C3E50; font-size:1.1em;"><strong>T<sub>end-to-end</sub> = <span style="color:#3498DB;">${total} ms</span></strong></p>
${n_retry > 0 ? html`<p style="margin:0; color:#7F8C8D; font-size:0.9em;">Retries add ${pctIncrease}% latency overhead vs. zero-loss path (${baseTotal} ms).</p>` : html`<p style="margin:0; color:#7F8C8D; font-size:0.9em;">No retries — this is the minimum achievable latency for ${hops_per_hop} hops.</p>`}
</div>`;
}Question: In Level 1 of the Packet Journey game, a switch must forward a frame to a device on the same LAN. Which address does the switch use?
Answer: The switch uses the destination MAC address, because switches forward at OSI Layer 2. IP addresses are used by routers at Layer 3, and port numbers belong to Layer 4.
Guide one sensor packet through LAN, WAN, and IoT mesh decisions.
The Packet Journey game reinforces these key networking concepts:
Level 1 - LAN Routing:
Level 2 - WAN Routing:
Level 3 - IoT Mesh Routing:
Question: When a packet leaves a 6LoWPAN mesh through a border router, compressed headers are restored to full IPv6 format. What is this process called?
Answer: This is header decompression. 6LoWPAN compresses IPv6 headers inside the constrained mesh, and the border router expands them back to standard IPv6 format for external networks.
Scenario: You’re designing a smart traffic light system. When a pedestrian presses the crosswalk button, the traffic controller must receive the signal within 500 ms to meet safety standards.
Network Path (similar to Game Level 2):
| Step | Network point | Role in the journey |
|---|---|---|
| 1 | Sensor button | Creates the safety message. |
| 2 | Edge router | Forwards the packet out of the local network. |
| 3 | ISP core | Carries the packet across the provider network. |
| 4 | Peering point | Hands traffic between networks; congestion often appears here. |
| 5 | Cloud firewall | Checks whether the packet is allowed. |
| 6 | Traffic controller | Receives the message and changes the crossing state. |
Delay Components from Packet Journey Game:
Hop 1: Sensor to Edge Router (LAN)
Hop 2: Edge Router to ISP Core
Hop 3: ISP Core to Peering Point
Hop 4: Peering Point to Cloud Firewall
Hop 5: Cloud Firewall to Traffic Controller
Total End-to-End Delay and Safety Margin:
| Check | Calculation | Result |
|---|---|---|
| Total path delay | 7 + 25 + 55 + 17 + 15 |
119 ms |
| Safety budget | System requirement | 500 ms |
| Remaining margin | 500 - 119 |
381 ms of headroom |
| Design status | 119 ms < 500 ms |
Within the safety budget |
What If We Made Wrong Protocol Choices?
Bad Decision 1: Skip QoS (treat as best-effort traffic) - Peering point queueing increases from 30 ms to 200 ms during congestion - New total: 119 - 30 + 200 = 289 ms (still OK, but margin reduced to 42%)
Bad Decision 2: Use UDP instead of TCP (Game Level 2 choice) - 5% packet loss requires retransmission - Retransmit timeout: 200 ms (RTT × 2) - Expected delay: 119 ms × 0.95 + (119 + 200) × 0.05 = 129 ms average - But worst-case (packet lost): 319 ms (still within 500 ms)
Bad Decision 3: Firewall rule misconfiguration (Game Level 2) - Packet blocked by default deny rule - Sensor timeout + retransmit: 1,000 ms (exceeds safety budget) - System failure: Pedestrian button press not detected
Real-World Lesson from Game Mechanics:
The Packet Journey Game teaches that delay is cumulative and unpredictable: - Each hop adds latency (sum of all hops) - Wrong protocol choices (UDP without retries, best-effort QoS) add risk - Firewall errors cause complete failure, not just delay
Design Rule: Budget for worst-case, not average: - Average path: 119 ms - Worst-case (congestion + 1 retransmit): ~500 ms - Design with 2x safety margin: 500 ms requirement means a 250 ms target latency
Optimizations Applied:
From Game Level 2 Decisions:
From Game Level 3 (6LoWPAN mesh):
Final System Design:
| Segment | Design choice | Typical delay |
|---|---|---|
| Sensor to edge router | Direct Wi-Fi, single hop | 7 ms |
| Edge router to ISP core | QoS enabled | 25 ms |
| ISP core to cloud | Expedited Forwarding | 35 ms |
| Cloud to controller | Firewall pre-configured | 32 ms |
| Total | Typical path | About 99 ms |
| Safety requirement | Worst-case design target | About 350 ms worst-case, still below 500 ms |
Key Insight from Game: Protocol decisions at each layer (MAC, transport, network, application) compound across the entire path. The game’s level structure mirrors real network hops, teaching that every decision matters for end-to-end latency.
Replaying a game to improve the score without reading the explanations for wrong answers reinforces incorrect mental models. Fix: read every explanation carefully before attempting the next question, even when the answer was correct.
Game scores measure performance on a specific question set, not broad mastery. Fix: supplement game exercises with worked examples, labs, and scenario problems to confirm genuine understanding.
Interactive games in this module are designed to reveal common misconceptions that text alone may not expose. Fix: attempt every game exercise and use wrong answers as diagnostic information about which concepts need more study.
The Packet Journey game demonstrates how every protocol decision compounds across network hops. A wrong transport-layer choice (UDP instead of TCP for critical data), a missing QoS marking, or a misconfigured firewall rule each affects end-to-end latency or causes outright delivery failure. The three-level structure—LAN, WAN, and IoT mesh—shows that the same core principles (addressing, forwarding, encapsulation) apply from a home switch all the way to a battery-constrained 6LoWPAN sensor node.
You have completed the Networking Fundamentals series. The table below shows where to go next based on the concepts introduced in this game.
| Topic | Chapter | Description |
|---|---|---|
| IP Addressing and Subnetting | Network Addressing and Subnetting | Build on the routing table decisions from Level 1 by mastering CIDR notation, subnet masks, and address allocation for IoT deployments |
| Packet Switching Mechanics | Network Mechanisms | Explore how packet switching and store-and-forward work inside the routers you navigated in Levels 1 and 2 |
| Routing Protocols in Depth | Routing Fundamentals | Go deeper on the routing table lookups used in the game and learn how OSPF, BGP, and RPL build those tables automatically |
| RPL for IoT Mesh Networks | RPL Fundamentals and Construction | Study the RPL energy-aware routing and DODAG repair mechanics that Level 3 of the game demonstrated |
| TCP and UDP Transport | Transport Fundamentals | Analyse the TCP versus UDP trade-off from Level 2 in detail, including connection setup, flow control, and congestion avoidance |
| Network Security and Firewalls | IoT Security Fundamentals | Extend the firewall rule challenge from Level 2 into a full study of IoT threat models, packet filtering, and intrusion detection |