Chapter 36 — Critical infrastructure and sector security: performance and scale
Lesson map
Lesson 36 published. Map, example, EX071.
flowchart TD
N0["Learning outcomes and connection"]
N1["36.1 Queues everywhere"]
N2["36.2 The cost of security"]
N3["36.3 Peak, degraded and attack load"]
N4["36.4 Scale"]
N5["36.6 Practical activity: Lab 13"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX071"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["36.1 Queues everywhere"]
N2["36.2 The cost of security"]
N3["36.3 Peak, degraded and attack load"]
N4["36.4 Scale"]
N5["36.6 Practical activity: Lab 13"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX071"]
[Learning outcomes and connection]
|
v
[36.1 Queues everywhere]
|
v
[36.2 The cost of security]
|
v
[36.3 Peak, degraded and attack load]
|
v
[36.4 Scale]
|
v
[36.6 Practical activity: Lab 13]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX071]
Learning outcomes and connection
After this chapter you can (1) model throughput, latency and utilisation with queueing theory and Little's law; (2) estimate the performance cost of security controls; (3) size systems for peak and degraded conditions, including attack-induced load; and (4) design for scale — fleets of thousands of devices — in key management, monitoring and updates. It builds on Chapters 11, 19 and 34 and prepares Chapter 41.
36.1 Queues everywhere
Messages wait in queues at gateways, servers and links. Little's law, $L = \lambda W$, relates the average number in a system $L$, the arrival rate $\lambda$ and the average time in the system $W$, under very general conditions. For the simple M/M/1 model (random arrivals, exponential service, one server with service rate $\mu$), utilisation is $\rho = \lambda/\mu$ and $W = 1/(\mu - \lambda)$. Delay grows without bound as $\rho \to 1$: at 80% utilisation the average message spends five service times in the system; at 96%, twenty-five. Size so that peak utilisation stays well below 1 — commonly under 0.7 for latency-critical paths.
36.2 The cost of security
Every control costs something: bytes (Lab 8's 22-byte overhead), CPU (MAC computation, TLS handshakes), latency (policy decisions, inspection), and operator time (re-authentication, approvals). Measure them on the bench. The costs are usually small relative to network round-trips, but they matter on constrained links (low-bandwidth radio), on constrained devices (small microcontrollers), and at scale.
For TMRP, the measured costs include the twenty-two extra bytes per frame, the MAC computation on each message at the SCADA-side verifier and the operator time for two-person approval of bulk setpoint changes. None is large, but the verifier's throughput limit is what the worked example has to size.
36.3 Peak, degraded and attack load
Size for the worst credible load: storm-time alarm floods, reconnection bursts after outages (Chapter 34), failover catch-up, and deliberate floods. An attacker who can send traffic to a gateway can push utilisation toward 1 and delay legitimate alarms; defences include rate limits per source, priority queues for alarms, early rejection of unauthenticated traffic (verify the cheap check first), and capacity margins.
For TMRP, the reconnection burst found in integration testing is the clearest example, and the verifier's priority queue for alarms is the defence chosen in the worked example.
36.4 Scale
At fleet scale, manual processes fail. Key enrolment, rotation and revocation must be automated with audit; monitoring must aggregate and prioritise; updates must be staged and observable; inventory must be continuously reconciled. A procedure that takes 30 minutes per device takes 500 hours of staff time, about three months for one full-time engineer, for a thousand devices.
LRWA has only 42 field stations today, but the same design may later be used for a much larger fleet, so TMRP automates key enrolment and rotation records from the start rather than relying on a spreadsheet maintained by one engineer.
36.5 Worked example: gateway sizing (synthetic)
The SCADA-side verifier can process 50 messages/s. In steady state LRWA's 42 stations generate about 20 messages/s ($\rho = 0.4$, $W \approx 33$ ms). During a storm, alarms raise arrivals to 40/s ($\rho = 0.8$, $W = 100$ ms, about 4 messages in the system). At 48/s, $W = 500$ ms and 24 messages are in the system on average. Sequential polling of 42 stations at 180 ms round-trip plus register time takes 7.8 s per cycle; six parallel channels reduce it to 1.3 s. Decisions: verifier capacity doubled to 100 messages/s for headroom; priority queue for alarms; report-by-exception for alarms rather than waiting for the poll.
36.6 Practical activity: Lab 13
# Lab 13 - is the telemetry gateway fast enough? M/M/1 and a polling cycle (synthetic, offline)
mu = 50.0 # messages/s the gateway can verify and forward
for lam in (20.0, 40.0, 45.0, 48.0):
rho = lam / mu; W = 1 / (mu - lam); L = lam * W
print(f"lambda={lam:>4} rho={rho:.2f} W={W*1000:6.1f} ms L={L:5.1f} msgs")
stations, regs_per_poll, rtt_ms, per_reg_ms = 42, 3, 180, 2
cycle = stations * (rtt_ms + regs_per_poll * per_reg_ms)
print(f"sequential polling cycle: {cycle/1000:.2f} s; with 6 parallel channels: {cycle/6/1000:.2f} s")
Expected output:
lambda=20.0 rho=0.40 W= 33.3 ms L= 0.7 msgs
lambda=40.0 rho=0.80 W= 100.0 ms L= 4.0 msgs
lambda=45.0 rho=0.90 W= 200.0 ms L= 9.0 msgs
lambda=48.0 rho=0.96 W= 500.0 ms L= 24.0 msgs
sequential polling cycle: 7.81 s; with 6 parallel channels: 1.30 s
The first four lines show delay growing sharply as arrivals approach the verifier's capacity of fifty messages a second: at twenty messages a second the average message waits about a third of a tenth of a second, while at forty-eight it waits half a second and two dozen messages are in the system. The polling lines show why LRWA uses six parallel channels: a sequential cycle of nearly eight seconds would leave alarms waiting long before they reached the verifier.
36.7 Common errors and limits
- Sizing for average load.
- Ignoring that delay explodes near full utilisation.
- Assuming security costs are negligible without measuring them on the target device.
- Manual procedures that do not scale.
- M/M/1 used where arrivals are bursty or service is deterministic; treat it as a first approximation.
TMRP's sizing avoids the first two errors by sizing for storm load and keeping the doubled verifier well below full utilisation, and treats the queueing results as a first approximation to be checked against bench measurements.
Exercises — chapter 36
EX071 — Doubling capacity. Objective: quantify headroom. Inputs: Lab 13 with $\mu = 100$. Steps: compute $\rho$, $W$ and $L$ at 20, 40 and 48 messages/s; compare with $\mu = 50$. Expected evidence: table. Rubric: 3 = correct values (e.g., at 48/s: ρ = 0.48, W ≈ 19.2 ms, L ≈ 0.92) and conclusion; 2 = one error; 1 = one rate; 0 = none.
EX072 — Flood defence. Objective: design against attack load. Inputs: an attacker on the LTE network can send 1,000 forged frames/s to the verifier. Steps: propose three defences in order of cost and explain how each protects alarm latency. Expected evidence: list. Rubric: 3 = network-level filtering by source/tunnel, cheap pre-checks before MAC, per-source rate limits and priority queues, with reasoning about where load is shed; 2 = one defence; 1 = "add capacity" only; 0 = none.
Chapter synthesis
Queues govern latency; Little's law and simple queueing models show that delay explodes as utilisation approaches one. Measure the costs of security controls, size for peak, degraded and attack load with priority for alarms, and automate fleet-scale processes from the start.
Continue studying — chapter 36 of 50
← Chapter 35 · Course chapter index · Chapter 37 →
Continue to the next authored lesson.