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

2. 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

3. AGENDA INTRODUCTION FRAMEWORK DEPLOYMENT CONCLUSION

4. INTRODUCTION  VoIP  Quality of VoIP  Internet Loss Characters

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

6. QUALITY ISSUE INTERACTIVE Delay CANNOT higher than 100-150 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

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

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

9. 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

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

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

12. > 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

13. 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

14. 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

15. > 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: Δ

16. 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

17. COMPARISON Different Routing Metrics - 100 nodes

18. DEPLOYMENT  Performance on Loaded Computer  Test over PlanetLab

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

20. PlanetLab US Planetlab US - Percentage of Streams That Missed

21. CONCLUSIONS

22. 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

23. THANK YOU FOR ATTENTION