DCTCP（資料中心 TCP）
/ DEE-see-TEE-see-PEE /
傳統 TCP 只有靠「撞車」才學到路上塞了——它一路加速直到一個封包遺失（溢出的緩衝區把它丟了），然後猛然退讓。這在廣域網際網路上行得通，但在你想要微秒級延遲的資料中心裡，等到緩衝區真的溢出才反應，會填滿佇列、增加延遲，並造成別處所述的 incast 崩潰。DCTCP 是一種壅塞控制，它改成讀取早期警訊、在緩衝區溢出之前就溫和而成比例地減速——像是車流開始變濃時就鬆開油門，而不是等到追撞前車。
具體來說，DCTCP（資料中心 TCP）依賴顯式壅塞通知（ECN）。交換器被設定成：一旦佇列長度越過一個低門檻——不是緩衝區滿了，而是它才剛開始堆積時——就給經過的封包標上 ECN 旗標。接收端把這些標記回傳。這就是與傳統 TCP 的關鍵差異：一般 TCP 把單一壅塞訊號當成「把我的視窗砍半」，而 DCTCP 估計在一個視窗裡「被標記的封包所佔的比例」，並依該比例成比例地降低送出速率。一點點壅塞就小幅降低；嚴重壅塞就大幅降低。結果是各傳送者落在一個讓交換器佇列保持短而穩定的速率上，於是延遲維持低、緩衝區也留有餘裕來吸收突發。
為什麼重要：DCTCP（出自一篇 2010 年論文）成了現代資料中心傳輸的範本，因為它直接瞄準建築內真正重要的指標——低而可預測的延遲、短佇列、抵抗 incast——而不只是把大宗傳輸量最大化。誠實的提醒：DCTCP 需要支援 ECN 的交換器、以及整個結構一致的低標記門檻，所以它是資料中心「內」的協定，不是拿到公開網際網路上跑的東西；而且因為它對壅塞的反應如此不同，DCTCP 在一個瓶頸上不會與傳統基於遺失的 TCP 公平分享頻寬，所以兩者不該混在同一路徑上。它是一整個以延遲為重的資料中心壅塞控制家族的一員，後來的方案（例如用精準逐封包延遲或網路內訊號的）把這個點子推得更遠。
一台交換器被設定成：佇列一旦超過 60 個封包就標 ECN。在輕負載下被標記的封包很少，所以 DCTCP 傳送者幾乎不減速。當數條資料流加速、佇列變長時，被標記封包的比例上升，每個傳送者就成比例地修剪自己的速率——於是佇列穩定在一個很短的長度，而非溢出，讓延遲維持低。
對 ECN 標記的比例反應，而不是對單一次遺失反應。
DCTCP 是僅限資料中心的協定：它假設交換器會做 ECN 標記、且門檻低而一致，並且在共用瓶頸上與傳統基於遺失的 TCP 無法公平共存。別把它拿到公開網際網路上跑。