Skip to content

CONCEPT Cited by 1 source

Additive Increase Multiplicative Decrease (AIMD)

Definition

Additive Increase Multiplicative Decrease (AIMD) is a feedback-control rule for adjusting a transmission-rate variable in response to binary congestion signals. It pairs two asymmetric update steps:

  • On "no congestion" — add a constant to the rate variable (additive increase): rate += a.
  • On "congested" — multiply the rate by a constant < 1 (multiplicative decrease): rate *= b, where 0 < b < 1.

AIMD is the congestion-control primitive in TCP's congestion window (along with slow start and timeout handling), and the sawtooth trajectory of cwnd over time — linear climb followed by sudden halving on packet loss — is its visual signature.

Why asymmetric

The additive/multiplicative asymmetry is load-bearing. It's provable that AIMD is the simplest rate-control rule that converges to fairness and efficiency across competing flows sharing a resource, without central coordination:

  • Additive increase probes gently for spare capacity so flows don't over-claim after a change.
  • Multiplicative decrease responds sharply to saturation so flows relinquish bandwidth fast enough to let the system recover.
  • Fairness — two flows with identical coefficients converge to equal shares regardless of starting point, because the same multiplicative cut reduces a larger rate by more absolute units than a smaller rate.

A rule where both phases are additive (AIAD), or where both are multiplicative (MIMD), does not converge to fair shares — the ratio between flows' rates is preserved, so the initial condition persists.

Why it's a distributed-systems primitive, not just a TCP trick

The properties of AIMD that make it compelling extend beyond packet networks:

  1. No measured capacity required. The throttled party doesn't need to know the downstream's actual rate limit; the signal "congested / not congested" is sufficient.
  2. No central coordinator. Every participant adapts using local state only. This is what lets TCP scale to billions of flows without any router knowing the global topology.
  3. Automatic capacity-growth adaptation. When downstream capacity increases (e.g. a fleet scales out), the additive-increase phase keeps probing, so the rate eventually rises to match. No re-configuration needed.
  4. Graceful degradation. When capacity decreases (e.g. a fleet is partially down), multiplicative decrease contracts quickly so the system recovers rather than drowning.

Using AIMD outside TCP

Because the algorithm needs only a rate variable and a binary congestion signal, it transfers cleanly to any rate- adaptation problem where:

  • The throttled party emits load toward a downstream with bounded capacity.
  • There's an observable signal that correlates with downstream saturation — e.g. request latency, queue depth, error rate, response code 429, dropped packets.
  • The signal has enough time-resolution to update faster than the downstream's saturation damage accumulates — otherwise the controller oscillates or overshoots.

Zalando's 2024 communications-platform post is a direct application: the rate variable is the event-type consumption batch size from Nakadi, the congestion signal is RabbitMQ publish latency or exception count, and each event type's Stream Consumer throttle runs an independent local AIMD loop (Source: sources/2024-04-22-zalando-enhancing-distributed-system-load-shedding-with-tcp-congestion-control-algorithm).

Seen in

Last updated · 501 distilled / 1,218 read