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 端，保證 p

acket 到達，在不把網路塞爆的情況下盡量利用剩餘頻寬

4

Introduction (cont.)

傳統 TCP 的假設： packet loss 的最主要原因是因為網路壅塞

TCP 是用 packet loss 當成 congestion的 indicator TCP 對於所有的 loss 都當成 congestion lo

ss 來處理，並且依賴 fast retransmit 以及 time out 的機制來處理 packet loss

5


6

Challenges in Wireless Networks (cont.)

Bad Network Condition

Route Failure and Random Loss

Slowness

Falsely

Trigger

End-to-End

Congestion

Control

Retransmission

by Sender

Long Delay and

Performance

Degradation

What happen if we can retransmit not only from sender??

7


如果我們能從每個 intermediate node進行 local 重傳，則反應封包遺失的速度可以提升

HB

H R

TT

A B C D

E2E

RT

T

A B C D

8

Introduction (cont.) 傳統的 TCP 只會在兩個端點上執行

一般而言網路的中間節點都是 Router ，因此不可能會有 TCP 在第四層中

在 MANET 中每個 node 可能都是 computer ，因此我們可以 Run protocol 在各個node 上我們利用 MANET 的這個特性，設計 Hop-by-

Hop TCP ，使封包一站一站確保傳送，期望縮短傳送的 delay time 、提升 throughput 。

9

Outline


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 sourc

e 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, Simon Baumann, Rainer May, Martin Pl

attner, 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 pe

r-link flow control and congestion control On this layer, data is managed in units of fragments(8 packe

ts) The end-to-end layer operates at the end points of the co

nnection, 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 ，節點一次傳送整個 fra

gment時，其他 flow 的封包就必須等待較多時間，且傳送失敗的機會亦相對高。

18

Summary 目前在無線隨意式網路中大部分的方法，大都著重在於利用分辨封包遺失的原因，以減少 TCP容易不必要降低傳送速率的機率，較少利用中間節點以幫助確保傳送的方法

然而在無線隨意式網路環境下，不穩定的環境使封包容易遺失從傳送端重傳每次從傳送端重傳會遭遇到相同的條件造成惡性循環，不斷從傳送端重送，封包送達速度緩慢，效能低落。

19

Outline


20

Our approach

Hop-by-Hop TCP 我們建議讓網路中的每個 intermediate no

de 可以一站一站進行 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 l

oss 如何處理 ) 如何處理 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 未回覆 AC

K 則重傳封包提昇傳輸可靠度

超過 Retransmission Threshold 則不再重傳 Route Failure Congestion

28

End-to-End ACK

End-to-End ACK ：傳統 TCP 中 Receiver 傳送至 Sender 的 AC

K 提昇 End-to-End ACK 存活率：

Receiver 端使用 One-Hop TCP 機制，將 End-to-End ACK 一站一站確保傳輸成功，傳送至 Sender 端

29

Our approach (cont.)

StartBuffer,Return LACK/Receive packet when another packet is outgoing

Buffer, Return LACK, Send/Receive packet and no packet is outgoing

Purge buffer,Cancel timer/Receive LACKSet no packet is outgoing/Buffer empty

Send/Other packet in buffer

Retransmit from buffer/Timeout and retry times<=5

Ready

Done

Wait

Drop packet, Cancel timer/Timeout and retry times >5

30

Our approach (cont.)Event Status Behavior of received node Next state

Receive packet when another on the air

Ready 檢查是否重複封包，若不是則暫存此封包 ,；回覆此封包之 Local ACK，若反方向有封包欲傳送，則 piggyback上去

Ready

Receive packet and no packet is outgoing

Ready 檢查是否重複封包，若不是則暫存此封包 ,；回覆此封包之 Local ACK，若反方向有封包欲傳送，則 piggyback上去；送出封包、開始計時器

Wait

Local Timeout and retry times less then 6

Wait 重傳超時的封包；重新開始計時器 Wait

Local Timeout and retry times large then 5

Wait 從暫存器清除重傳超過五次的封包；停止計時器 Done

Receiving a LACK from downstream node

Wait 停止計時器；清除暫存器內相對應封包 Done

Other Packet in Buffer Done 送出暫存器內的下一個封包，並開始計時器 Wait

Buffer empty Done 設定為無封包正在傳送，等待接收下一個封包 Ready

31

How to reduce overhead 為了要減少過多 ACK 的 overhead ，我們將 Local AC

K 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

Data

ACKforE2E

Sender

Receiver

ONEHOP

ACK

Data

ACKforE2E

Data

ACKforE2E

ONEHOP

ACK

ONEHOP

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

實驗設計1. Performance Test

觀察 Hop-by-Hop TCP 在不同變因下的整體效能調整 hop count 調整 error rate 調整 buffer size 調整 bandwidth 調整 window size

2. Fairness Test1. 觀察多協定共存狀態下的公平性 (Fairness)

和 Reno共存的情形2. 觀察有多個 Hop-by-Hop TCP flow 並存時的情形

38

實驗 1Performance Test 實驗目標

觀察在單一 TCP 的情況下， Hop-by-Hop TCP 機制的整體效能。

實驗流程一個傳送端、一個接收

端中間隔著數個中間節點

改變 buffer size 、 error rate 、 hop count來觀察

39

Topology

觀察整體效能的變化

Simulation 1

CWND Upper Bound

4

Bandwidth 0.5Mbps~1Mbps

Error Rate 0.0~0.2

Number of Nodes 5~11

實驗參數

40

Delay at different Number of hops

在封包容易遺失的 MANET 中，遺失的封包直接從 local 端快速重傳而不必由 sender 端重傳

能縮短 20%以上的 Delay time

Delay v.s. Number of hops(window =4, loss rate=0.0 )

0

250

500

4 5 6 7 8 9 10

Number of hops

Dela

y[ms

] NewReno

Hop-by-HopTCPVegas

Sack


0

500

1000

1500

2000

4 5 6 7 8 9

Number of hopsDe

lay[

ms]

NewReno

Hop-by-HopTCPVegas

Sack


1000

2000

3000

4000

5000

4 5 6 7 8

Number of hops

Dela

y[ms

] NewReno

Hop-by-HopTCPVegas

Sack

41

Delay at different Number of hops (cont.)


0

250

500

750

4 5 6 7 8 9 10

Number of hops

Dela

y[ms

] NewReno

Hop-by-HopTCPVegas

Sack


010002000300040005000

4 5 6 7 8 9

Number of hopsDe

lay[

ms] NewReno

Hop-by-HopTCPVegas

SackDelay v.s. Number of hops(window =4, loss rate=0.2 )

1000

3000

5000

7000

9000

4 5 6 7 8

Number of hops

Dela

y[ms

] NewReno

Hop-by-HopTCPVegas

Sack

可用頻寬不多時，封包遺失的傷害相對較大，提升封包傳輸可靠度也能縮短傳輸時間

能縮短 15%以上的 Delay time

42

Throughput at different Number of hops

在封包容易遺失的 MANET 中，中間節點一站一站確保傳送成功，使得封包到達的機率提升

能提升 25%以上的 throughput

Throughput v.s. Number of hops(window =4, loss rate=0.0 )

0

50

100

150

200

4 5 6 7 8 9 10

Number of hops

Thr

ough

put[K

pbs] NewReno

Hop-by-HopTCPVegas

Sack


01020304050

4 5 6 7 8 9 10

Number of hops

Thro

ughp

ut[K

pbs] NewReno

Hop-by-HopTCPVegas

Sack


0

5

10

15

4 5 6 7 8 9 10

Number of hops

Thr

ough

put[K

pbs] NewReno

Hop-by-HopTCPVegas

Sack

43

Throughput at different Number of hops (cont.)

可用頻寬不多時不穩定的環境下能提升 20%以上的 throughput


01020304050

4 5 6 7 8 9 10

Number of hops

Thr

ough

put[K

pbs] NewReno

Hop-by-HopTCPVegas

Sack


05

10152025

4 5 6 7 8 9 10

Number of hopsTh

roug

hput

[Kpb

s] NewReno

Hop-by-HopTCPVegas

SackThroughput v.s. Number of hops(window =4, loss rate=0.2 )

02468

10

4 5 6 7 8 9 10

Number of hops

Thr

ough

put[K

pbs] NewReno

Hop-by-HopTCPVegas

Sack

44

Retransmission Rate

Number of Retransmission(error rate=0.0, window=4)

0

0.02

0.04

0.06

0.08

0.1

4 5 6 7 8 9

Number of Hops

Retra

nsmi

ssion

rate NewReno

Hop-by-Hop TCPVegas

Sack

Number of Retransmission(error rate=0.1, window=4)

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

4 5 6 7 8 9

Number of Hops

Retra

nsmi

ssion

rate NewReno

Hop-by-Hop TCPVegas

Sack

45

Number of control message v.s. Data packet

Number of control message(LACK+E2E ACK's LACK) v.s. Datapacket (TCP+ACK)

0

1000

2000

3000

4000

4hop 5hop 6hop 7hop 8hop 9hop

Number of hops

Num

ber of

pac

kets(p

kt) data with piggyback

data withoutpiggyback

control message withpiggyback

control messagewithout piggyback

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

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 Ne

wReno

Fairness test 2 Throughput dynamics

TCP Flow 1

TCP Flow 2

50

Fairness Index

Fairness Index Jain’s Fairness Index [ ]

n: Number of Flow

χi : Throughput of the i-th Flow

51

Fairness Test 1

Fairness comparison - Throughput

Fairness Test 1 (Cross Topology)

0

50

100

150

4hop 6hop 8hop

Number of Hop

Avg

. Thr

ough

put (

Kpb

s)

NewReno

Vegas

Fairness Test 2 (Cross Topology)

0

50

100

150

4hop 6hop 8hop

Number of Hop

Avg

. Thr

ough

put (

Kpb

s)

NewReno

Hop-by-Hop TCP

52

Fairness Test 1

Fairness comparison – Jain’s Index

Fairness Index (Vegas vs. NewReno)

0

0.20.4

0.60.8

11.2

4hop 6hop 8hop

Number of Hop

Vegas vs. NewReno

Fairness Index (Hop-by-Hop TCP vs. NewReno)

0

0.20.4

0.60.8

11.2

4hop 6hop 8hop

Number of Hop

Hop-by-Hop TCP vs.NewReno

53

實驗 2Fairness Test 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 Three flows, each starts at different times

54

Fairness Test 2Jain's Fairness Index

0.50.60.70.80.9

1

12 14 16 18 20 22 24 26 28 30

Time(sec)

NewReno

Jain's Fairness Index

0.50.60.70.80.9

1

12 14 16 18 20 22 24 26 28 30

Time(sec)

Hop-by-HopTCP

Throughput Dynamics(NewReno error rate=0.0, window=4)

0

1

2

3

4

5

6

0 3 6 9 12 15 18 21 24 27 30

Time(sec)

Con

gest

ion

win

dow

siz

e(pk

ts)

cwnd0.0

cwnd10.0

cwnd20.0

Throughput Dynamics(HBH TCP error rate=0.0, window=4)

0

1

2

3

4

5

0 3 6 9 12 15 18 21 24 27 30

Time(sec)

Con

gest

ion

win

dow

siz

e(pk

ts)

cwnd0.0

cwnd10.0

cwnd20.0

55

Fairness Test 2 Fairness comparison – Jain’s Index

Jain's Fairness Index

0.50.60.70.80.9

1

12 14 16 18 20 22 24 26 28 30

Time(sec)

NewReno

Hop-by-HopTCP

2 flows 3 flows

56

Fairness Test 2

Fairness Test 2

0

10

20

30

40

50

flow0 flow1 flow2

Avg.

Throu

ghpu

t (Kpb

s)

NewReno

Hop-by-Hop TCP

Fairness Test 2

0

20

40

60

80

100

120

140

0~10 10~20 20~30

Avg.

Throu

ghpu

t (Kpb

s)

Hop-by-Hop TCP flow0



NewReno flow0

NewReno flow1

NewReno flow2

Fairness comparison - Throughput

57

Fairness Test 2 Fairness comparison – Jain’s Index

Fairness Comparison(3flow)

0

0.2

0.40.6

0.8

1

1.2

3flow fairness flow0,1 10~20 flow0,1,2 20~30

Number of Flow

NewReno

Hop-by-Hop TCP

58

Summary-實驗二我們的方法承襲了 Reno 的擁塞控制機制

雖然效能略有下降，不至於因為 Reno較侵略性擁塞控制方法而使得效能降低過多

因此相對於 Vegas 能有較好的公平性在多條 flow時候能達到同步化，可用頻寬較

一致每條 flow 在每個節點皆一次傳送一個封包晚到的 flow也能一起競爭頻道傳送，因此公平性較佳

59

Outline

Introduction Related work Our approach Performance evaluation Conclusion

60

Conclusion & Future work 我們提出了一個運用中間節點的 TCP Layer 幫忙確保

傳送的想法經過實驗驗證所提出的想法是可行的在不穩定的網路中可有優於 NewReno 及 Vegas 的平均吞吐量及延遲時間

和 NewReno共存的環境下則效能高於 Vegas 同步化的公平性優於 NewReno 使用中間節點幫忙傳輸的想法及細節還有很多可以改

進的地方與下層協定的結合將其他可能影響的參數列入考量 (queue size 、 RTT) 以提升效能。

61

Q & A

謝謝！

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

Documents