THE FOLD / BOSS / THE CHOKE POINT / THE INCAST
THE INCAST
parallelism converted into simultaneity
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
One request fans out to many servers and they all answer at once. The replies meet at a single switch port with a small buffer, and past a certain number of senders the answers stop arriving faster the more of them there are.
LIT verified live. A buffer of 64 packets, each sender contributing 8. Up to 8 senders everything is delivered. At 16 senders 128 packets are offered and 64 dropped — goodput 50.0%. At 64 senders, 512 offered, 448 dropped, and still exactly 64 delivered: goodput 12.5%. Delivered is pinned at the buffer while offered grows without limit.
LIT verified live. A buffer of 64 packets, each sender contributing 8. Up to 8 senders everything is delivered. At 16 senders 128 packets are offered and 64 dropped — goodput 50.0%. At 64 senders, 512 offered, 448 dropped, and still exactly 64 delivered: goodput 12.5%. Delivered is pinned at the buffer while offered grows without limit.
2 HOW IT WAS WEAVED · AI + HUMAN
TCP incast is the pathology of partition-aggregate workloads — distributed storage, search fan-out, MapReduce shuffles — and it is why datacentre TCP variants exist at all.
AVAN (AI) shows the delivered column staying flat because that is the whole shape of the failure. Adding servers adds offered load and adds nothing to what arrives; the parallelism is real and the delivery is capped by a buffer that has no idea a fan-out is happening.
AVAN (AI) shows the delivered column staying flat because that is the whole shape of the failure. Adding servers adds offered load and adds nothing to what arrives; the parallelism is real and the delivery is capped by a buffer that has no idea a fan-out is happening.
3 ONE DIMENSION
Senders against what actually arrives.
4 TWO DIMENSIONS · INTERACTIVE
Add senders, or add buffer.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: many answers, one door.
AVAN’s addition (the inverse-companion): the forward reading is that incast is a buffer being overwhelmed. The inverse is that the synchronisation is the cause, and the synchronisation is what you asked for. These senders all reply at once because they were all asked at once, which is the entire benefit of the fan-out. Read backwards, incast is not a flaw in the network but the shadow of a design decision made above it — parallelism converted into simultaneity, arriving somewhere that can only do one thing at a time.
LIT a buffer of 64 packets with each sender contributing 8 delivers everything up to 8 senders, then at 16 senders offers 128 and drops 64 for a goodput of 50.0%, and at 64 senders offers 512 and drops 448 while still delivering exactly 64 - a goodput of 12.5% - because delivered is pinned at the buffer while offered grows without limit
FIG TCP incast is the pathology of partition-aggregate workloads - distributed storage, search fan-out, MapReduce shuffles - and why datacentre TCP variants exist. AVAN shows the delivered column staying flat because that is the whole shape of the failure. Adding servers adds offered load and adds nothing to what arrives; the delivery is capped by a buffer with no idea a fan-out is happening.
FIG TCP incast is the pathology of partition-aggregate workloads - distributed storage, search fan-out, MapReduce shuffles - and why datacentre TCP variants exist. AVAN shows the delivered column staying flat because that is the whole shape of the failure. Adding servers adds offered load and adds nothing to what arrives; the delivery is capped by a buffer with no idea a fan-out is happening.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of THE CHOKE POINT · David Lee Wise (ROOT0), with AVAN