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 1 Now 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 Network Fast Slow Recipient (short polling) • Recipient’s server receives message almost instantaneously... • ...but short polling leads to delayed delivery 3 / 18

Pulling for Messages: Short Polling d u Server Client Request Connection ON Empty response Inter- Message polling arrives Connection OFF time Message delivery delay Connection ON Response w/ Connection OFF Time Message delivery delay No continuous connection 4 / 18

Alternative to Short Polling - Push Message Delivery u d Server Client Connect Message arrives Response w/ Connection always ON Time 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 (a) Duration of a TCP connection 60 Frequency 40 20 0 0 5 10 15 20 Time (mins) (b) Packets per TCP connection 200 Frequency 100 0 0 10 20 30 40 50 Packets exchanged 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 Android Client −−− Google: Simultaneously open ports (24H period) 14 12 10 8 Hours 6 4 2 0 0 1 2 3 4 5 6 Open ports 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 0.02 0.018 Relative frequency of email reception 0.016 0.014 0.012 0.01 0.008 0.006 S S M T W T F 0.004 0.002 0 0 20 40 60 80 100 120 140 160 180 Hours of a week (168 hrs total) 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 (a) Mean iit =2.36, Std. iit =8.09, Total msgs =2131 1 Relative frequency Fastest User (lowest average iits) 0.5 0 0 5 10 15 20 iit in Hours (axis truncated to 24h) (b) Mean iit =65.87, Std. iit =136.29, Total msgs =281 1 Relative frequency Slowest User (highest average iits) 0.5 0 0 5 10 15 20 iit in Hours (axis truncated to 24h) 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. F i +1 = α F i + (1 − α ) f i (1) F i - 168-element vector of hour rank vector of week i f i - 168-element vector of message arrival frequencies for week i 14 / 18

Performance - Fastest User 1 0.9 Fraction of real−time email delivery 0.8 0.7 0.6 0.5 0.4 0.3 25% 50% 75% 0.2 Adaptive Learning 0.1 Fixed Learning 0 0 20 40 60 80 100 120 140 160 Hours of active connection/week (168 hrs total) Figure: Fastest user, α = 0 . 9 for adaptive learning Both learning algorithms perform reasonably well 15 / 18

Performance - Averaged Across 150 Users Averaged across 150 users, with errorbars 1 0.9 Fraction of real−time email delivery 0.8 0.7 0.6 0.5 0.4 0.3 0.2 Adaptive Learning 0.1 Fixed Learning 0 20 40 60 80 100 120 140 160 Fraction of hours of active connection/week (168 hrs total) 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