II · The Box You Don't Control · Chapter 1

The Contract of the Box

Between your wall socket and Mira’s there is a box. You cannot open it and you cannot see inside it. You do not know how many machines it contains, or who runs them, or how they are connected to one another. When you hand a frame to your building’s router, the frame goes into the box, and some time later, usually, something comes out of the other side at Mira’s.

You could try to understand the box. People do, and whole careers are spent on it. But there is something more useful to do first, which is to refuse to understand the box and instead ask the question a lawyer would ask: what, precisely, does this thing owe you?

That is the better question for a practical reason. You are going to build things that run across this box, Courtyard first and a hundred other things after it, and those things will be correct or incorrect, fast or slow, robust or fragile, according to what you assume about the box. If you assume more than it delivers, your things will break in ways that look random. If you assume less, you will build machinery you did not need. The set of promises the box makes is the set of things you may rely on, and everything outside that set you must handle yourself.

You already know most of the answer, because you spent Part I finding it out. Every time something went wrong between your machine and Mira’s, every reordered piece, every lost acknowledgement, every laptop that fell silent, a clause of this contract was being enforced against you before you had read it. So the way to read it now is to go back through your scars.

Start with what the box will do, because there are only two affirmative promises. The first is that it will forward a piece toward a hierarchical location. You give it a piece carrying a destination address of the kind Chapter 5 built, a number with a network part that can be summarised, and it looks at the network part and moves the piece in the direction of that network. That is the entire affirmative content. It forwards by prefix. It knows nothing of your ports, your sequence numbers, your messages or your conversations; it reads the location header and moves the piece one step closer. Chapter 5’s router, which read one header and consulted one table, is a fair picture of the whole box. The box is bigger, and it does nothing more.

The second promise is that it will keep an address meaning roughly the same place for a while. If you send to Mira’s address today and again tomorrow, both pieces go toward Mira. Addresses are stable enough to be useful. They are not stable forever, since Chapter 6 showed you that they are assigned rather than owned, and this part will show you that they change more often than you would like, but they are stable enough that a table from names to addresses need not be rewritten every hour. Those are the two promises, and the second of them is soft.

Now the refusals, and for each one you should be able to name the chapter where you were burned. The box will not promise delivery. Pieces are dropped, by a full queue, by a damaged frame discarded along the way, by a box that for a moment has no route. That was Chapter 10’s missing piece and Chapter 3’s discard. Nothing tells the sender. The box owes you no notification, no error and no apology, only silence.

It will not promise order. Two pieces sent one after the other may take different paths through the box and arrive in either order, which was Chapter 10’s swapped band. The single wire of Part I preserved order because it was a single wire. The box is many wires, and it makes no such promise.

It will not promise that a piece arrives once. Occasionally a piece arrives twice, from a loop inside the box or from your own retransmission crossing a late acknowledgement. Chapter 10 warned of this and Chapter 11 delivered it.

It will not promise timing. How long a piece takes to cross is not fixed, not stated, and not the same from one piece to the next. Chapter 11 made you measure the round trip because there was no other way to know it. You will find out how variable the timing is in Chapter 5 of this part, and how large it can be in Chapter 6.

It will not tell you its capacity. No message ever comes from the box saying how much it can carry for you right now. Chapter 16 made you probe, sending more until pieces vanished and then backing off, because the only signal the box gives about being full is that it drops things.

It will not tell you whether the other end is alive. Through the box, a silent peer and a dead peer look the same. Chapter 13’s heartbeat exists because nothing below it will ever say that Mira’s machine is off.

It will not keep your secrets. Every piece crosses machines you do not control, and any of them can read it. This is Chapter 21’s tap, generalised to a city.

And it will not tell you why. When a piece is dropped, or delayed, or arrives twice, you learn that it happened, if you are lucky and have built the machinery to notice, but you never learn the reason. Loss is a signal and not an explanation. A good deal of Part III will be spent inferring causes from symptoms, because the box never volunteers a cause.

There is one further refusal, and you have not been burned by it yet, because you have never tried the thing it forbids. You will meet it in Chapter 3 of this part, and it will explain why Courtyard has a server at all.

With the list in hand, go back to the tower of Chapter 22 and ask, for each rung, which clause of the contract it answers.

loading…

The contract, clause by clause, beside the Tower. Hovering over a clause lights up the rungs that answer it. Switching a clause off, so that the box did promise order, say, greys out the rungs that existed only because it did not. What is left standing is what you would have needed regardless.

Numbering the pieces answers the refusal of order. Acknowledgements and retransmission answer the refusal of delivery. Discarding repeats answers the refusal to deliver once, the measured timer answers the refusal of timing, probing answers the refusal to state capacity, the heartbeat answers the refusal to report liveness, and the secure channel answers the refusal to keep secrets. Hierarchical addresses are the odd one out. They are not a response to a refusal at all; they are the form the one affirmative promise takes. The box forwards by prefix, and so addresses must have prefixes.

Chapters 10 through 17, and Chapter 21, which is to say the whole middle of Part I, turn out to be the contract written from the other side. You built each of those rungs because something broke, and in every case the something was a clause. You did not know it was a contract. You thought you were fixing a wire, and you were in fact negotiating with a box.

What is not on the list is as telling as what is. Framing and the check, Chapters 2 and 3, are not responses to the box. They answer the wire’s two defects from Chapter 1, that it does not know where anything starts and that it flips bits. Ports, sockets and the loop, Chapters 7, 8, 9 and 15, are not responses to the box either. They answer ambiguity at the ends: which program, which conversation, what to do while waiting. Those rungs would exist if the box were perfect.

loading…

The Tower with each rung coloured by what it answers to. The bottom rungs answer the wire’s defects, the middle rungs answer the box’s refusals, and the top rungs answer the program’s own ambiguities. Three sources and one tower.

So Part I’s tower has three origins, and you can now see the seams between them. The bottom third exists because of physics. The middle third exists because of this contract. The top third exists because a machine is not a program. When you come to design something new and find yourself asking whether some mechanism is really necessary, this is the test to apply. Ask which of the three it is answering.

You might reasonably feel short-changed. You pay for this box every month and it promises almost nothing. It is fair to ask why it does not promise more, why it does not deliver in order, reliably, once, with a known delay, the way a telephone call for most of a century promised a fixed circuit from one end to the other for as long as the call lasted. The answer is that promising more would make the box complicated, and a complicated middle does not scale.

Consider what promising order would require. Every box on the path would have to know about your conversation, that these pieces belong together, what order they go in, that piece 1043 must wait for 1042. Every box would hold state for every conversation crossing it, at once, for every pair of machines in the world. It would have to be told when conversations start and when they end. It would have to coordinate with the next box. And it would break differently for every kind of traffic, since order matters for a file and is poison for a video call, as Chapter 17 showed, so it would need to know which kind you were sending.

Now do the same for delivery, and timing, and capacity. The box becomes a thing that understands conversations, and understands them in a way that suits some conversations and not others, and holds an enormous amount of state, and has to agree with the next box about all of it.

The alternative is what you have, a box that promises nothing except to forward by prefix and pushes everything else out to the ends. Then the middle is simple. Any machine with two cards and a table can be a box. Boxes need agree on nothing except addresses. They need not know what a conversation is, so they work identically for chat and for video and for things nobody has invented yet. And the ends, your machine and Mira’s, build the guarantees they need, on top, without asking anyone’s permission.

The price is that the ends do more work. Every machine runs the middle third of Part I. That turns out to be a price worth paying many times over, because the ends are where new things get built, and a middle that does not have to understand them is a middle that never has to change.

The principle has a name. It is the end-to-end argument, and it is arguably the single design decision responsible for the internet existing. Put the intelligence at the edges, and keep the middle as dumb as it can possibly be. The dumb middle is why anything can attach to it, and why it has grown by a factor of a billion without being redesigned.

Two details of the fine print will matter later. The first is that the contract is statistical. “Usually, eventually” is neither “always” nor “never”. A healthy path drops a small fraction of a percent of pieces; a congested one drops several percent; a broken one drops everything for a while. Reordering happens on some paths and not on others. Duplicates are rare. You do not design for whether these things happen, because they do, but for the rates at which they happen, and the rates are not written down anywhere. You measure them, as you measured the round trip.

The second is that the contract is per piece. Every clause is about a single piece. The box has no notion of your connection, your message or your photo. When you wonder what the box will do to your video, the thing to imagine is what it will do to each of two thousand independent pieces, because that is the only unit the box can see.

You have not opened the box. You have done something better, which is to learn what it owes you: two promises, eight refusals, and one refusal still hidden. You can see the whole middle of Part I as the tower’s answer to it. When something across the city behaves strangely, this list is the first thing to reach for. If the strange behaviour is a clause, it is expected, and the tower already handles it. If it is not, something is actually wrong.

In the next chapter you open the box by one inch, not to learn how it is built, but to see why the contract has the shape it has.

Coming up · II·2 — A Network of Networks

Who inside the box holds the map? Nobody does, and that one fact turns out to explain every refusal on the list.

→
Coming up · II·3 — You Can Reach Out but Not Be Reached

There is a clause you have not hit. It is the one that decides where Courtyard’s server lives.

→