一、 現有TCP流量在擁塞的情況下出現的問題
根據RFC793的描述，TCP協議是按照端到端設計的可靠的流傳送協議。其特點是：
1、 在三次握手建立連接時，協商發送端和接收端的發送和接收能力，滑窗。
2、 在完成連接建立之後，TCP按照當初協商的窗口大小進行報文的發送。
3、 提供可靠地連接，TCP的接收端將使用ACK機制通知發送端數據是否成功接收。
4、 TCP發送端按照接收端的ACK來判斷數據是否正確接收，並且對沒有ACK的報文進行重發。
從上面的TCP協議的特點可以看出，TCP是端到端的協議，並不直接感知報文在中間路徑上傳送的狀態。即，在網絡中間路由器丟包時，TCP協議是通過感知是否有ACK或者是否有重複的ACK來重傳報文。TCP將網絡路徑中的所有轉發設備看做是黑盒，只要感知ACK沒有在規定的時間收到，則認爲報文被中間鏈路丟棄，並進行報文重傳，保證數據可靠性。
對於網絡鏈路中的路由器來說，需要轉發的TCP報文並不一定來自同一臺主機，各主機之間的TCP連接並不感知中間路由器的轉發隊列的忙閒狀態。當中間路由器隊列過載導致丟包後，
所有主機的TCP連接並不立即感知到，而是在定時器超時之後，由於沒有收到ACK，開始重傳報文。而這個定時器的時間相對較長，通常從幾秒到幾十秒不等。報文丟棄導致多路TCP開始降低發送速率，甚至在一個窗口發送完畢之後，TCP的重傳定時器沒有超時之前，整個發送過程會偶爾停滯。在所有TCP降低性能之後，路由器的轉發隊列擁塞得到緩解，不再丟棄報文，所有TCP又會同時提高發送速率，到達一定程度之後，路由器又開始丟棄報文，並重復剛纔TCP的重傳過程。該現象的問題有：
1、 丟包導致TCP重傳，該重傳定時器的時間較長，對時延敏感的應用來說，影響用戶感受。
2、 丟包之後，TCP根據RFC793規定的要求，所有TCP開始進行退避，下調發送性能，擁塞得到緩解，但此時的網絡利用率無法達到最優。
3、 在擁塞緩解之後，TCP爲了獲得發送的最優性能，又繼續擴大發送窗口，直到發現丟包，重複上述問題過程。
二、 現有TCP的擁塞控制
1、 慢啓動，TCP爲了探測網絡實際性能，也爲了避免一開始就發送過多數據，使用的一種發送算法。即一開始盡發送一個MSS報文段，隨着ACK的不停回覆，TCP發送端開始放大發送能力，該算法的放大時按照指數方式，當達到一定的速率時切換成線性增長方式。
2、 快速重傳，TCP在收到重複的3次ACK時，會認爲重傳隊列中的第一個報文段被網絡丟棄，但由於收到的重複的3次ACK，則認爲該報文段之後的三個報文已經被接收端收到，則不等待重傳定時器超時，直接重發重傳隊列中的第一個報文段。
3、 快速恢復，當TCP收到3次重複的ACK時，將擁塞窗口減半，並在後續再收到重複的ACK時線性增加窗口，以保證發送報文的性能。在收到新的非重複ACK後，TCP連接恢復到慢啓動狀態發送報文。
三、 路由器擁塞控制隊列
在網絡中的路由器的轉發隊列通常實現了Random Early Detection (RED)功能，即，路由器會根據當前轉發隊列的平均長度來做丟包決策，並且隨機的丟棄一些TCP流量的報文，而不是等待隊列溢出後丟棄全部的報文，這樣能夠很好的避免所有TCP同時超時的問題。由於按照隊列的平均長度來進行丟包，而不是隊列滿長，所以會引起一部分TCP的退避，讓一部分TCP先放緩，保證另一些TCP的通常。再次，使用的隨機丟棄，所以針對所有TCP連接來說是相對公平的。
四、 ECN的設計概念
在RFC3168中定義了ECN的設計目標，是通過TCP發送端和接收端以及中間路由器的配合，感知中間路徑的擁塞，並主動的減緩TCP的發送速率，從而從早期避免擁塞而導致的丟包，實現網絡性能的最大利用。能夠解決的問題如下：
1、 所有TCP發送端能夠早期感知中間路徑擁塞，並主動放緩發送速率，預防擁塞發生。
2、 在中間路由器上轉發的隊列上，對於超過平均隊列長度的TCP報文進行ECN標記，並繼續進行轉發，不再丟棄報文。避免了報文的丟棄和TCP的重傳。
3、 由於減少了丟包，TCP不需要經過幾秒貨幾十秒的重傳定時器出發報文重傳，提高了時延敏感應用的用戶感受。
4、 與沒有部署ECN功能的網絡相比，網絡的利用率更好，不再在過載和輕載之前來回震盪。
五、 ECN在IP層和TCP層的修改
IP首部的修改
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint
ECN: Explicit Congestion Notification
The Differentiated Services and ECN Fields in IP.
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
The ECN Field in IP.
IP首部的TOS字段中的第7和8bit的res字段被重新定義爲ECN字段，其中有四個取值，在RFC3168中描述，00代表該報文並不支持ECN，所以路由器的將該報文按照原始非ECN報文處理即可，即，過載丟包。01和10這兩個值針對路由器來說是一樣的，都表明該報文支持ECN功能，如果發生擁塞，則ECN字段的這兩個將修改爲11來表示報文經過了擁塞，並繼續被路由器轉發。針對01和10的具體區別請參考RFC3168。
所以路由器轉發側要支持ECN，需要有以下新增功能：
1、 當擁塞發生時，針對ECN=00的報文，走原有普通非ECN流程，即，進行RED丟包。
2、 當擁塞發生時，針對ECN=01或ECN=10的報文，都需要修改爲ECN=11，並繼續轉發流程。
3、 當擁塞發生時，針對ECN=11的報文，需要繼續轉發。
4、 爲了保證與不支持ECN報文的公平性，在隊列超過一定長度時，需要考慮對支持ECN報文的丟棄。
TCP首部的修改
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
CWR: Congestion Window Reduce
ECE: ECN-Echo
The new definition of bytes 13 and 14 of the TCP Header.
針對主機側的修改，首部將bit8和bit9的res字段修改爲CWR和ECE。在RFC3168中的設計如下：
1、 在TCP接收端收到IP頭中的ECN=11標記，並在回覆ACK時將ECE bit置1。並在後續的ACK總均將ECE bit置1。
2、 在TCP發送端收到ECE bit置1的ACK報文時，需要將自己的發送速率減半，並在發送下一個報文時，將CWR bit置1。
3、 在接收端收到CWR bit置1的報文時，後續的ECE bit將不再置1。直到再次收到IP首部ECN=11時，重複上述過程。
4、 TCP發送端在收到一個ECE=1時，縮小發送窗口，並且在本次RTT時間內將不再再次縮小發送窗口。
5、 TCP接收端向發送端迴應ACK時，如果該ACK是一個不帶數據的“純”ACK，那麼必須IP首部ECN=00，因爲TCP沒有機制對純ACK進行響應，就無法針對純ACK發送擁塞通知。
6、 對於支持IP ECN的主機，TCP層在發送報文時需要將IP首部中的ECN置爲01或10。
中間設備
針對防火牆、網管等中間安全和管理設備，其實現和配置規則可能不能很好的與當前ECN兼容。需要中間設備廠商修改代碼或修改安全配置。
ECN在各種隧道中的支持
針對IP Tunnel[RFC2003]，RFC3168明確規定了報文到達隧道ingress和egress時ECN字段的複製要求，詳細信息請參考RFC3168，這裏不再贅述。
針對IP Sec[RFC2401]，RFC3168中明確定義了需要在IP Sec的安全關聯數據庫（SAD）和安全關聯屬性（SAA）中增加類型和字段來支持ECN在IP Sec隧道下的協商。詳細信息請參考RFC3168，這裏不再贅述。
針對MPLS, GRE, L2TP, PPTP等隧道支持ECN的規範沒有在RFC3168中明確說明，但RFC3168提到使這些隧道支持ECN並非難事。
六、 ECN在現有網絡中的增量部署
1、 網絡中的路由器按照1999年的ECN草案方案實現，將只識別ECN=10的報文作爲支持ECN功能，而不識別ECN=01的報文，這類路由器可能將ECN=01的報文將按照ECN=00的行爲處理，最後進行RED丟包。但並不影響網絡的正常功能。
2、 針對防火牆、網管等中間安全和管理設備，其實現和配置規則可能不能很好的與當前ECN兼容。需要中間設備廠商修改代碼或修改安全配置。
3、 針對主機側TCP僅有一端支持ECN功能時，支持ECN的TCP端需要先嚐試進行ECN的協商，如果連接不成功，必須進行非ECN功能的TCP連接協商，以保證TCP的向後兼容性。
4、 當支持ECN的TCP協商了非ECN的TCP連接後，如果後續收到ECN報文，應該按照支持ECN的行爲進行相應，以兼容早期ECN實現。
5、 針對IP Tunnel和IP Sec隧道，設置兩種模式開關，即支持ECN和不支持ECN，在不支持ECN情況下，ECN報文通過隧道將按照原始不支持ECN的行爲進行轉發和丟棄。
6、 在隧道的ingress和egress必須同時支持ECN或同時不支持ECN，不允許非對稱處理。
七、 ECN安全問題
1、 當TCP發送端重傳定時器超時，引起重傳報文發送時，則已經下調了發送速率，所以重傳的報文IP頭的ECN=00，則中間路由器不再置ECN標記。以避免DOS攻擊。
2、 TCP接收端在收到IP頭的ECN=11時，但TCP序號不正確的報文，迴應ACK時，不應該將ECE bit置位，以避免DOS攻擊。