Applied stage summary

TCP has no view of the network. It opens with a three-way handshake to agree starting sequence numbers, then numbers every byte and infers from the acknowledgements coming back what the far end received. Loss is never reported to it; loss is deduced. Duplicate acknowledgements say a later segment arrived while an earlier one did not, which is a fast and specific signal. A retransmission timeout says nothing came back at all, which is slower and much less specific. Reading which of the two a sender reacted to is the first piece of evidence any transport diagnosis needs, because the two describe very different paths.

Two windows limit how much data is in flight, and they belong to different parties. The receive window is the receiver's own statement of what it can absorb, advertised in every acknowledgement, and it shrinks to zero when the receiving application stops keeping up. Wireshark labels those moments TCP Window Full and TCP ZeroWindow, and they explain the connection that crawls on a link with no loss at all. The congestion window is the sender's private estimate of what the path between them can carry, built by probing because no switch or queue on the way advertises its limit. The effective sending rate is the smaller of the two, which is why the sentence bandwidth is fine settles nothing.

RFC 9293 describes what TCP provides in one line: a reliable, in-order, byte-stream service. Each word is a boundary. Reliable means lost segments are retransmitted, not that delivery is guaranteed under any condition, because a path that fails entirely ends with the connection closing and the application seeing an error. In-order means segments are handed up in sequence, which is also why one lost segment stalls everything queued behind it. Byte-stream means TCP does not preserve message boundaries at all, so framing is the application's job. TCP can confirm bytes reached the receiving kernel; it cannot confirm anybody processed them.

The network gives senders no explicit capacity signal, so every congestion control algorithm is a way of guessing from indirect evidence. That framing matters more than any single algorithm: congestion control is millions of independent senders cooperating without negotiating, and the shape of the guess decides how the internet shares a bottleneck. CUBIC, standardised in RFC 9438 in August 2023 and the default in both Linux and Windows, still infers congestion from loss, but grows its window in a shape designed for the long, fast paths the classical Reno-era algorithms handled badly.

BBR takes the other route. Rather than waiting for loss, it estimates the bottleneck bandwidth and the round-trip time of the path and paces against that model, which keeps queues shorter on paths where loss is a poor proxy for congestion. Version 3 is an Internet-Draft, draft-ietf-ccwg-bbr, and calling it a published standard is a citation error the stage keeps refusing. That the field needed RFC 9743 in March 2025 to set out what any new congestion control algorithm must demonstrate is itself evidence that this is live engineering rather than settled history.

Bufferbloat is where the theory meets a user complaint. Deep buffers in home routers and access equipment absorb bursts instead of dropping them, which converts congestion into latency and hides the signal the sender needed. L4S, specified across RFC 9330, RFC 9331 and RFC 9332 in January 2023, marks packets with ECN before queues build so senders slow down while latency stays low, loss stays low and throughput still scales. It ships in DOCSIS low-latency modes and has been interoperability-tested by Comcast, Apple, Google and NVIDIA. The operational lesson is blunt: a latency problem caused by a full buffer does not improve when you buy more bandwidth.

Both transports put bits on the wire at the same rate, because the link, the queues along the path and the distance decide that, and an eight-byte header does not travel faster than a twenty-byte one. What differs is what each makes you wait for. TCP asks for a handshake before the first byte of data, holds itself back when it detects loss, and delivers one ordered byte stream, so one lost segment stalls everything behind it. UDP skips all three, which is why a DNS query feels instant and why voice and video reach for it: late data is worse than missing data when the deadline has already passed.

QUIC, specified in RFC 9000, keeps the guarantees and removes the waiting. It folds the transport and TLS handshakes into a single exchange, carries independent streams that recover separately so a loss on one does not block the others, and identifies a connection by an identifier rather than by the four-tuple, so a session survives a phone moving from Wi-Fi to cellular. Version 2, RFC 9369, exists mainly to keep middleboxes from ossifying around one wire image. HTTP/3, RFC 9114, is the application layer built on top of it.

The 2026 picture needs a dated, method-qualified number rather than a headline. Measured on 13 July 2026, QUIC carried roughly 21 to 35 percent of traffic depending on the window and method used by Cloudflare Radar, while about 39 percent of websites advertised HTTP/3 support according to W3Techs. Two different questions, two different numbers, both worth quoting with their source. MASQUE has also standardised proxying inside the protocol, with CONNECT-UDP in RFC 9298 and CONNECT-IP in RFC 9484 underpinning products such as iCloud Private Relay. Multipath QUIC remains an Internet-Draft.

Resolution is a hierarchy with three roles: the stub resolver in the operating system asks a recursive resolver, and the recursive resolver walks the authoritative servers from the root down until it holds an answer. Caching sits over the whole thing with time-to-live values attached, which is the real reason a DNS change appears to work for some users and not others for hours afterwards. Nothing was rejected; different recursive resolvers simply hold copies with different remaining lifetimes. RFC 9499, published as BCP 219 in March 2024, is the canonical vocabulary for all of it.

Three standards now carry those queries over an encrypted channel, and the difference between them is which existing traffic they resemble. DNS over TLS, RFC 7858, uses a dedicated TCP port 853, so a network can see the category and permit or block it without reading the names. DNS over QUIC, RFC 9250, keeps that dedicated-port honesty on UDP 853 while taking QUIC's faster setup and freedom from head-of-line blocking. DNS over HTTPS, RFC 8484, shares port 443 with the rest of the web and is correspondingly hard to single out. Discovery of Designated Resolvers, RFC 9462, lets a client upgrade automatically without anybody changing a setting.

In practice the firewall picks the transport, not the design document: sites that permit outbound TCP 443 and little else block DoQ and DoT by default, and DoH survives because blocking it means blocking the web. What none of them deliver is anonymity. The resolver now holds an attributable log of every name asked for, the destination IP address of the connection that follows is in the clear, and without Encrypted Client Hello the Server Name Indication field names the site in plain text during the TLS handshake. RFC 9849 closes that gap only where client, DNS records and server deployment all support it, and only down to the fronting deployment rather than the individual tenant.

The two words name two different planes. The control plane runs the routing protocols, exchanges reachability with neighbours, applies policy and produces a forwarding table. The data plane takes each arriving packet and does one thing with it: a longest prefix match against that table, then out of the matching interface. A packet for 10.0.0.5 leaves by the interface for 10.0.0.0/24 rather than 10.0.0.0/16 because the more specific entry wins, and no fresh path calculation happens per packet. Traceroute reads off this machinery, which is why it is evidence about one direction at one moment and not proof of the return path.

BGP-4, RFC 4271, has no way to decide whether an announcement is truthful. A router checks that the message is well formed and that policy permits the neighbour, then believes what the neighbour said. That is the design, not a defect nobody noticed. Route Origin Validation, RFC 6811, adds the missing check: the address holder publishes a Route Origin Authorisation naming the prefix, the maximum length permitted and the autonomous system authorised to originate it, and routers compare announcements against the validated set. The comparison yields Valid, Invalid or NotFound, and RFC 6811 deliberately leaves the action to local policy.

The settled operational norm is to drop Invalid, accept Valid and accept NotFound, because rejecting NotFound would disconnect every network that has not signed its space yet. The numbers turn this into engineering rather than an anecdote about a bad day: reading the NIST RPKI Monitor, ROAs now cover more than half the IPv4 routes in the global table from a published set of roughly 480,000 ROAs, while only about 12 percent of stub autonomous systems are fully protected. The limit is worth stating too. Validation checks the origin of a route, not the AS path attached to it, so a forged path with a correct origin still passes.

A NAT device rewrites addresses, and in the port-translating form almost everyone runs it rewrites ports as well, so many inside hosts share one outside address. The record of each rewrite is the state table, and it is the only reason return traffic can find its way home: an arriving packet is matched against an existing entry or it is dropped for want of one. Entries expire when idle, and the expiry timers are why an SSH session left alone over lunch is dead when you return, while the same session at home survives. Keepalives shorter than the timeout are the fix, not a longer wait.

That drop-unsolicited behaviour is what gets mistaken for security. RFC 4787 is the specification for how NAT must behave, covering mapping, filtering and hairpinning, and it is a behavioural document rather than a protective one; its own text is clear that its mapping choices do not determine the security properties of the device. NAT offers no authentication, no access-control policy you can express or audit, and no view of what a permitted connection carries once it is open. A network that names NAT as its security boundary has a boundary it cannot describe.

The IPv6 comparison settles the argument cleanly. An IPv6 network reaches the same default-deny position with a stateful firewall and no translation at all, on addresses that stay end to end from source to destination. The state that admits return traffic is still there; the address rewriting is gone. That separation is worth holding, because it shows the two functions were never the same thing, and it explains why removing NAT does not remove protection when the firewall is doing the job it was always doing.

Dual-stack was a truce rather than a transition. Running two internets side by side indefinitely doubles the addressing, the firewall rules, the monitoring and the troubleshooting, and gives nobody a reason to stop. An IPv6-mostly segment changes the incentive by putting three kinds of host on one network: IPv6-only hosts that have let go of IPv4, dual-stack hosts that have not, and IPv4-only devices that never will. DHCPv4 option 108, RFC 8925, is the polite question that makes it work: a capable host asks whether it may drop IPv4 on this network, and the network answers. The operational guidance, draft-ietf-v6ops-6mops, is a draft and is cited as one.

Two translation mechanisms cover what the IPv6-only hosts still need. NAT64, RFC 6146, translates between the address families in the network, and DNS64, RFC 6147, synthesises the IPv6 answers that steer traffic into it, so an IPv6-only client reaches an IPv4-only server without knowing anything happened. The predictable break is the IPv4 literal: an application that carries a hard-coded IPv4 address in configuration or in its own protocol payload never asks DNS, so the synthesis never happens and the connection fails in a way that looks like the network.

464XLAT, RFC 6877, is the fix that runs in your pocket. A CLAT on the host presents a local IPv4 interface to applications that insist on one and translates their traffic into IPv6 for the NAT64 in the network, so the literal case works again. Android, macOS and iOS have shipped it for years, Windows has announced expansion beyond cellular, and Fedora with NetworkManager gained an eBPF-based CLAT in July 2026. That transition works at population scale is not a projection: APNIC Labs measures India above 70 percent IPv6 capability.

TLS 1.3 was republished in July 2026 as RFC 9846, obsoleting RFC 8446 while keeping the protocol version at 1.3; the revision forbids KeyShare reuse and bans negotiating TLS 1.0 and 1.1. Where it sits differs by transport. Over TCP it is a second handshake layered on a connection that is already up, which is why a capture shows the connection and the negotiation as separate events. Inside QUIC the transport and cryptographic handshakes are one exchange, which is why the same capture shows far less and why the placement question changes what evidence you can gather at all.

What it promises is narrow and worth saying out loud. The chain of certificates is validated back to a trust store, Certificate Transparency under RFC 9162 makes issuance publicly auditable, and forward secrecy means a later key compromise does not decrypt yesterday's recorded sessions. None of that is a judgement about the site. Proving control of a domain is exactly what a phishing operator can do, so phishing sites hold valid certificates as a matter of routine, and the padlock reports that proof rather than any opinion about honesty. Read the name in the address bar, not the icon beside it.

The economics of certificates changed on a published schedule. The CA/Browser Forum approved ballot SC-081v3 on 11 April 2025: the maximum validity of a publicly trusted TLS certificate is 200 days from 15 March 2026, 100 days from March 2027 and 47 days from March 2029, with the reuse period for domain validation data shrinking on the same curve. A 47-day certificate cannot be a diary entry owned by a named person. ACME automation stops being an efficiency and becomes the baseline, and any manual step left in the renewal path is an outage waiting for a holiday. Private internal CAs sit outside the schedule, which is precisely why an inventory matters.

Most bad diagnoses fail at the first step, because the symptom was never stated precisely enough to be tested. Slow is not a symptom; slow for these users, to this name, since this time, while another location is unaffected, is a symptom with edges. From there the discipline is to isolate by layer and let each layer's tools produce a different class of evidence, then to pick the next test by what it costs against what it would rule out. The loop closes when the remaining hypotheses are narrow enough that one measurement separates them.

Error messages are distinctions, not noise. A connection refused means something answered and declined; a timeout means nothing answered at all; a negotiated h2 where h3 was expected means the connection succeeded over a different transport from the one the client wanted. That last one is the stage's worked example. A site feels slower in the office than on a hotspot, and the only evidence is the browser's protocol column reading h2 in one place and h3 in the other. HTTP/3 runs QUIC over UDP port 443, per RFC 9114, so a rule set written as allow 443 for TCP only drops the QUIC attempt silently and the client falls back. A short capture filtered to udp port 443 settles it in seconds, and an ICMP administratively-prohibited reply names the device doing it.

The downgrade is the finding, not yet the fault. HTTP/2 over a healthy path is not slow, and blocking UDP 443 is sometimes deliberate policy so traffic stays inspectable. What the evidence established is that the two networks were never running the same protocol, so any comparison of their performance was measuring a mixture. Writing that down as a diagnosis note, with the measurement, the hypothesis it supports and the hypothesis it does not, is what makes an escalation useful to the person who receives it.

The capstone runs the method on a case with no obvious culprit. Users in the London office report that a checkout site loads slowly or times out, but only since 09:00 today; the same site is fine from New York; no code was deployed and no server was restarted. The symptom is therefore environment-specific and time-bounded, and that shape alone rules out whole families of cause before a single tool is opened. The first measurement is taken from the affected location and against a control: a lookup through the London resolver returning in 3800 ms against the same lookup elsewhere returning in 45 ms is a finding about the resolver, not about the site.

Two branches then have to be considered rather than assumed away. The first is congestion instead of failure. If DNS is healthy, the connection is clean, and only the first byte arrives late while the office backup window runs, nothing is broken; queues are building on a shared link. Loss or an explicit congestion mark in that capture is the signal a working transport depends on, not proof of a fault, and the test that separates the two is idle latency compared with loaded latency. If idle is fine and loaded is not, more bandwidth will not fix it.

The second branch is that the client never used the resolver you tested. A browser or operating system configured for DNS over HTTPS sends its queries inside an HTTPS session to a resolver of its own choosing, so the corporate resolver logs stay empty and its cache state is irrelevant to what the user experienced. Establish which resolver actually answered before drawing any conclusion from resolver-side evidence. Neither branch changes the method. Both change which measurement counts as evidence, and that is the difference between a diagnosis that holds up under challenge and one that names the last thing anybody touched.