P2P

適用於P2P檔案共享系統

傳輸協定之設計



政治大學資訊科學系

行動計算與網路通訊實驗室Ⅱ

指導教授：連耀南

研究生：許弘奇



1

Outline

 Introduction

 Related Work

 Design of Protocol

 Packet Loss Recovery

 Segment Size Determination

 Adaptive UDP Mechanism

 Performance Evaluation

 Conclusion

2

Introduction

 Peer-to-Peer (P2P)架構：

 P2P架構讓社群內的使用者收集分散在網路各處之

資源。

 參與者可得到原本無法負擔之運算資源。

 P2P 檔案共享系統：

 最廣為風行的P2P系統，如Napster、BitTorrent。

 P2P 檔案共享系統，參與的角色分別為：

 資料提供者 (Data Source Provider)。

 資料下載者 (Downloader)。



3

Centralized Model &

Decentralized Model

 P2P 檔案共享系統架構分為：

 集中式，如Napster-like Model。

 分散式，如BitTorrent-like Model。









Centralized Model Decentralized Model

4

P2P檔案共享系統之

分散式架構又可細分

 結構化：

 下載檔案之來源點和網路拓樸位置有關。

 非結構化：

 下載檔案之來源點未將網路拓樸納入考量。









5

BitTorrent

 BitTorrent之優點：

 目前最為風行。

 可擴張性極佳(scalability)。

 以BitTorrent-like Model為代表，作為我們的研

究對象。









6

BitTorrent 運作時之參與角色

 檔案提供者(Seeder)

 檔案下載者(Downloader)

 Tracker

 扮演中央控管角色協助下載者尋找所需之檔案片段。

 網頁伺服器(Web server)

 公佈並提供檔案之相關資訊。









7

BitTorrent 特色

 P2P檔案共享協定。

 採分散式且非結構化之模式。

 檔案提供者將檔案切割成多個檔案片段。

 下載者會開放已完成之檔案片段，供其他下載者抓取。

 下載檔案時，可從不同之地點下載。

 同一檔案片段同時有許多地點可供下載。

 下載者可從不同地點下載同一檔案片段。

 參與者愈多時，其下載者之下載速度不會大幅降低。









8

BitTorrent 運作機制

 檔案提供：

 提供者Seeder利用BitTorrent

程式對檔案建立 .torrent 檔，

過程中需指定「Tracker」的

URL。

 檔案公佈：

 檔案提供者需將 .torrent 檔

公佈至某網頁。

 .torrent除了Tracker URL位

置之外，亦含被下載檔案之

檔名、檔案大小、檔案

Signature等訊息。

9

BitTorrent 運作機制









 檔案下載：

 下載前，先至網頁抓取 .torrent 檔， 用BitTorrent程式開啟

此.torrent檔，才可下載檔案。

 檔案下載時，系統會經由「Tracker」尋找所需之檔案片段。

10

BitTorrent 運作機制

 BitTorrent運作之檔案基本單位：

 Piece(Fragment)：檔案片段，大小為1/4 Mbytes。

 Sub-piece(Sub-fragment)：為利用Pipeline方式提

昇Piece傳輸速度之單位。大小為16 Kbytes。

 傳輸協定：採用TCP傳輸協定。









11

TCP的特色

 傳輸層協定(Transport layer protocol)。

 端對端(end-to-end):

 一個傳送端，一個接收端。

 資料傳輸前需建立連線(connection-oriented)。

 Positive ACK：

 接收端收到正確資料須回傳ACK。

 ACK驅動傳送端送出新的封包(self-clocking)。

 保證資料完整及保持原序(data integrity, in-order)。

 流量控制(flow controlled):

 傳送端之資料速率不超過接收端之接收能力。

 傳輸速率由擁塞窗框(congestion window)所控制。

12

TCP 擁塞控管機制

 利用Window Size調節資料傳輸速率。

 以封包遺失或逾時當作網路擁塞的指標。

 資料傳輸中若有封包遺失或逾時，TCP就會啟

動擁塞控制機制快速降低資料傳輸速率。









13

TCP擁塞控管機制

Slow Start

Congestion

Avoidance



threshold









3 duplicate ACKs

time out





(RTT)



 Slow Start (CWND Threshold)

 AIMD (Additive Increase Multiplicative Decrease) 14

P2P檔案共享系統的效能缺陷

 經驗中發現，上行頻寬窄、下行頻寬大的非對

稱網路(如ADSL)之下，BitTorrent-like Model

之傳輸速度不佳。

 下載者之下行頻寬大，使用率卻很低。下載者

無法完全使用下載頻寬。

200



180

Time (sec)









160 TCP Reno

TCP Vegas

140

Adaptive UDP

120



100

2 4 6 8

Downlink Bandwidth (Mbps)





15

P2P檔案共享系統效能問題分析

 Fractional Upward Bandwidth (FUB) ：

 一檔案片段被多個下載者同時下載。

 多個上傳訊務流要共用一個狹窄上行頻寬。

 Blockage of ACK (BoA) ：

 TCP協定下，接收端收到資料後，須回傳ACK。

 BitTorrent中之資料接收者，亦為資料上傳者。

 狹窄之上行頻寬擁塞，ACK無法順利回傳。

 ACK在佇列中逾時後，傳送端啟動擁塞控管機制，

降低資料傳送速度。

16

P2P檔案共享系統效能問題分析

 檔案片段樹(Fragment Tree) ：

 以檔案片段Seed為樹根(Root)。

 上傳者與下載者形成階層架構。









17

由檔案片段樹觀察到下列結果

 Long Physical Paths：

 檔案片段樹之一鏈結(link) 實際為路徑(path)。

 下載路徑可能很長，假如未考量路徑長短，便會浪

費網路資源。

 下載路徑之間可能有重疊之處，會浪費網路資源。

 Lien (2005)提出，如果能盡量縮短路徑、減少

重覆，必能降低頻寬之浪費。





18

Long Physical Paths









19

Bushy Tree









Bushy Tree Slim Tree

 Bushy Tree：

 太多下載者抓取本身下載完成之檔案片段。

 導致FUB與BoA的問題。

 Lien (2005)提出可將之改成分支度較小的Slim Tree，

控制每個參與者分享資料流數目，可減少FUB與BoA

的問題。

20

研究目標

 以上分析有BoA、FUB等問題。

 因為BoA問題現今尚未有完整之解決方案，本

研究之目的，即對BoA效能問題提出可行改進

措施。









21

Outline

 Introduction

 Related Work

 Design of Protocol

 Packet Loss Recovery

 Segment Size Determination

 Adaptive UDP Mechanism

 Performance Evaluation

 Conclusion

22

Related Work

 非對稱網路下之資料傳輸問題

 非對稱網路下TCP問題之回顧

 非對稱網路下TCP問題之解法









23

非對稱網路下TCP問題之回顧

 H. Balakrishnan and V. N. Padmanabhan, “How Network

Asymmetry Affect TCP,” IEEE Communications Magazine, Apr.

2001.

 回顧TCP協定，在非對稱網路下之效能影響並提出解

法。

 對狹窄頻寬進行管理：

 TCP Header Compression、ACK Filtering、ACK

Congestion Control、ACKs First Scheduling等方式

 ACK頻率低，會破壞Self-clocking，補救措施：

 ACK Reconstruction





24

非對稱網路下TCP問題之解法

 Wanjiun Liao and Yi-Der Li, "Improving TCP Performance for

Asymmetric Networks," IEEE ICC, Helsinki, Finland, Jun. 2001.



 TCP Vegas不能分辨在非對稱網路之下，因傳

輸方向不同所產生的負面影響，而導致整個效

能大為降低。

 提出一個新的TCP Formosa協定。

 Cumulative ACK的機制

 減少ACK的數量。

 避免非對稱網路之下因為ACK遺失所導致的影響 。

25

評論

 上述之方法皆是直接修改TCP協定。

 改變TCP茲事體大，協定更改幅度太大，影響

層面廣，不易被接受。

 現有之使用者不易為了解決非對稱網路產生之

問題即採用一個新版的TCP協定。









26

Outline

 Introduction

 Related Work

 Design of Protocol

 Packet Loss Recovery

 Segment Size Determination

 Adaptive UDP Mechanism

 Performance Evaluation

 Conclusion

27

解決BoA問題的方法

 方案一：增加TCP ACK Timeout時間。

 導致TCP對真正網路擁塞之反應時間拉長。

 不能即時處理網路擁塞。

 方案二：TCP之接受端重覆傳送ACK。

 增加ACK存活率，但會在非對稱網路狹窄的上行端

增加ACK訊務量。

 此法對TCP更改幅度太大。

 方案三：以UDP為基礎的方式(UDP-Based

Approach)解決。

28

我們採用UDP的方法

 使用UDP傳送資料，不必對接收到的封包回送

ACK，可避免BoA問題。

 UDP協定有兩個問題：

 無法確保資料的完整性。

 無法自動決定資料傳送速率。

 在應用層(Application Layer)加上相關機制解

決。





29

我們提出的協定之特色

 此協定以UDP協定為基礎，並加入下列機制：

 確保資料完整性之機制。

 自動決定資料傳送速率之機制。

 此協定之採用者：

 BitTorrent架構下之參與者。

 傳送端與接收端(sender & receiver)皆需採用。









30

我們提出的協定之特色

 本協定必須考慮下列的問題：

 避免因封包錯誤導致之重傳。

 提供自動重建遺失之封包。

 計算基本傳輸單位之大小。

 量測最適可用頻寬，決定傳送速率。









31

32

效能目標

 儘量降低重傳次數。

 儘量利用可利用之網路頻寬，提高每個下載者

的下載速度。









33

提昇效能之設計

 Packet Loss Recovery (自動重建遺失之封包)：

 避免封包遺失而重傳。

 Segment Size Determination (基本傳送單位

之計算)：

 計算檔案片段中，最佳的基本傳輸單位大小

 要保護封包，亦要降低overhead。

 Adaptive UDP Mechanism (調節式UDP機制)：

 應用層加上自動調整傳輸速率機制。



34

Fragment Structure









35

Packet Loss Recovery

 每n個封包為一群，加一個同位封包(Parity Packet) ，稱

為Segment。

 同位封包：Segment之資料封包經由同位計算後所產生。









36

Packet Loss Recovery

 同位封包之功用：

 Segment任一封包遺失，可用同位封包救回。

 Segment中若有兩個以上封包遺失，同位封包將無

法彌補，則資料必須重傳。

 重傳之單位：

 以Fragment為單位，重傳時須負擔較高的重傳成

本。

 以Segment為單位，減輕重傳之成本。





37

Packet Loss Recovery 示意圖









38

Packet Loss Recovery Issue

 Segment長短影響協定之效能：

 Segment較短時，錯誤更正能力較強，但Overhead

較大。

 Segment較長時，錯誤更正能力較弱，但Overhead

較小。









39

Segment Size Determination

 因Segment長短會影響協定效能。

 設計一計算最佳Segment大小之法。

 其中，每一封包之封包遺失率皆同為γ。



符 號 意義

m 一檔案片段(fragment)中之封包數

γ 封包遺失率, 0<=γ<=1

n 一segment中之封包數



40

Segment Size Determination

m

 一個Fragment可分為 Segment。

n

 一個Segment中，x 個封包遺失的機率：

 n  1 x

bin( x | n  1,  )     (1   )( n1 x )

 x 

 一個Segment傳送成功的機率：

bin(0 | n  1,  )  bin(1| n  1,  )

 反之，一個Segment傳送失敗之機率為：

p  1  bin(0 | n  1,  )  bin(1| n  1,  ) 

41

Segment Size Determination

 額外成本

 一個Segment中需增加一個同位封包，成本為1

 當一個Segment傳送失敗時，仍要再重傳一次，其

重傳成本為 n  1

 懲罰函數(Penalty Function)：

m

Penalty (n | m,  )    1  (n  1) p  2(n  1) p 2  3(n  1) p 3 

 



n

 m   (n  1) p 

 Penalty (n | m,  )    1  

 n   1  p  

2

 

 簡化：

m  (n  1) p   1 (n  1) p 

 Penalty (n | m,  )  1    m  

n  1  p 2   n n 1  p 2 

    42

Segment Size Determination

 當懲罰函數最小時，可得最佳Segment封包數。



d d  1 (n  1) p 

Penalty(n | m,  )  m   0

dn dn  n n 1  p 2 

 





d d  1 (n  1) p 

 Penalty(n |  )    0

dn dn  n n 1  p 2 

 







 給定一γ值即解得一個n值。

43

Adaptive UDP Mechanism

 UDP協定沒有調整傳送速率之機制。

 必須在應用層加入自動調整速率之機制。

 影響資料傳送速率之決定因素：瓶頸鏈結之頻

寬。

 傳送端如何獲得瓶頸鏈結之可用頻寬？

 如在傳送者上行端

 假設使用者已知上行端之實際可用頻寬。

 如在核心網路內部

 需利用探測封包(Probing Packet)的方式，幫助瞭解網

路內部瓶頸頻寬(bottleneck bandwidth)的狀況。

44

UDP with Probing Packets









 傳送端定期發送探測封包量測網路狀態，根據其變化

來調整合理傳送速率。

 接收端在ACK裡加入此項資訊。

 傳送端使用此資訊來調整合理傳送速率。

 目標：降低頻寬浪費或網路擁塞之機率。

45

Packet Dispersion







 C. Dovrolis et. al. ,"Packet-Dispersion Techniques and a Capacity-

Estimation Methodology," IEEE/ACM Transactions On Networking, VOL. 12,

No. 6, Dec 2004.

 緊鄰兩個封包通過瓶頸鏈結時，其封包距離有散開

(Dispersion)之現象，此散開可當做瓶頸可用頻寬之估計

依據，此法稱為Packet Dispersion法。

 利用此Packet Dispersion估計目前網路內部瓶頸的頻

寬。

46

Adjusting Coefficient α





Packet _ Size(bytes)

Estimated _ Bandwidth(bytes / sec)   

Average _ Dispersion _ Time(sec)



 為避免估計偏差(bias)對協定造成負面影響，以一校正係

數α(Adjusting Coefficient α)修正估計結果。

 我們所測得之可用頻寬為調整資料傳送速度之一參考指標，

其調整方式，可參考Yung-Ping Chung and Yao-Nan Lien,

"Design of TCP Congestion Control Techniques by Router-assisted

Approach," Sep. 2005。

47

Outline

 Introduction

 Related Work

 Design of Protocol

 Packet Loss Recovery

 Segment Size Determination

 Adaptive UDP Mechanism

 Performance Evaluation

 Conclusion

48

參數估算與效能評估

 模擬工具：

 模擬環境為Cygwin下之ns 2.28版。

 參數估算：

 計算最佳Segment數。

 用實驗估算調節式UDP機制之校正參數α值。

 效能評估：

 UDP-Based Approach與其他傳輸協定之效能比較。





49

Segment Size計算

 實驗目標：給定特定的網路環境，將懲罰函數(Penalty

Function)最小化以找出最佳Segment Size。





參 數 數 值 範 圍

l 1000 bytes/packet

m 263 packets/fragment

l × m = 1/4 MB

γ 0.5% ~ 2%



50

Segment Size計算結果

(γ=0.005, 0.01, 0.015, 0.02)









51

Segment Size計算之敏感度分析









 不同網路封包遺失率下，求得Segment Size變化情形。

 封包遺失率很低時，不太會發生封包遺失，求得的Segment Size比較大。

 封包遺失率提高時，封包遺失就容易發生，求得的Segment Size就較小。

52

Adaptive UDP Mechanism

α值參數估算

 實驗目標：

 利用Packet-Dispersion 估計可用頻寬，

 利用實驗找出適當之校正參數α值供他人參考。









53

Adaptive UDP Mechanism

α值參數估算實驗設計









 魚骨狀之網路架構。

 中介鏈結上有中介訊務流經其中。

 調整此魚骨拓樸之長度，並且控制實際可用頻寬之下，求取

參考用之α值。

54

Adaptive UDP Mechanism

α值參數估算實驗參數





參 數 數 值

中介鏈結數 1,3,5,7,9

可用頻寬 1～10 Mbps。









55

α值參數估算之實驗結果

(中介鏈結數=1)









 此例計算得到之α=0.897。

56

α值參數估算之實驗結果

(中介鏈結數=3)









 此例計算得到之α=0.962。

57

α值參數估算之實驗結果

(中介鏈結數=5)









 此例計算得到之α=0.944。

58

α值參數估算之實驗結果

(中介鏈結數=7)









 此例計算得到之α=0.958。

59

α值參數估算之實驗結果

(中介鏈結數=9)









 此例計算得到之α=0.885。

60

中介鏈結數之變化與校正參數α之

間的關係









 中介鏈結數變化與校正參數α之間的關係，發現α值之變化相當平穩。

 中介鏈結數之大小對α值的影響不大。

 得到最後估計之α值為0.93。

61

UDP-Based Approach與其他傳輸協定

之效能比較



 實驗目標：

 設計一個網路上發生FUB與BoA之網路場景，

 各種不同的傳輸協定進行效能分析與比較。

 實驗設計：

 UDP-Based Approach為實驗組。

 TCP-Reno、TCP-Vegas為對照組。

 核心網路(Core Network)中有充沛頻寬，雙向有

1Gbps頻寬，

 接取網路為非對稱網路。

62

UDP-Based Approach與其他傳輸協定

效能比較之網路拓樸

X Y









X Y



 核心網路上有R1、R2兩個路由器(Router)

 非對稱鏈結所接取的的機器有X1～X5及Y1共六台：

 X1～X5同時會至Y1下載資料。

 Y1亦有5個Session同時至X1～X5下載資料。

 在Y1至R2的上行鏈結會發生FUB與BoA的問題。



63

UDP-Based Approach與其他傳輸協定

效能比較之實驗參數







參 數 數 值

傳輸協定 TCP-Reno、TCP-Vegas、

UDP-Based Approach

檔案片段大小 1/4MB



核心網路頻寬 1Gbps



接取網路上下行頻寬 (64Kbps, 2Mbps)、(64Kbps, 4Mbps)、

(64Kbps, 6Mbps)、(64Kbps, 8Mbps)

核心網路封包遺失率γ 0%, 0.1%, 0.5%, 1%, 5%, 10%



64

傳輸協定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0)

X Y X Y

500

Frag. Transport Time (sec)









400



300 TCP Reno

TCP Vegas

200

Adaptive UDP

100



0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 164.8秒。(Lost ACK: 41)

 TCP Vegas 每個Session平均： 188秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 110.7秒。 (重傳次數: 0)

65

傳輸協定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.001)

700

X Y X Y

Frag. Transport Time (sec)





600

500

TCP Reno

400

TCP Vegas

300

Adaptive UDP

200

100

0

1 2 3 4 5 6 7 8 9 10

Session



 TCP Reno 每個Session平均： 201.5秒。 (Lost ACK: 66)

 TCP Vegas 每個Session平均： 187.8秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 112秒。 (重傳次數: 0)

66

傳輸協定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.005)



300

X Y X Y

Frag. Transport Time (sec)









250

200 TCP Reno

150 TCP Vegas

100 Adaptive UDP

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 150.1秒。 (Lost ACK: 39)

 TCP Vegas 每個Session平均： 159.2秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 115秒。 (重傳次數: 4)

67

傳輸協定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.01)



X Y X Y

400

Frag. Transport Time (sec)









350

300

250 TCP Reno

200 TCP Vegas

150 Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 150.2秒。 (Lost ACK: 34)

 TCP Vegas 每個Session平均： 164秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 119.6秒。 (重傳次數: 15)

68

傳輸協定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.05)



350

X Y X Y

Frag. Transport Time (sec)







300

250

TCP Reno

200

TCP Vegas

150

Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 208.7秒。 (Lost ACK: 1)

 TCP Vegas 每個Session平均： 196秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 131.3秒。 (重傳次數: 311)

69

傳輸協定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0. 1)

X Y X Y

400

Frag. Transport Time (sec)







350

300

250 TCP Reno

200 TCP Vegas

150 Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session



 TCP Reno 每個Session平均： 231.7秒。 (Lost ACK: 0)

 TCP Vegas 每個Session平均： 213.1秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 150.2秒。 (重傳次數: 480)

70

傳輸協定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0)



X Y X Y

400

Frag. Transport Time (sec)







350

300

250 TCP Reno

200 TCP Vegas

150 Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 174.4秒。 (Lost ACK: 40)

 TCP Vegas 每個Session平均： 188秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 110.7秒。 (重傳次數: 0)

71

傳輸協定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0.001)



350

X Y X Y

Frag. Transport Time (sec)







300

250

TCP Reno

200

TCP Vegas

150

Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session



 TCP Reno 每個Session平均： 151.1秒。 (Lost ACK: 39)

 TCP Vegas 每個Session平均： 187.8秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 112秒。 (重傳次數: 0)

72

傳輸協定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0.005)



300

X Y X Y

Frag. Transport Time (sec)









250

200 TCP Reno

150 TCP Vegas

100 Adaptive UDP

50

0

1 2 3 4 5 6 7 8 9 10

Session



 TCP Reno 每個Session平均： 143.3秒。 (Lost ACK: 45)

 TCP Vegas 每個Session平均： 148秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 115秒。 (重傳次數: 4)

73

傳輸協定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0.01)



300

X Y X Y

Frag. Transport Time (sec)









250

200 TCP Reno

150 TCP Vegas

100 Adaptive UDP

50

0

1 2 3 4 5 6 7 8 9 10

Session



 TCP Reno 每個Session平均： 142.9秒。 (Lost ACK: 24)

 TCP Vegas 每個Session平均： 164秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 119.6秒。 (重傳次數: 15)

74

傳輸協定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0.05)



300

X Y X Y

Frag. Transport Time (sec)









250

200 TCP Reno

150 TCP Vegas

100 Adaptive UDP

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 201.5秒。 (Lost ACK: 1)

 TCP Vegas 每個Session平均： 196秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 131.3秒。 (重傳次數: 311)

75

傳輸協定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0. 1)



X Y X Y

400

Frag. Transport Time (sec)







350

300

250 TCP Reno

200 TCP Vegas

150 Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 222.2秒。 (Lost ACK: 0)

 TCP Vegas 每個Session平均： 222.1秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 150.2秒。 (重傳次數: 480)

76

傳輸協定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0)



X Y X Y

450

Frag. Transport Time (sec)







400

350

300 TCP Reno

250

200 TCP Vegas

150 Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 177.9秒。 (Lost ACK: 40)

 TCP Vegas 每個Session平均： 188秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 110.7秒。 (重傳次數: 0)

77

傳輸協定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0.001)



X Y X Y

450

Frag. Transport Time (sec)







400

350

300 TCP Reno

250

200 TCP Vegas

150 Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 166.9秒。 (Lost ACK: 39)

 TCP Vegas 每個Session平均： 187.8秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 112秒。 (重傳次數: 0)

78

傳輸協定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0.005)



X Y X Y

350

Frag. Transport Time (sec)







300

250

TCP Reno

200

TCP Vegas

150

Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 148.5秒。 (Lost ACK: 43)

 TCP Vegas 每個Session平均： 148秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 115秒。 (重傳次數: 4)

79

傳輸協定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0.01)



X Y X Y

350

Frag. Transport Time (sec)







300

250

TCP Reno

200

TCP Vegas

150

Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 141.2秒。 (Lost ACK: 24)

 TCP Vegas 每個Session平均： 164秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 119.6秒。 (重傳次數: 15)

80

傳輸協定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0.05)



X Y X Y

300

Frag. Transport Time (sec)







250

200 TCP Reno

150 TCP Vegas

100 Adaptive UDP

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 201.5秒。 (Lost ACK: 1)

 TCP Vegas 每個Session平均： 192.3秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 131.3秒。 (重傳次數: 311)

81

傳輸協定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0. 1)

X Y X Y

450

Frag. Transport Time (sec)





400

350

300 TCP Reno

250

200 TCP Vegas

150 Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 211.5秒。 (Lost ACK: 0)

 TCP Vegas 每個Session平均： 197.4秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 150.2秒。 (重傳次數: 480)

82

傳輸協定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0)



X Y X Y

400

Frag. Transport Time (sec)







350

300

250 TCP Reno

200 TCP Vegas

150 Adaptive UDP

100

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 158.5秒。 (Lost ACK: 41)

 TCP Vegas 每個Session平均： 188秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 110.7秒。 (重傳次數: 0)

83

傳輸協定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0.001)



X Y X Y

500

Frag. Transport Time (sec)









400



300 TCP Reno

TCP Vegas

200

Adaptive UDP

100



0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 171.3秒。 (Lost ACK: 56)

 TCP Vegas 每個Session平均： 187.8秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 112秒。 (重傳次數: 0)

84

傳輸協定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0.005)

X Y X Y

300

Frag. Transport Time (sec)







250

200 TCP Reno

150 TCP Vegas

100 Adaptive UDP

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 149.3秒。 (Lost ACK: 46)

 TCP Vegas 每個Session平均： 148秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 115秒。 (重傳次數: 4)

85

傳輸協定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0.01)

X Y X Y

300

Frag. Transport Time (sec)









250

200 TCP Reno

150 TCP Vegas

100 Adaptive UDP

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 138.1秒。 (Lost ACK: 23)

 TCP Vegas 每個Session平均： 164秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 119.6秒。 (重傳次數: 15)

86

傳輸協定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0.05)



X Y X Y

300

Frag. Transport Time (sec)







250

200 TCP Reno

150 TCP Vegas

100 Adaptive UDP

50

0

1 2 3 4 5 6 7 8 9 10

Session

 TCP Reno 每個Session平均： 201.5秒。 (Lost ACK: 1)

 TCP Vegas 每個Session平均： 189.9秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 131.3秒。 (重傳次數: 311)

87

傳輸協定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0. 1)



600

X Y X Y

Frag. Transport Time (sec)









500

400 TCP Reno

300 TCP Vegas

200 Adaptive UDP

100

0

1 2 3 4 5 6 7 8 9 10

Session



 TCP Reno 每個Session平均： 211.4秒。 (Lost ACK: 0)

 TCP Vegas 每個Session平均： 242.7秒。 (Lost ACK: 0)

 Adaptive UDP 每個Session 平均： 150.2秒。 (重傳次數: 480)

88

傳輸協定效能比較之實驗結果

(總平均)

Meas Time (sec)





200



150



100



50



0

TCP Reno TCP Vegas Adaptive UDP





 Adaptive UDP的資料傳輸效能明顯的優於TCP Reno

及TCP Vegas。

 Reno、Vegas、UDP平均分別為175.8, 183.8, 123.1秒。



89

傳輸協定效能比較之實驗

不同下行頻寬之敏感度分析



200



180

Time (sec)









160 TCP Reno

TCP Vegas

140

Adaptive UDP

120



100

2 4 6 8

Downlink Bandwidth (Mbps)





 固定上行頻寬，各個協定在不同的下行頻寬之下，下

載完成時間變化皆不大。

 增大下行頻寬並不能對BitTorrent效能提昇有所幫助。 90

傳輸協定效能比較之實驗

不同封包遺失率之敏感度分析

240

220

200

Time (sec)







TCP Reno

180

TCP Vegas

160

Adaptive UDP

140

120

100

0 0 0.01 0.01 0.05 0.1

Packet Loss Rate in Core

Network





 各個協定在增加封包遺失率時，其下載完成時間有往上昇之趨勢。

 TCP Reno與TCP Vegas之訊務在Y之上行鏈結相當擁塞，有些許

Packet Loss有助於效能之提昇。

91

傳輸協定效能比較之實驗結果

 TCP Reno的效能表現相當不好

 資料及ACK封包因狹窄的上行頻寬擁塞，發生逾時

或被丟棄，導致傳送端重傳資料。

 FUB與BoA引起之意外，導致TCP Congestion

Window縮小，最後造成TCP Reno效能不彰。

 TCP Vegas無法分辨非對稱網路之方向性

 兩個方向之速率調節後大致相等。

 兩個方向Session之完成時間相當接近。

 未充分使用網路資源。

92

Outline

 Introduction

 Related Work

 Design of Protocol

 Packet Loss Recovery

 Segment Size Determination

 Adaptive UDP Mechanism

 Performance Evaluation

 Conclusion

93

Conclusion

 在文章中，我們對P2P檔案共享系統在非對稱

網路下進行分析。

 設計一傳輸層的網路協定進行效能改善。

 協定設計過程中，建立參數決定之數學模型以

及利用模擬進行效能分析。

 我們的傳輸協定效能表現優於TCP Reno、

TCP Vegas。

 希望此網路協定有效提昇P2P檔案共享系統之

運作效能。

94