symphony_guir.ppt

194
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
194
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

symphony_guir.ppt

  1. 1. Symphony : Reliable and Low-Latency Broadcast for Wireless CSCL Applications Jingtao Wang, Eric Tse [email_address] GUIR/BiD Weekly Meeting Oct 27, 2004
  2. 2. Agenda <ul><li>Motivation </li></ul><ul><li>Design Goals </li></ul><ul><li>Background </li></ul><ul><li>Understanding the Target Environments </li></ul><ul><li>The Symphony Protocol </li></ul><ul><li>Experiments </li></ul><ul><li>Conclusion </li></ul>
  3. 3. Motivation <ul><li>Overcome real-world data synchronization problems encountered in developing collaborative learning applications over Wireless LAN </li></ul><ul><ul><li>Unstable network connectivity </li></ul></ul><ul><ul><li>High packet loss rate </li></ul></ul><ul><ul><li>Long synchronization latency </li></ul></ul><ul><ul><li>Traffic congestions </li></ul></ul><ul><li>Vanilla TCP and UDP do not meet such requirements directly </li></ul><ul><li>Existing Reliable multicast/broadcast solutions have different assumptions </li></ul>
  4. 4. Design Goals <ul><li>Resilience to packet loss, network failures and membership changes </li></ul><ul><li>Low-Latency Delivery of small data packages </li></ul><ul><li>Resilience to workload bursts </li></ul><ul><li>Scalability </li></ul><ul><li>Data consistency </li></ul><ul><li>In-sequence delivery </li></ul>Priority
  5. 5. Background and Related Works <ul><li>SRM ( Scalable Reliable Multicast, Floyd95 ) </li></ul><ul><li>Erasure Correcting Scalable Reliable Multicast (ECSRM, Gemmell97 ) </li></ul><ul><li>Reliable Broadcast in Mobile Packet Networks ( Panani97 ) </li></ul>ARQ FEC
  6. 6. Understanding the Target Platform - 1 RTT Distribution <ul><li>Each machine sent at least 200 packets to every other machine (one-to-one) </li></ul><ul><li>RTT of nearly 70% packets ranges from 3ms to 5ms </li></ul><ul><li>No correlation between RTT and physical distance </li></ul><ul><li>No out-of-order packets detected </li></ul><ul><li>Conclusion – hop based RTT estimation not necessary in such environment </li></ul>*Data collected from five battery powered wireless Toshiba Portege 3500 Tablet PCs, PIII 1.3G CPU, 512M Ram, built-in 802.11b wireless adapter running in ad-hoc mode
  7. 7. Understanding the Target Platform - 2 Lost Packets Distribution *Data collected from five battery powered wireless Toshiba Portege 3500 Tablet PCs, PIII 1.3G CPU, 512M Ram, built-in 802.11b wireless adapter running in ad-hoc mode <ul><li>Each machine multicasts data packets with an increasing packet number to a fixed multicast address (one-to-multicast) </li></ul><ul><li>Each machine listens to the same channel and logs multicast packets sent by other nodes </li></ul><ul><li>Packet size set to 512 bytes, 1K and 1K bytes </li></ul>
  8. 8. Understanding the Target Platform – 2 Cont’ <ul><li>Surprisingly high loss rate </li></ul><ul><ul><li>9% when packet size = 512, 7.8% when packet size = 1024, 19% when packet size = 2048 </li></ul></ul><ul><li>Two kinds of packets loss – random 1 or 2 packets & continuous packet loss for more than 20 packets. The later is the majority </li></ul><ul><ul><li>8% when packet size = 512, 2.4% when packet size = 1024, 11% when packet size = 2048 </li></ul></ul><ul><li>Same as test 1, no out-of-order packets detected </li></ul>
  9. 9. Implications of the test <ul><li>Hop based RTT estimation will break </li></ul><ul><ul><li>Adopt a fixed expectation of RTT </li></ul></ul><ul><li>Expect to handle mixed packet loss effectively (random + burst) </li></ul><ul><ul><li>Use FEC for random loss </li></ul></ul><ul><ul><li>Need mechanisms to repair burst packet loss </li></ul></ul><ul><li>In sequence delivery won’t be a major concern </li></ul>
  10. 10. Symphony – Reliable and Low-Latency Broadcast in Single-hop Wireless Network <ul><li>Combination of Layered FEC & ARQ </li></ul><ul><li>Group Management </li></ul><ul><li>Randomized Group Repair Request </li></ul><ul><li>Sender Oriented Recovery </li></ul>
  11. 11. Combination of FEC and ARQ <ul><li>Use Layered FEC to recover random packet loss. (primarily caused by packet collision) </li></ul>Encoding/Decoding throughput (the stretch factor is 1.5) Of FEC code in C#, running on a Pentium III 1.3G Tablet PC *From Nonnenmacher97
  12. 12. Group Management <ul><li>Each member in the group generates a refresh message periodically </li></ul><ul><li>Each member i keeps track of the following information for every member in the group </li></ul><ul><ul><li>1. the member name k , 2. last sequence number Sn k that node i knows k had issued, 3. local time when i received the packet. 4. local time when i receives the last refresh message from k . </li></ul></ul><ul><li>Each packet in the network has a globally unique and persistent packet name composed by creator name and a monotonously increasing sequence number regarding the creator. </li></ul><ul><li>Each member must permanently store all the non-control packets it had received (and had sent). </li></ul><ul><li>Use timeouts to maintain member drops and network partition. </li></ul>
  13. 13. Randomized Group Repair Request <ul><li>Efficiently notify burst packet loss </li></ul><ul><li>Packet loss was detected by identifying gap in sequence number received </li></ul><ul><li>Wait for a random duration before sending the request </li></ul><ul><ul><li>C 1 , C 2 – algorithm parameters </li></ul></ul><ul><ul><li>n – current members in the group </li></ul></ul><ul><ul><li>i – iteration of repair request tries seen </li></ul></ul><ul><li>Algorithm </li></ul><ul><ul><li>Detect loss  set timer </li></ul></ul><ul><ul><li>Receive request that can cover the same data  cancel timer, set new timer, possibly with new iteration </li></ul></ul><ul><ul><li>Timer expires  send repair request and indicate the start and end sequence number of lost packets </li></ul></ul>
  14. 14. Sender Oriented Recovery <ul><li>Suppress redundant NACK request by giving priority to the sender </li></ul><ul><ul><li>Sender is always within one hop </li></ul></ul><ul><ul><li>When a sequence gap is detected, the sender should be alive in most cases since the last packet received is from the same sender </li></ul></ul><ul><li>When the sender receives the NACK request, broadcast the repair packets directly. </li></ul><ul><li>When non-sender receives the NACK request, if it has those requested packets, set a random timer for sending those packets otherwise create a new NACK timer </li></ul><ul><li>If repair packets received before the timer, cancel the timer, otherwise send the repair packets </li></ul>
  15. 15. Experiment 1 – Recovery Speed Recover Speed (SRM, Group Repair, Sender Oriented Recovery and Symphony )
  16. 16. Experiment 2 – NACK Traffic Group repair can reduce nearly 50% of the total NACK traffic
  17. 17. Experiment 3 – Recovery Packets Traffic Almost the same traffic. SOC causes slightly higher traffic
  18. 18. Conclusion <ul><li>Real measurements of the target communication platform </li></ul><ul><ul><li>no correlation between physical distance and RTT </li></ul></ul><ul><ul><li>mixture of random and burst packet loss (more than 50% in 2 out of 3 conditions) </li></ul></ul><ul><li>Symphony uses three techniques to enable reliable and low latency delivery of broadcast packets </li></ul><ul><ul><li>Layered FEC, Randomized Group Repair, Sender Oriented Recovery </li></ul></ul><ul><li>The recovery time of Symphony is about 41% faster than SRM, NACK packets are about 50% less than SRM with similar repair packet traffic. </li></ul>
  19. 19. Future Work <ul><li>Theoretical Analysis of the performance influence of different control parameters </li></ul><ul><li>Support multi-hop networking </li></ul><ul><li>Support Rate control/Congestion control </li></ul><ul><li>Adaptive schemes for adjusting control parameters dynamically </li></ul>
  20. 20. Q & A <ul><li>http://www.cs.berkeley.edu/~jingtaow/research/LiveNote </li></ul><ul><li>http://livenotes.sourceforge.net </li></ul>Thanks !
  21. 21. Backup Slides
  22. 22. (N)ACK Implosion S R1 R2 R3 1 2 3 S R1 R2 R3 3 3 3 2? 2? 2?
  23. 23. Scalable Reliable Multicast (SRM) <ul><li>Receivers use timers to send NACKS and retransmissions </li></ul><ul><ul><li>randomized </li></ul></ul><ul><ul><ul><li>prevent implosion </li></ul></ul></ul><ul><ul><li>uses latency estimates </li></ul></ul><ul><ul><ul><li>short timer  cause duplicates when there is reordering </li></ul></ul></ul><ul><ul><ul><li>long timer  causes excess delay </li></ul></ul></ul><ul><li>Any node retransmits </li></ul><ul><ul><li>sender can use its bandwidth more efficiently </li></ul></ul><ul><ul><li>overall group throughput is higher </li></ul></ul><ul><li>Duplicate NACK/retransmission suppression </li></ul>
  24. 24. The Target Application – LiveNotes 2 LiveNotes 2 Available for download at http://www.cs.berkeley.edu/~jingtaow/research/LiveNote/Setup_0.95.msi <ul><li>Using Symphony as the communication protocol </li></ul><ul><li>Support for Collaborative Ink Sharing/Editing </li></ul><ul><li>Instructor features such as Lecture feedback and Peer Instruction </li></ul><ul><li>Support for Slide Sharing </li></ul><ul><li>Support for common file formats like PPT, HTML, PDF </li></ul><ul><li>Written in C# running for Tablet PC Platform </li></ul>
  25. 25. Original LiveNotes Data-Sync Model N1 N2 N3 N4 N5 source N0

×