最新適用於P2P檔案共享系統(tǒng)傳輸協(xié)定之設(shè)計

1、1適用於適用於p2p檔案共享系統(tǒng)檔案共享系統(tǒng)傳輸協(xié)定之設(shè)計傳輸協(xié)定之設(shè)計政治大學(xué)資訊科學(xué)系行動計算與網(wǎng)路通訊實驗室指導(dǎo)教授：連耀南研究生：許弘奇2outlinelintroductionlrelated workldesign of protocollpacket loss recoverylsegment size determinationladaptive udp mechanismlperformance evaluationlconclusion3introductionlpeer-to-peer (p2p)架構(gòu)：lp2p架構(gòu)讓社群內(nèi)的使用者收集分散在網(wǎng)路各處之資源。l參與者可得到原

2、本無法負(fù)擔(dān)之運算資源。lp2p 檔案共享系統(tǒng)：l最廣為風(fēng)行的p2p系統(tǒng)，如napster、bittorrent。lp2p 檔案共享系統(tǒng)，參與的角色分別為：l資料提供者 (data source provider)。l資料下載者 (downloader)。4centralized model & decentralized modellp2p 檔案共享系統(tǒng)架構(gòu)分為：l集中式，如napster-like model。l分散式，如bittorrent-like model。centralized modeldecentralized model5p2p檔案共享系統(tǒng)之檔案共享系統(tǒng)之分散式架構(gòu)又

3、可細(xì)分分散式架構(gòu)又可細(xì)分l結(jié)構(gòu)化：l下載檔案之來源點和網(wǎng)路拓樸位置有關(guān)。l非結(jié)構(gòu)化：l下載檔案之來源點未將網(wǎng)路拓樸納入考量。6bittorrentlbittorrent之優(yōu)點：l目前最為風(fēng)行。l可擴(kuò)張性極佳(scalability)。l以bittorrent-like model為代表，作為我們的研究對象。7bittorrent 運作時之參與角色運作時之參與角色l檔案提供者(seeder)l檔案下載者(downloader)ltrackerl扮演中央控管角色協(xié)助下載者尋找所需之檔案片段。l網(wǎng)頁伺服器(web server)l公佈並提供檔案之相關(guān)資訊。8bittorrent 特色特色lp2p檔案

4、共享協(xié)定。l採分散式且非結(jié)構(gòu)化之模式。l檔案提供者將檔案切割成多個檔案片段。l下載者會開放已完成之檔案片段，供其他下載者抓取。l下載檔案時，可從不同之地點下載。l同一檔案片段同時有許多地點可供下載。l下載者可從不同地點下載同一檔案片段。l參與者愈多時，其下載者之下載速度不會大幅降低。9bittorrent 運作機(jī)制運作機(jī)制l檔案提供：l提供者seeder利用bittorrent程式對檔案建立 .torrent 檔，過程中需指定tracker的url。l檔案公佈：l檔案提供者需將 .torrent 檔公佈至某網(wǎng)頁。l.torrent除了tracker url位置之外，亦含被下載檔案之檔名、檔案大

5、小、檔案signature等訊息。10bittorrent 運作機(jī)制運作機(jī)制l檔案下載：l下載前，先至網(wǎng)頁抓取 .torrent 檔， 用bittorrent程式開啟此.torrent檔，才可下載檔案。l檔案下載時，系統(tǒng)會經(jīng)由tracker尋找所需之檔案片段。11bittorrent 運作機(jī)制運作機(jī)制lbittorrent運作之檔案基本單位：lpiece(fragment)：檔案片段，大小為1/4 mbytes。lsub-piece(sub-fragment)：為利用pipeline方式提昇piece傳輸速度之單位。大小為16 kbytes。l傳輸協(xié)定：採用tcp傳輸協(xié)定。12tcp的特色的特

6、色l傳輸層協(xié)定(transport layer protocol)。l端對端(end-to-end):l一個傳送端，一個接收端。l資料傳輸前需建立連線(connection-oriented)。lpositive ack：l接收端收到正確資料須回傳ack。lack驅(qū)動傳送端送出新的封包(self-clocking)。l保證資料完整及保持原序(data integrity, in-order)。l流量控制(flow controlled):l傳送端之資料速率不超過接收端之接收能力。l傳輸速率由擁塞窗框(congestion window)所控制。13tcp 擁塞控管機(jī)制擁塞控管機(jī)制l利用wind

7、ow size調(diào)節(jié)資料傳輸速率。l以封包遺失或逾時當(dāng)作網(wǎng)路擁塞的指標(biāo)。l資料傳輸中若有封包遺失或逾時，tcp就會啟動擁塞控制機(jī)制快速降低資料傳輸速率。14tcp擁塞控管機(jī)制擁塞控管機(jī)制lslow start (cwnd threshold)laimd (additive increase multiplicative decrease)slow starttime out3 duplicate ackscongestion avoidance(rtt)threshold15p2p檔案共享系統(tǒng)的效能缺陷檔案共享系統(tǒng)的效能缺陷l經(jīng)驗中發(fā)現(xiàn)，上行頻寬窄、下行頻寬大的非對稱網(wǎng)路(如adsl)之下，bi

8、ttorrent-like model之傳輸速度不佳。l下載者之下行頻寬大，使用率卻很低。下載者無法完全使用下載頻寬。1001201401601802002468downlink bandwidth (mbps)time (sec)tcp renotcp vegasadaptive udp16p2p檔案共享系統(tǒng)效能問題分析檔案共享系統(tǒng)效能問題分析lfractional upward bandwidth (fub) ：l一檔案片段被多個下載者同時下載。l多個上傳訊務(wù)流要共用一個狹窄上行頻寬。lblockage of ack (boa) ：ltcp協(xié)定下，接收端收到資料後，須回傳ack。lbitt

9、orrent中之資料接收者，亦為資料上傳者。l狹窄之上行頻寬擁塞，ack無法順利回傳。lack在佇列中逾時後，傳送端啟動擁塞控管機(jī)制，降低資料傳送速度。17p2p檔案共享系統(tǒng)效能問題分析檔案共享系統(tǒng)效能問題分析l檔案片段樹(fragment tree) ：l以檔案片段seed為樹根(root)。l上傳者與下載者形成階層架構(gòu)。18由由檔案片段樹檔案片段樹觀察到下列結(jié)果觀察到下列結(jié)果llong physical paths：l檔案片段樹之一鏈結(jié)(link) 實際為路徑(path)。l下載路徑可能很長，假如未考量路徑長短，便會浪費網(wǎng)路資源。l下載路徑之間可能有重疊之處，會浪費網(wǎng)路資源。llien (

10、2005)提出，如果能盡量縮短路徑、減少重覆，必能降低頻寬之浪費。19long physical paths20bushy treelbushy tree：l太多下載者抓取本身下載完成之檔案片段。l導(dǎo)致fub與boa的問題。llien (2005)提出可將之改成分支度較小的slim tree，控制每個參與者分享資料流數(shù)目，可減少fub與boa的問題。bushy treeslim tree21研究目標(biāo)研究目標(biāo)l以上分析有boa、fub等問題。l因為boa問題現(xiàn)今尚未有完整之解決方案，本研究之目的，即對boa效能問題提出可行改進(jìn)措施。22outlinelintroductionlrelated w

11、orkldesign of protocollpacket loss recoverylsegment size determinationladaptive udp mechanismlperformance evaluationlconclusion23related workl非對稱網(wǎng)路下之資料傳輸問題l非對稱網(wǎng)路下tcp問題之回顧l非對稱網(wǎng)路下tcp問題之解法24非對稱網(wǎng)路下非對稱網(wǎng)路下tcp問題之回顧問題之回顧lh. balakrishnan and v. n. padmanabhan, “how network asymmetry affect tcp,” ieee communi

12、cations magazine, apr. 2001.l回顧tcp協(xié)定，在非對稱網(wǎng)路下之效能影響並提出解法。l對狹窄頻寬進(jìn)行管理：ltcp header compression、ack filtering、ack congestion control、acks first scheduling等方式lack頻率低，會破壞self-clocking，補(bǔ)救措施：lack reconstruction25非對稱網(wǎng)路下非對稱網(wǎng)路下tcp問題之解法問題之解法lwanjiun liao and yi-der li, improving tcp performance for asymmetric net

13、works, ieee icc, helsinki, finland, jun. 2001.ltcp vegas不能分辨在非對稱網(wǎng)路之下，因傳輸方向不同所產(chǎn)生的負(fù)面影響，而導(dǎo)致整個效能大為降低。l提出一個新的tcp formosa協(xié)定。lcumulative ack的機(jī)制l減少ack的數(shù)量。l避免非對稱網(wǎng)路之下因為ack遺失所導(dǎo)致的影響 。26評論評論l上述之方法皆是直接修改tcp協(xié)定。l改變tcp茲事體大，協(xié)定更改幅度太大，影響層面廣，不易被接受。l現(xiàn)有之使用者不易為了解決非對稱網(wǎng)路產(chǎn)生之問題即採用一個新版的tcp協(xié)定。27outlinelintroductionlrelated workl

14、design of protocollpacket loss recoverylsegment size determinationladaptive udp mechanismlperformance evaluationlconclusion28解決解決boa問題的方法問題的方法l方案一：增加tcp ack timeout時間。l導(dǎo)致tcp對真正網(wǎng)路擁塞之反應(yīng)時間拉長。l不能即時處理網(wǎng)路擁塞。l方案二：tcp之接受端重覆傳送ack。l增加ack存活率，但會在非對稱網(wǎng)路狹窄的上行端增加ack訊務(wù)量。l此法對tcp更改幅度太大。l方案三：以udp為基礎(chǔ)的方式(udp-based approac

15、h)解決。29我們採用我們採用udp的方法的方法l使用udp傳送資料，不必對接收到的封包回送ack，可避免boa問題。ludp協(xié)定有兩個問題：l無法確保資料的完整性。l無法自動決定資料傳送速率。l在應(yīng)用層(application layer)加上相關(guān)機(jī)制解決。30我們提出的協(xié)定之特色我們提出的協(xié)定之特色l此協(xié)定以udp協(xié)定為基礎(chǔ)，並加入下列機(jī)制：l確保資料完整性之機(jī)制。l自動決定資料傳送速率之機(jī)制。l此協(xié)定之採用者：lbittorrent架構(gòu)下之參與者。l傳送端與接收端(sender & receiver)皆需採用。31我們提出的協(xié)定之特色我們提出的協(xié)定之特色l本協(xié)定必須考慮下列的問題

16、：l避免因封包錯誤導(dǎo)致之重傳。l提供自動重建遺失之封包。l計算基本傳輸單位之大小。l量測最適可用頻寬，決定傳送速率。3233效能目標(biāo)效能目標(biāo)l儘量降低重傳次數(shù)。l儘量利用可利用之網(wǎng)路頻寬，提高每個下載者的下載速度。34提昇效能之設(shè)計提昇效能之設(shè)計 lpacket loss recovery (自動重建遺失之封包)： l避免封包遺失而重傳。lsegment size determination (基本傳送單位之計算)：l計算檔案片段中，最佳的基本傳輸單位大小l要保護(hù)封包，亦要降低overhead。ladaptive udp mechanism (調(diào)節(jié)式udp機(jī)制)：l應(yīng)用層加上自動調(diào)整傳輸速率機(jī)

17、制。35fragment structure36packet loss recoveryl每n個封包為一群，加一個同位封包(parity packet) ，稱為segment。l同位封包：segment之資料封包經(jīng)由同位計算後所產(chǎn)生。37packet loss recoveryl同位封包之功用：lsegment任一封包遺失，可用同位封包救回。lsegment中若有兩個以上封包遺失，同位封包將無法彌補(bǔ)，則資料必須重傳。l重傳之單位：l以fragment為單位，重傳時須負(fù)擔(dān)較高的重傳成本。l以segment為單位，減輕重傳之成本。38packet loss recovery 示意圖示意圖39pac

18、ket loss recovery issuelsegment長短影響協(xié)定之效能：lsegment較短時，錯誤更正能力較強(qiáng)，但overhead較大。lsegment較長時，錯誤更正能力較弱，但overhead較小。 40segment size determinationl因segment長短會影響協(xié)定效能。l設(shè)計一計算最佳segment大小之法。l其中，每一封包之封包遺失率皆同為。符 號意義m一檔案片段(fragment)中之封包數(shù)封包遺失率, 0=1n一segment中之封包數(shù)41segment size determinationl一個fragment可分為 segment。l一個seg

19、ment中，x 個封包遺失的機(jī)率：l一個segment傳送成功的機(jī)率：l反之，一個segment傳送失敗之機(jī)率為：(1)1( |1, )(1) xnxnbin x nxmn(0|1, )(1|1, )binnbinn1(0|1, )(1|1, )pbinnbinn 42segment size determinationl額外成本l一個segment中需增加一個同位封包，成本為l當(dāng)一個segment傳送失敗時，仍要再重傳一次，其重傳成本為l懲罰函數(shù)(penalty function)：l簡化：1n123( |, )1 (1)2(1)3(1)mpenalty n mnpnpnpn2(1)( |,

20、 )11mnppenalty n mnp2(1)( |, )11mnppenalty n mnp21(1)1npmnnp43segment size determinationl當(dāng)懲罰函數(shù)最小時，可得最佳segment封包數(shù)。l給定一值即解得一個n值。21(1)( |, )01ddnppenalty n mmdndnnnp21(1)( | )01ddnppenalty ndndn nnp44adaptive udp mechanismludp協(xié)定沒有調(diào)整傳送速率之機(jī)制。l必須在應(yīng)用層加入自動調(diào)整速率之機(jī)制。l影響資料傳送速率之決定因素：瓶頸鏈結(jié)之頻寬。l傳送端如何獲得瓶頸鏈結(jié)之可用頻寬？l如在

21、傳送者上行端l假設(shè)使用者已知上行端之實際可用頻寬。l如在核心網(wǎng)路內(nèi)部l需利用探測封包(probing packet)的方式，幫助瞭解網(wǎng)路內(nèi)部瓶頸頻寬(bottleneck bandwidth)的狀況。45udp with probing packetsl傳送端定期發(fā)送探測封包量測網(wǎng)路狀態(tài)，根據(jù)其變化來調(diào)整合理傳送速率。l接收端在ack裡加入此項資訊。l傳送端使用此資訊來調(diào)整合理傳送速率。l目標(biāo)：降低頻寬浪費或網(wǎng)路擁塞之機(jī)率。46packet dispersionlc. dovrolis et. al. ,packet-dispersion techniques and a capacity-e

22、stimation methodology, ieee/acm transactions on networking, vol. 12, no. 6, dec 2004.l緊鄰兩個封包通過瓶頸鏈結(jié)時，其封包距離有散開(dispersion)之現(xiàn)象，此散開可當(dāng)做瓶頸可用頻寬之估計依據(jù)，此法稱為packet dispersion法。l利用此packet dispersion估計目前網(wǎng)路內(nèi)部瓶頸的頻寬。47adjusting coefficient l為避免估計偏差(bias)對協(xié)定造成負(fù)面影響，以一校正係數(shù)(adjusting coefficient )修正估計結(jié)果。l我們所測得之可用頻寬為調(diào)整資

23、料傳送速度之一參考指標(biāo)，其調(diào)整方式，可參考yung-ping chung and yao-nan lien, design of tcp congestion control techniques by router-assisted approach, sep. 2005。_()_(/)_()packet size bytesestimated bandwidth bytes secaverage dispersion time sec 48outlinelintroductionlrelated workldesign of protocollpacket loss recoverylse

24、gment size determinationladaptive udp mechanismlperformance evaluationlconclusion49參數(shù)估算與效能評估參數(shù)估算與效能評估l模擬工具：l模擬環(huán)境為cygwin下之ns 2.28版。l參數(shù)估算：l計算最佳segment數(shù)。l用實驗估算調(diào)節(jié)式udp機(jī)制之校正參數(shù)值。l效能評估：ludp-based approach與其他傳輸協(xié)定之效能比較。50segment size計算計算l實驗?zāi)繕?biāo)：給定特定的網(wǎng)路環(huán)境，將懲罰函數(shù)(penalty function)最小化以找出最佳segment size。參 數(shù)數(shù) 值 範(fàn) 圍l10

25、00 bytes/packetm263 packets/fragment l m = 1/4 mb0.5% 2%51segment size計算結(jié)果計算結(jié)果(=0.005, 0.01, 0.015, 0.02)52segment size計算之敏感度分析計算之敏感度分析l不同網(wǎng)路封包遺失率下，求得segment size變化情形。l封包遺失率很低時，不太會發(fā)生封包遺失，求得的segment size比較大。l封包遺失率提高時，封包遺失就容易發(fā)生，求得的segment size就較小。53adaptive udp mechanism值參數(shù)估算值參數(shù)估算l實驗?zāi)繕?biāo)：l利用packet-disper

26、sion 估計可用頻寬，l利用實驗找出適當(dāng)之校正參數(shù)值供他人參考。54adaptive udp mechanism值參數(shù)估算實驗設(shè)計值參數(shù)估算實驗設(shè)計l魚骨狀之網(wǎng)路架構(gòu)。l中介鏈結(jié)上有中介訊務(wù)流經(jīng)其中。l調(diào)整此魚骨拓樸之長度，並且控制實際可用頻寬之下，求取參考用之值。55adaptive udp mechanism值參數(shù)估算實驗參數(shù)值參數(shù)估算實驗參數(shù)參 數(shù)數(shù) 值中介鏈結(jié)數(shù)1,3,5,7,9可用頻寬110 mbps。56值參數(shù)估算之實驗結(jié)果值參數(shù)估算之實驗結(jié)果(中介鏈結(jié)數(shù)中介鏈結(jié)數(shù)=1)l此例計算得到之=0.897。57值參數(shù)估算之實驗結(jié)果值參數(shù)估算之實驗結(jié)果(中介鏈結(jié)數(shù)中介鏈結(jié)數(shù)=3)l此例計

27、算得到之=0.962。58值參數(shù)估算之實驗結(jié)果值參數(shù)估算之實驗結(jié)果(中介鏈結(jié)數(shù)中介鏈結(jié)數(shù)=5)l此例計算得到之=0.944。59值參數(shù)估算之實驗結(jié)果值參數(shù)估算之實驗結(jié)果(中介鏈結(jié)數(shù)中介鏈結(jié)數(shù)=7)l此例計算得到之=0.958。60值參數(shù)估算之實驗結(jié)果值參數(shù)估算之實驗結(jié)果(中介鏈結(jié)數(shù)中介鏈結(jié)數(shù)=9)l此例計算得到之=0.885。61中介鏈結(jié)數(shù)之變化與校正參數(shù)中介鏈結(jié)數(shù)之變化與校正參數(shù)之之間的關(guān)係間的關(guān)係l中介鏈結(jié)數(shù)變化與校正參數(shù)之間的關(guān)係，發(fā)現(xiàn)值之變化相當(dāng)平穩(wěn)。l中介鏈結(jié)數(shù)之大小對值的影響不大。l得到最後估計之值為0.93。62udp-based approach與其他傳輸協(xié)定與其他傳輸協(xié)定之效

28、能比較之效能比較l實驗?zāi)繕?biāo)：l設(shè)計一個網(wǎng)路上發(fā)生fub與boa之網(wǎng)路場景，l各種不同的傳輸協(xié)定進(jìn)行效能分析與比較。l實驗設(shè)計：ludp-based approach為實驗組。ltcp-reno、tcp-vegas為對照組。l核心網(wǎng)路(core network)中有充沛頻寬，雙向有1gbps頻寬，l接取網(wǎng)路為非對稱網(wǎng)路。63udp-based approach與其他傳輸協(xié)定與其他傳輸協(xié)定效能比較之網(wǎng)路拓樸效能比較之網(wǎng)路拓樸l核心網(wǎng)路上有r1、r2兩個路由器(router)l非對稱鏈結(jié)所接取的的機(jī)器有x1x5及y1共六臺：lx1x5同時會至y1下載資料。ly1亦有5個session同時至x1x5下

29、載資料。l在y1至r2的上行鏈結(jié)會發(fā)生fub與boa的問題。xyyx64udp-based approach與其他傳輸協(xié)定與其他傳輸協(xié)定效能比較之實驗參數(shù)效能比較之實驗參數(shù)參 數(shù)數(shù) 值傳輸協(xié)定 tcp-reno、tcp-vegas、udp-based approach 檔案片段大小1/4mb核心網(wǎng)路頻寬 1gbps接取網(wǎng)路上下行頻寬(64kbps, 2mbps)、(64kbps, 4mbps)、(64kbps, 6mbps)、(64kbps, 8mbps)核心網(wǎng)路封包遺失率 0%, 0.1%, 0.5%, 1%, 5%, 10%65傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行

30、64kbps,下行下行2mbps,=0)ltcp reno 每個session平均： 164.8秒。(lost ack: 41)ltcp vegas 每個session平均： 188秒。 (lost ack: 0)ladaptive udp 每個session 平均： 110.7秒。 (重傳次數(shù): 0)010020030040050012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx66傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行2mbps,=0.00

31、1)ltcp reno 每個session平均： 201.5秒。 (lost ack: 66)ltcp vegas 每個session平均： 187.8秒。 (lost ack: 0)ladaptive udp 每個session 平均： 112秒。 (重傳次數(shù): 0)010020030040050060070012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx67傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行2mbps,=0.005)ltcp reno

32、 每個session平均： 150.1秒。 (lost ack: 39)ltcp vegas 每個session平均： 159.2秒。 (lost ack: 0)ladaptive udp 每個session 平均： 115秒。 (重傳次數(shù): 4)05010015020025030012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx68傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行2mbps,=0.01)ltcp reno 每個session平均： 15

33、0.2秒。 (lost ack: 34)ltcp vegas 每個session平均： 164秒。 (lost ack: 0)ladaptive udp 每個session 平均： 119.6秒。 (重傳次數(shù): 15)05010015020025030035040012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx69傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行2mbps,=0.05)ltcp reno 每個session平均： 208.7秒。 (lo

34、st ack: 1)ltcp vegas 每個session平均： 196秒。 (lost ack: 0)ladaptive udp 每個session 平均： 131.3秒。 (重傳次數(shù): 311)05010015020025030035012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx70傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行2mbps,=0. 1)ltcp reno 每個session平均： 231.7秒。 (lost ack: 0)lt

35、cp vegas 每個session平均： 213.1秒。 (lost ack: 0)ladaptive udp 每個session 平均： 150.2秒。 (重傳次數(shù): 480)05010015020025030035040012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx71傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行4mbps,=0)ltcp reno 每個session平均： 174.4秒。 (lost ack: 40)ltcp vegas

36、每個session平均： 188秒。 (lost ack: 0)ladaptive udp 每個session 平均： 110.7秒。 (重傳次數(shù): 0)05010015020025030035040012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx72傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行4mbps,=0.001)ltcp reno 每個session平均： 151.1秒。 (lost ack: 39)ltcp vegas 每個session

37、平均： 187.8秒。 (lost ack: 0)ladaptive udp 每個session 平均： 112秒。 (重傳次數(shù): 0)05010015020025030035012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx73傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行4mbps,=0.005)ltcp reno 每個session平均： 143.3秒。 (lost ack: 45)ltcp vegas 每個session平均： 148秒。 (l

38、ost ack: 0)ladaptive udp 每個session 平均： 115秒。 (重傳次數(shù): 4)05010015020025030012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx74傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行4mbps,=0.01)ltcp reno 每個session平均： 142.9秒。 (lost ack: 24)ltcp vegas 每個session平均： 164秒。 (lost ack: 0)ladapti

39、ve udp 每個session 平均： 119.6秒。 (重傳次數(shù): 15)05010015020025030012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx75傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行4mbps,=0.05)ltcp reno 每個session平均： 201.5秒。 (lost ack: 1)ltcp vegas 每個session平均： 196秒。 (lost ack: 0)ladaptive udp 每個session

40、 平均： 131.3秒。 (重傳次數(shù): 311)05010015020025030012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx76傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行4mbps,=0. 1)ltcp reno 每個session平均： 222.2秒。 (lost ack: 0)ltcp vegas 每個session平均： 222.1秒。 (lost ack: 0)ladaptive udp 每個session 平均： 150.2秒。

41、(重傳次數(shù): 480)05010015020025030035040012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx77傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行6mbps,=0)ltcp reno 每個session平均： 177.9秒。 (lost ack: 40)ltcp vegas 每個session平均： 188秒。 (lost ack: 0)ladaptive udp 每個session 平均： 110.7秒。 (重傳次數(shù): 0)05

42、010015020025030035040045012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx78傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行6mbps,=0.001)ltcp reno 每個session平均： 166.9秒。 (lost ack: 39)ltcp vegas 每個session平均： 187.8秒。 (lost ack: 0)ladaptive udp 每個session 平均： 112秒。 (重傳次數(shù): 0)05010015

43、020025030035040045012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx79傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行6mbps,=0.005)ltcp reno 每個session平均： 148.5秒。 (lost ack: 43)ltcp vegas 每個session平均： 148秒。 (lost ack: 0)ladaptive udp 每個session 平均： 115秒。 (重傳次數(shù): 4)0501001502002503

44、0035012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx80傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行6mbps,=0.01)ltcp reno 每個session平均： 141.2秒。 (lost ack: 24)ltcp vegas 每個session平均： 164秒。 (lost ack: 0)ladaptive udp 每個session 平均： 119.6秒。 (重傳次數(shù): 15)0501001502002503003501234567

45、8910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx81傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行6mbps,=0.05)ltcp reno 每個session平均： 201.5秒。 (lost ack: 1)ltcp vegas 每個session平均： 192.3秒。 (lost ack: 0)ladaptive udp 每個session 平均： 131.3秒。 (重傳次數(shù): 311)05010015020025030012345678910sessionfr

46、ag. transport time (sec)tcp renotcp vegasadaptive udpxyyx82傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行6mbps,=0. 1)ltcp reno 每個session平均： 211.5秒。 (lost ack: 0)ltcp vegas 每個session平均： 197.4秒。 (lost ack: 0)ladaptive udp 每個session 平均： 150.2秒。 (重傳次數(shù): 480)05010015020025030035040045012345678910sessionfrag.

47、transport time (sec)tcp renotcp vegasadaptive udpxyyx83傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行8mbps,=0)ltcp reno 每個session平均： 158.5秒。 (lost ack: 41)ltcp vegas 每個session平均： 188秒。 (lost ack: 0)ladaptive udp 每個session 平均： 110.7秒。 (重傳次數(shù): 0)05010015020025030035040012345678910sessionfrag. transport tim

48、e (sec)tcp renotcp vegasadaptive udpxyyx84傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行8mbps,=0.001)ltcp reno 每個session平均： 171.3秒。 (lost ack: 56)ltcp vegas 每個session平均： 187.8秒。 (lost ack: 0)ladaptive udp 每個session 平均： 112秒。 (重傳次數(shù): 0)010020030040050012345678910sessionfrag. transport time (sec)tcp renotc

49、p vegasadaptive udpxyyx85傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行8mbps,=0.005)ltcp reno 每個session平均： 149.3秒。 (lost ack: 46)ltcp vegas 每個session平均： 148秒。 (lost ack: 0)ladaptive udp 每個session 平均： 115秒。 (重傳次數(shù): 4)05010015020025030012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive u

50、dpxyyx86傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行8mbps,=0.01)ltcp reno 每個session平均： 138.1秒。 (lost ack: 23)ltcp vegas 每個session平均： 164秒。 (lost ack: 0)ladaptive udp 每個session 平均： 119.6秒。 (重傳次數(shù): 15)05010015020025030012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx87傳輸協(xié)定效能比較之實驗結(jié)果傳輸協(xié)定效能比較之實驗結(jié)果(上行上行64kbps,下行下行8mbps,=0.05)l