• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
symphony_guir.ppt
 

symphony_guir.ppt

on

  • 302 views

 

Statistics

Views

Total Views
302
Views on SlideShare
302
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    symphony_guir.ppt symphony_guir.ppt Presentation Transcript

    • Symphony : Reliable and Low-Latency Broadcast for Wireless CSCL Applications Jingtao Wang, Eric Tse [email_address] GUIR/BiD Weekly Meeting Oct 27, 2004
    • Agenda
      • Motivation
      • Design Goals
      • Background
      • Understanding the Target Environments
      • The Symphony Protocol
      • Experiments
      • Conclusion
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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.
    • 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
    • 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
    • Experiment 1 – Recovery Speed Recover Speed (SRM, Group Repair, Sender Oriented Recovery and Symphony )
    • Experiment 2 – NACK Traffic Group repair can reduce nearly 50% of the total NACK traffic
    • Experiment 3 – Recovery Packets Traffic Almost the same traffic. SOC causes slightly higher traffic
    • 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.
    • 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
    • Q & A
      • http://www.cs.berkeley.edu/~jingtaow/research/LiveNote
      • http://livenotes.sourceforge.net
      Thanks !
    • Backup Slides
    • (N)ACK Implosion S R1 R2 R3 1 2 3 S R1 R2 R3 3 3 3 2? 2? 2?
    • 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
    • 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
    • Original LiveNotes Data-Sync Model N1 N2 N3 N4 N5 source N0