An Overlay Architecture for High Quality VoIP Streams IEEE Trans. on Multimedia 2006 R 翁郁婷 R 周克遠

AUTHORS Yair Amir Johns Hopkins, US Prof. Yair Amir Johns Hopkins, US Prof. Claudiu Danilov Johns Hopkins, Assist. Claudiu Danilov Johns Hopkins, Assist. Stuart Goose IEEE Member Stuart Goose IEEE Member David Hedqvist Chalmers, Sweden, Stud. David Hedqvist Chalmers, Sweden, Stud. Andreas Terzis IEEE Member Andreas Terzis IEEE Member

AGENDA INTRODUCTION FRAMEWORK DEPLOYMENT CONCLUSION

INTRODUCTION  VoIP  Quality of VoIP  Internet Loss Characters

VoIP Voice over IP > Characters of VoIP All-IP Service Low Quality Low Cost

QUALITY ISSUE INTERACTIVE Delay CANNOT higher than ms Use UDP to deliver VoIP Packets LOW QUALITY: PACKET LOSS OR DROP Loss during the Internet Routing Delay and Drop Packet Note: Currently we allow short delay: Use a buffer on receiver side > The Cause Factors of VoIP Quality

INTERNET Internet Loss Rate: 0.42% Internet Burstiness Rate: 72%

FRAMEWORK  Overlay Network & Spines  Real-time Recovery Protocol  Real-time Routing for Audio

THE PROTOCOL Why use UNRELIABLE UDP protocol? No sufficient time to End-to-end Retransmission How about BREAK the END-TO-END into HOP-TO-HOP > The Reason to Use Spines

OVERLAY NETWORK Virtual Network with Limited Scope Easy to Implement and Control Overhead Signaling Message > What is Overlay?

THE SPINES Spines Daemon Applications Open Source Overlay Network Two-level Architecture Each Spines Daemon (Node) is both SERVER and ROUTER > The Spines Architecture

> The Real-time Recovery Protocol 1.Keep a buffer on each outgoing link 2.Intermediate nodes forward packets as they are received 3.Upon detecting loss, asks the upstream node for Retransmission. A Retransmission Request for a packet is only sent once. 4.When receives a Retransmission Request: If it has the packet, resends it If not, ignore the request 5.Only the first instance will be forwarded RECOVERY PROTOCOL Real-time Recovery Protocol

LOSS RATE PACKET LOSS RATE on Link: p One Overlay Link with Two Overlay Nodes CASE OF CANNOT RECOVERY 1.Retransmission Request Loss p(1–p)p = p 2 – p 3 2.Retransmission Packet Loss p(1–p)(1–p)p = p 2 – 2p 3 + p 4 3.Else – Negligible Total Loss Probability: 2p 2 – 3p 3, approximately Total Loss Probability: 2p 2 – 3p 3, approximately > Calculate the Loss Rate of the Real-time Recovery Protocol p

THE ROUTING Real Time Routing For Audio Adjust Overlay Routing to avoid Problematic Path Two Parameter: Packet Loss Rate and Latency > Use a COST FUNCTION to handle the Two-metric Decision

> Calculate the Cost Function of the Routing COST FUNCTION THE COST: TRANSMISSION DELAY ALL CASES 1.Success Transmit: (1 – p)T 2.Recovery Transmit: (p – 2p 2 + 3p 3 )(3T + Δ) 3.Packet Loss: (2p 2 – 3p 3 ) T max The Cost Function T exp (1 – p)T + (p – 2p 2 + 3p 3 )(3T + Δ) + (2p 2 – 3p 3 ) T max PACKET LOSS RATE on Link: p Maximum WAITING TIME: T max ERROR DETECT TIME: Δ

DELAY DISTRIBUTION ALWAYS CANNOT HANDLE Delay distribution - 1 link, 5% loss (1–p) (p – 2p 2 + 3p 3 ) (2p 2 - 3p 3 ) T T (3T+Δ) T max

COMPARISON Different Routing Metrics nodes

DEPLOYMENT  Performance on Loaded Computer  Test over PlanetLab

Affected on the LOADED COMPUTERS? APPLICATION LOAD OVERLAY PROBLEM INCREASE the PRIORITY > Overlay Loading Affected by Application Layer

PlanetLab US Planetlab US - Percentage of Streams That Missed

CONCLUSIONS

OVERLAY ADVANTAGE DISADVANTAGE CONCLUSION Segment End-to-end into shorter Overlay Paths Recovery Lost Packets with Limited Time Avoid Problematic Path Slightly Change the Overall Architecture More Flexibility Easy to Implement and Deployment Overhead Diminish Margin Utility

THANK YOU FOR ATTENTION