3. TDMA 排程及 TCP 效能分析
3.3. 實驗結果
3.3.4. Link utilization
我們認為 schedule A 有其缺點，由於 schedule A 將 timeslots 平均分配給所有 wireless link，但在其上運行的 TCP 效能可能會被 bottleneck link 的 capacity 限制 住。離 gateway 較遠的 node 雖然可以很快地送出封包，但也終究會因靠近 gateway (所有 TCP flows 匯集之處)的 bottleneck link capacity 不夠而將這些封包暫存在 intermediate node，而使得 TCP flows 不能夠順暢的流動。由於 TCP 是 feed-back based 的 protocol，會自動探測可用的 bandwidth 並調整傳送端的 sending rate，在 schedule A 中最終的結果可能導致離 gateway 較遠的 wireless link 沒有被有效利 用。
我們可以觀察各個 wireless link 的 utilization 證明這點。表 3-7 和表 3-8 將
four-node chain topology 和 seven-node chain topology 的 link utilization 列出。編號 較小的是離 gateway 較遠的 wireless link，traffic demand 比較少，在 schedule A 中，數據顯示這些 link 的 utilization 都相當低。但在 schedule B 中，timeslots 的 分配是按照 traffic demand 輕重程度來排，因此所有 link 都可以保持很高的 utilization。實驗證明 Schedule B 保存 TCP 的良好特性之一：讓 TCP flows 盡可 能地使用所有的可用頻寬。
表 3-7 link utilization (four-node)
Link utilization – four-node chain topology Link d
1Link d
2Link d
3Schedule A 32.62% 65.74% 99.98%
Schedule B 96.08% 97.92% 99.92%
表 3-8 link utilization (seven-node)
Link utilization – seven-node chain topology
Link d
1Link d
2Link d
3Link d
4Link d
5Link d
6Schedule A
16.01% 32.15% 48.29% 64.78% 81.30% 99.02%Schedule B
88.62% 90.60% 92.51% 94.28% 95.49% 97.39%3.4. 討論 討論 討論 討論
我們在這一章討論使 TCP 順暢流動的 k=1 model，並依此提出兩種 TDMA scheduling scheme：一個是平均分配 timeslots 給所有 wireless link 的 schedule A，
另外一個是按照 traffic demand 分配 timeslots 的 schedule B。實驗結果的各項數 據整理在下面表 3-9 和表 3-10 中。
表 3-9 各項效能比較(four-node)
index Bottleneck Link utilization
Link
9Nu_data+9Nu_ack 1.27 Mbps 0.9996
最終所有 flow 的 data rate
6Nu_data+6Nu_ack 1.90 Mbps 0.9990
Link
d3
99.92%
實驗數據證明根據 traffic demand 分配 timeslots 的 schedule B 比 schedule A 提 供 TCP 更好的 overall TCP throughput，主要原因是在於 schedule A 分配一樣多的 頻寬給每個 hop，使得 cycle time 變長，per-link 可以獲得的頻寬變少，per-flow 可以使用的頻寬變少，所以影響到 overall throughput。schedule B 根據 per-hop 的 traffic demand 讓 end-to-end 的傳輸一輪所需的 cycle time 比 schedule A 小，這點 可以從 3.3.3 的 TCP flows 的 round-trip time 數據上看出，schedule B 的所有 TCP flows 的 round-trip time 都比 schedule A 的 round-trip time 小。另外，Schedule A 的 timeslots 不考慮 per-hop 的 traffic demand，因此讓 TCP flow 卡在 bottleneck link，這樣會導致其它 wireless link 的 utilization 過低而造成 timeslots 的浪費，
schedule B 改善了這個情況，這點在 3.3.4 的數據中可以觀察到。
表 3-10 各項效能比較(seven-node)
index Bottleneck Link utilization Link
24Nu_data+24Nu_ack 0.95 Mbps 0.9988
最終所有 flow 的 data
在 individual throughput fairness 方面來看，兩種 scheduling 方式都可以得到 很好的 fairness 結果。這點可以從 3.3.2 的 congestion window 的變化情形來說明。
兩種 scheduling 的 congestion window 變化情形極為類似，所有 TCP flow 都在很 短的時間內將 congestion window 成長到並且維持在最大值，進入 steady state，
因此在大部份時間內，所有 TCP flow 都是以最大的 window size 傳輸資料，這造 成所有 TCP flows 送出大量的資料到網路上，讓 intermediate node 的 queue size
維持在很高的狀態，因此也使得 TCP flows 的 rtt 很大。Short-hop flow (編號較大 的 flow)的 window size 成長速度稍快，因此 throughput 稍微大於 long-hop flow。
但長期來說，因為所有 TCP flow 在絕大部份時間內都以最大 window size 傳輸資 料，而且在同一種 scheduling 中的 per-flow round-trip time 差異不大，因此 per-flow 的 throughput 差異不明顯，可以有很好的 throughput fairness。
總結來說，schedule B 使 TCP 有較好的效能表現，schedule B 同時保留兩項 TCP 在有線網路上的良好特性：使 TCP 盡可能的利用可用頻寬，以及保持 throughput fairness。在之後的章節中，我們將只使用 schedule B 進行效能評估。
4. Wireless link errors 引發的 引發的 引發的 引發的
packet loss 對 對 對 對 TCP 效能 效能 效能 效能的影響 的影響 的影響 的影響
使用 TDMA-based scheduling scheme 可以避免無線網狀網路因為 channel interference 和 channel contention 造成的 collision，我們稱此類 packet loss 為 MAC layer packet loss，因為這些 packet loss 是由於 MAC layer protocol 機制的本質所 造成。而在現實的環境中，wireless link 非常容易發生 error 而造成 packet loss。
Timeout 和 three duplicate ACK 是 TCP 判斷 packet loss 的指標。在有線網路上，
輕微的 congestion 可能造成一個 window 內的一兩個封包遺失，因此有 three duplicate ACK 的狀況發生，嚴重的 congestion 可能讓一連串送出的 data 封包都 被遺失(因為 buffer 滿了)而發生 timeout，而 TCP 將所有 packet loss 都視為網路 發生 congestion 的徵兆，發生 packet loss 時，TCP congestion control 機制會調整 congestion window 甚至是 timeout value，進而影響 TCP 的 throughput。但在 wireless link 上，packet loss 是偶然發生，但這些 packet loss 不代表網路發生 congestion，
此時 packet loss 引發 TCP congestion control 機制調降 window size 對 TCP throughput 可能造成傷害。本章將著重 TCP 良好特性的第二點 (參考 1.1.1)，討 論因 wireless link error 而造成的 random packet loss 對使用 TDMA scheduling 的 TCP performance 將有何影響？
4.1. Packet loss at the bottleneck link
我們考慮只有在 traffic load 最重的 bottleneck link 發生 packet loss 的情境，如 圖 4-1，所有 TCP flows 都會流經此處。我們定義一個參數：packet loss probability on single wireless link probability
p
，讓 bottleneck link 以 p 的機率隨機地遺失封 包。我們觀察各種不同的 TCP flow 在遭遇 packet loss 時的效能有何變化。圖 4-1 packet loss at the bottleneck link
4.1.1. Throughput performance
表 4-1 和表 4-2 是沒有 packet loss (即 p=0%)和 p=5% packet loss 的 overall TCP throughput 比較。在
p=5%時，TCP 的 throughput 下降，也無法保持 throughput
fairness。表 4-1 有無 packet loss 之效能比較(four-node) 我們觀察 per-flow 的 individual throughput，如圖 4-2 和圖 4-3。Long-hop flows 的 throughput 衰退程度比 short-hop flows 嚴重。對於 long-hop low 來說，packet loss 發生在離 TCP 傳送端最遠的 wireless link，TCP 的 end-to-end retransmission 機制 讓 long-hop flow 要花比較久的時間(相對於 short-hop flow)才發現 packet loss，因 此也要花比較長的時間復原。但 short-hop flow 在發生 packet loss 時，throughput 居然不降反升，這是因為 long-hop flow throughput 下降之後空出來的可用頻寬被 反應速度比較快(距離發生 packet loss 的 link 比較近)的 short-hop 使用掉。
圖 4-2 individual TCP throughput under p=5% (four-node)
圖 4-3 individual TCP throughput under p=5% (seven-node)
圖 4-4 和圖 4-5 為 flow 1 (long-hop flow)和 flow 6 (short-hop flow)的 TCP sequence number 隨時間變化的情形。兩張圖的 x 軸時間尺度是一樣的，在圖上 連續 sequence number 中間的斷層表示 TCP 遭遇 packet loss 發生 timeout，斷層越 大表示反應和恢復速度越慢。flow 1 (圖 4-4)上的斷層比起 flow 6 (圖 4-5)的斷層 大，說明 long-hop flow 的確需要花較多的時間復原 lost packet。
圖 4-4 TCP sequence number of flow 1 under p=5% (seven-node)
圖 4-5 TCP sequence number of flow6 under p=5% (seven-node)
4.1.2. TCP congestion window 變化情形 變化情形 變化情形 變化情形
我們將 p=5%的 TCP congestion window 隨時間變化的情形整理在圖 4-6 和圖 4-7。
圖 4-6 p=5%時 TCP congestion window 變化情形(four-node)
圖 4-7 p=5%時 TCP congestion window 變化情形(seven-node)
我們比對 3.3.2 之中 p=0%的數據(圖 3-21 和圖 3-23)發現，p=5%時，TCP 的 congestion window 不斷地上下震盪，因為 TCP 的 congestion control 演算法在發 生 packet loss 時會調降 congestion window size，但隨著及時收到的 TCP ACK 又 會逐漸調升其 congestion window size。由此可知 TCP 將 wireless link error 所造成 的 packet loss 當成是因 network congested 造成的 packet loss，因此而不恰當地調 降 congestion window size 使 throughput 下降。實際上這些 packet loss 是隨機地發 生，調降 congestion window 並沒有辦法避免 packet loss 的發生。
4.1.3. TCP smoothed round-trip time
表 4-3 表 4-4 和列出在 p=5%時 TCP 模擬結束時的 smoothed round-trip time。跟表 3-3 表 3-4 和比較起來，p=5%時的 round-trip time 都小很多。因為 packet loss 導致 TCP 時時調降的 congestion window 的緣故，TCP 沒辦法持續以 最大的 window size 送出資料，因此 data 並不像 p=0%時大量排在 queue 中而增 加 queueing delay。
表 4-3 srtt under p=5% (four-node)
Smoothed round-trip time – four-node chain topology Flow 1 Flow 2 Flow 3 Schedule B 0.2031 sec 0.1250 sec 0.1094 sec
表 4-4 srtt under p=5% (seven-node)
Smoothed round-trip time – seven-node chain topology
Flow 1 Flow 2 Flow 3 Flow 4 Flow 5 Flow 6
4.2. 討論 討論 討論 討論
在 Wireless bottleneck link error 造成的 random packet loss，會使得 wireless mesh network 上 path hop 長度不同的 TCP flow 有不同程度的 throughput 衰退，
long-hop flow 的 throughput 衰退程度遠比 short-hop flow 嚴重，因此使 throughput fairness 下降。這是因為在實驗的環境中，僅依靠 TCP end-to-end retransmission 機制處理 random packet loss，而 long-hop flow 需要花較長的時間才能 recover，
所以 long-hop flow 的 throughput 衰退得比較嚴重。另外，TCP congestion control 機制受到 random packet loss 的影響，使得 congestion window 不斷上下震盪無法 保持穩定，對 throughput 也是一項傷害。
我們在第五章將使用 link-layer retransmission scheme 解決 random packet loss 造成的 TCP 效能衰減。
5. Link-layer 重傳機制及 重傳機制及 重傳機制及 重傳機制及 TCP 效能 效能 效能 效能 分析
分析 分析 分析
針對 bottleneck link 發生 packet loss 而造成 TCP 效能下降問題，我們採用 link-layer retransmission scheme 作為解決方法。在文獻上，有許多文章[14] [15] [16]
討論如何在容易發生 error 的 wireless link 上提升 TCP throughput，不過都是考慮 在 single-hop wireless network 的環境。Eckhardt 等人[14] 認為處理 wireless link errors 的理想方法應該是用 local error control，而不應該讓 TCP 的 end-to-end error control 機制或是其他 end-to-end 的方式處理。End-to-end 的方法有其缺點，
end-to-end retransmission 在沿途經過的每段 wireless link 都要花費時間和消耗網 路資源。若使用 link-layer local error control，可以迅速地處理 packet loss，而且 可以達到 transparent 的效果(上層 protocol 不需要進行修改，而且也不容易發覺 packet loss 的發生)，因此佈署 link-layer local error control 比佈署 end-to-end error control 機制容易。
在這一章，我們將加入一個 link-layer retransmission scheme 以幫助 TCP 在 error-prone 的 wireless mesh network 上提升 throughput，並進行模擬實驗觀察並討 論其效能。
5.1. Link-layer retransmission scheme
我們使用一個簡單的 link-layer retransmission scheme，運作方式如圖 5-1，
每個 wireless node 若收到一個封包，則回覆傳送者一個 link-layer ACK 封包。TCP data 和 TCP ACK 對 link-layer 來說都是一個 link-layer data 封包，因此都要回覆 一個 link-layer ACK 以確認封包是否正確被接收。送出 link-layer data 封包之後，
若在下一個 receiving timeslot 沒有收到 link-layer ACK，傳送者就認為此封包遺 失，會立即在下一個 sending timeslot 安排重傳此 link-layer data 封包。不使用 timer 計時以判斷是否 timeout 的原因是由於 TDMA timeslot 的時間非常規律，timeslot index 本身就可以當 timer 作計時使用。如同 IEEE 802.11，我們也設定一個重傳 上限次數的參數，重傳次數上限設為 7 次，若重傳 7 次還沒有成功送達，此封包 就會被丟棄。
圖 5-1 link-layer retransmission scheme 運作方式示意圖
5.2. 實驗結果 實驗結果 實驗結果 實驗結果
和 4.1 一樣，我們設定 bottleneck link 有 p 的機率發生 packet loss，分別在 four-node chain topology 和 seven-node chain topology 上進行實驗，比較使用 link-layer retransmission scheme 和沒有使用 link-layer retransmission scheme 的 TCP 效能表現。
5.2.1. 分析 分析 分析 分析與 與 與 與量測 量測 量測 link-layer retransmission 量測 scheme 的 的 的 的 overhead
由於 link-layer retransmission scheme 需要傳輸 link-layer ACK 以確認封包是 否送達，會額外消耗可用頻寬帶來 overhead。我們先在 p=0%的狀況下，比較有 否使用 link-layer retransmission scheme 的 throughput 來量測 link-layer ACK 造成 多少 overhead。
每個 TCP data packet 或 TCP ACK packet，對 link-layer 來說都是 link-layer data，因此傳送一個 TCP data packet 或 TCP ACK packet 額外付出的代價是一個 link-layer ACK packet 所消耗的頻寬。要分析 link-layer ACK 造成的 overhead，我 們必需要知道 TCP data packet、TCP ACK packet 和 link-layer ACK packet 分別所 消耗的頻寬。我們將傳送封包所花費的時間視為消耗的頻寬，圖 5-2、圖 5-3、
圖 5-4 分別為 TCP data packet、TCP ACK packet 和 link-layer ACK packet 的結構 及傳輸所耗費時間。
圖 5-2 structure of TCP data packet
圖 5-3 structure of TCP ACK packet
圖 5-4 structure of link-layer ACK packet
在 IEEE 802.11b 中，封包中 physical layer header 的部份是以最低速 1Mbps 傳送，後面 link-layer 以上的部份才用設定的速度(11Mbps)傳送。因此，傳送一 個 payload 為 1460Bytes 的 TCP data packet 需時：
ms
傳送一個 link-layer ACK packet 需時：
ms schedule，計算出在一個 frame 裡面所傳送的 link-layer ACKs 消耗的頻寬，然後 依此計算傳送 link-layer ACK 所產生的 overhead。
在 four-node chain topology 中 schedule B(參考圖 3-12)的 link-layer ACK
表 5-1 overhead due to transmission of link-layer ACK
Four-node Seven-node Schedule B 21.24% 19.16%
實驗結果如下，表 5-2 為 four-node chain topology 的結果，表 5-3 為
實驗結果如下，表 5-2 為 four-node chain topology 的結果，表 5-3 為