Measurement and Analysis for Protocols Research Group (maprg)
Agenda for IETF-99 (Prague)

Session: Thursday, July 20, 2017, 09:30-12:00 (Morning session I)
Room: Congress Hall II

Intro & Overview, Project "Advertisements" [slides]
Mirja Kuhlewind & Dave Plonka
5 min

IPv6 Reluctanct Devices and Applications [Abstract] [slides]
Mikael Abrahamsson, MAPRG chairs
10 mins

Fingerprint-based detection of DNS hijacks using RIPE Atlas [Abstract] [slides]
Pawel Foremski
20 mins

Rate-limiting of IPv6 traceroutes is widespread: measurements and mitigations [Abstract] [slides]
Pablo Alvarez
20 mins

kIP: a Measured Approach to IPv6 Address Anonymization [Abstract] [slides]
David Plonka
20 mins

Measuring Latency Variation in the Internet [Abstract] [slides]
Toke Hoiland-Jorgensen
20 mins

Measuring YouTube Content Delivery over IPv6 [Abstract] [slides]
Vaibhav Bajpai
20 mins

The QUIC Transport Protocol: Design and Internet-Scale Deployment [Abstract] [slides]
Jana Iyengar
30 mins

Abstracts

IPv6 Reluctanct Devices and Applications (Mikael Abrahamsson)

There are numerous reports of consumer products and devices that either (a) don't support IPv6 yet or (b) ostensibly support IPv6 in that they configure an IPv6 address, but subsequently seem not to use it, perhaps due to their Happy Eyeballs implementation. We request that a measurement effort be undertaken to identify and report on this behavior, so that we can mitigate this impediment to IPv6[-only] operation.

Fingerprint-based detection of DNS hijacks using RIPE Atlas (Pawel Foremski and Maciej Andziński)

The DNS protocol does not protect from hijacking resolver traffic. In fact, some network operators and government agencies transparently redirect DNS queries made from end-user devices to popular recursive resolvers to their own servers. This effectively allows the hijacking party to easily monitor, block, and manipulate the content published to the World Wide Web, and in general to control its Internet users.

In this paper, we present a novel fingerprinting algorithm that is able to detect hijacking of recursive DNS resolver traffic. By sending specific DNS queries to the resolver and analyzing the replies using machine learning algorithms, we are able to classify the resolver as legitimate or rogue. We evaluate our technique through the RIPE Atlas platform, collecting DNS measurements on Google Public DNS and OpenDNS servers from 9,500 probes distributed around the world.

Rate-limiting of IPv6 traceroutes is widespread: measurements and mitigations (Pablo Alvarez)

With IPv6, high-frequency traceroutes show many more missing hops than IPv4. This appears to be due to the fact that RFC 4443 states IPv6 routers MUST rate-limit the ICMPv6 error packets that traceroute and similar programs depend on to determine hops on a route. We measured the characteristics of this rate-limiting from many vantage points to thousands of targets across continents. We find that about 2/3 of all routers exhibit rate-limiting at frequencies < 100Hz. The distribution of the data suggest most of these rate-limits might be factory defaults. We discuss strategies to overcome this limitation, including altering the order of packets across single or multiple traceroutes, and merging information from traceroutes to different targets.

kIP: a Measured Approach to IPv6 Address Anonymization (David Plonka)

Related pre-print, "kIP: a Measured Approach to IPv6 Address Anonymization" (Plonka & Berger)
Privacy-minded Internet service operators anonymize IPv6 addresses by truncating them to a fixed length, perhaps due to long-standing use of this technique with IPv4 and a belief that it's "good enough." We claim that simple anonymization by truncation is suspect since it does not entail privacy guarantees nor does it take into account some common address assignment practices observed today. To investigate, with standard activity logs as input, we develop a counting method to determine a lower bound on the number of active IPv6 addresses that are simultaneously assigned, such as those of clients that access World-Wide Web services. In many instances, we find that these empirical measurements offer no evidence that truncating IPv6 addresses to a fixed number of bits, e.g., 48 in common practice, protects individuals' privacy.

To remedy this problem, we propose kIP anonymization, an aggregation method that ensures a certain level of address privacy. Our method adaptively determines variable truncation lengths using parameter k, the desired number of active (rather than merely potential) addresses, e.g., 32 or 256, that can not be distinguished from each other once anonymized. We describe our implementation and present first results of its application to millions of real IPv6 client addresses active over a week's time, demonstrating both feasibility at large scale and ability to automatically adapt to each network's address assignment practice and synthesize a set of anonymous aggregates (prefixes), each of which is guaranteed to cover (contain) at least k of the active addresses. Each address is anonymized by truncating it to the length of its longest matching prefix in that set.

Measuring Latency Variation in the Internet (Toke Hoiland-Jorgensen)

Related paper, "Measuring Latency Variation in the Internet" (Toke Hoiland-Jorgensen et al., CoNEXT '16)
We analyse two complementary datasets to quantify the latency variation experienced by internet end-users: (i) a large-scale active measurement dataset (from the Measurement Lab Network Diagnostic Tool) which shed light on long-term trends and regional differences; and (ii) passive measurement data from an access aggregation link which is used to analyse the edge links closest to the user.

The analysis shows that variation in latency is both common and of significant magnitude, with two thirds of samples exceeding 100 ms of variation. The variation is seen within single connections as well as between connections to the same client. The distribution of experienced latency variation is heavy-tailed, with the most affected clients seeing an order of magnitude larger variation than the least affected. In addition, there are large differences between regions, both within and between continents. Despite consistent improvements in throughput, most regions show no reduction in latency variation over time, and in one region it even increases.

We examine load-induced queueing latency as a possible cause for the variation in latency and find that both datasets readily exhibit symptoms of queueing latency correlated with network load. Additionally, when this queueing latency does occur, it is of significant magnitude, more than 200 ms in the median. This indicates that load-induced queueing contributes significantly to the overall latency variation.

Measuring YouTube Content Delivery over IPv6 (Vaibhav Bajpai)

To appear in the SIGCOMM Computer Communication Review (CCR), July issue.
We measure the performance of YouTube over IPv6 using ~100 SamKnows probes connected to dual-stacked networks representing 66 different origin ASes. Using a 29-months long (Aug 2014 - Jan 2017) dataset, we show that success rates of streaming a stall-free version of a video over IPv6 have improved over time. We show that a Happy Eyeballs (HE) race during initial TCP connection establishment leads to a strong (more than 97%) preference over IPv6. However, even though clients prefer streaming videos over IPv6, we observe worse performance over IPv6 than over IPv4. We witness consistently higher TCP connection establishment times and startup delays (~100 ms or more) over IPv6. We also observe consistently lower achieved throughput both for audio and video over IPv6. We observe less than 1% stall rates over both address families. Due to lower stall rates, bitrates that can be reliably streamed over both address families are comparable. However, in situations, where a stall does occur, 80% of the samples experience higher stall durations that are at least 1s longer over IPv6 and have not reduced over time. The worse performance over IPv6 is due to the disparity in the availability of Google Global Caches (GGC) over IPv6. The measurements performed in this work using the youtube test and the entire dataset is made available to the measurement community.

The QUIC Transport Protocol: Design and Internet-Scale Deployment (Jana Iyengar)

QUIC is an encrypted, multiplexed, and low-latency transport protocol designed from the ground up to improve transport performance for HTTPS traffic and to enable rapid deployment and continued evolution of transport mechanisms. QUIC has been globally deployed at Google on thousands of servers and is used to serve traffic to a range of clients including a widely-used web browser (Chrome) and a popular mobile video streaming app (YouTube). We estimate that 7% of Internet traffic is now QUIC. This talk will cover the Internet-scale process that we used to perform iterative experiments on QUIC, performance improvements seen by our various services, and our experience deploying QUIC globally.