主動佇列管理（active queue management）
一個天真的路由器只是讓緩衝區的佇列一直長到完全塞滿，然後把接下來抵達的任何東西丟掉——這種策略叫尾端丟棄（tail drop）。問題在於，長期塞滿的緩衝區會替每個封包加上穩定的延遲（緩衝膨脹問題），而且傾向把眾多流的一整陣封包一次全部丟掉，使它們陷入同步的退讓。主動佇列管理（active queue management，AQM）就是路由器變聰明：它監看自己的佇列並及早行動——在緩衝區塞滿之前就丟掉或標記少數封包——以保持佇列短，並溫和而及時地發出壅塞信號。
兩個著名的 AQM 方案展示了這個概念。RED（隨機早期偵測，Random Early Detection）監看平均佇列長度，當它增長超過一個門檻時，隨機丟掉（或 ECN 標記）越來越大比例的抵達封包。因為這些丟棄是分散且隨機的，它們會在佇列溢位之前推著少數流放慢，並避免尾端丟棄所造成的同步崩潰。CoDel（受控延遲，Controlled Delay）採取較現代的角度：它監看的不是佇列長度，而是封包實際在佇列裡停留多久，若那個停留時間維持過高太久就開始丟棄。CoDel 幾乎不需要調參，而那正是 RED 惡名昭彰的弱點。
AQM 重要，是因為替代方案——配上尾端丟棄的大緩衝區——正是緩衝膨脹的配方：高而多變的延遲，即使頻寬充裕也會毀掉視訊通話與遊戲。藉由保持佇列短，AQM 讓延遲維持低，同時仍讓連結滿載運轉。它與 ECN（用標記取代丟棄）搭配得很漂亮，也是壅塞控制這場合作中路由器這一半：端點做 AIMD，而路由器以 AQM 給它們乾淨、及時的信號去回應。
一台採用尾端丟棄的家用路由器有 256 個封包的緩衝區；在負載下它一直保持滿載，替每個封包加上數百毫秒的延遲——即使下載依然跑得快，你的視訊通話卻會卡頓。換上 CoDel：它注意到封包停留得比它的目標（幾毫秒）還久，便恰好丟掉足夠的封包讓傳送端緩下來，於是佇列——以及延遲——保持短，而吞吐量幾乎不變。
AQM（RED、CoDel）及早丟棄或標記以保持佇列短，用一點點吞吐量損失換取大幅降低的延遲。
AQM 並不會增加連結的容量——它無法把慢連結變快。它做的是保持佇列短，使延遲維持低、傳送端得到及時的壅塞信號，這正是緩衝膨脹的解藥。把「更多緩衝」誤當成「更好」，正是 AQM 之所以存在要去糾正的錯誤。