Congestion Control Engine
Congestion Control Engine
Every Queue Pair that sends traffic carries live congestion-control state alongside it: a current injection rate, and the ECN-marked feedback that rate reacts to. This part opens that state up field by field, the standard-defined Congestion Notification Packet that triggers a rate cut, and the three-phase recovery mechanism that runs in its absence – plus a real surprise this book didn’t expect going in: the interesting multi-instance question here isn’t on the send side, the way it is everywhere else in this book, but on the receive side, where generating that same notification packet turns out to be a real, bounded, measured hardware resource.
Chapters
A Queue Pair’s rate limiter doesn’t track a rate. It tracks two – a current one and a target one – plus the one factor that decides how hard the current rate gets cut the next time congestion is reported, and the timer-and-counter pair that claws the current rate back toward the target when it isn’t. Five fields, one algorithm, and a standard that specifies none of them.
QP Capacity and Timing left this question open before this Part even existed: does a Rate Limiter entry behave like the QP Table’s hard-allocated row, or like the Replay Buffer’s dual-natured mix of hard quota and soft cache? The answer turns out to be the simpler of the two – and the more interesting question is whether this table is even a separate structure at all.
Every other table this book has covered gets a caching chapter with a citable finding behind it. This one doesn’t – and the honest reason why turns out to be more interesting than a missing source: this resource might be small enough that the question doesn’t even apply the way it does to its three siblings.
There’s no congestion-control switch on a Queue Pair. There’s a Traffic Class attribute – the same QoS mechanism InfiniBand has always had – and RoCEv2’s own annex is what turns setting it correctly into the one act that actually makes a QP’s packets eligible for the whole mechanism this Part describes.
Every other chapter in this Part is about the sender’s own state. This one is the exception – the receive-side mechanism that has to exist for any of that state to ever change at all, built around a real, standard-defined packet the sender never builds and the receiver never asked to send.
A CNP cuts the current rate once, immediately. Getting it back is not one action but three – a fast phase, a steady phase, and an aggressive phase, picked automatically by two counters this book already named, not chosen by whichever chapter happens to be reading them.
A malformed Congestion Notification Packet isn’t a new failure mode this Part has to invent a story for – it’s an ordinary malformed packet, caught the same way any other one is. What’s genuinely open is quieter: what a rate limiter’s own gate is actually for, once the QP behind it can no longer send anything at all.
Every other multi-instance chapter in this book is about many QPs contending for one shared, serialized gate on the send side. This Part doesn’t have one of those – each QP’s rate limiter runs entirely independent state. The real contention here is on the other side of the connection entirely, and it’s a bounded, measured, real hardware number, not a hypothetical.
Every other eviction chapter in this book starts from a confirmed working set with confirmed pressure. This one starts from Caching’s own open question – and finds that if a working-set cache does exist here, the same three familiar candidates apply, fixed or programmable, exactly the way they already have three times before.
Mid-Transaction QP Reset named this resource directly, before this Part had a title: congestion/rate-limiter state, built the same table-plus-working-set-plus-eviction way the Replay Buffer is, and left for whenever Congestion Control Engine got written. It’s written now, and the honest answer is the same one that chapter already gave – this book still doesn’t know.
Last updated on