Microsoft Word - _新_TCP模擬分析報告_M 王凱弘_

Size: px

Start display at page:

Download "Microsoft Word - _新_TCP模擬分析報告_M 王凱弘_"

翩齐
6 years ago
Views:

1 TCP 分析模擬報告 M 王凱弘 Introduction: TCP 是一種以連線為主的通訊協定, 而且它具有可靠的按照順序的傳送資料以 byte 為主的特性, 同時遵照特定的擁塞控制來傳輸資料,TCP 傳送端將所要傳輸的資料分割成幾個單獨的 segment, 但是每一個 segment 不能超過連線建立時所規定的最大 SMSS(Sender Maximum Segment Size) 大小, 而且每一個 segment 中都有附上一個單一的序號 (sequence number), 此序號主要是用來保證接收端可以確實收到每一個封包, 當接收端收到一個按照順序的封包時, 它會送出一個 ACK 給傳送端告知此序號的封包已經收到了, 但是如何接收端收到一個亂序 (out-of-order) 的封包時, 此時它會送出 duplicate ACK 給傳送端, 告訴傳送端某個序號的封包尚未收到, 如果經過一段很長的時間都沒有收到, 此時便會發生 timeout, 並重新從 slow-start 開始傳送資料隨著網路科技的進步,TCP 的版本也隨之演進, 從最初的 Tahoe 版本, 延伸出了 Reno New Reno Sack 及 Vegas 版本 Tahoe: 包含 Slow Start Congestion Avoidance Fast Retransmit 等功能在 Slow Start 的階段,Congestion Window 從 1 開始增長, 每當收到一個 ACK, 就會將 Congestion Window 增加 1 個 Size( 指數的增長 ), 一直增長到 ssthreshold(slow Start Threshold) 的 Size 後, 就將狀態切換到 Congestion Avoidance( 線性的增長 ) 若 Sender 收到三個 Duplicate ACK, 表示可能發生了 Congestion 情況,Sender 會立刻 Retransimit 這個 Packet, 不必等到此 packet timeout, 才可 Retransmit, 並且將 ssthreshold 設為 Congestion Window 的一半, 再將 Congestion Windows 設為 1, 重新回到 Slow Start 的階段 Reno: 目前使用最廣的 TCP 版本, 加入 fast recovry 機制, 允許傳送端可以在等待重送封包的 ACK 回來期間仍可以繼續送出新的 packet, 藉以提升 link 的 utilization New Reno: 修改 Reno 的 fast recovry 機制以解決 Reno 在收到 partial ACK 時提早結束 fast recovery 而導致 timeout 的問題, 每個 RTT 時間內可重送一個遺失的封包 SACK: 修改 TCP 的傳送端與接收端, 在 TCP header 加入 SACK 選項, 允許接收在收到 out-of-order packet 時, 回傳目前已經連續收到的區段, 傳送端可藉由這些資訊得知那些 packet 是沒被收到的並直接重送

2 Vegas:TCP 的傳送端. 利用 RTT 針測由傳送端到接收端之間 queue 的長度並藉此調整 congestion window 的值, 主要修改的部份有三點 :1. slow start: 大約 2 個 RTT 時間,cwnd 才會增加一倍 ;2. Congestion Avoidance:Vegas 藉由比較預期的速率與實際傳送的速率算出 Diff 的值, 並限制 Diff 的值必須介於 alpha 與 beta 之間, 若 Diff < alpha, 則增加傳送的速率, 反之, 若 Diff > beta, 則減少傳送的速率 ;3. 藉由觀察 RTT 的值比判斷是否已經有 packet timeout Simulation & Analysis: n0 n1 n2 上圖為此模擬的 Topology, 節點 n0 為來源端, 節點 n2 為目的端, 在節點 n0 與節點 n2 中, 架設了一條 TCP link, 分別對上述四種 TCP 版本做測試, 下列圖示中, 縱軸為 Packet Number (Mod 60), 橫軸為 Time( 單位為秒 ) 實驗ㄧ ( 一個封包漏失 ): Tahoe 首先由 slow-start 階段開始, 每收到一個 ACK,cwnd = cwnd +1, 到了第 14 個封包 ( 藍色點 ) 發生 packet drop, 等到此封包 timeout 或收到 3 個 duplicate ACK (fast recovery), 重傳第 14 個封包 ( 約上圖 1.3 秒的時候 ), 且 ssthresh = cwnd / 2 = 8 ( 前一次的 cwnd = 16),cwnd = 1, 重新進入 slow-star; 等到 cwnd > 8, 則進入 congestion avoidance, 每收到 cwnd 個的 ACK,cwnd = cwnd + 1

3 Reno 首先由 slow-start 階段開始, 每收到一個 ACK,cwnd = cwnd +1, 到了第 14 個封包 ( 藍色點 ) 發生 packet drop, 則 ssthresh = cwnd / 2 = 8,cwnd = ssthresh + 3 = 11(fast recovery), 因為 cwnd 大於 ssthresh, 所以 cwnd 只會增長到 8( 上圖黑虛線之間為同一個 cwnd 的封包 ), 由上圖觀察到狀態進入了 congestion avoidance, 所以可得知, 重傳的第 14 個封包的 ACK 在 timeout 之前就被接收到了 New-Reno 掉一個封包時, 同 Reno Sack 掉一個封包時, 同 New-Reno

4 實驗二 ( 兩個封包漏失 ): Tahoe 首先由 slow-start 階段開始, 每收到一個 ACK,cwnd = cwnd +1, 到了第 14 個封包 ( 藍色點 ) 發生 packet drop, 等到此封包 timeout 或收到 3 個 duplicate ACK (fast recovery), 重傳第 14 個封包 ( 約上圖 1.3 秒的時候 ), 且 ssthresh = cwnd / 2 = 8 ( 前一次的 cwnd = 16),cwnd = 1, 重新進入 slow-star, 由於第 28 個封包 drop( 第二個藍點 ) 在重新進入 slow-start 之前發生, 所以並不會再重新執行一次 slow-start 的機制, 只會接這重新傳送 ; 等到 cwnd > 8, 則進入 congestion avoidance, 每收到 cwnd 個的 ACK,cwnd = cwnd + 1 Reno 由於第 28 個封包 drop( 第二個藍色點 ) 之後, 後面幾個封包產生了一組 Partial ACK, 結束 Fast Recovery 的狀態, 且它必須等到 timeout, 才能在重送 ( 約上圖 1.8 秒的時候 )

5 New-Reno New-Reno 不會因為收到 Partial ACK 時結束 Fast Recovery, 傳送端會繼續重送封包, 直到所有的遺失的封包都重送後才結束 Fast Recovery, 所以不需等到 timeout 就能重新傳送第 28 個封包 Sack 掉兩個封包時, 同 New-Reno 實驗三 ( 三個封包漏失 ): Tahoe 由於第 28 個 ( 第二個藍色點 ) 與第 29 個 ( 第三個藍色點 ) 封包為同一個

6 cwnd, 所以第 28 個封包要重傳, 必須要等到第 29 封包 timeout( 如上圖黑色虛線的間隔 ) Reno 由於第 28 個 ( 第二個藍色點 ) 與第 29 個 ( 第三個藍色點 ) 封包為同一個 cwnd, 當第 29 個封包 drop( 第三個藍色點 ) 之後, 後面幾個封包產生了一組 Partial ACK, 結束 Fast Recovery 的狀態, 且它必須等到第 29 個封包 timeout, 才能在重送第 28 個封包 ( 約上圖 1.9 秒的時候 ) New-Reno New-Reno 不會因為收到 Partial ACK 時結束 Fast Recovery, 傳送端會繼續重送封包, 直到所有的遺失的封包都重送後才結束 Fast Recovery, 所以不需等到第 29 個封包 timeout 就能先重新傳送第 28 個封包, 同理, 第 29 個封包也不需等待 timeout, 就能重傳

7 Sack 在 SACK 中, 新加入一個 SACK option, 會將 Recevier 裡已收到的封包範圍回傳給 Sender, 其範圍間隔就是遺失的封包 ( 第 28~29 個 ), 並重傳此遺失的封包 ( 在上圖 1.5 秒左右 ) 實驗四 ( 四個封包漏失 ): Tahoe 由於第 28 個 ( 第二個藍色點 ) 第 29 個 ( 第三個藍色點 ) 與第 30 個 ( 第四個藍色點 ) 封包為同一個 cwnd, 所以第 28 個封包要重傳, 必須要等到第 30 封包 timeout( 如上圖黑色虛線的間隔 ) Reno

8 由於第 28 個 ( 第二個藍色點 ) 第 29 個 ( 第三個藍色點 ) 與第 30 個 ( 第四個藍色點 ) 封包為同一個 cwnd, 當第 30 個封包 drop( 第四個藍色點 ) 之後, 後面幾個封包產生了一組 Partial ACK, 結束 Fast Recovery 的狀態, 且它必須等到第 30 個封包 timeout, 才能在重送第 28 個封包 ( 約上圖 2 秒的時候 ) New-Reno New-Reno 不會因為收到 Partial ACK 時結束 Fast Recovery, 傳送端會繼續重送封包, 直到所有的遺失的封包都重送後才結束 Fast Recovery, 所以不需等到第 29 個封包 timeout 就能先重新傳送第 28 個封包, 同理, 第 29 個封包也不需等待第 30 個封包 timeout, 就能重傳, 第 30 個封包也相同, 但上圖時間在 2 秒左右, 又重傳第 29 到第 33 個封包, 也許是模擬時, 使用 cbr 所導致的異狀 Sack 同掉三個封包的實驗,SACK option 會將 Recevier 裡已收到的封包範圍回傳給 Sender, 其範圍間隔就是遺失的封包 ( 第 28~30 個 ), 並重傳此遺失的封包 ( 在上圖 1.5 秒左右 )

穨control.PDF

穨control.PDF TCP congestion control yhmiu Outline Congestion control algorithms Purpose of RFC2581 Purpose of RFC2582 TCP SS-DR 1998 TCP Extensions RFC1072 1988 SACK RFC2018 1996 FACK 1996 Rate-Halving 1997 OldTahoe