Symphony : Reliable and Low-Latency

Broadcast for Wireless CSCL Applications

Jingtao Wang, Eric Tse

jingtaow@cs.berkeley.edu

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