Improving Web QoE: The effect of reducing RTT and Page Load times for subscribers

Transcription

1 Improving Web QoE: The effect of reducing RTT and Page Load times for subscribers INTRODUCTION Broadband subscribers have become very sensitive to the Quality of Experience that they receive from their providers. Although streaming video makes up the largest portion of traffic by volume on most networks, web browsing is the biggest use of the Internet for most consumers - whether they have internet access through a browser or via an application container such as the Facebook or Twitter apps on a mobile device. A compliation of studies done by Kissmetrics ( your-website-design-should-load-in-4-seconds/) reports that, ideally, pages should load in less than 4 seconds, while 47% of consumers expect a page load time of less than 2 seconds. However, consumers seldom blame websites for slow page-loading meaning that ultimately, broadband operators bear the stigma of bad QoE. Operators need to understand the QoE their network is delivering and improve it where and whenever possible. In this White paper we look at the impact of RTT and loss on page load times using two different methods. In Section 2 we present the result from using a model to investigate the effect of latency and loss on page load time. In section 3 we look at the consequences of prioritizing interactive web traffic over other traffic types in a lab environment. Model Based Investigation We used two popular web pages with our model, google.com and aftonbladet.se (a popular Swedish tabloid). Google was picked because it is a popular, simple web page which should load quickly during most network conditions. Aftonbladet was chosen because it depends on data from many different servers and has a poor load time even during good network conditions. Our model is based on B.Sidar, S. Kalyanaraman and K.S. model for multiple packet loss for TCP Tahoe as presented in Analytic Models for the Latency and Steady-State Throughput of TCP Tahoe, Reno and SACK[3]. The model is fed with HTTP Archive[2] trace files collected from a Chrome browser. The effect of latency and loss in DNS traffic is not taken into account. Table 1 gives short description of the traffic related to the two different web sites. Table 1 - Trace File Summary Site Servers Segments Mbyte (Approx.) Get Reqs. Aftonbladet.se Google.com

2 Set up The setup consisted of a PacketLogic Real-Time Enforcer (PRE) for classifying and marking traffic with DiffServ Code Points (DSCPs), a bottle neck on a 50Mbps downlink and a 10Mbps uplink, two Linux servers, one on the internal side and one on the external side. Figure 1 below, shows how the equipment was connected. Twenty web users periodically request a large web page similar to the aftonbladet.se used in the Model based investigation using Procera-developed proprietary software with up to eight parallel connections per server. After the users connections have completed the download they will sleep between one and thirty seconds before requesting the page again. The five streaming media users mimic Adaptive Bitrate Streaming with an average bitrate of 2.4Mbps and a chunk size corresponding to four seconds. The intention is to mimic non-hd content from popular streaming services like Netflix that dominate broadband network traffic. The bulk download user replicates the behavior of users such as Steam or file sharing customers - 3.2Gbyte of data is downloaded using eight parallel connections. Figure 3 Lab Setup Web Servers Bulk Servers Streaming Media Server External LInux 10 Gbps PRE 10 Gbps Bottleneck 50 Mbps 15ms 10 Mbps 20ms Internal LInux 20 x Web Users 1 x Bulk Download User 5 x Streaming Media Viewers The time it takes for the bulk download user to download his large file was measured along with the page load time for the web users, during which time the number of stalls experienced by the streaming media users was monitored. 2

3 Aftonbladet.se RESULT The model was run for RTTs between 30ms and 200ms at 10ms increments, with a packet loss rate of 1%, 3% and 5%.The page load time included the setup times for these connections. Most Get Requests include only a few segments worth of data which means that when connections experience packet loss there are not enough segments in flight for TCP s fast retransmissions to trigger. Instead TCP has to depend on timeouts to indicate packet loss and signal retransmissions. The results for aftonbladet.se are plotted below in figure X. As expected aftonbladet.se quickly became unusable. Figure X Page Load Time, Aftonbladet.se Drop Probability 1% % 5% Page Load Time (s) RTT (s) By using technologies such as Nokia s Application Aware RAN[1] to give priority to interactive HTTP traffic, the RTT and packet loss rate experienced by that traffic during peak hour will resemble RTT and loss rate measured during off peak. Table 2 shows a subset of the results for the aftonbladet.se model. The two highlighted rows for 100ms RTT with 1% packet loss and for 140ms RTT with 3% packet loss in table 2, show that such a change can result in a 50% reduction in page load time for complex web pages. Table 2: Result, Aftonbladet RTT (ms) Loss Page Load Time (s) 40 1% % % % % % % % %

4 google.com RESULT Figure Y shows the result for google.com. It is clear that even simple sites such as google are very sensitive to RTT and packet loss. The highlighted rows in table 3 shows that if we managed to decrease in RTT and loss rate as described in the results for aftonbladet.se, the page load time would be cut in half for google as well. Figure Y Page Load Time, google.com Drop Probability 1% % 5% Page Load Time (s) RTT (s) Table 3 - Result, Google RTT (ms) Loss Page Load Time (s) 40 1% % % % % % % % %

5 Lab Test RESULT The test was run for ten rounds and the results are presented below in table 4. In Plain mode the Bottle Neck was configured to perform per subscriber prioritization while in Web Priority the Bottle Neck was configured to give priority to Interactive Web traffic (marked by the PRE) over Bulk Transfers and Streaming Media. The results show that by giving a priority to interactive web traffic, page load time can be cut almost in half (reduced by 45%) with minimal drawback for other users, i.e no stalls for Streaming Media Users and a slight increase in Bulk Download Time (7%). Figure 4 LiveView during test Table 4: Result, Lab Test Plain Web Priority Mean Page Load Time 15.4s 8.4s Mean Download Time 17m 9s 18m 18s Streaming Media Stalls 0 0 5

6 CASE STUDY SUMMARY This whitepaper demonstrates how an operator can deliver a higher overall subscriber QoE by reducing page load times and RTT through intelligent traffic management techniques. In the era of Network Neutrality, many operators are hesitant to implement any form of traffic management, but even the recent Body of European Regulators for Electronic Communications (BEREC) draft version of their Network Neutrality regulations specifies that some forms of traffic management can enhance the subscriber experience. The draft indicates that an operator can differentiate between objectively different categories of traffic i.e. Video, gaming, web browsing, etc. as long as the purpose is to optimize the overall quality and user experience based on technical quality of service requirements (for example, in terms of latency, jitter, packet loss, and bandwidth) of the specific categories of traffic. The draft follows this up with requirements that the ISP must be able to detail the traffic management rationale to the NRAs and be transparent to the end user. Towards the end of the document, the draft goes on to suggest that NRAs should monitor ISPs to ensure they are correctly dimensioning their networks to avoid recurring network quality issues. The techniques described and demonstrated in this paper will help operators improve the QoE delivered to their end users and the ScoreCard products from Procera can help monitor network QoE performance. For more information, please see REFERENCES [1] 3g application aware ran with in-bearer optimization. default/files/document/nsn cellload and applicationaware trafficmanagement white paper 0.pdf. Accessed: [2] Http archive 1.2 specification. Accessed: [3] Biplab Sikdar, Shivkumar Kalyanaraman, and Kenneth S. Vastola. Analytic models for the latency and steady-state throughput of tcp tahoe, reno, and sack. IEEE/ACM Trans. Netw., 11(6): , December v ABOUT PROCERA NETWORKS Procera Networks, the global Subscriber Experience company, is revolutionizing the way operators and vendors monitor, manage and monetize their network traffic. Elevate your business value and improve customer experience with Procera s sophisticated intelligence solutions. For more information, visit proceranetworks.com or follow Procera on Twitter CORPORATE OFFICES Procera Networks, Inc Fremont Blvd Fremont, CA P F CORPORATE OFFICES Procera Networks Birger Svenssons Väg 28D Varberg, Sweden P. +46 (0) F. +46 (0) ASIA/PACIFIC HEADQUARTERS Unit B-02-11, Gateway Corporate Suite, Gateway Kiaramas No. 1, Jalan Desa Kiara, Mont Kiara Kuala Lumpur, Malaysia Copyright 2015 Procera Networks. All rights reserved. All other trademarks are property of their respective owners.