Measurement Result

In this section, we illustrate our approach via some experiments.

2. Initial Platform 15 2.3.2.1 Wireless vs. Wired Client

The experiments are done in a private home on both, a wired and wireless PC sharing the same network access. We run the tests on two PCs simultaneously. In order to make the client fetch the Web content from the server, we automatically clear the browser cache after each browsing.

Load times of the YouTube sessions, where the main page of YouTube is requested, are shown in Fig. 2.4(a)-2.4(b). We see that most of the YouTube Web sessions in both, the wireless and wired cases, achieve load times of two seconds or less; However, in the wireless case, there are some outliers with very high values: The first impression time sometimes being larger than 5 seconds and the page full load time as large as 10 seconds. In Fig. 2.4(c)-2.4(d) (best viewed in color), we see that some of them have large handshake time and others may have large data transfer period. The explanation for these large values can be obtained looking at Fig. 2.4(e) and Fig. 2.4(f), which depict the Net.RTTs.

For the wired case we see very stable values in the range between 20 – 100 ms. However, in the wireless case these values increase to 3 seconds. There are two possible explanations: (i) the wireless access point is overloaded or (ii) the quality of the wireless link is poor, which results in many link layer retransmissions.

2.3.2.2 Student Residence A

In the second experiment we have a client PC in a student residence. The client is connected via Ethernet and is sharing the access link from the residence to the Internet with a large number of other clients.

Fig. 2.5(a) depicts the page load times as experienced by the client. We see that the full load times are in the order of 5 seconds or higher. Some of the first impression times are also in the order of several seconds.

Fig. 2.5(b) shows the contributions of the different metrics that make up the load time of a Web page.

What is striking are the high values fortDNS and tTCPRTT relative to the timetDataTrans it takes to download the data of the object. In Fig. 2.5(c) we plot the DNS response time and TCP handshake time values. We see that the values are either below 200 ms or above several seconds. Since the default timeout value for DNS and TCP SYN retransmission in the Linux client is 5 seconds and 3 seconds respectively, we can infer that the high values observed are due to packet loss and retransmission after timeout. Fig. 2.5(d) shows the retransmission rate during data downloading for all the sessions. We see that all sessions suffer from packet retransmissions, with a retransmission rate ranging from 1%

up to 8%. Also, not shown here, most of the retransmissions are triggered by timeout and not by fast retransmit¹.

2.3.2.3 Student Residence B

In the third experiment, we move to another student residence and the client PC is connected to Internet with its public wireless access point.

Fig. 2.6(a) depicts the client perceived results for the YouTube page. We see that, for both first im-pression and full load time are larger than 10 seconds in the first 2 hours (e.g. 22:00–00:00), and less

1We sayfast retransmitas 3-duplicate ACK observed before retransmission; otherwise asretransmission timeout.

16 2. Initial Platform

(a) User Perceived Results in Wireless Connection

17:30 18:00 18:30 19:00 19:30

(b) User Perceived Results in Wired Connection

17:300 18:00 18:30 19:00 19:30 10

17:300 18:00 18:30 19:00 19:30 2

Figure 2.4: YouTube Sessions of Wired and Wireless Client.(starting around 2011-02-22 17:30) than 3 seconds in the last few hours (e.g. after 2:00 am). We pick up parts of Web browsing with goodandbadlabels in Fig. 2.6(a) and show the weighted breakdown in Fig. 2.6(b)-2.6(c). From those breakdown figures, we see that:

1. Service offset takes large portion in thebadsessions.

2. Handshake SYNACK RTT almost weights nothing for bothgoodandbadsessions.

We start to investigate this behavior by the RTTs in Fig. 2.6(d). We see that SYNACK RTT is almost close to0ms, while Net.RTTs locate on two regions: one part that with the ACK payload=0 locates very close to100ms; while another with ACK payload size>0 are from50ms up to100ms. Based on this observation, we suspect that there should be a proxy close to the client and is used to establish TCP connections with client and such100 ms should be a threshold of the proxy for each HTTP request:

if the GET request does not receive corresponding data from remote Web server within 100 ms, as shown in Fig. 2.7(a), the proxy will send back the ACK to the client to avoid request retransmission;

otherwise, as shown in Fig. 2.7(b), the proxy can directly send back the ACK together with the data.

2. Initial Platform 17

00:000 00:30 01:00 01:30 02:00

5

00:000 00:30 01:00 01:30 02:00

2

Figure 2.5: YouTube Sessions at Student Residence A. (starting around 2011-02-20 00:00)

Due to large weight for service offset in the whole page downloading, we report the results in time-series in Fig. 2.6(e). We see that large delays existing before 2:00 am while almost negligible after-ward. Based on all the above discussions, we infer that bad performance for the Web browsing in this residence is due to the proxy side overload.

To learn more about this home network environment, we set up a Web server outside this residence and make the client PC inside the residence browse a particular Web page of our server. Meanwhile, we capture the traces at both client and server sides. We make such tests during both an evening period right after dinner and also early in the morning, we assume these periods as peak and non-peak Internet usage hours for the residence inhabitants. In Fig. 2.8, we show the measured handshake RTT (RT Tsin Fig. 2.7(a)) that captured at server side for both periods². From Fig. 2.8, we clearly discover the differences, e.g. RTT values in both periods can have as large as 10 times differences in the median case. Such observation also illustrate possible overload behavior at the client side proxy.

Indeed, such proxy in this network environment can be considered as an HTTP proxy which is work-ing on port 80. We show an example by collectwork-ing 1-hour random browswork-ing trace from this residence, Fig. 2.9(a)-2.9(b) report different RTTs of this random trace for port 80 and 443. We see that con-nections for port 80 have similar RTT behaviors as discussed before, however, concon-nections for port 443 have SYNACK.RTT and Net.RTT quite close with each other which indicates that no connection manipulation for that port.

2We use RTT samples with no retransmission occurring during TCP handshake.

18 2. Initial Platform

22:300 22:40 22:50 23:00 23:10 23:20 10

03:000 03:10 03:20 03:30 03:40 03:50 5

22:000 00:00 02:00 04:00 06:00 50

Figure 2.6: YouTube Sessions at Residence B. (starting around 2010-11-23 22:00:00)