symphony_guir.ppt
-
Upload
johnsondon -
Category
Documents
-
view
169 -
download
2
Transcript of symphony_guir.ppt
Symphony : Reliable and Low-Latency
Broadcast for Wireless CSCL Applications
Jingtao Wang, Eric Tse
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
2 4 6 8 10 12 14 160
5
10
15
20
25
30
Round trip time between nodes (ms)
perc
enta
ge %
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 5msNo 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
0 50 100 1500
1
2
3
4
5
6
7
8
9
continuously lost packets
Tot
al p
erce
ntag
e %
size=512size=1024size=2048
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 nodesPacket 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)
200 400 600 800 1000 1200 1400 1600 1800 2000 22000
50
100
150
200
250
Data Size (kb)
Tim
e U
sed
(sec
)
EncodingDecoding
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 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.
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
)])(log(),(log[2 211 bnCCbnCi
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
)])(log(),(log[ 211 bnDDbnD
Experiment 1 – Recovery Speed
Recover Speed (SRM, Group Repair, Sender Oriented Recovery and Symphony )
0 5 10 15 20 25 30 35 40 455
10
15
20
25
30
35
40
45
Number of lost packets
rec
ov
ery
tim
e (
ms
)
SRMGroup RepairSender Oriented RecoverySymphony
Experiment 2 – NACK Traffic
Group repair can reduce nearly 50% of the total NACK traffic
0 5 10 15 20 25 30 35 40 450
5
10
15
20
25
30
35
40
45
Number of lost packets
Nu
mb
er
of
req
ue
sts
SRMGroup Repair
Experiment 3 – Recovery Packets Traffic
Almost the same traffic. SOC causes slightly higher traffic
0 5 10 15 20 25 30 35 40 450
5
10
15
20
25
30
35
40
45
50
Number of lost packets
Nu
mb
er
of
rep
are
pa
ck
ets
se
nt
SRMGroup RepairSender Oriented RecoverySymphony
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 para
meters dynamically
Q & A
http://www.cs.berkeley.edu/~jingtaow/research/LiveNote http://livenotes.sourceforge.net
Thanks !
Backup Slides
(N)ACK Implosion
SS
R1R1
R2R2
R3R3
123
SS
R1R1
R2R2
R3R3
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 protocolSupport for Collaborative Ink Sharing/Editing Instructor features such as Lecture feedback and Peer InstructionSupport for Slide SharingSupport for common file formats like PPT, HTML, PDFWritten in C# running for Tablet PC Platform
Original LiveNotes Data-Sync Model
N1N1
N2N2
N3N3 N4N4
N5N5
source
N0N0