顯式壅塞通知（explicit congestion notification）
傳統 TCP 用一種粗暴的方式得知壅塞：靠一個封包被丟掉。那就像工廠只有在箱子開始從輸送帶末端掉下來時，才知道隊伍太長。顯式壅塞通知（explicit congestion notification，ECN）提供一個更溫和的信號：當路由器的佇列開始塞滿時，路由器不丟掉封包，而是替封包標記一個旗標，意思是「我快壅塞了」，傳送端便放慢——完全沒有封包、也沒有資料遺失。
它以一種跨層的小型協作運作。IP 標頭裡有兩個保留給 ECN 的位元。當傳送端支援 ECN 時，它把自己的封包標記為「具 ECN 能力」。若這樣的封包通過一個佇列正在堆積的路由器，該路由器不丟掉它，而是設定「已遭遇壅塞」的碼點並轉送它。接收端注意到這個標記，並在它回傳的確認裡（使用 TCP 標頭中一個專用旗標），把這個消息回響給傳送端。傳送端接著就像偵測到遺失一樣反應——縮小它的壅塞視窗——但資料完好地通過，從未需要重送。
回報是避免了基於遺失的信號所帶來的代價：沒有浪費的重送、沒有逾時風險，而且壅塞警告可以稍微提早抵達（在佇列堆積時、而尚未溢位時）。ECN 需要傳送端、接收端、以及中間路由器三方的合作，這正是它普及花了很長時間、以及某些中間盒過去會錯誤處理那些位元的原因。它與主動佇列管理（後者決定「何時」標記）自然搭配，並且是資料中心方案如 DCTCP、以及現代低延遲網際網路努力的核心。
一個路由器的佇列開始堆積。它不丟掉下一個具 ECN 能力的封包，而是設定「已遭遇壅塞」的位元並轉送它。接收端看到這個標記，便在它的 ACK 上設定 ECN-Echo 旗標。傳送端讀到那個旗標，把它的壅塞視窗砍半——這正是它對一個被丟封包會做出的回應，但沒有任何資料遺失、也不需要任何重送。
ECN 用標記取代丟棄，於是傳送端放慢，而沒有任何封包遺失或被重送。
ECN 只有在傳送端、接收端、以及路徑上每個路由器都合作時才有效——而且一個被標記的封包仍是壅塞信號，所以傳送端仍必須放慢；ECN 避免的是遺失，而非放慢。過去有些有問題的中間盒會清除或錯誤處理 ECN 位元，使它的部署延宕了好幾年。