最新适用於P2P档案共享系统传输协定之设计

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19、ment中，x 個封包遺失的機率：l一個segment傳送成功的機率：l反之，一個segment傳送失敗之機率為：(1)1( |1, )(1) xnxnbin x nxmn(0|1, )(1|1, )binnbinn1(0|1, )(1|1, )pbinnbinn 42segment size determinationl額外成本l一個segment中需增加一個同位封包，成本為l當一個segment傳送失敗時，仍要再重傳一次，其重傳成本為l懲罰函數(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當懲罰函數最小時，可得最佳segment封包數。l給定一值即解得一個n值。21(1)( |, )01ddnppenalty n mmdndnnnp21(1)( | )01ddnppenalty ndndn nnp44adaptive udp mechanismludp協定沒有調整傳送速率之機制。l必須在應用層加入自動調整速率之機制。l影響資料傳送速率之決定因素：瓶頸鏈結之頻寬。l傳送端如何獲得瓶頸鏈結之可用頻寬？l如在

21、傳送者上行端l假設使用者已知上行端之實際可用頻寬。l如在核心網路內部l需利用探測封包(probing packet)的方式，幫助瞭解網路內部瓶頸頻寬(bottleneck bandwidth)的狀況。45udp with probing packetsl傳送端定期發送探測封包量測網路狀態，根據其變化來調整合理傳送速率。l接收端在ack裡加入此項資訊。l傳送端使用此資訊來調整合理傳送速率。l目標：降低頻寬浪費或網路擁塞之機率。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緊鄰兩個封包通過瓶頸鏈結時，其封包距離有散開(dispersion)之現象，此散開可當做瓶頸可用頻寬之估計依據，此法稱為packet dispersion法。l利用此packet dispersion估計目前網路內部瓶頸的頻寬。47adjusting coefficient l為避免估計偏差(bias)對協定造成負面影響，以一校正係數(adjusting coefficient )修正估計結果。l我們所測得之可用頻寬為調整資

23、料傳送速度之一參考指標，其調整方式，可參考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參數估算與效能評估參數估算與效能評估l模擬工具：l模擬環境為cygwin下之ns 2.28版。l參數估算：l計算最佳segment數。l用實驗估算調節式udp機制之校正參數值。l效能評估：ludp-based approach與其他傳輸協定之效能比較。50segment size計算計算l實驗目標：給定特定的網路環境，將懲罰函數(penalty function)最小化以找出最佳segment size。參 數數 值 範 圍l10

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

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

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

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

29、載資料。l在y1至r2的上行鏈結會發生fub與boa的問題。xyyx64udp-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%65傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行

30、64kbps,下行下行2mbps,=0)ltcp reno 每個session平均： 164.8秒。(lost ack: 41)ltcp vegas 每個session平均： 188秒。 (lost ack: 0)ladaptive udp 每個session 平均： 110.7秒。 (重傳次數: 0)010020030040050012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx66傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 0)010020030040050060070012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx67傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 4)05010015020025030012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx68傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 15)05010015020025030035040012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx69傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 311)05010015020025030035012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx70傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 480)05010015020025030035040012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx71傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行64kbps,下行下行4mbps,=0)ltcp reno 每個session平均： 174.4秒。 (lost ack: 40)ltcp vegas

36、每個session平均： 188秒。 (lost ack: 0)ladaptive udp 每個session 平均： 110.7秒。 (重傳次數: 0)05010015020025030035040012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx72傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 0)05010015020025030035012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx73傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 4)05010015020025030012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx74傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 15)05010015020025030012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx75傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 311)05010015020025030012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx76傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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、(重傳次數: 480)05010015020025030035040012345678910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx77傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行64kbps,下行下行6mbps,=0)ltcp reno 每個session平均： 177.9秒。 (lost ack: 40)ltcp vegas 每個session平均： 188秒。 (lost ack: 0)ladaptive udp 每個session 平均： 110.7秒。 (重傳次數: 0)05

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

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

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

45、8910sessionfrag. transport time (sec)tcp renotcp vegasadaptive udpxyyx81傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 311)05010015020025030012345678910sessionfr

46、ag. transport time (sec)tcp renotcp vegasadaptive udpxyyx82傳輸協定效能比較之實驗結果傳輸協定效能比較之實驗結果(上行上行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秒。 (重傳次數: 480)05010015020025030035040045012345678910sessionfrag.

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

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

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

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