1 Staleness vs.Waiting time in Universal Discrete Broadcast Michael Langberg California Institute of Technology Joint work with Jehoshua Bruck and Alex Sprintson

2 Broadcast channel Server Server Proactively transmits data to clients. Proactively transmits data to clients. e.g., stock quotes, weather, traffic. e.g., stock quotes, weather, traffic. Clients Clients Passive (“listen-only”). Passive (“listen-only”). Listen to a channel only when need data. Listen to a channel only when need data.

3 Framework Single information source. Single information source. Distribute highly dynamic data. Distribute highly dynamic data. E.g., stock market. E.g., stock market. The data is sent in unit sized packets. The data is sent in unit sized packets time

4 Model The server: The server: Gathers the data. Gathers the data. Encapsulates it into packets of unit length. Encapsulates it into packets of unit length. Sends the packets over the channel. Sends the packets over the channel. The client: The client: Must listen to entire packet to receive information. Must listen to entire packet to receive information. Q: How should server schedule packets? Q: How should server schedule packets? Client request time Request satisfied

5 Naïve approach Transmit data every time unit. Schedule quality: Schedule quality: Delay (D) - the time elapsed between a request and the beginning of the next transmission. Delay (D) - the time elapsed between a request and the beginning of the next transmission request t 4 D>0 request D=0

6 Objective Goal: Design a schedule with “low” delay (D). Goal: Design a schedule with “low” delay (D). Typical assumption (e.g. [Ammar87], [VaidyaHameed96,97], [Bar-Noy NaorSchieber03,+Bhatia98], [KenyonSchabanelYoung03]): Typical assumption (e.g. [Ammar87], [VaidyaHameed96,97], [Bar-Noy NaorSchieber03,+Bhatia98], [KenyonSchabanelYoung03]): Uniform distribution of clients requests. Uniform distribution of clients requests. Uniform distribution: in expectation D=1/2. Uniform distribution: in expectation D=1/ [LSprintsonBruck04]) We study universal schedules that guarantee low delay for any client, regardless of its behavior (studied in [LSprintsonBruck04]).

Universal schedules Goal: Design a (universal) schedule. Goal: Design a (universal) schedule. The delay is small for any client behavior. The delay is small for any client behavior. Model: game against an adversary. Model: game against an adversary. Minimize the worst case delay. Minimize the worst case delay. D~1D~1/2D~0

8 Universal schedules D~1 Naïve schedule: worst case delay is arbitrary close to 1. This is the case for any deterministic schedule. Would like: design schedule with delay strictly less than 1. Introduce redundancy & randomness.

9 Redundancy: encoding Instead of sending packet of unit length – send redundant packets (length ≥ unit). Instead of sending packet of unit length – send redundant packets (length ≥ unit). Listening to any unit portion of packet reveals info. Listening to any unit portion of packet reveals info … … D~1 D=0 Encoding = cyclic permutation Old: New: 2 unit

10 Redundancy: encoding Properties: worst case delay still ~ 1! Properties: worst case delay still ~ 1! Need to add randomness. Need to add randomness … … D~1 Old: New: 2 less than one unit

11 Randomness + redundancy Each packet will have different (random) length. Each packet will have different (random) length. Distribution over schedules. Distribution over schedules. Adversary cannot place “bad” queries. Adversary cannot place “bad” queries … … D~? Old: New: 2

12 New objective Once we introduce randomness: new objective. Once we introduce randomness: new objective. Expected delay: expected time “wasted” by client until receiving full unit of information. Expected delay: expected time “wasted” by client until receiving full unit of information. Expectation over distribution of schedules. Expectation over distribution of schedules. Schedule quality: worst case expected delay. Schedule quality: worst case expected delay. 134 … D~? New: 2

13 Schedule quality: example Packet length ~ U[1,2]. Packet length ~ U[1,2]. Quality: what is worst case client request time t? Quality: what is worst case client request time t? We assume history up to time t is known. We assume history up to time t is known. Adaptive adversary. Adaptive adversary. Can prove: expected delay ≤ ½. Can prove: expected delay ≤ ½. Worst case expected delay = ½! Worst case expected delay = ½! 34 … 2 0 t 1

14 Can one do better? Broadcast single package over time. Broadcast single package over time. For any t: delay = 0! For any t: delay = 0! Problem: information received is not “fresh”. Problem: information received is not “fresh”. New Objective: New Objective: Small delay. Small delay. Fresh information. Fresh information. … 0 t 1 unit

15 Staleness Definition: Staleness (S): time elapsed between the moment the information is sampled (by server) and the moment the information is received by the client. Definition: Staleness (S): time elapsed between the moment the information is sampled (by server) and the moment the information is received by the client. Objective: find schedules with small delay and staleness. Objective: find schedules with small delay and staleness. Analyze relation between delay and staleness. Analyze relation between delay and staleness. 34 … 2 t 1 S

16 Previous example with staleness Packet length ~ U[1,2], consider query at time t. Packet length ~ U[1,2], consider query at time t. Seen: expected delay ≤ ½. Seen: expected delay ≤ ½. Can show: expected staleness ≤ ¼. Can show: expected staleness ≤ ¼. This example: worst case (S,D) of (¼,½). This example: worst case (S,D) of (¼,½). One package: worst case (S,D) of ( ,0). One package: worst case (S,D) of ( ,0). Naïve schedule: worst case (S,D) of (0,1). Naïve schedule: worst case (S,D) of (0,1). 34 … 2 0 t 1

17 Our results Formalize universal (adaptive adversarial) analysis of broadcast schedules: delay, staleness. Formalize universal (adaptive adversarial) analysis of broadcast schedules: delay, staleness. Observe a tradeoff between worst case expected delay and worst case expected staleness. Observe a tradeoff between worst case expected delay and worst case expected staleness. Analyze this tradeoff – present tight upper lower bounds. Analyze this tradeoff – present tight upper lower bounds. Observe a nice “knee” property: Observe a nice “knee” property: Single schedule: low delay with low staleness.

18 Review: goal Design random schedule (distribution over schedules). Design random schedule (distribution over schedules). Randomness introduces redundant packets. Randomness introduces redundant packets. Schedule has worst case delay D, and staleness S: Schedule has worst case delay D, and staleness S: The worst case expected delay is D. The worst case expected delay is D. The worst case expected staleness is S. The worst case expected staleness is S. Expectation is over server’s coins only (no distribution is assumed on client requests). Expectation is over server’s coins only (no distribution is assumed on client requests). 34 … 2 0 t 1

19 Tradeoff Plot of achievable (S,D) schedules. Plot of achievable (S,D) schedules. Represents both lower and upper bounds. Represents both lower and upper bounds. Observe “knee” point. Observe “knee” point Staleness Delay

20 Proof techniques Both upper and lower bounds are obtained (up to arbitrary precision) by the solution of a certain LP. Both upper and lower bounds are obtained (up to arbitrary precision) by the solution of a certain LP. For each value of staleness S: For each value of staleness S: Positive: present schedules with low delay. Positive: present schedules with low delay. Negative: prove that one cannot do better. Negative: prove that one cannot do better. Can obtain “closed form” schedules (optimal for a certain range of staleness values s). Can obtain “closed form” schedules (optimal for a certain range of staleness values s).

21 Conclusion Considered broadcasting of discrete items. Considered broadcasting of discrete items. Study the notions of delay and staleness. Study the notions of delay and staleness. Focused on worst case (universal) analysis. Focused on worst case (universal) analysis. Observed a fundamental trade-off: delay vs. staleness. Observed a fundamental trade-off: delay vs. staleness. Established tight lower + upper bounds. Established tight lower + upper bounds. Identified “knee”. Identified “knee”. Future research: Future research: Errors. Errors. Multiple items. Multiple items.