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

適用於P2P檔案共享系統(tǒng)

傳輸協(xié)定之設計政治大學資訊科學系行動計算與網路通訊實驗室Ⅱ指導教授：連耀南研究生：許弘奇1適用於P2P檔案共享系統(tǒng)

傳輸協(xié)定之設計政治大學資訊科學系1OutlineIntroductionRelatedWorkDesignofProtocolPacketLossRecoverySegmentSizeDeterminationAdaptiveUDPMechanismPerformanceEvaluationConclusion2OutlineIntroduction2IntroductionPeer-to-Peer(P2P)架構：P2P架構讓社群內的使用者收集分散在網路各處之資源。參與者可得到原本無法負擔之運算資源。P2P檔案共享系統(tǒng)：最廣為風行的P2P系統(tǒng)，如Napster、BitTorrent。P2P檔案共享系統(tǒng)，參與的角色分別為：資料提供者(DataSourceProvider)。資料下載者(Downloader)。3IntroductionPeer-to-Peer(P2P)CentralizedModel&DecentralizedModelP2P檔案共享系統(tǒng)架構分為：集中式，如Napster-likeModel。分散式，如BitTorrent-likeModel。CentralizedModelDecentralizedModel4CentralizedModel&DecentraliP2P檔案共享系統(tǒng)之

分散式架構又可細分結構化：下載檔案之來源點和網路拓樸位置有關。非結構化：下載檔案之來源點未將網路拓樸納入考量。5P2P檔案共享系統(tǒng)之

分散式架構又可細分結構化：5BitTorrentBitTorrent之優(yōu)點：目前最為風行?？蓴U張性極佳(scalability)。以BitTorrent-likeModel為代表，作為我們的研究對象。6BitTorrentBitTorrent之優(yōu)點：6BitTorrent運作時之參與角色檔案提供者(Seeder)檔案下載者(Downloader)Tracker扮演中央控管角色協(xié)助下載者尋找所需之檔案片段。網頁伺服器(Webserver)公佈並提供檔案之相關資訊。7BitTorrent運作時之參與角色檔案提供者(SeedeBitTorrent特色P2P檔案共享協(xié)定。採分散式且非結構化之模式。檔案提供者將檔案切割成多個檔案片段。下載者會開放已完成之檔案片段，供其他下載者抓取。下載檔案時，可從不同之地點下載。同一檔案片段同時有許多地點可供下載。下載者可從不同地點下載同一檔案片段。參與者愈多時，其下載者之下載速度不會大幅降低。8BitTorrent特色P2P檔案共享協(xié)定。8BitTorrent運作機制檔案提供：提供者Seeder利用BitTorrent程式對檔案建立.torrent檔，過程中需指定「Tracker」的URL。檔案公佈：檔案提供者需將.torrent檔公佈至某網頁。.torrent除了TrackerURL位置之外，亦含被下載檔案之檔名、檔案大小、檔案Signature等訊息。9BitTorrent運作機制檔案提供：9BitTorrent運作機制檔案下載：下載前，先至網頁抓取.torrent檔，用BitTorrent程式開啟此.torrent檔，才可下載檔案。檔案下載時，系統(tǒng)會經由「Tracker」尋找所需之檔案片段。10BitTorrent運作機制檔案下載：10BitTorrent運作機制BitTorrent運作之檔案基本單位：Piece(Fragment)：檔案片段，大小為1/4Mbytes。Sub-piece(Sub-fragment)：為利用Pipeline方式提昇Piece傳輸速度之單位。大小為16Kbytes。傳輸協(xié)定：採用TCP傳輸協(xié)定。11BitTorrent運作機制BitTorrent運作之檔案TCP的特色傳輸層協(xié)定(Transportlayerprotocol)。端對端(end-to-end):一個傳送端，一個接收端。資料傳輸前需建立連線(connection-oriented)。PositiveACK：接收端收到正確資料須回傳ACK。ACK驅動傳送端送出新的封包(self-clocking)。保證資料完整及保持原序(dataintegrity,in-order)。流量控制(flowcontrolled):傳送端之資料速率不超過接收端之接收能力。傳輸速率由擁塞窗框(congestionwindow)所控制。12TCP的特色傳輸層協(xié)定(TransportlayerprTCP擁塞控管機制利用WindowSize調節(jié)資料傳輸速率。以封包遺失或逾時當作網路擁塞的指標。資料傳輸中若有封包遺失或逾時，TCP就會啟動擁塞控制機制快速降低資料傳輸速率。13TCP擁塞控管機制利用WindowSize調節(jié)資料傳輸速TCP擁塞控管機制

SlowStart(CWND<Threshold)探測目前網路可承載的頻寬。當connection建立以後，CWND大小以指數的速度成長，直至超過Treshold或封包遺失產生為止。CongestionAvoidance(CWND>Threshold)AIMD(AdditiveIncreaseMultiplicativeDecrease)SlowStarttimeout3duplicateACKsCongestionAvoidance(RTT)threshold14TCP擁塞控管機制

SlowStarttimeout3P2P檔案共享系統(tǒng)的效能缺陷經驗中發(fā)現，上行頻寬窄、下行頻寬大的非對稱網路(如ADSL)之下，BitTorrent-likeModel之傳輸速度不佳。下載者之下行頻寬大，使用率卻很低。下載者無法完全使用下載頻寬。15P2P檔案共享系統(tǒng)的效能缺陷經驗中發(fā)現，上行頻寬窄、下行頻寬P2P檔案共享系統(tǒng)效能問題分析FractionalUpwardBandwidth(FUB)：一檔案片段被多個下載者同時下載。多個上傳訊務流要共用一個狹窄上行頻寬。BlockageofACK(BoA)：TCP協(xié)定下，接收端收到資料後，須回傳ACK。BitTorrent中之資料接收者，亦為資料上傳者。狹窄之上行頻寬擁塞，ACK無法順利回傳。ACK在佇列中逾時後，傳送端啟動擁塞控管機制，降低資料傳送速度。16P2P檔案共享系統(tǒng)效能問題分析FractionalUpwaP2P檔案共享系統(tǒng)效能問題分析檔案片段樹(FragmentTree)：以檔案片段Seed為樹根(Root)。上傳者與下載者形成階層架構。17P2P檔案共享系統(tǒng)效能問題分析檔案片段樹(Fragment由檔案片段樹觀察到下列結果LongPhysicalPaths：檔案片段樹之一鏈結(link)實際為路徑(path)。下載路徑可能很長，假如未考量路徑長短，便會浪費網路資源。下載路徑之間可能有重疊之處，會浪費網路資源。Lien(2005)提出，如果能盡量縮短路徑、減少重覆，必能降低頻寬之浪費。18由檔案片段樹觀察到下列結果LongPhysicalPatLongPhysicalPaths19LongPhysicalPaths19BushyTreeBushyTree：太多下載者抓取本身下載完成之檔案片段。導致FUB與BoA的問題。Lien(2005)提出可將之改成分支度較小的SlimTree，控制每個參與者分享資料流數目，可減少FUB與BoA的問題。BushyTreeSlimTree20BushyTreeBushyTree：BushyTre研究目標以上分析有BoA、FUB等問題。因為BoA問題現今尚未有完整之解決方案，本研究之目的，即對BoA效能問題提出可行改進措施。21研究目標以上分析有BoA、FUB等問題。21OutlineIntroductionRelatedWorkDesignofProtocolPacketLossRecoverySegmentSizeDeterminationAdaptiveUDPMechanismPerformanceEvaluationConclusion22OutlineIntroduction22RelatedWork非對稱網路下之資料傳輸問題非對稱網路下TCP問題之回顧非對稱網路下TCP問題之解法23RelatedWork非對稱網路下之資料傳輸問題23非對稱網路下TCP問題之回顧H.BalakrishnanandV.N.Padmanabhan,“HowNetworkAsymmetryAffectTCP,”IEEECommunicationsMagazine,Apr.2001.回顧TCP協(xié)定，在非對稱網路下之效能影響並提出解法。對狹窄頻寬進行管理：TCPHeaderCompression、ACKFiltering、ACKCongestionControl、ACKsFirstScheduling等方式ACK頻率低，會破壞Self-clocking，補救措施：ACKReconstruction24非對稱網路下TCP問題之回顧H.Balakrishnan非對稱網路下TCP問題之解法WanjiunLiaoandYi-DerLi,"ImprovingTCPPerformanceforAsymmetricNetworks,"IEEEICC,Helsinki,Finland,Jun.2001.TCPVegas不能分辨在非對稱網路之下，因傳輸方向不同所產生的負面影響，而導致整個效能大為降低。提出一個新的TCPFormosa協(xié)定。CumulativeACK的機制減少ACK的數量。避免非對稱網路之下因為ACK遺失所導致的影響。25非對稱網路下TCP問題之解法WanjiunLiaoand評論上述之方法皆是直接修改TCP協(xié)定。改變TCP茲事體大，協(xié)定更改幅度太大，影響層面廣，不易被接受?，F有之使用者不易為了解決非對稱網路產生之問題即採用一個新版的TCP協(xié)定。26評論上述之方法皆是直接修改TCP協(xié)定。26OutlineIntroductionRelatedWorkDesignofProtocolPacketLossRecoverySegmentSizeDeterminationAdaptiveUDPMechanismPerformanceEvaluationConclusion27OutlineIntroduction27解決BoA問題的方法方案一：增加TCPACKTimeout時間。導致TCP對真正網路擁塞之反應時間拉長。不能即時處理網路擁塞。方案二：TCP之接受端重覆傳送ACK。增加ACK存活率，但會在非對稱網路狹窄的上行端增加ACK訊務量。此法對TCP更改幅度太大。方案三：以UDP為基礎的方式(UDP-BasedApproach)解決。28解決BoA問題的方法方案一：增加TCPACKTimeou我們採用UDP的方法使用UDP傳送資料，不必對接收到的封包回送ACK，可避免BoA問題。UDP協(xié)定有兩個問題：無法確保資料的完整性。無法自動決定資料傳送速率。在應用層(ApplicationLayer)加上相關機制解決。29我們採用UDP的方法使用UDP傳送資料，不必對接收到的封包回我們提出的協(xié)定之特色此協(xié)定以UDP協(xié)定為基礎，並加入下列機制：確保資料完整性之機制。自動決定資料傳送速率之機制。此協(xié)定之採用者：BitTorrent架構下之參與者。傳送端與接收端(sender&receiver)皆需採用。30我們提出的協(xié)定之特色此協(xié)定以UDP協(xié)定為基礎，並加入下列機制我們提出的協(xié)定之特色本協(xié)定必須考慮下列的問題：避免因封包錯誤導致之重傳。提供自動重建遺失之封包。計算基本傳輸單位之大小。量測最適可用頻寬，決定傳送速率。31我們提出的協(xié)定之特色本協(xié)定必須考慮下列的問題：313232效能目標儘量降低重傳次數。儘量利用可利用之網路頻寬，提高每個下載者的下載速度。33效能目標儘量降低重傳次數。33提昇效能之設計

PacketLossRecovery(自動重建遺失之封包)：避免封包遺失而重傳。SegmentSizeDetermination(基本傳送單位之計算)：計算檔案片段中，最佳的基本傳輸單位大小要保護封包，亦要降低overhead。AdaptiveUDPMechanism(調節(jié)式UDP機制)：應用層加上自動調整傳輸速率機制。34提昇效能之設計PacketLossRecovery(FragmentStructure35FragmentStructure35PacketLossRecovery每n個封包為一群，加一個同位封包(ParityPacket)，稱為Segment。同位封包：Segment之資料封包經由同位計算後所產生。36PacketLossRecovery每n個封包為一群，加PacketLossRecovery同位封包之功用：Segment任一封包遺失，可用同位封包救回。Segment中若有兩個以上封包遺失，同位封包將無法彌補，則資料必須重傳。重傳之單位：以Fragment為單位，重傳時須負擔較高的重傳成本。以Segment為單位，減輕重傳之成本。37PacketLossRecovery同位封包之功用：37PacketLossRecovery示意圖38PacketLossRecovery示意圖38PacketLossRecoveryIssueSegment長短影響協(xié)定之效能：Segment較短時，錯誤更正能力較強，但Overhead較大。Segment較長時，錯誤更正能力較弱，但Overhead較小。

39PacketLossRecoveryIssueSegmSegmentSizeDetermination因Segment長短會影響協(xié)定效能。設計一計算最佳Segment大小之法。其中，每一封包之封包遺失率皆同為γ。符號意義m一檔案片段(fragment)中之封包數γ封包遺失率,0<=γ<=1n一segment中之封包數40SegmentSizeDetermination因SegSegmentSizeDetermination一個Fragment可分為Segment。一個Segment中，x個封包遺失的機率：一個Segment傳送成功的機率：反之，一個Segment傳送失敗之機率為：41SegmentSizeDetermination一個FrSegmentSizeDetermination額外成本一個Segment中需增加一個同位封包，成本為當一個Segment傳送失敗時，仍要再重傳一次，其重傳成本為懲罰函數(PenaltyFunction)：簡化：42SegmentSizeDetermination額外成本SegmentSizeDetermination當懲罰函數最小時，可得最佳Segment封包數。給定一γ值即解得一個n值。43SegmentSizeDetermination當懲罰函AdaptiveUDPMechanismUDP協(xié)定沒有調整傳送速率之機制。必須在應用層加入自動調整速率之機制。影響資料傳送速率之決定因素：瓶頸鏈結之頻寬。傳送端如何獲得瓶頸鏈結之可用頻寬？如在傳送者上行端假設使用者已知上行端之實際可用頻寬。如在核心網路內部需利用探測封包(ProbingPacket)的方式，幫助瞭解網路內部瓶頸頻寬(bottleneckbandwidth)的狀況。44AdaptiveUDPMechanismUDP協(xié)定沒有調UDPwithProbingPackets傳送端定期發(fā)送探測封包量測網路狀態(tài)，根據其變化來調整合理傳送速率。接收端在ACK裡加入此項資訊。傳送端使用此資訊來調整合理傳送速率。目標：降低頻寬浪費或網路擁塞之機率。45UDPwithProbingPackets45PacketDispersionC.Dovroliset.al.,"Packet-DispersionTechniquesandaCapacity-EstimationMethodology,"IEEE/ACMTransactionsOnNetworking,VOL.12,No.6,Dec2004.緊鄰兩個封包通過瓶頸鏈結時，其封包距離有散開(Dispersion)之現象，此散開可當做瓶頸可用頻寬之估計依據，此法稱為PacketDispersion法。利用此PacketDispersion估計目前網路內部瓶頸的頻寬。46PacketDispersion46AdjustingCoefficientα為避免估計偏差(bias)對協(xié)定造成負面影響，以一校正係數α(AdjustingCoefficientα)修正估計結果。我們所測得之可用頻寬為調整資料傳送速度之一參考指標，其調整方式，可參考Yung-PingChungandYao-NanLien,"DesignofTCPCongestionControlTechniquesbyRouter-assistedApproach,"Sep.2005。47AdjustingCoefficientα47OutlineIntroductionRelatedWorkDesignofProtocolPacketLossRecoverySegmentSizeDeterminationAdaptiveUDPMechanismPerformanceEvaluationConclusion48OutlineIntroduction48參數估算與效能評估模擬工具：模擬環(huán)境為Cygwin下之ns2.28版。參數估算：計算最佳Segment數。用實驗估算調節(jié)式UDP機制之校正參數α值。效能評估：UDP-BasedApproach與其他傳輸協(xié)定之效能比較。49參數估算與效能評估模擬工具：49SegmentSize計算實驗目標：給定特定的網路環(huán)境，將懲罰函數(PenaltyFunction)最小化以找出最佳SegmentSize。參數數值範圍l1000bytes/packetm263packets/fragmentl×m=1/4MBγ0.5%~2%50SegmentSize計算實驗目標：給定特定的網路環(huán)境，將SegmentSize計算結果

(γ=0.005,0.01,0.015,0.02)51SegmentSize計算結果

(γ=0.005,0.0SegmentSize計算之敏感度分析不同網路封包遺失率下，求得SegmentSize變化情形。封包遺失率很低時，不太會發(fā)生封包遺失，求得的SegmentSize比較大。封包遺失率提高時，封包遺失就容易發(fā)生，求得的SegmentSize就較小。52SegmentSize計算之敏感度分析52AdaptiveUDPMechanism

α值參數估算實驗目標：利用Packet-Dispersion估計可用頻寬，利用實驗找出適當之校正參數α值供他人參考。53AdaptiveUDPMechanism

α值參數估算實AdaptiveUDPMechanism

α值參數估算實驗設計魚骨狀之網路架構。中介鏈結上有中介訊務流經其中。調整此魚骨拓樸之長度，並且控制實際可用頻寬之下，求取參考用之α值。54AdaptiveUDPMechanism

α值參數估算實AdaptiveUDPMechanism

α值參數估算實驗參數參數數值中介鏈結數1,3,5,7,9可用頻寬1～10Mbps。55AdaptiveUDPMechanism

α值參數估算實α值參數估算之實驗結果

(中介鏈結數=1)此例計算得到之α=0.897。56α值參數估算之實驗結果

(中介鏈結數=1)56α值參數估算之實驗結果

(中介鏈結數=3)此例計算得到之α=0.962。57α值參數估算之實驗結果

(中介鏈結數=3)57α值參數估算之實驗結果

(中介鏈結數=5)此例計算得到之α=0.944。58α值參數估算之實驗結果

(中介鏈結數=5)58α值參數估算之實驗結果

(中介鏈結數=7)此例計算得到之α=0.958。59α值參數估算之實驗結果

(中介鏈結數=7)59α值參數估算之實驗結果

(中介鏈結數=9)此例計算得到之α=0.885。60α值參數估算之實驗結果

(中介鏈結數=9)60中介鏈結數之變化與校正參數α之間的關係中介鏈結數變化與校正參數α之間的關係，發(fā)現α值之變化相當平穩(wěn)。中介鏈結數之大小對α值的影響不大。得到最後估計之α值為0.93。61中介鏈結數之變化與校正參數α之間的關係61UDP-BasedApproach與其他傳輸協(xié)定

之效能比較實驗目標：設計一個網路上發(fā)生FUB與BoA之網路場景，各種不同的傳輸協(xié)定進行效能分析與比較。實驗設計：UDP-BasedApproach為實驗組。TCP-Reno、TCP-Vegas為對照組。核心網路(CoreNetwork)中有充沛頻寬，雙向有1Gbps頻寬，接取網路為非對稱網路。62UDP-BasedApproach與其他傳輸協(xié)定

之效能比UDP-BasedApproach與其他傳輸協(xié)定

效能比較之網路拓樸核心網路上有R1、R2兩個路由器(Router)非對稱鏈結所接取的的機器有X1～X5及Y1共六臺：X1～X5同時會至Y1下載資料。Y1亦有5個Session同時至X1～X5下載資料。在Y1至R2的上行鏈結會發(fā)生FUB與BoA的問題。63UDP-BasedApproach與其他傳輸協(xié)定

效能比較UDP-BasedApproach與其他傳輸協(xié)定

效能比較之實驗參數參數數值傳輸協(xié)定TCP-Reno、TCP-Vegas、UDP-BasedApproach

檔案片段大小1/4MB核心網路頻寬1Gbps接取網路上下行頻寬(64Kbps,2Mbps)、(64Kbps,4Mbps)、(64Kbps,6Mbps)、(64Kbps,8Mbps)核心網路封包遺失率γ0%,0.1%,0.5%,1%,5%,10%64UDP-BasedApproach與其他傳輸協(xié)定

效能比較傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0)TCPReno每個Session平均：164.8秒。(LostACK:41)TCPVegas每個Session平均：188秒。(LostACK:0)AdaptiveUDP每個Session平均：110.7秒。(重傳次數:0)65傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.001)TCPReno每個Session平均：201.5秒。(LostACK:66)TCPVegas每個Session平均：187.8秒。(LostACK:0)AdaptiveUDP每個Session平均：112秒。(重傳次數:0)66傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.005)TCPReno每個Session平均：150.1秒。(LostACK:39)TCPVegas每個Session平均：159.2秒。(LostACK:0)AdaptiveUDP每個Session平均：115秒。(重傳次數:4)67傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.01)TCPReno每個Session平均：150.2秒。(LostACK:34)TCPVegas每個Session平均：164秒。(LostACK:0)AdaptiveUDP每個Session平均：119.6秒。(重傳次數:15)68傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.05)TCPReno每個Session平均：208.7秒。(LostACK:1)TCPVegas每個Session平均：196秒。(LostACK:0)AdaptiveUDP每個Session平均：131.3秒。(重傳次數:311)69傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.1)TCPReno每個Session平均：231.7秒。(LostACK:0)TCPVegas每個Session平均：213.1秒。(LostACK:0)AdaptiveUDP每個Session平均：150.2秒。(重傳次數:480)70傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0)TCPReno每個Session平均：174.4秒。(LostACK:40)TCPVegas每個Session平均：188秒。(LostACK:0)AdaptiveUDP每個Session平均：110.7秒。(重傳次數:0)71傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0.001)TCPReno每個Session平均：151.1秒。(LostACK:39)TCPVegas每個Session平均：187.8秒。(LostACK:0)AdaptiveUDP每個Session平均：112秒。(重傳次數:0)72傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0.005)TCPReno每個Session平均：143.3秒。(LostACK:45)TCPVegas每個Session平均：148秒。(LostACK:0)AdaptiveUDP每個Session平均：115秒。(重傳次數:4)73傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0.01)TCPReno每個Session平均：142.9秒。(LostACK:24)TCPVegas每個Session平均：164秒。(LostACK:0)AdaptiveUDP每個Session平均：119.6秒。(重傳次數:15)74傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0.05)TCPReno每個Session平均：201.5秒。(LostACK:1)TCPVegas每個Session平均：196秒。(LostACK:0)AdaptiveUDP每個Session平均：131.3秒。(重傳次數:311)75傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbps,γ=0.1)TCPReno每個Session平均：222.2秒。(LostACK:0)TCPVegas每個Session平均：222.1秒。(LostACK:0)AdaptiveUDP每個Session平均：150.2秒。(重傳次數:480)76傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行4Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0)TCPReno每個Session平均：177.9秒。(LostACK:40)TCPVegas每個Session平均：188秒。(LostACK:0)AdaptiveUDP每個Session平均：110.7秒。(重傳次數:0)77傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0.001)TCPReno每個Session平均：166.9秒。(LostACK:39)TCPVegas每個Session平均：187.8秒。(LostACK:0)AdaptiveUDP每個Session平均：112秒。(重傳次數:0)78傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0.005)TCPReno每個Session平均：148.5秒。(LostACK:43)TCPVegas每個Session平均：148秒。(LostACK:0)AdaptiveUDP每個Session平均：115秒。(重傳次數:4)79傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0.01)TCPReno每個Session平均：141.2秒。(LostACK:24)TCPVegas每個Session平均：164秒。(LostACK:0)AdaptiveUDP每個Session平均：119.6秒。(重傳次數:15)80傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0.05)TCPReno每個Session平均：201.5秒。(LostACK:1)TCPVegas每個Session平均：192.3秒。(LostACK:0)AdaptiveUDP每個Session平均：131.3秒。(重傳次數:311)81傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbps,γ=0.1)TCPReno每個Session平均：211.5秒。(LostACK:0)TCPVegas每個Session平均：197.4秒。(LostACK:0)AdaptiveUDP每個Session平均：150.2秒。(重傳次數:480)82傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行6Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0)TCPReno每個Session平均：158.5秒。(LostACK:41)TCPVegas每個Session平均：188秒。(LostACK:0)AdaptiveUDP每個Session平均：110.7秒。(重傳次數:0)83傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0.001)TCPReno每個Session平均：171.3秒。(LostACK:56)TCPVegas每個Session平均：187.8秒。(LostACK:0)AdaptiveUDP每個Session平均：112秒。(重傳次數:0)84傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0.005)TCPReno每個Session平均：149.3秒。(LostACK:46)TCPVegas每個Session平均：148秒。(LostACK:0)AdaptiveUDP每個Session平均：115秒。(重傳次數:4)85傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0.01)TCPReno每個Session平均：138.1秒。(LostACK:23)TCPVegas每個Session平均：164秒。(LostACK:0)AdaptiveUDP每個Session平均：119.6秒。(重傳次數:15)86傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0.05)TCPReno每個Session平均：201.5秒。(LostACK:1)TCPVegas每個Session平均：189.9秒。(LostACK:0)AdaptiveUDP每個Session平均：131.3秒。(重傳次數:311)87傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbps,γ=0.1)TCPReno每個Session平均：211.4秒。(LostACK:0)TCPVegas每個Session平均：242.7秒。(LostACK:0)AdaptiveUDP每個Session平均：150.2秒。(重傳次數:480)88傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行8Mbp傳輸協(xié)定效能比較之實驗結果

(總平均)AdaptiveUDP的資料傳輸效能明顯的優(yōu)於TCPReno及TCPVegas。Reno、Vegas、UDP平均分別為175.8,183.8,123.1秒。89傳輸協(xié)定效能比較之實驗結果

(總平均)89傳輸協(xié)定效能比較之實驗

不同下行頻寬之敏感度分析固定上行頻寬，各個協(xié)定在不同的下行頻寬之下，下載完成時間變化皆不大。增大下行頻寬並不能對BitTorrent效能提昇有所幫助。90傳輸協(xié)定效能比較之實驗

不同下行頻寬之敏感度分析90傳輸協(xié)定效能比較之實驗

不同封包遺失率之敏感度分析各個協(xié)定在增加封包遺失率時，其下載完成時間有往上昇之趨勢。TCPReno與TCPVegas之訊務在Y之上行鏈結相當擁塞，有些許PacketLoss有助於效能之提昇。91傳輸協(xié)定效能比較之實驗

不同封包遺失率之敏感度分析91傳輸協(xié)定效能比較之實驗結果TCPReno的效能表現相當不好資料及ACK封包因狹窄的上行頻寬擁塞，發(fā)生逾時或被丟棄，導致傳送端重傳資料。FUB與BoA引起之意外，導致TCPCongestionWindow縮小，最後造成TCPReno效能不彰。TCPVegas無法分辨非對稱網路之方向性兩個方向之速率調節(jié)後大致相等。兩個方向Session之完成時間相當接近。未充分使用網路資源。92傳輸協(xié)定效能比較之實驗結果TCPReno的效能表現相當不好OutlineIntroductionRelatedWorkDesignofProtocolPacketLossRecoverySegmentSizeDeterminationAdaptiveUDPMechanismPerformanceEvaluationConclusion93OutlineIntroduction93Conclusion在文章中，我們對P2P檔案共享系統(tǒng)在非對稱網路下進行分析。設計一傳輸層的網路協(xié)定進行效能改善。協(xié)定設計過程中，建立參數決定之數學模型以及利用模擬進行效能分析。我們的傳輸協(xié)定效能表現優(yōu)於TCPReno、TCPVegas。希望此網路協(xié)定有效提昇P2P檔案共享系統(tǒng)之運作效能。94Conclusion在文章中，我們對P2P檔案共享系統(tǒng)在非對適用於P2P檔案共享系統(tǒng)

傳輸協(xié)定之設計政治大學資訊科學系行動計算與網路通訊實驗室Ⅱ指導教授：連耀南研究生：許弘奇95適用於P2P檔案共享系統(tǒng)

傳輸協(xié)定之設計政治大學資訊科學系1OutlineIntroductionRelatedWorkDesignofProtocolPacketLossRecoverySegmentSizeDeterminationAdaptiveUDPMechanismPerformanceEvaluationConclusion96OutlineIntroduction2IntroductionPeer-to-Peer(P2P)架構：P2P架構讓社群內的使用者收集分散在網路各處之資源。參與者可得到原本無法負擔之運算資源。P2P檔案共享系統(tǒng)：最廣為風行的P2P系統(tǒng)，如Napster、BitTorrent。P2P檔案共享系統(tǒng)，參與的角色分別為：資料提供者(DataSourceProvider)。資料下載者(Downloader)。97IntroductionPeer-to-Peer(P2P)CentralizedModel&DecentralizedModelP2P檔案共享系統(tǒng)架構分為：集中式，如Napster-likeModel。分散式，如BitTorrent-likeModel。CentralizedModelDecentralizedModel98CentralizedModel&DecentraliP2P檔案共享系統(tǒng)之

分散式架構又可細分結構化：下載檔案之來源點和網路拓樸位置有關。非結構化：下載檔案之來源點未將網路拓樸納入考量。99P2P檔案共享系統(tǒng)之

分散式架構又可細分結構化：5BitTorrentBitTorrent之優(yōu)點：目前最為風行?？蓴U張性極佳(scalability)。以BitTorrent-likeModel為代表，作為我們的研究對象。100BitTorrentBitTorrent之優(yōu)點：6BitTorrent運作時之參與角色檔案提供者(Seeder)檔案下載者(Downloader)Tracker扮演中央控管角色協(xié)助下載者尋找所需之檔案片段。網頁伺服器(Webserver)公佈並提供檔案之相關資訊。101BitTorrent運作時之參與角色檔案提供者(SeedeBitTorrent特色P2P檔案共享協(xié)定。採分散式且非結構化之模式。檔案提供者將檔案切割成多個檔案片段。下載者會開放已完成之檔案片段，供其他下載者抓取。下載檔案時，可從不同之地點下載。同一檔案片段同時有許多地點可供下載。下載者可從不同地點下載同一檔案片段。參與者愈多時，其下載者之下載速度不會大幅降低。102BitTorrent特色P2P檔案共享協(xié)定。8BitTorrent運作機制檔案提供：提供者Seeder利用BitTorrent程式對檔案建立.torrent檔，過程中需指定「Tracker」的URL。檔案公佈：檔案提供者需將.torrent檔公佈至某網頁。.torrent除了TrackerURL位置之外，亦含被下載檔案之檔名、檔案大小、檔案Signature等訊息。103BitTorrent運作機制檔案提供：9BitTorrent運作機制檔案下載：下載前，先至網頁抓取.torrent檔，用BitTorrent程式開啟此.torrent檔，才可下載檔案。檔案下載時，系統(tǒng)會經由「Tracker」尋找所需之檔案片段。104BitTorrent運作機制檔案下載：10BitTorrent運作機制BitTorrent運作之檔案基本單位：Piece(Fragment)：檔案片段，大小為1/4Mbytes。Sub-piece(Sub-fragment)：為利用Pipeline方式提昇Piece傳輸速度之單位。大小為16Kbytes。傳輸協(xié)定：採用TCP傳輸協(xié)定。105BitTorrent運作機制BitTorrent運作之檔案TCP的特色傳輸層協(xié)定(Transportlayerprotocol)。端對端(end-to-end):一個傳送端，一個接收端。資料傳輸前需建立連線(connection-oriented)。PositiveACK：接收端收到正確資料須回傳ACK。ACK驅動傳送端送出新的封包(self-clocking)。保證資料完整及保持原序(dataintegrity,in-order)。流量控制(flowcontrolled):傳送端之資料速率不超過接收端之接收能力。傳輸速率由擁塞窗框(congestionwindow)所控制。106TCP的特色傳輸層協(xié)定(TransportlayerprTCP擁塞控管機制利用WindowSize調節(jié)資料傳輸速率。以封包遺失或逾時當作網路擁塞的指標。資料傳輸中若有封包遺失或逾時，TCP就會啟動擁塞控制機制快速降低資料傳輸速率。107TCP擁塞控管機制利用WindowSize調節(jié)資料傳輸速TCP擁塞控管機制

SlowStart(CWND<Threshold)探測目前網路可承載的頻寬。當connection建立以後，CWND大小以指數的速度成長，直至超過Treshold或封包遺失產生為止。CongestionAvoidance(CWND>Threshold)AIMD(AdditiveIncreaseMultiplicativeDecrease)SlowStarttimeout3duplicateACKsCongestionAvoidance(RTT)threshold108TCP擁塞控管機制

SlowStarttimeout3P2P檔案共享系統(tǒng)的效能缺陷經驗中發(fā)現，上行頻寬窄、下行頻寬大的非對稱網路(如ADSL)之下，BitTorrent-likeModel之傳輸速度不佳。下載者之下行頻寬大，使用率卻很低。下載者無法完全使用下載頻寬。109P2P檔案共享系統(tǒng)的效能缺陷經驗中發(fā)現，上行頻寬窄、下行頻寬P2P檔案共享系統(tǒng)效能問題分析FractionalUpwardBandwidth(FUB)：一檔案片段被多個下載者同時下載。多個上傳訊務流要共用一個狹窄上行頻寬。BlockageofACK(BoA)：TCP協(xié)定下，接收端收到資料後，須回傳ACK。BitTorrent中之資料接收者，亦為資料上傳者。狹窄之上行頻寬擁塞，ACK無法順利回傳。ACK在佇列中逾時後，傳送端啟動擁塞控管機制，降低資料傳送速度。110P2P檔案共享系統(tǒng)效能問題分析FractionalUpwaP2P檔案共享系統(tǒng)效能問題分析檔案片段樹(FragmentTree)：以檔案片段Seed為樹根(Root)。上傳者與下載者形成階層架構。111P2P檔案共享系統(tǒng)效能問題分析檔案片段樹(Fragment由檔案片段樹觀察到下列結果LongPhysicalPaths：檔案片段樹之一鏈結(link)實際為路徑(path)。下載路徑可能很長，假如未考量路徑長短，便會浪費網路資源。下載路徑之間可能有重疊之處，會浪費網路資源。Lien(2005)提出，如果能盡量縮短路徑、減少重覆，必能降低頻寬之浪費。112由檔案片段樹觀察到下列結果LongPhysicalPatLongPhysicalPaths113LongPhysicalPaths19BushyTreeBushyTree：太多下載者抓取本身下載完成之檔案片段。導致FUB與BoA的問題。Lien(2005)提出可將之改成分支度較小的SlimTree，控制每個參與者分享資料流數目，可減少FUB與BoA的問題。BushyTreeSlimTree114BushyTreeBushyTree：BushyTre研究目標以上分析有BoA、FUB等問題。因為BoA問題現今尚未有完整之解決方案，本研究之目的，即對BoA效能問題提出可行改進措施。115研究目標以上分析有BoA、FUB等問題。21OutlineIntroductionRelatedWorkDesignofProtocolPacketLossRecoverySegmentSizeDeterminationAdaptiveUDPMechanismPerformanceEvaluationConclusion116OutlineIntroduction22RelatedWork非對稱網路下之資料傳輸問題非對稱網路下TCP問題之回顧非對稱網路下TCP問題之解法117RelatedWork非對稱網路下之資料傳輸問題23非對稱網路下TCP問題之回顧H.BalakrishnanandV.N.Padmanabhan,“HowNetworkAsymmetryAffectTCP,”IEEECommunicationsMagazine,Apr.2001.回顧TCP協(xié)定，在非對稱網路下之效能影響並提出解法。對狹窄頻寬進行管理：TCPHeaderCompression、ACKFiltering、ACKCongestionControl、ACKsFirstScheduling等方式ACK頻率低，會破壞Self-clocking，補救措施：ACKReconstruction118非對稱網路下TCP問題之回顧H.Balakrishnan非對稱網路下TCP問題之解法WanjiunLiaoandYi-DerLi,"ImprovingTCPPerformanceforAsymmetricNetworks,"IEEEICC,Helsinki,Finland,Jun.2001.TCPVegas不能分辨在非對稱網路之下，因傳輸方向不同所產生的負面影響，而導致整個效能大為降低。提出一個新的TCPFormosa協(xié)定。CumulativeACK的機制減少ACK的數量。避免非對稱網路之下因為ACK遺失所導致的影響。119非對稱網路下TCP問題之解法WanjiunLiaoand評論上述之方法皆是直接修改TCP協(xié)定。改變TCP茲事體大，協(xié)定更改幅度太大，影響層面廣，不易被接受?，F有之使用者不易為了解決非對稱網路產生之問題即採用一個新版的TCP協(xié)定。120評論上述之方法皆是直接修改TCP協(xié)定。26OutlineIntroductionRelatedWorkDesignofProtocolPacketLossRecoverySegmentSizeDeterminationAdaptiveUDPMechanismPerformanceEvaluationConclusion121OutlineIntroduction27解決BoA問題的方法方案一：增加TCPACKTimeout時間。導致TCP對真正網路擁塞之反應時間拉長。不能即時處理網路擁塞。方案二：TCP之接受端重覆傳送ACK。增加ACK存活率，但會在非對稱網路狹窄的上行端增加ACK訊務量。此法對TCP更改幅度太大。方案三：以UDP為基礎的方式(UDP-BasedApproach)解決。122解決BoA問題的方法方案一：增加TCPACKTimeou我們採用UDP的方法使用UDP傳送資料，不必對接收到的封包回送ACK，可避免BoA問題。UDP協(xié)定有兩個問題：無法確保資料的完整性。無法自動決定資料傳送速率。在應用層(ApplicationLayer)加上相關機制解決。123我們採用UDP的方法使用UDP傳送資料，不必對接收到的封包回我們提出的協(xié)定之特色此協(xié)定以UDP協(xié)定為基礎，並加入下列機制：確保資料完整性之機制。自動決定資料傳送速率之機制。此協(xié)定之採用者：BitTorrent架構下之參與者。傳送端與接收端(sender&receiver)皆需採用。124我們提出的協(xié)定之特色此協(xié)定以UDP協(xié)定為基礎，並加入下列機制我們提出的協(xié)定之特色本協(xié)定必須考慮下列的問題：避免因封包錯誤導致之重傳。提供自動重建遺失之封包。計算基本傳輸單位之大小。量測最適可用頻寬，決定傳送速率。125我們提出的協(xié)定之特色本協(xié)定必須考慮下列的問題：3112632效能目標儘量降低重傳次數。儘量利用可利用之網路頻寬，提高每個下載者的下載速度。127效能目標儘量降低重傳次數。33提昇效能之設計

PacketLossRecovery(自動重建遺失之封包)：避免封包遺失而重傳。SegmentSizeDetermination(基本傳送單位之計算)：計算檔案片段中，最佳的基本傳輸單位大小要保護封包，亦要降低overhead。AdaptiveUDPMechanism(調節(jié)式UDP機制)：應用層加上自動調整傳輸速率機制。128提昇效能之設計PacketLossRecovery(FragmentStructure129FragmentStructure35PacketLossRecovery每n個封包為一群，加一個同位封包(ParityPacket)，稱為Segment。同位封包：Segment之資料封包經由同位計算後所產生。130PacketLossRecovery每n個封包為一群，加PacketLossRecovery同位封包之功用：Segment任一封包遺失，可用同位封包救回。Segment中若有兩個以上封包遺失，同位封包將無法彌補，則資料必須重傳。重傳之單位：以Fragment為單位，重傳時須負擔較高的重傳成本。以Segment為單位，減輕重傳之成本。131PacketLossRecovery同位封包之功用：37PacketLossRecovery示意圖132PacketLossRecovery示意圖38PacketLossRecoveryIssueSegment長短影響協(xié)定之效能：Segment較短時，錯誤更正能力較強，但Overhead較大。Segment較長時，錯誤更正能力較弱，但Overhead較小。

133PacketLossRecoveryIssueSegmSegmentSizeDetermination因Segment長短會影響協(xié)定效能。設計一計算最佳Segment大小之法。其中，每一封包之封包遺失率皆同為γ。符號意義m一檔案片段(fragment)中之封包數γ封包遺失率,0<=γ<=1n一segment中之封包數134SegmentSizeDetermination因SegSegmentSizeDetermination一個Fragment可分為Segment。一個Segment中，x個封包遺失的機率：一個Segment傳送成功的機率：反之，一個Segment傳送失敗之機率為：135SegmentSizeDetermination一個FrSegmentSizeDetermination額外成本一個Segment中需增加一個同位封包，成本為當一個Segment傳送失敗時，仍要再重傳一次，其重傳成本為懲罰函數(PenaltyFunction)：簡化：136SegmentSizeDetermination額外成本SegmentSizeDetermination當懲罰函數最小時，可得最佳Segment封包數。給定一γ值即解得一個n值。137SegmentSizeDetermination當懲罰函AdaptiveUDPMechanismUDP協(xié)定沒有調整傳送速率之機制。必須在應用層加入自動調整速率之機制。影響資料傳送速率之決定因素：瓶頸鏈結之頻寬。傳送端如何獲得瓶頸鏈結之可用頻寬？如在傳送者上行端假設使用者已知上行端之實際可用頻寬。如在核心網路內部需利用探測封包(ProbingPacket)的方式，幫助瞭解網路內部瓶頸頻寬(bottleneckbandwidth)的狀況。138AdaptiveUDPMechanismUDP協(xié)定沒有調UDPwithProbingPackets傳送端定期發(fā)送探測封包量測網路狀態(tài)，根據其變化來調整合理傳送速率。接收端在ACK裡加入此項資訊。傳送端使用此資訊來調整合理傳送速率。目標：降低頻寬浪費或網路擁塞之機率。139UDPwithProbingPackets45PacketDispersionC.Dovroliset.al.,"Packet-DispersionTechniquesandaCapacity-EstimationMethodology,"IEEE/ACMTransactionsOnNetworking,VOL.12,No.6,Dec2004.緊鄰兩個封包通過瓶頸鏈結時，其封包距離有散開(Dispersion)之現象，此散開可當做瓶頸可用頻寬之估計依據，此法稱為PacketDispersion法。利用此PacketDispersion估計目前網路內部瓶頸的頻寬。140PacketDispersion46AdjustingCoefficientα為避免估計偏差(bias)對協(xié)定造成負面影響，以一校正係數α(AdjustingCoefficientα)修正估計結果。我們所測得之可用頻寬為調整資料傳送速度之一參考指標，其調整方式，可參考Yung-PingChungandYao-NanLien,"DesignofTCPCongestionControlTechniquesbyRouter-assistedApproach,"Sep.2005。141AdjustingCoefficientα47OutlineIntroductionRelatedWorkDesignofProtocolPacketLossRecoverySegmentSizeDeterminationAdaptiveUDPMechanismPerformanceEvaluationConclusion142OutlineIntroduction48參數估算與效能評估模擬工具：模擬環(huán)境為Cygwin下之ns2.28版。參數估算：計算最佳Segment數。用實驗估算調節(jié)式UDP機制之校正參數α值。效能評估：UDP-BasedApproach與其他傳輸協(xié)定之效能比較。143參數估算與效能評估模擬工具：49SegmentSize計算實驗目標：給定特定的網路環(huán)境，將懲罰函數(PenaltyFunction)最小化以找出最佳SegmentSize。參數數值範圍l1000bytes/packetm263packets/fragmentl×m=1/4MBγ0.5%~2%144SegmentSize計算實驗目標：給定特定的網路環(huán)境，將SegmentSize計算結果

(γ=0.005,0.01,0.015,0.02)145SegmentSize計算結果

(γ=0.005,0.0SegmentSize計算之敏感度分析不同網路封包遺失率下，求得SegmentSize變化情形。封包遺失率很低時，不太會發(fā)生封包遺失，求得的SegmentSize比較大。封包遺失率提高時，封包遺失就容易發(fā)生，求得的SegmentSize就較小。146SegmentSize計算之敏感度分析52AdaptiveUDPMechanism

α值參數估算實驗目標：利用Packet-Dispersion估計可用頻寬，利用實驗找出適當之校正參數α值供他人參考。147AdaptiveUDPMechanism

α值參數估算實AdaptiveUDPMechanism

α值參數估算實驗設計魚骨狀之網路架構。中介鏈結上有中介訊務流經其中。調整此魚骨拓樸之長度，並且控制實際可用頻寬之下，求取參考用之α值。148AdaptiveUDPMechanism

α值參數估算實AdaptiveUDPMechanism

α值參數估算實驗參數參數數值中介鏈結數1,3,5,7,9可用頻寬1～10Mbps。149AdaptiveUDPMechanism

α值參數估算實α值參數估算之實驗結果

(中介鏈結數=1)此例計算得到之α=0.897。150α值參數估算之實驗結果

(中介鏈結數=1)56α值參數估算之實驗結果

(中介鏈結數=3)此例計算得到之α=0.962。151α值參數估算之實驗結果

(中介鏈結數=3)57α值參數估算之實驗結果

(中介鏈結數=5)此例計算得到之α=0.944。152α值參數估算之實驗結果

(中介鏈結數=5)58α值參數估算之實驗結果

(中介鏈結數=7)此例計算得到之α=0.958。153α值參數估算之實驗結果

(中介鏈結數=7)59α值參數估算之實驗結果

(中介鏈結數=9)此例計算得到之α=0.885。154α值參數估算之實驗結果

(中介鏈結數=9)60中介鏈結數之變化與校正參數α之間的關係中介鏈結數變化與校正參數α之間的關係，發(fā)現α值之變化相當平穩(wěn)。中介鏈結數之大小對α值的影響不大。得到最後估計之α值為0.93。155中介鏈結數之變化與校正參數α之間的關係61UDP-BasedApproach與其他傳輸協(xié)定

之效能比較實驗目標：設計一個網路上發(fā)生FUB與BoA之網路場景，各種不同的傳輸協(xié)定進行效能分析與比較。實驗設計：UDP-BasedApproach為實驗組。TCP-Reno、TCP-Vegas為對照組。核心網路(CoreNetwork)中有充沛頻寬，雙向有1Gbps頻寬，接取網路為非對稱網路。156UDP-BasedApproach與其他傳輸協(xié)定

之效能比UDP-BasedApproach與其他傳輸協(xié)定

效能比較之網路拓樸核心網路上有R1、R2兩個路由器(Router)非對稱鏈結所接取的的機器有X1～X5及Y1共六臺：X1～X5同時會至Y1下載資料。Y1亦有5個Session同時至X1～X5下載資料。在Y1至R2的上行鏈結會發(fā)生FUB與BoA的問題。157UDP-BasedApproach與其他傳輸協(xié)定

效能比較UDP-BasedApproach與其他傳輸協(xié)定

效能比較之實驗參數參數數值傳輸協(xié)定TCP-Reno、TCP-Vegas、UDP-BasedApproach

檔案片段大小1/4MB核心網路頻寬1Gbps接取網路上下行頻寬(64Kbps,2Mbps)、(64Kbps,4Mbps)、(64Kbps,6Mbps)、(64Kbps,8Mbps)核心網路封包遺失率γ0%,0.1%,0.5%,1%,5%,10%158UDP-BasedApproach與其他傳輸協(xié)定

效能比較傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0)TCPReno每個Session平均：164.8秒。(LostACK:41)TCPVegas每個Session平均：188秒。(LostACK:0)AdaptiveUDP每個Session平均：110.7秒。(重傳次數:0)159傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.001)TCPReno每個Session平均：201.5秒。(LostACK:66)TCPVegas每個Session平均：187.8秒。(LostACK:0)AdaptiveUDP每個Session平均：112秒。(重傳次數:0)160傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.005)TCPReno每個Session平均：150.1秒。(LostACK:39)TCPVegas每個Session平均：159.2秒。(LostACK:0)AdaptiveUDP每個Session平均：115秒。(重傳次數:4)161傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.01)TCPReno每個Session平均：150.2秒。(LostACK:34)TCPVegas每個Session平均：164秒。(LostACK:0)AdaptiveUDP每個Session平均：119.6秒。(重傳次數:15)162傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbp傳輸協(xié)定效能比較之實驗結果

(上行64Kbps,下行2Mbps,γ=0.05)TCPReno每個Session平均：208.7秒。(LostACK: