Toward a Push-Scalable Global Internet IEEE Global Internet - - PowerPoint PPT Presentation

Toward a Push-Scalable Global Internet

IEEE Global Internet Symposium, IEEE Infocom 2011 Sachin Agarwal 1

ska@alum.bu.edu

• Presented by Oliver Hohlfeld

—– Deutsche Telekom A.G., Laboratories & TU Berlin Ernst-Reuter-Platz 7 10409 Berlin, Germany

April 15th, 2011

1Now with NEC Europe Laboratories, Heidelberg, Germany 1 / 18

Outline

• Motivation - Push and Internet scalability
• Case study: Android’s push service
• Our solution: Content-based optimization
• Conclusions and future Work

2 / 18

Information Delivery on the Web

Sender Recipient (short polling) Network Fast Slow

• Recipient’s server receives message almost instantaneously...
• ...but short polling leads to delayed delivery

3 / 18

Pulling for Messages: Short Polling

Inter- polling time Message arrives Time

Message delivery delay Request Empty response Server Client

Connection ON Connection ON Connection OFF Connection OFF

Response w/

Message delivery delay

No continuous connection

4 / 18

Alternative to Short Polling - Push Message Delivery

Message arrives Time

Connect Server Client

Connection always ON

Response w/

Near-zero delay in message delivery

Continuous (TCP) connection

5 / 18

Effects of Long-lived Connections on Web Infrastructure

• !

"

• #$%

&'

• '%

() % (* +,-%!

• %%!-

.

Tied up network resources (e.g. proxy memory/processing) End-point scalability limitations (client battery/processing, server capacity)

6 / 18

Android’s Cloud-to-Device Messaging Service

• !

" # $ % &

• Figure: Time-line of a long polling interaction between client and server.

Always-on connection via long polling

7 / 18

Android: Longevity & Packets per Connection

5 10 15 20 20 40 60 Time (mins) Frequency (a) Duration of a TCP connection 10 20 30 40 50 100 200 Packets exchanged Frequency (b) Packets per TCP connection

Figure: Durations & packet counts of TCP connection between Android client and C2DM server

Recurring durations & packet counts imply algorithmic control (not random disconnects)

8 / 18

Android: Concurrent TCP Connections

1 2 3 4 5 6 2 4 6 8 10 12 14 Open ports Hours Android Client −−− Google: Simultaneously open ports (24H period)

Figure: Concurrent TCP connections - Android client & push server

Scalability concerns Multiple concurrent TCP connections per client, 24 × 7 Uses HTTPS for security and transparent proxying (further burden on endpoints)

9 / 18

Our Idea: Content-based Optimization

Turn-off always-on connections when message arrivals are rare. Question: Learning when to flick the switch Answer: Message arrival patterns (over time)

10 / 18

Enron Email Data-set

• Publicly released by the US Federal Energy Regulatory

Commission

• Contains ˜

500,000 email messages of 150 senior Enron employees over ˜ 4 years

• Email headers also available (e.g. email sending times)
• Convenient database representation of data-set available via

A.Fiore and J.Heer, UC Berkeley, Enron Email Analysis http://bailando.sims.berkeley.edu/enron email.html 11 / 18

Example: Day of week Email Message Arrivals

20 40 60 80 100 120 140 160 180 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02 Hours of a week (168 hrs total) Relative frequency of email reception S S M T W T F

Figure: A user’s weekly email reception (averaged over 110 weeks).

Rare messages arrivals during several hours of a week

12 / 18

Message inter-arrival times

5 10 15 20 0.5 1 iit in Hours (axis truncated to 24h) Relative frequency (a) Mean iit =2.36, Std. iit =8.09, Total msgs =2131 Fastest User (lowest average iits) 5 10 15 20 0.5 1 iit in Hours (axis truncated to 24h) Relative frequency (b) Mean iit =65.87, Std. iit =136.29, Total msgs =281 Slowest User (highest average iits)

Figure: Relative frequency of inter-arrival times (iits) in hours for (a) the fastest user and for (b) the slowest user.

Non-Poisson message arrivals

13 / 18

When to Flick the Switch - Simple Machine Learning (ML)

Fixed Learning For each user, use a small fraction of arrival-times to rank hours of the week according to the relative frequency of email arrival. Adaptive Learning Use all previous arrival-times, weigh more recent arrival-times more. Fi+1 = αFi + (1 − α)fi (1) Fi - 168-element vector of hour rank vector of week i fi - 168-element vector of message arrival frequencies for week i

14 / 18

Performance - Fastest User

20 40 60 80 100 120 140 160 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 25% 50% 75% Hours of active connection/week (168 hrs total) Fraction of real−time email delivery Adaptive Learning Fixed Learning

Figure: Fastest user, α = 0.9 for adaptive learning

Both learning algorithms perform reasonably well

15 / 18

Performance - Averaged Across 150 Users

20 40 60 80 100 120 140 160 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Fraction of hours of active connection/week (168 hrs total) Fraction of real−time email delivery Averaged across 150 users, with errorbars Adaptive Learning Fixed Learning

Figure: 150 users, α = 0.9 for adaptive learning

Adaptive learning more effective for slower users

16 / 18

Future Work

• Quantitative study of scalability bottlenecks - client battery,

network elements, server resources

• Other content information for ML: e.g. semantic meaning,

importance of message, sender, spam score, size, attachments, etc.

• Applicability to other pushed information e.g. social network

updates

• Sophisticated ML algorithms

17 / 18

Conclusion

• Push messaging on the web is not free
• Content-based optimization may hold the key
• Proposed approach yielded 50% on-time reduction with 90%

messages delivered instantaneously

• Multiple future directions possible here - more measurements,

ML, other message types, etc.

• High impact research problem - explosion of mobile devices

and HTTP (port 80) based communication

18 / 18