TCP 雷達

什麼是 Laminar？

Laminar 是 TCP 壅塞控制項的新架構，可將傳輸排程分開，從單純的壅塞控制機制精準確定資料傳送的時間。它會決定每個 RTT 期間傳送的總資料量。

傳輸排程的預設演算法是 Van Jacobson 封包保存原則 [Jacobson88] 的嚴格實作。傳入接收端的資料會引發 ACK，接著導致傳送方將等量的資料傳回網路。主要狀態變數是隱含在網路中的資料量和 ACK 內。此狀態會透過改良的 tcp_packets_in_flight() estimator (又稱 total_pipe) 觀察到此狀態。Total_pipe 是以 RFC 3517 中所述的「管道」為基礎，但也包含目前 ACK 和等待擁塞控制，但正在等待 TSO 等其他事件的待處理傳輸資料量。

CCwin 是一個新的變數，是主要壅塞控制狀態變數。壅塞控制演算法會調整 CCwin 以調節路徑上的整體壅塞程度。雖然 CCwin 類似於後盾，但 cwnd 會超載，並由多個演算法 (例如爆發抑制) 用於不同目標，有時互相衝突的目標。

任何時間 total_pipe 與 CCwin 不同，傳輸排程演算法會稍微調整回應每個 ACK 時傳送的片段數量。緩慢啟動和比例降低率 [PRR] (用於減緩速率的替代項目) 都嵌入到傳輸排程演算法中。

Laminar 架構的主要優點是，將壅塞控制和傳輸排程分割到不同的子系統，每個子系統都有更簡單的設計限制，方便您開發許多無法和先前程式碼組織使用的新演算法。

Laminar 架構會改變 TCP 壅塞控制的基礎設計理念，而且除了修補程式本身以外，還可能產生許多影響。這個修補程式旨在讓人們實驗程式碼、加上註解，並協助找出任何可能忽略的極端案例。此外，修補程式還不完整，因為我們仍然缺少多個演算法，特別是 CUBIC 和 Reno 以外的擁塞控制演算法、cwnd 驗證、目的地指標等。若其他人可以協助重構其中一些其他演算法，那麼這項功能會非常實用。

在網際網路草稿 draft-mathis-tcpm-tcp-laminar 中，我們將對於 Laminar 架構和動機有更詳細的說明。

請將意見和建議傳送至 [e-mail]。

這項專案是 Google 透過進一步改善通訊協定來加快網頁速度的成果。

實作注意事項

Laminar 主要透過 3 個函式 (tcp_input.c) 實作：

Tcp_cong_avoid() 和 tcp_mult_decr() 可使用 CCwin 狀態變數執行 AIMD 壅塞控制。除了復原以外，只有這兩個函式是 CCwin 變更的唯一位置。(這兩個函式都會叫用壅塞模組的特定處理常式)。

Tcp_laminar_schedule() 會判斷回應每個 ACK 時要傳送多少資料。它會實作 Van Jacobson 封包保護，並稍微調整，讓 tcp_packets_in_flight() 匯聚至 CCwin。

tcp_packets_in_flight() Estimator 有重大變更，以便在大部分的通訊協定事件中保持不變。應用程式會延遲 tcp_laminar_schedule() 的調整，實際封包遺失率就會變更 tcp_packets_in_flight()。ACK 處理、TSO 和其他多數事件則不會。請注意，當傳輸失敗時，航班中的實際封包數量會立即變更，但在重新傳輸的機器將封包標示為遺失並遞增時，此值才會反映在 tcp_packets_in_flight() 估算工具中。

取得修補程式

這個修補與 Dave Miller 的 net-next 一致，並套用至 3.5-rc2。
NB：其他 Reno 和 CUBIC 尚未更新，也不會編譯的壅塞控制模組。如果您的設定會建立其他壅塞控制模組，例如時速、可擴充、高速等模組，請先停用這些模組。