Your SlideShare is downloading. ×
symphony_guir.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

symphony_guir.ppt

161
views

Published on


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

  • Be the first to like this

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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