Gregor Maier

On dominant characteristics of residential broadband internet traffic

While residential broadband Internet access is popular in many parts of the world, only a few studies have examined the characteristics of such traffic. In this paper we describe observations from monitoring the network activity for more than 20,000 residential DSL customers in an urban area. To ensure privacy, all data is immediately anonymized. We augment the anonymized packet traces with information about DSL-level sessions, IP (re-)assignments, and DSL link bandwidth. Our analysis reveals a number of surprises in terms of the mental models we developed from the measurement literature. For example, we find that HTTP - not peer-to-peer - traffic dominates by a significant margin; that more often than not the home users immediate ISP connectivity contributes more to the round-trip times the user experiences than the WAN portion of the path; and that the DSL lines are frequently not the bottleneck in bulk-transfer performance.

A first look at mobile hand-held device traffic

Although mobile hand-held devices (MHDs) are ubiquitous today, little is know about how they are used--especially at home. In this paper, we cast a first look on mobile hand-held device usage from a network perspective. We base our study on anonymized packet level data representing more than 20,000 residential DSL customers. Our characterization of the traffic shows that MHDs are active on up to 3% of the monitored DSL lines. Mobile devices from Apple (i. e., iPhones and iPods) are, by a huge margin, the most commonly used MHDs and account for most of the traffic. We find that MHD traffic is dominated by multi-media content and downloads of mobile applications.

Enriching network security analysis with time travel

In many situations it can be enormously helpful to archive the raw contents of a network traffic stream to disk, to enable later inspection of activity that becomes interesting only in retrospect. We present a Time Machine (TM) for network traffic that provides such a capability. The TM leverages the heavy-tailed nature of network flows to capture nearly all of the likely-interesting traffic while storing only a small fraction of the total volume. An initial proof-of-principle prototype established the forensic value of such an approach, contributing to the investigation of numerous attacks at a site with thousands of users. Based on these experiences, a rearchitected implementation of the system provides flexible, highperformance traffic stream capture, indexing and retrieval, including an interface between the TM and a real-time network intrusion detection system (NIDS). The NIDS controls the TM by dynamically adjusting recording parameters, instructing it to permanently store suspicious activity for offline forensics, and fetching traffic from the past for retrospective analysis. We present a detailed performance evaluation of both stand-alone and joint setups, and report on experiences with running the system live in high-volume environments.

NAT usage in residential broadband networks

Many Internet customers use network address translation (NAT) when connecting to the Internet. To understand the extend of NAT usage and its implications, we explore NAT usage in residential broadband networks based on observations from more than 20,000 DSL lines. We present a unique approach for detecting the presence of NAT and for estimating the number of hosts connected behind a NAT gateway using IP TTLs and HTTP user-agent strings. Furthermore, we study when each of the multiple hosts behind a single NAT gateway is active. This enables us to detect simultaneous use. In addition, we evaluate the accuracy of NAT analysis techniques when fewer information is available. We find that more than 90% of DSL lines use NAT gateways to connect to the Internet and that 10% of DSL lines have multiple hosts that are active at the same time. Overall, up to 52% of lines have multiple hosts. Our findings point out that using IPs as host identifiers may introduce substantial errors and therefore should be used with caution.

Investigating IPv6 traffic: what happened at the world IPv6 day?

While the IETF standardized IPv6 more than fifteen years ago, IPv4 is still the prevalent Internet protocol today. On June 8th, 2011, several large content and service providers coordinated a large-scale IPv6 test-run, by enabling support for IPv6 simultaneously: the World IPv6 Day. In this paper, we compare IPv6 activity before, during, and after the event. We examine traffic traces recorded at a large European Internet Exchange Point (IXP) and on the campus of a major US university; analyzing volume, application mix, and the use of tunneling protocols for transporting IPv6 packets. For the exchange point we find that native IPv6 traffic almost doubled during the World IPv6 Day while changes in tunneled traffic were limited. At the university, IPv6 traffic increased from 3---6 GB/day to over 130 GB/day during the World IPv6 Day, accompanied by a significant shift in the application and HTTP destination mix. Our results also show that a significant number of participants at the World IPv6 Day kept their IPv6 support online even after the test period ended, suggesting that they did not encounter any significant problems.

Pitfalls in HTTP traffic measurements and analysis

Being responsible for more than half of the total traffic volume in the Internet, HTTP is a popular subject for traffic analysis. From our experiences with HTTP traffic analysis we identified a number of pitfalls which can render a carefully executed study flawed. Often these pitfalls can be avoided easily. Based on passive traffic measurements of 20.000 European residential broadband customers, we quantify the potential error of three issues: Non-consideration of persistent or pipelined HTTP requests, mismatches between the Content-Type header field and the actual content, and mismatches between the Content-Length header and the actual transmitted volume. We find that 60% (30%) of all HTTP requests (bytes) are persistent (i.e., not the first in a TCP connection) and 4% are pipelined. Moreover, we observe a Content-Type mismatch for 35% of the total HTTP volume. In terms of Content-Length accuracy our data shows a factor of at least 3.2 more bytes reported in the HTTP header than actually transferred.

Experiences from Netalyzr with engaging users in end-system measurement

Netalyzr is a widely used network diagnostic and debugging tool that has collected 259,000 measurement sessions to date. To use Netalyzr, users visit its website, download an applet that proceeds to conduct a suite of tests and measurements, and obtain a summary report detailing the findings. Along with the measurement data, for each session, we record the HTTP referrer that brought the user to the Netalyzr page, the level of trust the user bestowed upon the applet, and any feedback that the user voluntarily left via a form that we include at the bottom of the report page. These data sources illuminate how Netalyzrs users employ the tool, and can provide insights as to how other measurement tools or user surveys involving end-host measurement could effectively involve users. We find that even with little prompting, users leave explicit comments 3% of the time and answer one or more survey questions in 17% of the sessions, reaching up to 44% og sessions during bursts of activity. We also find that significant usage of the tool comes from four types of need: (i) to aid in troubleshooting performance for an on-line game, often via measurement sessions conducted when requested by more sophisticated users in a help forum; (ii) curiosity, often exacerbated by blog postings and other mentions on high-profile websites; (iii) repeat visitors who arrive via a search engine that they used to locate Netalyzrs website; and (iv) IPv6 deployment tests conducted or organized by specialists.

Enabling Seamless Internet Mobility

Mobility is a requirement not appropriately addressed by the original design of the Internet since an IP address has two fundamentally different tasks. It specifies a network location (for routing) and serves as an application identifier. A plethora of suggestions have been made to overcome this, e.g., Mobile IP and HIP. Yet, each of the proposed solutions has drawbacks such as requiring fundamental changes to the Internet architecture or relying on triangular routing. We propose the Seamless Internet Mobility System (SIMS) for enabling seamless IP network layer mobility. Our goals are (1) to enable mobility even for users that do not have a permanent IP address and therefore cannot rely on a Mobile IP home agent; (2) to impose no overhead for applications initiating network traffic in the current network; (3) to preserve sessions that started in any previously visited network location; (4) to be robust, scalable, and easily deployable in the current Internet; (5) address the economics of roaming between different administrative domains. The key ideas are to allow any new connection to use the current IP address and to take advantage of the heavy-tailed nature of connections. This implies that after a network change only a small number of connections need to be retained.

Enabling seamless internet mobility

Mobility is a requirement not appropriately addressed by the original design of the Internet since an IP address has two fundamentally different tasks. It specifies a network location (for routing) and serves as an application identifier. A plethora of suggestions have been made to overcome this, e.g., Mobile IP and HIP. Yet, each of the proposed solutions has drawbacks such as requiring fundamental changes to the Internet architecture or relying on triangular routing. We propose the Seamless Internet Mobility System (SIMS) for enabling seamless IP network layer mobility. Our goals are (1) to enable mobility even for users that do not have a permanent IP address and therefore cannot rely on a Mobile IP home agent; (2) to impose no overhead for applications initiating network traffic in the current network; (3) to preserve sessions that started in any previously visited network location; (4) to be robust, scalable, and easily deployable in the current Internet; (5) address the economics of roaming between different administrative domains. The key ideas are to allow any new connection to use the current IP address and to take advantage of the heavy-tailed nature of connections. This implies that after a network change only a small number of connections need to be retained.