The transport frontier, and how to read the numbers

The frontier is not a queue of protocols waiting their turn. It is a board with two independent axes, and almost every confused argument about transport comes from collapsing them into one. The first axis is what the document is: a published RFC, or an Internet-Draft that is still being written. The second axis is what the mechanism is for: ordinary traffic for everybody, or one specific problem for particular hosts and paths. An item can be published and narrow. It can be unpublished and general. The two facts do not move together.

Start with the pair that makes the point. Multipath TCP is RFC 8684. It lets a single connection run across several paths at once, adding and removing them underneath an application that still believes it holds one ordinary socket. A phone with mobile and Wi-Fi interfaces is the obvious case, and so is any device where one of the two links can disappear without warning. It is published, it is implemented, and it is used where multi-homing pays for itself. It never became universal, and that is not a failure. Most connections in the world have exactly one path worth using, so most connections gain nothing from a mechanism for choosing between several.

Multipath QUIC is the same idea written for QUIC instead of for TCP. It is draft-ietf-quic-multipath, and version 21 of that draft dates from March 2026. It is not an RFC, it has never been an RFC, and a sentence that gives it an RFC number is wrong in a way that a reviewer can catch in seconds. Same idea, opposite sides of the line: that is the whole horizontal axis of the board above, and it is why the board is a board rather than a ranked list.

TCP Fast Open is the cautionary tale. RFC 7413 lets a client put application data inside the very first packet of a connection, the SYN, using a cookie the server issued on a previous visit as proof that the client has been seen before, which buys back up to one round trip on repeat visits. The idea is sound and the saving is real. It still did not become the way connections start, because a first packet carrying data looks unusual to the equipment sitting between the two ends. Devices on the path that were built when a SYN carried no data may drop it, strip the option, or hold the connection while they decide. The specification even tells implementations not to switch it on by default.

Read that carefully, because it is the most useful lesson on this page. TCP Fast Open was not beaten by a better idea. It was beaten by the installed base of middleboxes, which is a fact about deployment rather than about design. Every serious transport change since has been shaped by that experience.

Two more items sit on the published side of the board and matter for different reasons. DNS over QUIC, RFC 9250, is encrypted DNS carried on its own QUIC connection over UDP 853, and the case above is the evidence that it has reached production at a resolver anyone can use. L4S, published as RFC 9330, 9331 and 9332, is the modern answer to bufferbloat, the delay you feel when equipment on the path holds a long queue of packets rather than dropping any of them: senders react to frequent congestion marks instead of waiting for a packet to be lost, and the network keeps that traffic in a separate low-latency queue. It ships in the low-latency modes of DOCSIS, the standard behind cable broadband, which is the sort of detail that decides whether a mechanism is real or theoretical.

WebTransport is the odd one out and worth a moment. From one session over HTTP/3 it gives a browser both kinds of delivery at once: streams where everything arrives in the order it was sent, and small standalone messages that may be dropped rather than delayed, which is what a live game or a video call actually wants. Web applications used to reach for WebSockets or a native client to get that. It is general rather than niche: any interactive web application is a candidate. Its documents are a W3C Working Draft for the browser interface and an Internet-Draft for the protocol underneath, so it has no RFC number of its own. It is the clearest case of a mechanism that is general, useful, and still not something you may cite as a standard.

Put the six together and the honest summary of the frontier is unglamorous. One published multipath mechanism used where multi-homing pays. One published round-trip saving that middleboxes kept specialist. One published encrypted DNS transport now switched on at a public resolver. One published low-latency queueing architecture shipping in cable networks. Two general mechanisms, multipath on QUIC and WebTransport, that are genuinely useful and genuinely unpublished.

The board separated two facts that arguments normally blur, and the pair at the bottom did the work: Multipath TCP and Multipath QUIC are the same engineering idea, and the only difference between them is what kind of document describes each one. That difference is carrying a lot of weight in a sentence, so it is worth being precise about what it actually promises.

A citation is not decoration. It is a claim about stability. Writing RFC 8684 after a sentence says: this text is fixed, that number will always resolve to it, and anyone implementing against it is implementing against the same words you read. Writing draft-ietf-quic-multipath-21 says something weaker and more honest: this is the twenty-first revision of a document that is still being argued about, and the twenty-second may say something else.

The pipeline behind those two states is short enough to hold in your head. Anyone may write an Internet-Draft and publish it; there is no gate. A draft that a working group has taken on gets the prefix draft-ietf- and the working group name, which is why that prefix in a citation is meaningful: it tells you the document has an owner and a process, not that it is finished. Each revision is numbered, and each one replaces the last. Drafts have no formal standing, can be changed or withdrawn at any time, and become standards only if they are published as RFCs. Publication is the moment the text stops moving and gets a number that never changes.

Besides WebTransport, which the board above already puts on the unpublished side, this course cites five more things that have no RFC number, and naming them together is the point. BBR version 3 is draft-ietf-ccwg-bbr. Multipath QUIC is draft-ietf-quic-multipath. The third version of Happy Eyeballs, the connection-racing behaviour that hides a broken IPv6 path, is draft-ietf-happy-happyeyeballs-v3, while the published version is RFC 8305. The hybrid post-quantum key agreement X25519MLKEM768 is specified in draft-ietf-tls-ecdhe-mlkem. The operational guidance for IPv6-mostly networks is draft-ietf-v6ops-6mops. Every one of those is in the working vocabulary of a network engineer in 2026, and not one of them may be written down with an RFC number.

That list also kills the obvious objection. If they are all unpublished, why are they in a course at all? Because unpublished does not mean unusable. A draft can be implemented at both ends of a connection and put into production long before the text settles, and the transport protocols of the last decade were deliberately built to make exactly that possible.

The reverse mistake is just as common: treating an RFC number as a badge of approval. It is not one. RFC 7413, the TCP Fast Open document from the previous section, sits in the Experimental category, which is why its own text tells implementations to leave the feature off by default. An RFC number tells you the text is fixed. It does not tell you the mechanism is recommended, widely implemented, or a good idea for your network.

Nor is a number permanent in the way people assume. TLS 1.3 was republished in July 2026 as RFC 9846, which obsoletes RFC 8446 while keeping the protocol version at 1.3, forbidding reuse of a key share and banning the negotiation of TLS 1.0 and 1.1. DNS terminology moved the same way: RFC 9499, published as BCP 219 in March 2024, obsoletes RFC 8499. In both cases the older number still resolves and still returns a document, which is exactly why a citation without a date can be stale and look perfectly healthy.

So the working rule is two lines long. Cite an RFC by its number, and say when you last checked whether it had been obsoleted. Cite a draft by its full name and revision, describe it as a draft in the sentence itself, and never let the two forms blur, because the whole value of the distinction is that a reader can tell from your sentence how much weight to put on it.

Standards status settles what you may claim about a mechanism. It says nothing at all about how much of the internet is using it, and that second question goes wrong in its own particular way: not a citation pointing at the wrong kind of document, but a number quoted with no idea who was counted.

Four public observatories supply almost every adoption figure in this course, and they answer four different questions. None of them measures the internet. Each one measures the part of it that passes in front of a particular window, which is why two credible sources can publish different numbers for what sounds like the same thing and both be right.

Cloudflare Radar reports the traffic arriving at one very large edge network. Its answer to any adoption question is a share of the requests and connections that network actually carried, over a window you choose. That makes it the best available source for traffic share and for sudden shifts, and it carries the bias you would expect: the customers of that network, and the mix of what those customers publish.

APNIC Labs samples end users and tests them directly, then weights the results by how many users each economy has, because the raw sample is not spread evenly across the world. Its answer is about capability: can this user reach a service over IPv6 at all. That is a different question from how much traffic went that way, and it is the right question when you are deciding whether a market can reach you.

W3Techs surveys websites, counting each site once and recording what it advertises. A site with a hundred visitors a month counts exactly as much as one with a hundred million. That sounds like a defect and is not: it is the right instrument for a question about server-side support, and the wrong one for any question about traffic or about people.

The NIST RPKI Monitor looks at the global routing table itself and reports how much of it carries signed Route Origin Authorization records. Its population is routes, not users, not sites and not traffic, which makes it the only one of the four that can answer a question about routing security with a number rather than an anecdote.

Now put one question to two of those windows and watch the answers separate. How much of the internet is QUIC? Cloudflare Radar puts QUIC and HTTP/3 at roughly 21 to 35 percent of the traffic it carries, depending on the window and the method. W3Techs puts about 39 percent of websites as advertising HTTP/3 support. Both figures were read on 13 July 2026. They are not in conflict, because one counts traffic arriving at one network and the other counts websites one at a time. A service can advertise HTTP/3 and receive almost no traffic, and a handful of very large services can move a traffic share on their own.

The same exercise on IPv6 produces the same shape. Google published 50.10 percent of its worldwide users arriving over IPv6 on 28 March 2026: users, seen from Google properties, on one named date. APNIC Labs measures whether sampled end users are capable of IPv6 at all, and puts India and France above 70 percent. If your question is what share of one company's users already arrive over IPv6, the first figure is the relevant one. If your question is whether the customers you are about to launch to can reach an IPv6-only service, the second is, and the worldwide average is nearly useless to you either way.

This is the habit the course has been quietly practising all along, and it has a name: measurement literacy. Read a statistic together with its method. Ask who was sampled, from what vantage point, over what window, and how the counts were weighted. Every adoption figure in these thirty-four modules was chosen with that lens, which means you are now equipped to audit them rather than trust them, and auditing them is the better relationship to have with a number.

Four windows, four populations, and no contradiction between them once the population is named. That is the diagnosis. What it needs next is a procedure short enough to run in the middle of a meeting, on a claim you did not write and have not seen before.

The checklist has four entries and takes about ten seconds. What is the source, and is it the body that produced the measurement or somebody quoting it? What is the method, meaning what was counted and how? What is the date, both of the measurement and of your reading of it? What is the population, meaning who or what the percentage is a percentage of? Three of the four are usually present in some form. The date is the one that goes missing, and it is the one that turns a good number into a wrong one over time without anybody noticing the moment it happened.

Take the three claims this course had to repair, each in the loose form it usually circulates in, and run the checklist on all three. The first is not a hypothetical example. An earlier version of this course carried it.

Claim one: Google reports that QUIC carries over 25 percent of internet traffic. Source: a company name with no document behind it, so there is nothing to open. Method: unstated, so there is no way to know whether the count was requests, bytes, connections or something else. Date: absent, which is fatal for a figure that moves. Population: the internet, which no measurement anywhere covers. The repaired version runs longer and holds: Cloudflare Radar put QUIC and HTTP/3 at roughly 21 to 35 percent of the traffic it carries, depending on the window and the method, while W3Techs put about 39 percent of websites as advertising HTTP/3 support, both read on 13 July 2026. Two sources, two named populations, one date, and a range rather than a point because the honest measurement is a range.

Claim two: IPv6 adoption has passed 50 percent.Source: usually nobody, though the figure is real. Method: unstated. Date: absent. Population: undefined, and this is where the sentence quietly breaks, because there are at least two defensible populations and they do not agree. Repaired: Google measured 50.10 percent of its worldwide users arriving over IPv6 on 28 March 2026, and APNIC Labs, which tests sampled end users for capability rather than counting arrivals, puts India and France above 70 percent. Notice what the repair buys you in a meeting. The original sentence invites the reply that it cannot be right because the speaker's own network is IPv4-only. The repaired one cannot be answered that way, because it already says whose users were counted.

Claim three: RPKI has fixed BGP. Source: normally a conference talk. Method: unstated. Date: absent. Population: undefined, and here the population matters more than usual, because two different things can be counted and they give very different impressions. The NIST RPKI Monitor reports that more than 50 percent of IPv4 routes now have ROAs, roughly 480,000 of them, while only about 12 percent of stub autonomous systems, meaning the networks at the edge that carry no traffic on anyone else's behalf, are fully protected. Both numbers describe the same system. Route Origin Validation, specified in RFC 6811, checks that the network announcing a prefix is authorised to announce it, which is real progress and is not the same as verifying the whole path an announcement travelled. The honest sentence is that coverage has passed half and enforcement has not caught up, which is a more useful thing to tell a board than either half on its own.

Three repairs, one pattern. Each fixed sentence is longer, names a population, carries a date, and gives a range where a range is what the measurement supports. That length is the price of a claim that survives a challenge, and it is a low price given the alternative is being corrected in public by somebody who opened the source.

The habit is cheap for one reason worth stating plainly: you apply it to your own sentences first. Running the checklist on other people's claims makes you tiresome. Running it on your own before the slide leaves your laptop makes you the person in the room whose numbers nobody bothers to check, which is a considerably better position to occupy.

The three repairs all worked the same way: name the population, attach the date, and accept a longer sentence. The check below runs that discipline against claims of the kind that turn up in a design paper, where the citation and the number sit next to each other and both need reading.