TCP/IP通訊協議采用了4層的層級結構，每一層都呼叫它的下一層所提供的網絡來完成自己的需求。

由于ARPNET的設計者注重的是網絡互聯，允許通信子網(網絡接口層)采用已有的或是將來有的各種協議，所以這個層次中沒有提供專門的協議。

一、TCP 包進入和流出這個盒子。有些時候進入盒子的包被丟失了。因為今天的數字和光媒體上出現比特級錯誤的機會非常少，TCP 的設計者們就假設包的丟失很大程度上是因為路由器的擁塞，也即是路由器用來容納進入包的緩沖已經被填滿了，這樣路由器會靜默地丟棄接下來進入的包。

二、盡管TCP可以檢測到TCP包的丟失并且進行重傳，但是從TCP處理過程，重傳過程和吞吐率下降這些方面看，這個重傳過程將會耗費很大，當一個發送的TCP端節點檢測倒一個包丟失時，可以進行快速重傳或者包的重傳計時器超時而重傳。然后該TCP端節點減小發送窗口(在等待響應之前可以發送的包數量)，進行慢啟動和擁塞避免算法(RFC 2001)。這會立刻降低發送端的發送速率，以便路由器來減輕擁塞。發送端會逐漸將發送窗口恢復倒擁塞發生前的大小。

三、盡管因為路由器擁塞而產生的包丟失是偶然發生的事件，它們并不會負面地影響塊數據傳輸，只是會增加一些重傳數據包和恢復發送速率的時間。

慢啟動和擁塞避免算法對于時間敏感的，成塊數據流的控制效果非常好。然而，TCP處理丟包的方法對于交互式的，丟失敏感和時間敏感的流量來說效果不是很好。

四、當路由器開始丟棄進入的數據包時，它一般并不區分數據流的不同。當多個TCP數據流都產生包丟失時，所有的數據流都要減少自身的發送速率。根據路由器擁塞減輕的程度，多個TCP數據流將會逐漸恢復自身的發送速率。這會降低路由器及相關鏈路的使用率，直到所有的TCP數據流恢復到以擁塞之前的速率進行發送。路由器從擁塞狀態又進入到了低使用狀態。

五、這種擁塞后因為重傳和低鏈路使用而帶來的吞吐量問題，是僅僅通過發送端來管理擁塞的結果。為了避免因為路由器擁塞而帶來的丟包而產生的一系列問題，TCP/IP的設計者們創建了一些用于主機和路由器的標準。這些標準描述了在IP路由器上進行的主動隊列管理算法(AQM)(RFC 2309)，使得路由器能夠監控轉發隊列的狀態，以提供一個路由器向發送端報告發生擁塞的機制，讓發送端在路由器開始丟包前降低發送速率。這種路由器報告和主機響應機制被稱為顯式擁塞通告(ECN)(RFC 3168)。

六、當擁塞發生時，發送主機必須仍然在降低它們的發送速率。然而，通過避免包的丟失，發送主機無需進入重傳過程，丟失敏感的數據包流也不會因為擁塞而受到很大影響，IP和TCP使用包頭中的未使用字段來支持ECN。

在網絡層(IP)，一個發送主機必須能夠表明自身可以進行ECN，路由器在轉發時必須能夠表明它正在經歷擁塞。

七、在傳輸層(TCP)，TCP端必須對對方表明自身是可以進行ECN操作的。接收端必須能夠通知發送端它收到了一個來自路由器的擁塞通告。

發送端必須能夠通知接收端它受到了來自接收端的通告并且已經降低了發送速率，IP包頭中的8位的服務類型域(TOS)原先在RFC791中被定義為表明包的發送優先級，時延，吞吐量，可靠性和消耗等特征。在RFC2474中被重新定義為包含一個6位的區分服務碼點(DSCP)和兩個未用的位。

八、DSCP值表明一個在路由器上配置的和隊列相關聯的發送優先級。IP對ECN的支持使用到了TOS域中剩下的這兩位，一個支持ECN的主機發送數據包時將ECN設置為01或者10。

對于支持ECN的主機發送的包，如果路徑上的路由器支持ECN并且經歷擁塞，它將ECN域設置為11。如果該數值已經被設置為11，那么下游路徑上的路由器不會修改該值。

TCP是一個基于連接的協議，一個好的軟件工程應該將功能與實現方法區分開來，TCP/IP恰恰沒有很好地做到這點，就使得TCP/IP參考模型對于使用新的技術的指導意義是不夠的。TCP/IP參考模型不適合于其他非TCP/IP協議簇。