Implementación de la interfaz gráfica

For the purposes of showing how HICCUPS can be used in debugging, we will walk through an example scenario to detect a blocked ECN negotiation. In this scenario, both hosts A and B of Figure 7.1 are ECN-enabled and request ECN during TCP connection negotiation. The middlebox script described in Section 7.4 is programmed to set both ECN flags in the TCP header to zero on any packets it sees (i.e., to improperly clear these ECN bits). As we will see later in Section 8.3.2, this behavior occurs in the wild on the actual Internet. The modification has the effect of preventing both end hosts from using ECN, even when they both support it.

Working from the point of view of Host A, we have reason to believe that ECN is not working properly. For example, if we run a packet capture during a connection attempt to Host B, we notice that SYN-ACKs returning from Host B do not have ECN enabled, as shown in Figure 7.2. The SYN leaves Host A with the ECE and CWR TCP flags set

(to indicate a desire to enable ECN for this connection), but the SYN-ACK returns from B with neither flag set, even though they should be set. If we have administrative access to Host B, we can verify this claim using traditional debugging methods (i.e., run a packet capture at both ends and compare the headers). However, with HICCUPS, we can verify this behavior without needing access to Host B at all.

Figure 7.2: Screenshot of packet capture from Host A

Using HICCUPS, we confirm that a middlebox is disabling our ECN flags in transit be- tween A and B. Shown in Figure 7.3 is the output from running our user-space HICCUPS test client on Host A. The user-space HICCUPS client mirrors the same logic used in the Linux kernel patch implementation.

Figure 7.3: Screenshot of HICCUPS test client probing from Host A to B with ECN enabled

First, HICCUPS probes (i.e., standard TCP connection attempts) are sent from Host A to B. The failed integrity checks reveal to A that a modification is occurring on its SYN, but not the SYN-ACK. Specifically, that the modification is to one of the bits covered by

the HECNTCP probe type. Second, assuming we have no knowledge of what changes the middlebox simulator is making, we can try disabling ECN to further test if a middlebox is targeting ECN in particular. We disable ECN negotiation on Host A and try testing with the HICCUPS client again. Now, as we see in Figure 7.4, no modifications were detected by HICCUPS implying that the middlebox was specifically configured to target ECN flags.

CHAPTER 8:

Surveying Internet Paths with HICCUPS

If you cannot measure it, you cannot improve it.

Lord Kelvin

This chapter details results from running HICCUPS in the wild. We examine the types, frequencies, and symmetry of HICCUPS-inferred modifications and give examples of how a HICCUPS-enabled TCP can adjust its behavior based on path inference to improve per- formance. Last, we discuss HICCUPS overhead, including the empirical number of RTTs for full-path characterization.

While previous research [12, 19, 20, 39, 43] examined real Internet paths to catalog various forms of packet header modifications, these efforts required some degree of interaction ex- ternal to the operating systems. To our knowledge, HICCUPS is the first solution to both capture measurements of packet header modifications within TCP and expose the results directly through the operating system itself. For example, the servers in our measurement infrastructure do not run any specialized server application. Instead, we simply start a stan- dard HTTP daemon that listens on the desired port(s). With a HICCUPS-enabled kernel, no extra support is required to perform HICCUPS and expose path behaviors to the operating system and applications.

8.1

Experimental Infrastructure

Using HICCUPS-enabled hosts, we survey a diverse set of real Internet paths. We employ 218 Planetlab [119] nodes, 56 Archipelago (Ark) [120] nodes, and 12 distributed HICCUPS servers; the autonomous system (AS) and geographic distribution of our infrastructure is given in Tables 8.1 and 8.2. This infrastructure enables us to run HICCUPS between 3,288 pairs of distinct hosts, testing 26,304 directed path/port pairs.

Our HICCUPS-enabled Linux kernel runs on 12 systems: one at MIT, one at Virgina Tech, one at ICSI, one on Comcast Business, and one at each of the eight Amazon EC2 infras-

Table 8.1: Top ASNs represented

Servers PlanetLab Ark AS16509 6 AS680 13 AS22773 3

. . . 1 ea. AS2200 6 AS1213 2 AS766 6 . . . 1 ea.

. . . <6 ea.

Total 7 Total 154 Total 53

Table 8.2: Geographic distribution

Location PlanetLab Ark Servers Europe 101 18 1 N. America 75 25 7 Asia 26 9 2 S. America 10 1 1 Oceania 6 0 1 Africa 0 3 0 Total 218 56 12

tructure sites. To run HICCUPS from PlanetLab (where installing a custom Linux kernel is not possible), we duplicate the connection initiation portion of TCP with HICCUPS into a user-space client that employs raw sockets to craft HICCUPS-enabled SYNs.

In selecting PlanetLab nodes, we used PlanetLab’s management API to use a single node per site. Thus, all 218 Planetlab nodes we use represent distinct sites. The PlanetLab nodes were distributed both geographically and logically around the Internet. The Planetlab and Ark nodes reside in 207 distinct ASes. Geographically, our Planetlab nodes are situated in five continents and 37 different countries, while the Ark nodes are spread across 28 countries.