选择性保证封包到达之通讯协定设计课件

選擇性保證封包到達之通訊協定設計Student:Ming-HanWuAdvisor:Yao-NanLien2007Partial-ReliableTCP

選擇性保證封包到達之通訊協定設計Student:Ming-Page1Outline IntroductionBackground/RelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction2Outline IntroductionBackground/RelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction3Introduction隨著網路的進步與發展，許多新興的數位資訊，在網路上傳輸時並未要求每一個封包均確實送達目的地。例如影音資訊，因為使用者不要求，所以影音封包不需每個都要無誤到達。由於影像在網路上傳輸是經過mpeg格式壓縮，而mpeg會將影片壓縮成不同重要程度的影格，若封包遺失，將會造成不同程度的影像品質影響。Introduction隨著網路的進步與發展，許多新興的數位4IntroductionDifferentiationofpacketswithinanMPEGmediastreamMPEGframes(I)Intraframecoded,key-frame(max.priority)(P)Predicted(B)Bidirectional有Iframes才能組成Pframes，而有I與Pframes才能組成Bframes

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

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

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

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

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

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

PP(PacketProtection)scheme

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

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

Packetlossrecoveryscheme

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

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

這個值越大，表示目的影像和原始影像的差距越小，也就是畫面品質越好，以下為計算公式:PerformanceevaluationPeaksig38實驗1:影片中I、P、Bframe

的封包數量解析

Foreman實驗短片實驗1:影片中I、P、Bframe

的封包數量解析Fo39實驗1:影片中I、P、Bframe

的封包數量解析Stefan實驗短片實驗1:影片中I、P、Bframe

的封包數量解析Ste40

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

實驗2A調整source跟destination之間的ho41PR-TCP與其他通訊協定的delaytime

比較

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

比較pa42PR-TCP與其他通訊協定的

可解畫面數比較

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

可解畫面數比較Path越長43PR-TCP與其他通訊協定的

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

PSNR值的比較Path越長，44

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

實驗2B調整2-3之間的loserate45PR-TCP與其他通訊協定的delaytime

比較

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

比較Lo46PR-TCP與其他通訊協定的

可解畫面數比較

Lossrate越大，可解畫面數越低PR-TCP與其他通訊協定的

可解畫面數比較Lossra47PR-TCP與其他通訊協定的

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

PSNR值的比較Lossra48PR-TCP與其他通訊協定的

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

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

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

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

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

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

CWND(congestionwindow)藉由察覺網路的擁塞做動態調整Sender端如何察覺網路的擁塞呢?losstimeoutor3duplicateacksTCPsenderreducesrate(cwnd)afterlossevent主要的機制SlowStartCongestionAvoidanceAIMD(additiveincreaseandmultiplicativedecrease)FastRetransmit&FastRecoveryrate

=

CWNDRTT

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

DCCPRFC4340,March2006thinkofDCCPasTCPminusbytestreamsemanticsandreliabilityorasUDPpluscongestioncontrol,handshakes,andacknowledgementsRelatedWorkDCCP:DatagramCon58RelatedworkOtherprotocolRTP即時傳輸協定和即時控制協定端對端傳輸服務的即時傳輸協定，用來支援在單目標廣播和多目標廣播網路服務中傳輸即時資料不擔保在遞送過程中不丟失資訊包或者防止資訊包的次序不被打亂RTCP:用來監視服務品質和傳送有關與會者的資訊

RelatedworkOtherprotocol59PR-TCP-basicSenderReceiver123X4ACK1ACK3ACK4Packet2wasloss.Andit’sRegistedorcertified.Senderwillretransmitpacket2PR-TCP-basicSenderReceiver123X60PR-TCP-basicSenderReceiver123X4ACK1ACK3ACK4Packet2wasloss.Andit’sregular.Senderwillnotretransmitpacket2Receiverwillnotwaitpacket2PR-TCP-basicSenderReceiver123X61PR-TCP-singlesideSenderReceiver123X4ACK1ACK3ACK4Ifpacket2isregisted:retransmitpacket2withpayloadElseretransmitduplicatedpacket2withoutpayloadPR-TCP-singlesideSenderReceiv62選擇性保證封包到達之通訊協定設計Student:Ming-HanWuAdvisor:Yao-NanLien2007Partial-ReliableTCP

選擇性保證封包到達之通訊協定設計Student:Ming-Page63Outline IntroductionBackground/RelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction64Outline IntroductionBackground/RelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction65Introduction隨著網路的進步與發展，許多新興的數位資訊，在網路上傳輸時並未要求每一個封包均確實送達目的地。例如影音資訊，因為使用者不要求，所以影音封包不需每個都要無誤到達。由於影像在網路上傳輸是經過mpeg格式壓縮，而mpeg會將影片壓縮成不同重要程度的影格，若封包遺失，將會造成不同程度的影像品質影響。Introduction隨著網路的進步與發展，許多新興的數位66IntroductionDifferentiationofpacketswithinanMPEGmediastreamMPEGframes(I)Intraframecoded,key-frame(max.priority)(P)Predicted(B)Bidirectional有Iframes才能組成Pframes，而有I與Pframes才能組成Bframes

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

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

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

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

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

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

PP(PacketProtection)scheme

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

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

Packetlossrecoveryscheme

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

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

這個值越大，表示目的影像和原始影像的差距越小，也就是畫面品質越好，以下為計算公式:PerformanceevaluationPeaksig100實驗1:影片中I、P、Bframe

的封包數量解析

Foreman實驗短片實驗1:影片中I、P、Bframe

的封包數量解析Fo101實驗1:影片中I、P、Bframe

的封包數量解析Stefan實驗短片實驗1:影片中I、P、Bframe

的封包數量解析Ste102

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

實驗2A調整source跟destination之間的ho103PR-TCP與其他通訊協定的delaytime

比較

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

比較pa104PR-TCP與其他通訊協定的

可解畫面數比較

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

可解畫面數比較Path越長105PR-TCP與其他通訊協定的

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

PSNR值的比較Path越長，106

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

實驗2B調整2-3之間的loserate107PR-TCP與其他通訊協定的delaytime

比較

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

比較Lo108PR-TCP與其他通訊協定的

可解畫面數比較

Lossrate越大，可解畫面數越低PR-TCP與其他通訊協定的

可解畫面數比較Lossra109PR-TCP與其他通訊協定的

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

PSNR值的比較Lossra110PR-TCP與其他通訊協定的

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

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

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

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

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

影像模擬比較UDPTCPRe113Outline IntroductionRelatedWorkPR-TCPBasicSinglesidePerformanceEvaluationConclusionOutline Introduction114conclusion透過了模擬實驗，PR-TCP可以有效的達到選擇性保證封包傳達的目的，能有效的確保重要封包的到達又不會因為當不重要封包遺失而浪費時間重傳。並且我們在應用層上加上自動重建遺失之封包、降低packetloss的機會。以videoconference傳輸為例，在網路的資源較少，壅塞狀況較嚴重的情況之下，比TCP最多降低約25