Hop-by-Hop TCP over MANET 適用於無線隨意式網路之逐節點 TCP 傳輸協定

1. Hop-by-Hop TCP over MANET適用於無線隨意式網路之逐節點TCP傳輸協定 政治大學資訊科學所 指導教授 ： 連耀南 教授 學生 : 游逸帆 2007.12.27

2. Outline • Introduction • Related works • Our approach • Performance evaluation • Conclusion

3. Introduction • What is TCP ? • 網路上被廣為使用的端對端傳輸層協定 • Reliable , in-order • Connection-oriented • Flow controlled • TCP flow control & congestion control • Trial-and-error based flow control for control congestion • Sliding window mechanism • 調整 window size • 　調整 flow 的快慢 • TCP 的設計目標： • 確保網路從sender端可以可靠的傳輸至receiver端，保證packet到達，在不把網路塞爆的情況下盡量利用剩餘頻寬

4. Introduction (cont.) • 傳統TCP的假設： • packet loss的最主要原因是因為網路壅塞 • TCP是用packet loss當成congestion的indicator • TCP對於所有的loss都當成congestion loss來處理，並且依賴fast retransmit以及time out的機制來處理packet loss

5. Introduction (cont.)

6. Route Failure and Random Loss Retransmission by Sender End-to-End Congestion Control Long Delay and Performance Degradation Falsely Trigger Slowness Challenges in Wireless Networks (cont.) Bad Network Condition What happen if we can retransmit not only from sender??

7. Introduction (cont.) • 如果我們能從每個intermediate node進行local重傳，則反應封包遺失的速度可以提升 A B C D A B C D HBH RTT E2E RTT

8. Introduction (cont.) • 傳統的TCP只會在兩個端點上執行 • 一般而言網路的中間節點都是Router，因此不可能會有TCP在第四層中 • 在MANET中每個node可能都是computer，因此我們可以Run protocol在各個node上 • 我們利用MANET的這個特性，設計Hop-by-Hop TCP，使封包一站一站確保傳送，期望縮短傳送的delay time、提升throughput。

9. Outline • Introduction • Related works • Our approach • Performance evaluation • Conclusion

10. Related Works • 利用網路提供的一些資訊分辨封包遺失原因以免不必要降速 • ATCP (Ad Hoc TCP) • TCP Muzha • 運用中間節點幫助傳送封包 • The transport layer revisited

11. ATCP • A layer called ATCP is inserted between the TCP and IP layers of the source node • ATCP listens to the network state by • ECN (Explicit Congestion Notification) message • Congestion!! • ICMP “Destination Unreachable” message • Network Partitioning!! • Sender can be put into 3 states: • Persist State– by ICMP message • Congestion Control State– by ECN message • Retransmit State– by packet loss without ECN flag • Note - After receiving three duplicate ACKs, sender does not invoke congestion control and puts TCP in Persist State and quickly retransmit the loss packet from buffer ( Multipath routing or channel loss) • Recomputation of congestion window size after route re-establishment

12. TCP-Muzha • 藉由路由器協助，提供網路內部資訊給傳送端 • 在未發生擁塞前不需依賴封包遺失便可進行適度的傳輸速度控制 • 尋找傳送路徑中的瓶頸，進而計算出瓶頸提供的可用頻寬，藉由瓶頸所提供的資訊動態的進行流量控制以充份利用頻寬並避免產生擁塞 • 可辨別出封包遺失的原因是否為網路擁塞所引起或是Random loss而遺失並進而作相對應的處理

13. Adaptive CWL (Congestion Window Limit) • If the congestion window size is greater than an upper bound, the TCP performance will degrade. • Find the BDP (Bandwidth Delay Product) of a path in MANET • They use this upper bound of BDP to dynamically adjust TCP’s max. window size

14. The Transport Layer Revisited • Heimlicher, SimonBaumann, RainerMay, MartinPlattner, Bernhard, “ The Transport Layer Revisited,” Communication Systems Software and Middleware, 2007. COMSWARE 2007. • The framework is implemented on two sublayers • The hop-by-hop layer runs on every node and provides per-link flow control and congestion control • On this layer, data is managed in units of fragments(8 packets) • The end-to-end layer operates at the end points of the connection, provides a reliable-byte-stream interface to the application-layer, just like TCP • Data is managed as segments, which are data units comprising a few fragments(4 fragments)

15. The Transport Layer Revisited (cont.) • The end-to-end congestion control mechanism has a job similar to the congestion control algorithm of TCP: it limits the number of un-acknowledged segments on a per-connection basis. • If no acknowledgement is received for a segment for a certain period, the source needs to retransmit the segment.

16. The Transport Layer Revisited (cont.) • If a packet is lost on any intermediate link, the node at the receiving side will not acknowledge the corresponding fragment and the last hop will retransmit the fragment.

17. Comment • 如果sender沒收到segment的ACK，則必須重傳整個segment • ACK遺失則重傳overhead相當大 • Segment的重傳使用exponential back-off，delay time將會拉更長 • 若中間節點遺失一個封包，則必須重傳整個fragment • 網路環境不穩定，容易因為一個封包遺失而重新傳送沒遺失的封包 • 如果網路上不止有一條flow，節點一次傳送整個fragment時，其他flow的封包就必須等待較多時間，且傳送失敗的機會亦相對高。

18. Summary • 目前在無線隨意式網路中大部分的方法，大都著重在於利用分辨封包遺失的原因，以減少TCP容易不必要降低傳送速率的機率，較少利用中間節點以幫助確保傳送的方法 • 然而在無線隨意式網路環境下，不穩定的環境使封包容易遺失 • 從傳送端重傳 • 每次從傳送端重傳會遭遇到相同的條件 • 造成惡性循環，不斷從傳送端重送，封包送達速度緩慢，效能低落。

19. Outline • Introduction • Related works • Our approach • Performance evaluation • Conclusion

20. Our approach • Hop-by-Hop TCP • 我們建議讓網路中的每個intermediate node可以一站一站進行retransmission，提昇傳輸可靠度 • 每個node都幫忙keep住封包 • 封包遺失時，只需從Local端重新發送，而不需回到sender端重送

21. Our approach (cont.) • Hop-by-Hop TCP • Composed by End-to-End TCP and One-hop TCP

22. 設計目標 • 降低平均delay time使封包能快速送達 • 減少Number of retransmission • 提升throughput • 和其它協定共存時(NewReno)，仍能保有相當的效能

23. TCP Design issues • 速度調控 : 如何不造成congestion並有效利用頻寬 • Fairness • 如何處理Packet loss (End-to-End packet loss 如何處理) • 如何處理ACK loss • 重傳機制 • Buffer控制 • 重送次數

24. Hop-by-Hop TCP • 利用MANET特性，使傳輸delay time能降低的protocol • 由 • End-to-End TCP • One-Hop TCP所組成

25. End-to-End TCP • 用於網路的兩個端點，確保封包能從sender端成功傳輸至receiver端的protocol • 延續TCP Reno的機制 • 不同之處： • 我們將Sender的congestion window設定一個upper bound，使其不會過度的成長 • Time Out重傳： • 採取較大的End-to-End RTO 計算方式

26. One-Hop TCP • 用於相鄰兩個節點之間，提升packet傳輸可靠度，保證送達下一站的傳輸層協定 • 功能： • Buffer packet • 進行遺失封包的重傳

27. One-Hop TCP • 速度調控： • 一次送一個packet過去，等待ACK回來，再送下個packet • 重傳： • One-Hop RTO之內downstream node未回覆ACK則重傳封包 • 提昇傳輸可靠度 • 超過Retransmission Threshold則不再重傳 • Route Failure • Congestion

28. End-to-End ACK • End-to-End ACK： • 傳統TCP中Receiver傳送至Sender的ACK • 提昇End-to-End ACK 存活率： • Receiver端使用One-Hop TCP機制，將End-to-End ACK一站一站確保傳輸成功，傳送至Sender端

29. Start Buffer,Return LACK/Receive packet when another packet is outgoing Retransmit from buffer/Timeout and retry times<=5 Buffer, Return LACK, Send/Receive packet and no packet is outgoing Wait Ready Drop packet, Cancel timer/Timeout and retry times >5 Purge buffer,Cancel timer/Receive LACK Set no packet is outgoing/Buffer empty Send/Other packet in buffer Done Our approach (cont.)

30. Our approach (cont.)

31. How to reduce overhead • 為了要減少過多ACK的overhead，我們將Local ACK for E2E ACK封包及Loacl ACK封包分別利用Piggybacking的方式搭在Data封包及End-to-End ACK封包上。 • Header新增piggyback_欄位 • Forward : • Data • Local ACK for E2E ACK • Backward : • End-to-End ACK • Local ACK

32. How to reduce overhead ACKforE2E ACKforE2E ACKforE2E Data Data Data Receiver Sender ONEHOP ONEHOP ONEHOP ACK ACK ACK

33. 收到資料封包流程

34. Outline • Introduction • Related work • Our approach • Performance evaluation • Conclusion

35. Performance Evaluation • 本研究將以NS-2模擬器評估我們提出的方法，驗證我們的機制可以降低傳輸的delay time，提升效能 • 測試環境：我們的研究將以NS-2模擬器模擬MANET環境，在MANET中使用TCP通訊協定進行資料傳輸。

36. Performance Evaluation • 實驗scenario： • 在MANET下比較Hop-by-Hop TCP與不同版本的TCP，在不同參數下的表現 • 評估指標： • Average Delay Time • Average Throughput • Retransmission • CWND (congestion window size) 的變化狀況 • Fairness Index

37. 實驗設計 • Performance Test • 觀察Hop-by-Hop TCP在不同變因下的整體效能 • 調整 hop count • 調整 error rate • 調整 buffer size • 調整bandwidth • 調整window size • Fairness Test • 觀察多協定共存狀態下的公平性 (Fairness) • 和Reno共存的情形 • 觀察有多個Hop-by-Hop TCP flow並存時的情形

38. 實驗1Performance Test • 實驗流程 • 一個傳送端、一個接收端中間隔著數個中間節點 • 改變 buffer size、error rate、hop count來觀察 • 實驗目標 • 觀察在單一TCP的情況下，Hop-by-Hop TCP機制的整體效能。

39. Topology • 實驗參數 • 觀察 • 整體效能的變化

40. Delay at different Number of hops • 在封包容易遺失的MANET中，遺失的封包直接從local端快速重傳而不必由sender端重傳 • 能縮短20%以上的Delay time

41. Delay at different Number of hops (cont.) • 可用頻寬不多時，封包遺失的傷害相對較大，提升封包傳輸可靠度也能縮短傳輸時間 • 能縮短15%以上的Delay time

42. Throughput at different Number of hops • 在封包容易遺失的MANET中，中間節點一站一站確保傳送成功，使得封包到達的機率提升 • 能提升25%以上的throughput

43. Throughput at different Number of hops (cont.) • 可用頻寬不多時不穩定的環境下能提升20%以上的throughput

44. Retransmission Rate

45. Number of control message v.s. Data packet

46. Change of Congestion window size

47. Summary-實驗一 • 在不穩定的網路環境中，遺失的封包能從local端立刻重傳，平均延遲時間比NewReno縮短了20%以上，整體效能高於25%以上 • 不會因為MANET不穩定的環境遺失封包而影響congestion window size，造成傳輸速度不必要的降低

48. 實驗2Fairness Test • 公平性(Fairness) • 在網路上不完全採用同一版本TCP時，會有共存的問題 • TCP Vegas 的一個問題便是它和TCP Reno共存時會因為Reno採用較具侵略性的擁塞控制方法，因此在共存時，Vegas效能差了很多

49. TCP Flow 1 TCP Flow 2 Performance Evaluation • Fairness test 1 • Cross Topology • 4 hops, 6 hops, and 8 hops • Bandwidth : 1Mb/s • Simulation time: 100 sec • Two Sets • TCP Vegas, TCP NewReno • Hop-by-Hop TCP, TCP NewReno • Fairness test 2 • Throughput dynamics

50. Fairness Index • Fairness Index • Jain’s Fairness Index [ ] n: Number of Flow χi : Throughput of the i-th Flow