Symphony : Reliable and LowLatency Broadcast for Wireless CSCL Applications

1
Symphony Reliable and Low-Latency Broadcast
for Wireless CSCL Applications

• Jingtao Wang, Eric Tse
• jingtaow_at_cs.berkeley.edu
• 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
Priority

• 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

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

• 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

RTT 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
7
Understanding the Target Platform - 2

• 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

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
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 wont 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 Snk
  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
• C1, C2 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
Thanks !

• http//www.cs.berkeley.edu/jingtaow/research/Live
  Note
• http//livenotes.sourceforge.net

21
Backup Slides

22
(N)ACK Implosion
R1
1
2
3
S
R2
R3
R1
3
2?
S
3
R2
2?
2?
R3
3
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

• 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

LiveNotes 2 Available for download
at http//www.cs.berkeley.edu/jingtaow/research/L
iveNote/Setup_0.95.msi
25
Original LiveNotes Data-Sync Model
source
N1
N2
N5
N0
N3
N4