Monthly floods make SYN cookies engage and silently cap distant customers' throughput. How do you decide, and who owns it?

## Why this is not an engineering decision Both options are defensible and both hurt someone. Leaving stateless admission armed means that whenever the queue of half-completed handshakes overflows, connections are admitted with degraded parameters — no window scaling, so a hard ceiling of 65,535 bytes in flight, which on a long path is a throughput cap the customer feels and nobody logs. Disabling it means that during the same minutes the queue simply fills and new connections are refused, for every customer, near and far, until the flood stops. One of those costs is loud, symmetrical and short. The other is quiet, concentrated on a minority, and long — it lasts as long as the affected connections do, which for pooled API clients can be weeks. Engineering can describe both. It cannot decide which one the business would rather pay, because that depends on who the distant customers are, what was promised to them, and what an outage costs. ## Make the invisible half measurable first An argument about an unmeasured harm is an argument about temperament, and the person with the strongest opinion wins. So the first move is instrumentation, and it is cheap: - A signal for when the degraded path engaged, and for how long. Without it you cannot even say how many hours a month this happens. - A tag on connections admitted during those windows, so you can count them and see how long they persist. - Throughput reported by client round-trip time band rather than in aggregate. The harm is invisible in an average and obvious once you split by distance, because the ceiling is arithmetic: about 1.7 Mbps at 300 ms, about 3.5 Mbps at 150 ms, unnoticeable under 20 ms. Note what is deliberately absent from that list: error rates. This failure produces no errors, so every alert you already own is blind to it. That fact is itself worth putting in front of an owner, because it explains why nobody reported the problem for a month. ## The number you take to the owner Multiply affected customers by the hours their connections stayed capped by the gap between their measured throughput and their normal throughput. It is an estimate, and you say so, but a bounded estimate ends the argument about whether the problem is real and starts the argument that actually matters. Put the alternative in the same units: floods of the size we actually see, times the minutes of refused connections, times all customers rather than the distant ones. Then hand the decision over, with the constraints named: - **Contracts.** If any agreement commits to throughput or to a performance level rather than to availability, that clause decides the question and the decision is not yours. - **Segment value.** Distant customers are frequently the ones who bought reach specifically. Losing throughput for the segment that pays for distance is not a rounding error. - **Measured flood sizes, not feared ones.** The case for disabling the mechanism only exists if there is enough headroom that realistic floods never overflow the queue. That is a measurement, and it changes over time, so it is a commitment to keep measuring rather than a one-off finding. ## What you do not do Do not present this as protection with no downside — the moment a defence is recorded as free, the residual loses its owner. Do not argue that the degradation does not count because nothing failed; that reasoning is exactly why it went unreported. And do not let the decision be made by default. The default in every estate is that the degraded path is armed, which is probably right, but a default that nobody chose is a risk nobody accepted. The outcome you are aiming for is unglamorous: the trade is written down, one named person accepts the residual, the invisible cost now has a graph, and if the owner will not accept it, that refusal becomes the business case for capacity or for absorbing the flood before it reaches your racks — which somebody then has to fund.