symphony_guir.ppt
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
361
On Slideshare
361
From Embeds
0
Number of Embeds
0

Actions

Shares
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