選擇性保證封包到達(dá)之通訊協(xié)定設(shè)計(jì)課件

選擇性保證封包到達(dá)之通訊協(xié)定設(shè)計(jì)Student:Ming-HanWuAdvisor:Yao-NanLien2007Partial-ReliableTCP

選擇性保證封包到達(dá)之通訊協(xié)定設(shè)計(jì)Student:Ming-Page1Outline IntroductionBackground/RelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction2Outline IntroductionBackground/RelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction3Introduction隨著網(wǎng)路的進(jìn)步與發(fā)展，許多新興的數(shù)位資訊，在網(wǎng)路上傳輸時(shí)並未要求每一個(gè)封包均確實(shí)送達(dá)目的地。例如影音資訊，因?yàn)槭褂谜卟灰?，所以影音封包不需每個(gè)都要無誤到達(dá)。由於影像在網(wǎng)路上傳輸是經(jīng)過mpeg格式壓縮，而mpeg會(huì)將影片壓縮成不同重要程度的影格，若封包遺失，將會(huì)造成不同程度的影像品質(zhì)影響。Introduction隨著網(wǎng)路的進(jìn)步與發(fā)展，許多新興的數(shù)位4IntroductionDifferentiationofpacketswithinanMPEGmediastreamMPEGframes(I)Intraframecoded,key-frame(max.priority)(P)Predicted(B)Bidirectional有Iframes才能組成Pframes，而有I與Pframes才能組成Bframes

frame的重要程度:I>P>B。IntroductionDifferentiationo5Introduction前述資訊服務(wù)類型不須確保所有封包到達(dá)，不同重要程度的封包掉了會(huì)造成服務(wù)品質(zhì)不同程度的影響。UDP與TCP都對所有封包一視同仁，前者不做任何保證，而後者雖可保證所有封包的送達(dá)，但效率較差。Introduction前述資訊服務(wù)類型不須確保所有封包到達(dá)6IntroductionUDPvs.TCP(在網(wǎng)路情況差，資源不足情況下)UDP封包傳輸速率都相同，無法根據(jù)網(wǎng)路狀況來調(diào)節(jié)封包傳送速度，可能會(huì)讓網(wǎng)路狀況更差。沒有重傳的機(jī)制，封包遺失掉落時(shí)不做任何處理。Impactoftransmittingvideodata因?yàn)椴槐ＷC資料能準(zhǔn)確到達(dá)，且不對遺失的封包做處理，當(dāng)重要性高的封包遺失，影像品質(zhì)大打折扣。IntroductionUDPvs.TCP(在網(wǎng)路情況差7IntroductionUDPvs.TCP(在網(wǎng)路情況差，資源不足情況下)TCP可以根據(jù)網(wǎng)路狀況來調(diào)整封包傳輸速率。有重傳機(jī)制，所以能夠確保每個(gè)封包準(zhǔn)確到達(dá)。Impactoftransmittingvideodata保證封包到達(dá)，當(dāng)封包遺失，啟動(dòng)重傳機(jī)制，但重傳封包delaytime會(huì)較高，可能封包到了也已經(jīng)失效。IntroductionUDPvs.TCP(在網(wǎng)路情況差8Introduction由上述得知UDP一視同仁不保護(hù)封包=>重要的封包遺失TCP一視同仁保護(hù)封包=>delaytime拉長都無法適用於封包有重要等級之分的資訊服務(wù)。如果我們選擇性保護(hù)封包?Introduction由上述得知9IntroductionOurMotivation

提出一個(gè)有選擇性保證封包傳送機(jī)制的TCP，Partial-ReliableTCP，能根據(jù)封包的不同重要程度，選擇性保證封包傳達(dá)，配合上層應(yīng)用程式的需求，可以在網(wǎng)路狀況較差的情況下，達(dá)到應(yīng)用程式的服務(wù)品質(zhì)。IntroductionOurMotivation10Outline IntroductionBackground/RelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationconclusionOutline Introduction11Outline IntroductionRelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationconclusionOutline Introduction12PR-TCP-basicDesignObjective在封包遺失時(shí)，配合AP的需求，根據(jù)遺失封包的不同重要程度，做選擇性的重傳，在網(wǎng)路狀況不好的情況下，維持資訊服務(wù)品質(zhì)。

PR-TCP-basicDesignObjective13PR-TCP-basicDesignissue如何調(diào)控速度?如何應(yīng)付網(wǎng)路壅塞?如何只重傳較重要的封包?如何讓重傳能更有效率?如何降低delaytime?PR-TCP-basicDesignissue14PR-TCP-basicProtectionclass在PR-TCP-basic中將封包分為三個(gè)種類:Regular:一般性的封包。Certified:在時(shí)效內(nèi)是重要的封包，過了時(shí)效就不重要。Registed:重要的封包，必須確保無誤送達(dá)。在packetheader新增以下欄位:pt:記錄packet的type。B_pt:記錄前一個(gè)packet的packettype。N_pt:記錄下一個(gè)packet的packettype。讓PR-TCP兩端知道傳送封包的種類。PR-TCP-basicProtectionclass15PR-TCP-basicSetPSH==1封包所攜帶的資料就會(huì)被直接上遞給上層的應(yīng)用程式而無需經(jīng)過TCP處理了。延伸TCPSack，修改傳送端與接收端,在TCPheader加入SACK選項(xiàng).允許接收回傳目前已經(jīng)連續(xù)收到的區(qū)段.傳送端可藉由這些資訊得知那些packet是沒被收到的並直接重送。PR-TCP-basicSetPSH==116PR-TCP-basicSlowStart(CWND<Threshold)當(dāng)connection建立以後，cwnd大小以加倍的方式增加速率，直到loss的產(chǎn)生CongestionAvoidance

(CWND>Threshold)AIMD(additiveincreaseandmultiplicativedecrease)FastSelectiveRetransmit&FastRecovery當(dāng)封包遺失，降低傳送速度僅重傳指定封包。SlowStarttimeoutPacketlossCongestionAvoidance(RTT)thresholdthresholdPR-TCP-basicSlowStart(CWND<17PR-TCP-basicPacketRetransmission:Registed傳送端判斷遺失的封包如果是Registed，則重傳。Certified傳送端判斷遺失的封包如果是Certified，則在有限時(shí)效內(nèi)重傳。If(packetlife==0)donotretransmit; Elseretransmit;packetlife--。Regular傳送端判斷遺失的封包如果是Regular，則不重傳。接收端判斷遺失的封包中如果是Regular，則不等待此封包。PR-TCP-basicPacketRetransmiss18PR-TCP-basicPacketLifeControlscheme(suitableforCertifiedclass)在packetheader裡新增一個(gè)欄位”TL”(TimeLimit)記錄封包重傳時(shí)間限制Registed的封包，設(shè)定TL為0，此封包必須無誤到達(dá)。Certified的封包，設(shè)定TL為非0值，超出TL則放棄重傳。FNP(forwardNextPacket)message:告知接收端，已經(jīng)不再重傳了。當(dāng)接收端收到fnp時(shí)當(dāng)做此封包已收到，不再等待。PR-TCP-basicPacketLifeContro19PR-TCP-basic

SenderReceiver123X4ACK1ACK45ACK5X23XACK2封包2的重傳等待時(shí)間封包3的重傳等待時(shí)間Time’supTime’supFWDNP2FWDNP3PR-TCP-basicSenderReceiver12320PR-TCP-basicPR-TCPstatediagramCAFFStartCWND>=SSTHRESHDuplicateAckTimeoutSSNewAck/CoarsegainedtimeoutNewAckPacketloss/timeoutPacketloss/TimeoutNewAck/regularSlowStart(SS)CongestionAvoidance(CA)FastSelectiveRetransmitandFastRecovery(FF)PR-TCP-basicPR-TCPstatediagr21PR-TCP-basic事件狀態(tài)PR-TCP傳送端的行為說明接收到先前還未收到的ACK慢啟動(dòng)階段(SS)CWND=CWND*2當(dāng)CWND>threshold時(shí)，進(jìn)入congestionavoidance階段在每一個(gè)RTT便增加一倍。接收到先前還未收到的ACK擁塞避免階段(CA)CWND=CWND+1在每一個(gè)RTT，CWND呈線性增加。封包遺失判斷(SS&CA)threshold=CWND*(1/2)CWND=threshold進(jìn)入congestionavoidance階段快速回覆以及減半降速。逾期(timeout)(SS&CA)threshold=CWND*(1/2)CWND=1進(jìn)入SlowStart階段進(jìn)入SlowStart階段。PR-TCP-basic事件狀態(tài)PR-TCP傳送端的行為說22PR-TCP-basic接到Ack的反應(yīng)PR-TCP-basic接到Ack的反應(yīng)23PR-TCP-basicBasicversion:更改傳送端及接收端的通訊協(xié)定?？梢愿鶕?jù)網(wǎng)路狀況調(diào)整傳送速度，減緩網(wǎng)路壅塞情況。有效的達(dá)到部份保護(hù)封包的目的，讓AP更有彈性的應(yīng)用。但是，改變兩端的通訊協(xié)定，較難推行。PR-TCP-basicBasicversion:24Outline IntroductionRelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationconclusionOutline Introduction25PR-TCP-singlesideDesignObjectivePR-TCP-singleside只需更改一端的TCP，可以應(yīng)用在如client/server這種一對多架構(gòu)中，只需更改server端的TCP，而client端可以使用原本TCP，不用作變更。

PR-TCP-singlesideDesignObjec26PR-TCP-singlesideDesignissue如何調(diào)控速度?(samewithTCP-Reno)如何應(yīng)付網(wǎng)路壅塞?(samewithTCP-Reno)當(dāng)封包遺失如何避免重傳較不重要封包造成delaytime?接收端沒收到packet會(huì)等待，並要求重送PR-TCP-singlesideDesignissue27PR-TCP-singlesideProtectionclass在PR-TCP-singleside中將封包分為兩個(gè)種類:Regular:一般性的封包。Registed:重要的封包，必須確保無誤送達(dá)。在packetheader新增以下欄位:pt:記錄packet的type。SetPSH==1封包所攜帶的資料就會(huì)被直接上遞給上層的應(yīng)用程式而無需經(jīng)過TCP處理了。PR-TCP-singlesideProtection28PR-TCP-singlesideTCPheadersizeV.S.TCPPacketsizeHeadersize:20bytePacketsize:1500byteHeadersize<<<<<<Packetsize如果複製多個(gè)僅有header的packet傳送，是否可以接收端因?yàn)閜acketloss而等待的機(jī)會(huì)?PR-TCP-singleside29PR-TCP-singlesideAnalysisofduplicateheader、timeoutandlossrate。PR-TCP-singlesideAnalysisof30PR-TCP-singleside因?yàn)閔eader的大小遠(yuǎn)小於packet大小，多傳送僅有header的packet不會(huì)增加太高的overhead，但是可以在網(wǎng)路狀況比較不好的情況下減低傳送端timeout的機(jī)會(huì)。TCP接收端如果接收到重複號碼的封包會(huì)直接drop，不會(huì)造成影響。如果TCP接收端收到的封包，是沒有payload的，上層的AP會(huì)做處理。PR-TCP-singleside因?yàn)閔eader的大小遠(yuǎn)31PR-TCP-singleside

PP(PacketProtection)scheme

Red:RegistedWhite:RegularRegisted:複製含有header及部分payload的封包Regular:複製多個(gè)僅含有header的封包13214123423113PR-TCP-singleside

PP(Packet32PR-TCP-singlesidePacketRetransmission:Registed傳送端判斷遺失的封包如果是Registed，則重傳。Regular傳送端判斷遺失的封包如果是Regular，則重傳只有header的封包。PR-TCP-singlesidePacketRetra33PR-TCP

Packetlossrecoveryscheme

為了避免封包損傷導(dǎo)致太多的資料重傳，在每n個(gè)封包之後，加上一個(gè)同位封包(ParityPacket)，當(dāng)一個(gè)Segment中任何一個(gè)封包發(fā)生遺失時(shí)，就可利用同位封包將所遺失的封包還原PR-TCP

Packetlossrecoverys34Outline IntroductionRelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationconclusionOutline Introduction35Performanceevaluation實(shí)驗(yàn)設(shè)計(jì)實(shí)驗(yàn)工具在NS-2軟體上做模擬實(shí)驗(yàn)方法拓樸環(huán)境由3~10個(gè)節(jié)點(diǎn)組成，依各個(gè)子實(shí)驗(yàn)分別調(diào)整不同的參數(shù)並觀察其結(jié)果在部份子實(shí)驗(yàn)中以具有burst性質(zhì)的訊務(wù)加入其中以增加網(wǎng)路的變化以TCPReno，TCPVegas，UDP，做為對照組參數(shù)範(fàn)圍節(jié)點(diǎn)數(shù)目3~10連結(jié)頻寬1~10MbpsPacketsize1000bytestrafficload300~900Kbps實(shí)驗(yàn)參數(shù)Performanceevaluation實(shí)驗(yàn)設(shè)計(jì)參數(shù)範(fàn)圍36Performanceevaluation可解畫面比例(thefractionofdecodableframes)傳送的畫面中，有多少比例的畫面是可以被解出來的，當(dāng)接收端接受到一個(gè)畫面的資料量超過一個(gè)門檻，認(rèn)為此畫面是可以直接被解壓縮的，但是一個(gè)畫面可以真正被解壓縮，除了接收的資料量到達(dá)門檻外，這個(gè)畫面所參考的畫面也要是可被解壓縮的。畫面可解壓縮的條件門檻值:0~1(ap定義)，允許幾%的資料遺失I-frame:只要收到的資料量超過門檻即可P-frame:資料量超過門檻外，所參考的I-frame也要可解壓縮B-frame:資料量超過門檻外，所參考的I-frame，P-frame也要可解壓縮Performanceevaluation可解畫面比例(t37PerformanceevaluationPeaksignal-to-noiseratio（PSNR）,峰值訊雜比，是一個(gè)較為大眾認(rèn)可的影像品質(zhì)評鑑客觀指標(biāo)，計(jì)算方式為: 比較原始影像S和目的影像D的亮度部份Y。

這個(gè)值越大，表示目的影像和原始影像的差距越小，也就是畫面品質(zhì)越好，以下為計(jì)算公式:PerformanceevaluationPeaksig38實(shí)驗(yàn)1:影片中I、P、Bframe

的封包數(shù)量解析

Foreman實(shí)驗(yàn)短片實(shí)驗(yàn)1:影片中I、P、Bframe

的封包數(shù)量解析Fo39實(shí)驗(yàn)1:影片中I、P、Bframe

的封包數(shù)量解析Stefan實(shí)驗(yàn)短片實(shí)驗(yàn)1:影片中I、P、Bframe

的封包數(shù)量解析Ste40

實(shí)驗(yàn)2A調(diào)整source跟destination之間的hop數(shù)觀察Delaytime可解畫面數(shù)PSNR值影像觀察UDP(512kbps)bursttrafficat4、9sec.

實(shí)驗(yàn)2A調(diào)整source跟destination之間的ho41PR-TCP與其他通訊協(xié)定的delaytime

比較

path越長的情況下，delaytime越長PR-TCP的delaytime略高於UDP，低於TCPPR-TCP與其他通訊協(xié)定的delaytime

比較pa42PR-TCP與其他通訊協(xié)定的

可解畫面數(shù)比較

Path越長，可解畫面數(shù)越低PR-TCP的可解畫面數(shù)皆高於其他通訊協(xié)定PR-TCP與其他通訊協(xié)定的

可解畫面數(shù)比較Path越長43PR-TCP與其他通訊協(xié)定的

PSNR值的比較Path越長，PSNR值越小PR-TCP的PSNR值在path較長的情況下PSNR值較其他通訊協(xié)定高PR-TCP與其他通訊協(xié)定的

PSNR值的比較Path越長，44

實(shí)驗(yàn)2B調(diào)整2-3之間的loserate觀察Delaytime可解畫面數(shù)PSNR值UDP(512kbps)bursttrafficat4、9sec.

實(shí)驗(yàn)2B調(diào)整2-3之間的loserate45PR-TCP與其他通訊協(xié)定的delaytime

比較

Lossrate越大，delaytime越長PR-TCP與其他通訊協(xié)定的delaytime

比較Lo46PR-TCP與其他通訊協(xié)定的

可解畫面數(shù)比較

Lossrate越大，可解畫面數(shù)越低PR-TCP與其他通訊協(xié)定的

可解畫面數(shù)比較Lossra47PR-TCP與其他通訊協(xié)定的

PSNR值的比較Lossrate越大，PSNR值越小PR-TCP的PSNR值高於其他通訊協(xié)定registed的數(shù)量越多PSNR值越高PR-TCP與其他通訊協(xié)定的

PSNR值的比較Lossra48PR-TCP與其他通訊協(xié)定的

影像模擬比較foremanPR-TCP(i+p)PR-TCP與其他通訊協(xié)定的

影像模擬比較foremanPR49PR-TCP與其他通訊協(xié)定的

影像模擬比較PR-TCP(i)PR-TCP(ss)PR-TCP與其他通訊協(xié)定的

影像模擬比較PR-TCP(i50PR-TCP與其他通訊協(xié)定的

影像模擬比較UDPTCPRenoPR-TCP與其他通訊協(xié)定的

影像模擬比較UDPTCPRe51Outline IntroductionRelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction52conclusion透過了模擬實(shí)驗(yàn)，PR-TCP可以有效的達(dá)到選擇性保證封包傳達(dá)的目的，能有效的確保重要封包的到達(dá)又不會(huì)因?yàn)楫?dāng)不重要封包遺失而浪費(fèi)時(shí)間重傳。並且我們在應(yīng)用層上加上自動(dòng)重建遺失之封包、降低packetloss的機(jī)會(huì)。以videoconference傳輸為例，在網(wǎng)路的資源較少，壅塞狀況較嚴(yán)重的情況之下，比TCP最多降低約25%的aaplicationdelaytime，比UDP及TCP在影像品質(zhì)PSNR值最多提升15%。conclusion透過了模擬實(shí)驗(yàn)，PR-TCP可以有效的達(dá)53Q&AQ&APage54RelatedworkTCP的特色Transportlayerprotocolpoint-to-point:一個(gè)傳送端，一個(gè)接收端reliable,in-order connection-orientedflowcontrolled:senderwillnotoverwhelmreceiver傳輸速率由擁塞視窗(congestionwindow)所控制CongestionistriggerbypacketlossortimeoutRelatedworkTCP的特色55RelatedworkCongestioncontrolatsender:只能依據(jù)觀察到的網(wǎng)路狀態(tài)(封包遺失或延遲)來推論是否發(fā)生congestion

CWND(congestionwindow)藉由察覺網(wǎng)路的擁塞做動(dòng)態(tài)調(diào)整Sender端如何察覺網(wǎng)路的擁塞呢?losstimeoutor3duplicateacksTCPsenderreducesrate(cwnd)afterlossevent主要的機(jī)制SlowStartCongestionAvoidanceAIMD(additiveincreaseandmultiplicativedecrease)FastRetransmit&FastRecoveryrate

=

CWNDRTT

Bytes/secRelatedworkCongestioncontrol56RelatedworkOtherprotocolDCCP為DatagramCongestionControlProtocol的縮寫。由於一些Delay-Sensitive的應(yīng)用服務(wù)，像是StreamingMedia以及Telephony之類的訊務(wù)服務(wù)，較在乎的是資料到達(dá)目的地之時(shí)效性，而不注重資料的完整可靠性。所以DCCP的研究，即設(shè)計(jì)一個(gè)可讓已經(jīng)在使用的訊務(wù)服務(wù)達(dá)到傳輸時(shí)效性，較不在乎資料完整性，並且不破壞整個(gè)網(wǎng)路穩(wěn)定品質(zhì)的網(wǎng)路協(xié)定，為其主要目的。RelatedworkOtherprotocol57RelatedWorkDCCP:DatagramCongestionControlProtocolUnreliable(noautomaticretransmission)PacketnumbersAcknowledgementsInformationonlostpacketsInformationaboutthenetwork(RTT)Congestioncontrol(TCP-like,TFRC)

DCCPRFC4340,March2006thinkofDCCPasTCPminusbytestreamsemanticsandreliabilityorasUDPpluscongestioncontrol,handshakes,andacknowledgementsRelatedWorkDCCP:DatagramCon58RelatedworkOtherprotocolRTP即時(shí)傳輸協(xié)定和即時(shí)控制協(xié)定端對端傳輸服務(wù)的即時(shí)傳輸協(xié)定，用來支援在單目標(biāo)廣播和多目標(biāo)廣播網(wǎng)路服務(wù)中傳輸即時(shí)資料不擔(dān)保在遞送過程中不丟失資訊包或者防止資訊包的次序不被打亂RTCP:用來監(jiān)視服務(wù)品質(zhì)和傳送有關(guān)與會(huì)者的資訊

RelatedworkOtherprotocol59PR-TCP-basicSenderReceiver123X4ACK1ACK3ACK4Packet2wasloss.Andit’sRegistedorcertified.Senderwillretransmitpacket2PR-TCP-basicSenderReceiver123X60PR-TCP-basicSenderReceiver123X4ACK1ACK3ACK4Packet2wasloss.Andit’sregular.Senderwillnotretransmitpacket2Receiverwillnotwaitpacket2PR-TCP-basicSenderReceiver123X61PR-TCP-singlesideSenderReceiver123X4ACK1ACK3ACK4Ifpacket2isregisted:retransmitpacket2withpayloadElseretransmitduplicatedpacket2withoutpayloadPR-TCP-singlesideSenderReceiv62選擇性保證封包到達(dá)之通訊協(xié)定設(shè)計(jì)Student:Ming-HanWuAdvisor:Yao-NanLien2007Partial-ReliableTCP

選擇性保證封包到達(dá)之通訊協(xié)定設(shè)計(jì)Student:Ming-Page63Outline IntroductionBackground/RelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction64Outline IntroductionBackground/RelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction65Introduction隨著網(wǎng)路的進(jìn)步與發(fā)展，許多新興的數(shù)位資訊，在網(wǎng)路上傳輸時(shí)並未要求每一個(gè)封包均確實(shí)送達(dá)目的地。例如影音資訊，因?yàn)槭褂谜卟灰?，所以影音封包不需每個(gè)都要無誤到達(dá)。由於影像在網(wǎng)路上傳輸是經(jīng)過mpeg格式壓縮，而mpeg會(huì)將影片壓縮成不同重要程度的影格，若封包遺失，將會(huì)造成不同程度的影像品質(zhì)影響。Introduction隨著網(wǎng)路的進(jìn)步與發(fā)展，許多新興的數(shù)位66IntroductionDifferentiationofpacketswithinanMPEGmediastreamMPEGframes(I)Intraframecoded,key-frame(max.priority)(P)Predicted(B)Bidirectional有Iframes才能組成Pframes，而有I與Pframes才能組成Bframes

frame的重要程度:I>P>B。IntroductionDifferentiationo67Introduction前述資訊服務(wù)類型不須確保所有封包到達(dá)，不同重要程度的封包掉了會(huì)造成服務(wù)品質(zhì)不同程度的影響。UDP與TCP都對所有封包一視同仁，前者不做任何保證，而後者雖可保證所有封包的送達(dá)，但效率較差。Introduction前述資訊服務(wù)類型不須確保所有封包到達(dá)68IntroductionUDPvs.TCP(在網(wǎng)路情況差，資源不足情況下)UDP封包傳輸速率都相同，無法根據(jù)網(wǎng)路狀況來調(diào)節(jié)封包傳送速度，可能會(huì)讓網(wǎng)路狀況更差。沒有重傳的機(jī)制，封包遺失掉落時(shí)不做任何處理。Impactoftransmittingvideodata因?yàn)椴槐ＷC資料能準(zhǔn)確到達(dá)，且不對遺失的封包做處理，當(dāng)重要性高的封包遺失，影像品質(zhì)大打折扣。IntroductionUDPvs.TCP(在網(wǎng)路情況差69IntroductionUDPvs.TCP(在網(wǎng)路情況差，資源不足情況下)TCP可以根據(jù)網(wǎng)路狀況來調(diào)整封包傳輸速率。有重傳機(jī)制，所以能夠確保每個(gè)封包準(zhǔn)確到達(dá)。Impactoftransmittingvideodata保證封包到達(dá)，當(dāng)封包遺失，啟動(dòng)重傳機(jī)制，但重傳封包delaytime會(huì)較高，可能封包到了也已經(jīng)失效。IntroductionUDPvs.TCP(在網(wǎng)路情況差70Introduction由上述得知UDP一視同仁不保護(hù)封包=>重要的封包遺失TCP一視同仁保護(hù)封包=>delaytime拉長都無法適用於封包有重要等級之分的資訊服務(wù)。如果我們選擇性保護(hù)封包?Introduction由上述得知71IntroductionOurMotivation

提出一個(gè)有選擇性保證封包傳送機(jī)制的TCP，Partial-ReliableTCP，能根據(jù)封包的不同重要程度，選擇性保證封包傳達(dá)，配合上層應(yīng)用程式的需求，可以在網(wǎng)路狀況較差的情況下，達(dá)到應(yīng)用程式的服務(wù)品質(zhì)。IntroductionOurMotivation72Outline IntroductionBackground/RelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationconclusionOutline Introduction73Outline IntroductionRelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationconclusionOutline Introduction74PR-TCP-basicDesignObjective在封包遺失時(shí)，配合AP的需求，根據(jù)遺失封包的不同重要程度，做選擇性的重傳，在網(wǎng)路狀況不好的情況下，維持資訊服務(wù)品質(zhì)。

PR-TCP-basicDesignObjective75PR-TCP-basicDesignissue如何調(diào)控速度?如何應(yīng)付網(wǎng)路壅塞?如何只重傳較重要的封包?如何讓重傳能更有效率?如何降低delaytime?PR-TCP-basicDesignissue76PR-TCP-basicProtectionclass在PR-TCP-basic中將封包分為三個(gè)種類:Regular:一般性的封包。Certified:在時(shí)效內(nèi)是重要的封包，過了時(shí)效就不重要。Registed:重要的封包，必須確保無誤送達(dá)。在packetheader新增以下欄位:pt:記錄packet的type。B_pt:記錄前一個(gè)packet的packettype。N_pt:記錄下一個(gè)packet的packettype。讓PR-TCP兩端知道傳送封包的種類。PR-TCP-basicProtectionclass77PR-TCP-basicSetPSH==1封包所攜帶的資料就會(huì)被直接上遞給上層的應(yīng)用程式而無需經(jīng)過TCP處理了。延伸TCPSack，修改傳送端與接收端,在TCPheader加入SACK選項(xiàng).允許接收回傳目前已經(jīng)連續(xù)收到的區(qū)段.傳送端可藉由這些資訊得知那些packet是沒被收到的並直接重送。PR-TCP-basicSetPSH==178PR-TCP-basicSlowStart(CWND<Threshold)當(dāng)connection建立以後，cwnd大小以加倍的方式增加速率，直到loss的產(chǎn)生CongestionAvoidance

(CWND>Threshold)AIMD(additiveincreaseandmultiplicativedecrease)FastSelectiveRetransmit&FastRecovery當(dāng)封包遺失，降低傳送速度僅重傳指定封包。SlowStarttimeoutPacketlossCongestionAvoidance(RTT)thresholdthresholdPR-TCP-basicSlowStart(CWND<79PR-TCP-basicPacketRetransmission:Registed傳送端判斷遺失的封包如果是Registed，則重傳。Certified傳送端判斷遺失的封包如果是Certified，則在有限時(shí)效內(nèi)重傳。If(packetlife==0)donotretransmit; Elseretransmit;packetlife--。Regular傳送端判斷遺失的封包如果是Regular，則不重傳。接收端判斷遺失的封包中如果是Regular，則不等待此封包。PR-TCP-basicPacketRetransmiss80PR-TCP-basicPacketLifeControlscheme(suitableforCertifiedclass)在packetheader裡新增一個(gè)欄位”TL”(TimeLimit)記錄封包重傳時(shí)間限制Registed的封包，設(shè)定TL為0，此封包必須無誤到達(dá)。Certified的封包，設(shè)定TL為非0值，超出TL則放棄重傳。FNP(forwardNextPacket)message:告知接收端，已經(jīng)不再重傳了。當(dāng)接收端收到fnp時(shí)當(dāng)做此封包已收到，不再等待。PR-TCP-basicPacketLifeContro81PR-TCP-basic

SenderReceiver123X4ACK1ACK45ACK5X23XACK2封包2的重傳等待時(shí)間封包3的重傳等待時(shí)間Time’supTime’supFWDNP2FWDNP3PR-TCP-basicSenderReceiver12382PR-TCP-basicPR-TCPstatediagramCAFFStartCWND>=SSTHRESHDuplicateAckTimeoutSSNewAck/CoarsegainedtimeoutNewAckPacketloss/timeoutPacketloss/TimeoutNewAck/regularSlowStart(SS)CongestionAvoidance(CA)FastSelectiveRetransmitandFastRecovery(FF)PR-TCP-basicPR-TCPstatediagr83PR-TCP-basic事件狀態(tài)PR-TCP傳送端的行為說明接收到先前還未收到的ACK慢啟動(dòng)階段(SS)CWND=CWND*2當(dāng)CWND>threshold時(shí)，進(jìn)入congestionavoidance階段在每一個(gè)RTT便增加一倍。接收到先前還未收到的ACK擁塞避免階段(CA)CWND=CWND+1在每一個(gè)RTT，CWND呈線性增加。封包遺失判斷(SS&CA)threshold=CWND*(1/2)CWND=threshold進(jìn)入congestionavoidance階段快速回覆以及減半降速。逾期(timeout)(SS&CA)threshold=CWND*(1/2)CWND=1進(jìn)入SlowStart階段進(jìn)入SlowStart階段。PR-TCP-basic事件狀態(tài)PR-TCP傳送端的行為說84PR-TCP-basic接到Ack的反應(yīng)PR-TCP-basic接到Ack的反應(yīng)85PR-TCP-basicBasicversion:更改傳送端及接收端的通訊協(xié)定?？梢愿鶕?jù)網(wǎng)路狀況調(diào)整傳送速度，減緩網(wǎng)路壅塞情況。有效的達(dá)到部份保護(hù)封包的目的，讓AP更有彈性的應(yīng)用。但是，改變兩端的通訊協(xié)定，較難推行。PR-TCP-basicBasicversion:86Outline IntroductionRelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationconclusionOutline Introduction87PR-TCP-singlesideDesignObjectivePR-TCP-singleside只需更改一端的TCP，可以應(yīng)用在如client/server這種一對多架構(gòu)中，只需更改server端的TCP，而client端可以使用原本TCP，不用作變更。

PR-TCP-singlesideDesignObjec88PR-TCP-singlesideDesignissue如何調(diào)控速度?(samewithTCP-Reno)如何應(yīng)付網(wǎng)路壅塞?(samewithTCP-Reno)當(dāng)封包遺失如何避免重傳較不重要封包造成delaytime?接收端沒收到packet會(huì)等待，並要求重送PR-TCP-singlesideDesignissue89PR-TCP-singlesideProtectionclass在PR-TCP-singleside中將封包分為兩個(gè)種類:Regular:一般性的封包。Registed:重要的封包，必須確保無誤送達(dá)。在packetheader新增以下欄位:pt:記錄packet的type。SetPSH==1封包所攜帶的資料就會(huì)被直接上遞給上層的應(yīng)用程式而無需經(jīng)過TCP處理了。PR-TCP-singlesideProtection90PR-TCP-singlesideTCPheadersizeV.S.TCPPacketsizeHeadersize:20bytePacketsize:1500byteHeadersize<<<<<<Packetsize如果複製多個(gè)僅有header的packet傳送，是否可以接收端因?yàn)閜acketloss而等待的機(jī)會(huì)?PR-TCP-singleside91PR-TCP-singlesideAnalysisofduplicateheader、timeoutandlossrate。PR-TCP-singlesideAnalysisof92PR-TCP-singleside因?yàn)閔eader的大小遠(yuǎn)小於packet大小，多傳送僅有header的packet不會(huì)增加太高的overhead，但是可以在網(wǎng)路狀況比較不好的情況下減低傳送端timeout的機(jī)會(huì)。TCP接收端如果接收到重複號碼的封包會(huì)直接drop，不會(huì)造成影響。如果TCP接收端收到的封包，是沒有payload的，上層的AP會(huì)做處理。PR-TCP-singleside因?yàn)閔eader的大小遠(yuǎn)93PR-TCP-singleside

PP(PacketProtection)scheme

Red:RegistedWhite:RegularRegisted:複製含有header及部分payload的封包Regular:複製多個(gè)僅含有header的封包13214123423113PR-TCP-singleside

PP(Packet94PR-TCP-singlesidePacketRetransmission:Registed傳送端判斷遺失的封包如果是Registed，則重傳。Regular傳送端判斷遺失的封包如果是Regular，則重傳只有header的封包。PR-TCP-singlesidePacketRetra95PR-TCP

Packetlossrecoveryscheme

為了避免封包損傷導(dǎo)致太多的資料重傳，在每n個(gè)封包之後，加上一個(gè)同位封包(ParityPacket)，當(dāng)一個(gè)Segment中任何一個(gè)封包發(fā)生遺失時(shí)，就可利用同位封包將所遺失的封包還原PR-TCP

Packetlossrecoverys96Outline IntroductionRelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationconclusionOutline Introduction97Performanceevaluation實(shí)驗(yàn)設(shè)計(jì)實(shí)驗(yàn)工具在NS-2軟體上做模擬實(shí)驗(yàn)方法拓樸環(huán)境由3~10個(gè)節(jié)點(diǎn)組成，依各個(gè)子實(shí)驗(yàn)分別調(diào)整不同的參數(shù)並觀察其結(jié)果在部份子實(shí)驗(yàn)中以具有burst性質(zhì)的訊務(wù)加入其中以增加網(wǎng)路的變化以TCPReno，TCPVegas，UDP，做為對照組參數(shù)範(fàn)圍節(jié)點(diǎn)數(shù)目3~10連結(jié)頻寬1~10MbpsPacketsize1000bytestrafficload300~900Kbps實(shí)驗(yàn)參數(shù)Performanceevaluation實(shí)驗(yàn)設(shè)計(jì)參數(shù)範(fàn)圍98Performanceevaluation可解畫面比例(thefractionofdecodableframes)傳送的畫面中，有多少比例的畫面是可以被解出來的，當(dāng)接收端接受到一個(gè)畫面的資料量超過一個(gè)門檻，認(rèn)為此畫面是可以直接被解壓縮的，但是一個(gè)畫面可以真正被解壓縮，除了接收的資料量到達(dá)門檻外，這個(gè)畫面所參考的畫面也要是可被解壓縮的。畫面可解壓縮的條件門檻值:0~1(ap定義)，允許幾%的資料遺失I-frame:只要收到的資料量超過門檻即可P-frame:資料量超過門檻外，所參考的I-frame也要可解壓縮B-frame:資料量超過門檻外，所參考的I-frame，P-frame也要可解壓縮Performanceevaluation可解畫面比例(t99PerformanceevaluationPeaksignal-to-noiseratio（PSNR）,峰值訊雜比，是一個(gè)較為大眾認(rèn)可的影像品質(zhì)評鑑客觀指標(biāo)，計(jì)算方式為: 比較原始影像S和目的影像D的亮度部份Y。

這個(gè)值越大，表示目的影像和原始影像的差距越小，也就是畫面品質(zhì)越好，以下為計(jì)算公式:PerformanceevaluationPeaksig100實(shí)驗(yàn)1:影片中I、P、Bframe

的封包數(shù)量解析

Foreman實(shí)驗(yàn)短片實(shí)驗(yàn)1:影片中I、P、Bframe

的封包數(shù)量解析Fo101實(shí)驗(yàn)1:影片中I、P、Bframe

的封包數(shù)量解析Stefan實(shí)驗(yàn)短片實(shí)驗(yàn)1:影片中I、P、Bframe

的封包數(shù)量解析Ste102

實(shí)驗(yàn)2A調(diào)整source跟destination之間的hop數(shù)觀察Delaytime可解畫面數(shù)PSNR值影像觀察UDP(512kbps)bursttrafficat4、9sec.

實(shí)驗(yàn)2A調(diào)整source跟destination之間的ho103PR-TCP與其他通訊協(xié)定的delaytime

比較

path越長的情況下，delaytime越長PR-TCP的delaytime略高於UDP，低於TCPPR-TCP與其他通訊協(xié)定的delaytime

比較pa104PR-TCP與其他通訊協(xié)定的

可解畫面數(shù)比較

Path越長，可解畫面數(shù)越低PR-TCP的可解畫面數(shù)皆高於其他通訊協(xié)定PR-TCP與其他通訊協(xié)定的

可解畫面數(shù)比較Path越長105PR-TCP與其他通訊協(xié)定的

PSNR值的比較Path越長，PSNR值越小PR-TCP的PSNR值在path較長的情況下PSNR值較其他通訊協(xié)定高PR-TCP與其他通訊協(xié)定的

PSNR值的比較Path越長，106

實(shí)驗(yàn)2B調(diào)整2-3之間的loserate觀察Delaytime可解畫面數(shù)PSNR值UDP(512kbps)bursttrafficat4、9sec.

實(shí)驗(yàn)2B調(diào)整2-3之間的loserate107PR-TCP與其他通訊協(xié)定的delaytime

比較

Lossrate越大，delaytime越長PR-TCP與其他通訊協(xié)定的delaytime

比較Lo108PR-TCP與其他通訊協(xié)定的

可解畫面數(shù)比較

Lossrate越大，可解畫面數(shù)越低PR-TCP與其他通訊協(xié)定的

可解畫面數(shù)比較Lossra109PR-TCP與其他通訊協(xié)定的

PSNR值的比較Lossrate越大，PSNR值越小PR-TCP的PSNR值高於其他通訊協(xié)定registed的數(shù)量越多PSNR值越高PR-TCP與其他通訊協(xié)定的

PSNR值的比較Lossra110PR-TCP與其他通訊協(xié)定的

影像模擬比較foremanPR-TCP(i+p)PR-TCP與其他通訊協(xié)定的

影像模擬比較foremanPR111PR-TCP與其他通訊協(xié)定的

影像模擬比較PR-TCP(i)PR-TCP(ss)PR-TCP與其他通訊協(xié)定的

影像模擬比較PR-TCP(i112PR-TCP與其他通訊協(xié)定的

影像模擬比較UDPTCPRenoPR-TCP與其他通訊協(xié)定的

影像模擬比較UDPTCPRe113Outline IntroductionRelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction114conclusion透過了模擬實(shí)驗(yàn)，PR-TCP可以有效的達(dá)到選擇性保證封包傳達(dá)的目的，能有效的確保重要封包的到達(dá)又不會(huì)因?yàn)楫?dāng)不重要封包遺失而浪費(fèi)時(shí)間重傳。並且我們在應(yīng)用層上加上自動(dòng)重建遺失之封包、降低packetloss的機(jī)會(huì)。以videoconference傳輸為例，在網(wǎng)路的資源較少，壅塞狀況較嚴(yán)重的情況之下，比TCP最多降低約25