In this section, we detail our methodology for measuring and understanding the feasibility of outsourcing an OpenFlow controller to a cloud server given the current residential network con- nectivity present in the continental United States (US). We focus on the continental US given its broad geographic region, diverse last-mile network connectivity, and its mixture of urban and rural residences. We leverage four popular public cloud platforms: Amazon EC2, Google Cloud Plat- form, Microsoft Azure, and Digital Ocean. Using these services, we host a total of 12 measurement servers inside virtual machines (VMs). In addition, we also include a server running in a VM at our university. These servers are geographically spread across US, as shown in Figure 8.2(a), and are used in either a proxy or measurement server role. We then recruit residential users to perform two separate sets of measurements using the above infrastructure. We collect network-level data for both network latency and bandwidth to determine the performance implications of a cloud-based OpenFlow controller on residential networks.
We now describe our measurements and participant recruiting methodology in greater detail.
8.3.1
Cloud Controller Latency Measurement
As discussed in Section 8.2, the network latency between the SDN controller and the residential router is an important factor that could influence residential network performance. To gauge the feasibility of our ReSDN architecture given the current public cloud infrastructure, we conducted a two-week measurement in August 2016.
Using Amazon’s Mechanical Turk service [140] we recruited participants and provided them with modest compensation to visit a speed testing website 1 that we hosted at our institution. Through that service, we initially recruited a total of 497 unique participants. However, we had to exclude users that did not meet our eligibility criteria, namely that the user is located in the United
Mechanical Turk Users Throughput Users Measurement Servers
(a) Mechanical Turk users and cloud infrastructure
For each server: connect();
Browser
Home
RouterWAN Estimated RTT Pcap Mechanical Turk U seri U seri M S13 … Pcap M S2 M S1 Pcap (b) RTT measurement
For each server: Download(); Upload(); Browser Home RouterWAN Throughput UserU serii Estimated Bandwidth Pcap M S13 … Pcap M S2 M S1 Pcap Pcap Pcap M S2 M S13 Stage 1 Stage 2 (c) Throughput Measurement
Figure 8.2: Illustration of our data collection and measurement methodology. Figure 8.2(a) shows the distribution of Mechanical Turk users, throughput users, and measurement servers3. Fig- ure 8.2(b) shows the process an Mechanical Turk client performs allowing us to determine RTT. Stage 1 in Figure 8.2(c) shows the throughput clients perform a series of downloads and uploads directly to all servers. Using JavaScript approximations in Stage 2, these clients perform an ad- dition download and upload using the fastest server as a proxy to the slowest and next fastest server.
States and is using a residential network connection (which excludes VPNs, cellular connections, and corporate networks). We used a combination of reverse DNS, IP geolocation databases, and an examination of the IP address’s associated network provider, we filtered our participants to a total of 270 eligible participants.
During the speed test, the residential user’s browser first downloads a JavaScript file that contains URLs that can be used to access our distributed cloud VMs. The browser then runs the script to establish HTTP connections to all our VM servers. We calculate the round trip time (RTT) between the residential user and all cloud servers using packet captures collected at the VM servers. We present and analyze these results in Section 8.4.
8.3.2
Cloud Middlebox Throughput Measurement
We perform a throughput measurement to determine what impact, if any, a cloud-hosted middlebox would have on the end-to-end throughput between a residential user and a cloud server. In theory, the impact should be relatively small if the cloud-hosted middlebox has good network connectiv- ity since the “last mile” connection between the residential user and the user’s Internet Service Provider (ISP) is often the throughput bottleneck and cloud providers often have high available bandwidth and have a successful track record of hosting servers that demand high throughput, like video streaming providers. However, in practice, rerouting network traffic can expose new throughput bottlenecks or congestion on either the original or rerouted path. Accordingly, we empirically examine the impact of cloud middleboxes.
We recruited 13 users, comprised of colleagues, family, and friends, from 11 different states
across the US, shown in Figure 8.2(a). Again, we use the same measurement infrastructure3 and the JavaScript-based approach to perform throughput measurements. To measure the end-to-end throughput between a residential user and a cloud server, the user’s browser first downloads an 18 MB file from the server and then uploads a 10 MB file to the same server. The browser calculates both the download and upload throughput by dividing the file size by the transmission time as mea- sured in JavaScript. For both upload and download throughput, we separately sort all cloud servers in descending order based on throughput measurements and labeled as {M S1, M S2, . . . , M S13},
whereM S1represents the server with the best throughput between itself and the client andM S13
represents the server with the worst throughput between itself and the client. We then perform two more throughput measurements: 1) an end-to-end throughput measurement from the client to M1 to M2 and 2) a measurement from the client to M1 to M13. Intuitively, these extra two
measurements show us what throughput impact one would expect for the client if a cloud-based middlebox was hosted at the M1 site and provided connectivity to the other sites. The first
case is most likely to manifest a throughput degradation since the throughput to M2 is relatively
good. The second case, via M13, has relatively poor throughput and would be least likely to have
a throughput degradation. Accordingly, these are useful sample points for bounding the likely throughput a client would see when tunneling via a well-positioned cloud middlebox in practice. The corresponding bandwidth results and the performance implications of using cloud middleboxes are presented and analyzed in Section 8.5.