Minutes IETF100: maprg
minutes-100-maprg-00

Measurement and Analysis for Protocols Research Group (maprg) Agenda at
IETF-100 (Singapore) Date: Monday, Nov 13, 15:50-17:20 (Afternoon session II)
Room: Padang

Chair: Mirja Kühlewind
Chair's assistant: Roland van Rijswijk-Deij

Scribe: Mat Ford

N.B. Abstracts for all longer talks are included at the foot of these notes.

-----

Intro & Overview
---
Mirja Kühlewind (MK) provided attendees with information about the IRTF Note
Well, the research group and the agenda. If there is something you would like
to present at the IETF101 meeting in Londond, please contact the chairs. 5
minute slots are available for news announcements, or updates on previously
presented work. Longer slots are available for bigger topics.

Heads-up talk: Net Neutrality Measurements: Regulatory Use Case and Problem
Statement - Klaus Nieminen
---
See draft-nieminen-ippm-nn-measurements

Aaron Falk: Will you be releasing the data that this tool collects?
Klaus Nieminen: Let's discuss offline - answer will take some time.
MK: Read the draft, talk to Klaus, use the maprg mailing list for further
discussion.

Update on previous presentation: A Continuing Study of the Active IPv6 WWW
Client Address Space - Kyle Rose (previously presented by Dave Plonka)
---
Lorenzo Collitti: You can't issue privacy addresses
KR: Sorry, that they chose privacy addresses - some networks are using DHCP and
so don't allow the clients to choose privacy addresses. LC: Reliance Jio is a
mobile network so doesn't use DHCP. I wonder if there's something in the data
that you're not seeing. On wireline you'd expect to see these privacy
extensions. Wireline or wi-fi networks where hosts join and leave frequently
you would expect this, but on a mobile network clients will keep the same IP
until you disconnect and reconnect. So it's surprising that you see different
addresses in your data. KR: Interesting - will bring that to Dave's attention.

Wes Hardaker: Why aggregating at /64 - when /56 is currently recommended? You
may be aggregating multiple /64s that are technically in the same network. KR:
Need to refer you to Dave for an answer. WH: See the relevant RFC for
recommendation. KR: Part of the methodology is to build subnets that are large
enough to have at least a certain number of IPs. Not sure how that fits with
this study, but there may be something there.

Principles for Measurability in Protocol Design - Brian Trammell
---
Main contribution of this paper is the principles - please read and send
comments to the maprg mailing list.

The Root Canary: measuring the root KSK rollover and beyond - Roland van
Rijswijk (RvR)
---
Yoshiro Yoneya: Did you analyse root servers other than B-root?
RvR: For changes in traffic, no. We only had data from B-root. We were working
to a tight timescale so we worked with what we could get. We are interested to
work with other roots. Did you see something different? Yoneya: We saw nothing
happening on September 19th. RvR: OK so your data agrees with ours - that's
good!

Recursives in the Wild: Engineering Authoritative DNS Servers - Giovane C. M.
Moura (GM)
---
Geoff Huston: How do you reconcile recommendation to always use anycast for
authoritative name servers with impact of anycast on ICMP IPv6 packet-too-big
messages? Surely the recommendation is not a good recommendation
unconditionally. You need to be careful deploying anycast in IPv6 because you
will not ensure the integrity of any kind of ICMP packet-too-big signalling.
Your conclusion should be a lot more conditional. G. Moura: We have only done
this for IPv4, not for IPv6. Regardless the focus was to deliver better
response times, I think our conclusions still hold for that. ICMP is something
we will have to look it, but nevertheless we are focussed on latency.

MK: So come back with the IPv6 measurements.
GM: This is something we have to do.

Verfploeter: Broad and Load-Aware Anycast Mapping - Wes Hardaker (WH)
---
Robert Kisteleki (RK): Could it be that RIPE has 2000 unique /24s because the
target included an IP that is not pingable? Wes Hardaker: In some places
firewall restrictions are very different - we haven't been able to analyse why
there is that much difference - but could be entire country doesn't allow
incoming ping. RK: What stops you doing a full IPv4 ping? WH: With a hitlist
you don't need to flood the Internet - we use John Heidemann's results RK:
Doing once would give useful results - then could be repeated WH: Didn't want
to oversaturate the network RK: Understood, but tools are ready to do this if
you want

Giovanne Moura: I wondered how I could use this as an operator - I realised if
you want to design an anycast system you can use verfploeter to see what impact
of site placement decisions will be. WH:Yes, that's exactly what we did in our
DNS-OARC talk.

Mirja Kühlewind: Is the dataset available?
WH: Yes, see next slide - software, datasets and paper are all available.

----
Abstracts
----

Principles for Measurability in Protocol Design (Mark Allman, Robert Beverly,
Brian Trammell) Paper: https://arxiv.org/pdf/1612.02902.pdf

Measurement has become fundamental to the operation of networks and at-scale
services---whether for management, security, diagnostics, optimization, or
simply enhancing our collective understanding of the Internet as a complex
system. Further, measurements are useful across points of view---from end hosts
to enterprise networks and data centers to the wide area Internet. We observe
that many measurements are decoupled from the protocols and applications they
are designed to illuminate. Worse, current measurement practice often involves
the exploitation of side-effects and unintended features of the network, or, in
other words, the artful piling of hacks atop one another. This state of affairs
is a direct result of the relative paucity of diagnostic and measurement
capabilities built into today's network stack. Given our modern dependence on
ubiquitous measurement, we propose measurability as an explicit low-level goal
of current protocol design, and argue that measurements should be available to
all network protocols throughout the stack. We seek to generalize the idea of
measurement within protocols, e.g., the way in which TCP relies on measurement
to drive its end-to-end behavior. Rhetorically, we pose the question: what if
the stack had been built with measurability and diagnostic support in mind? We
start from a set of principles for explicit measurability, and define
primitives that, were they supported by the stack, would not only provide a
solid foundation for protocol design going forward, but also reduce the cost
and increase the accuracy of measuring the network.

The Root Canary: measuring the root KSK rollover and beyond (Roland van
Rijswijk, Willem Toorop, Moritz Müller)

Hopefully, it has not escaped most people's notice that ICANN is in the process
of replacing the DNSSEC signing key (KSK) for the root zone of the DNS. This
event, which started with the publication of the new key in July of this year,
is unique, as it is the first time ever that the key for the root is replaced.
In this presentation, we discuss the "Root Canary" project, the goal of which
is to monitor and measure this root key rollover. Using tens of thousands of
vantage points worldwide (RIPE Atlas probes and through the Luminati VPN proxy
network), the Root Canary project measures the impact of the root key rollover
and can function as a proverbial "canary-in-the-coalmine" if resolvers start
exhibiting problems during the key rollover. The presentation will discuss how
the Root Canary project is set up, and shows current results. In addition to
this, we discuss spin-off results, such as the DNSSEC algorithm support test.
We will end by discussing ICANN's recent decision to "pause" the root key
rollover process, and what this means for our project. For more information,
see https://rootcanary.org/

Recursives in the Wild: Engineering Authoritative DNS Servers (Moritz Müller,
Giovane C. M. Moura) Paper: https://www.isi.edu/~johnh/PAPERS/Mueller17b.html

DNS operators strive for to reduce latency for users of their service. However,
because they control only their servers, and not how their clients choose among
the servers, it is difficult to insure that that clients will be answered with
optimal latency. Knowing how clients (recursive resolvers) choose authoritative
servers is a key step to better engineer authoritative servers deployments. In
this presentation, we employ active measurements using 9,000+ Ripe Atlas probes
to determine, in the wild, how recursive resolvers choose authoritative
servers. We found a consistent behavior in seven different geographic
configurations of authoritatives: recursives query all available authoritative
servers regardless of latency, but the distribution of queries tend to be
skewed towards authoritatives with lower latency. We also discuss the
implications of these findings for DNS operators in engineering their services.

Verfploeter: Broad and Load-Aware Anycast Mapping (Wouter B. de Vries, Ricardo
de O. Schmidt, Wes Haraker, John Heidemann, Pieter-Tjerk de Boer and Aiko Pras)
Paper: https://www.isi.edu/~johnh/PAPERS/Vries17a.html

IP anycast provides DNS operators and CDNs with automatic fail-over and reduced
latency by breaking the Internet into catchments, each served by a different
anycast site. Unfortunately, understanding and predicting changes to catchments
as sites are added or removed has been challenging. Current tools such as RIPE
Atlas or commercial equivalents map from thousands of vantage points (VPs), but
their coverage can be inconsistent around the globe. This paper proposes
Verfploeter, a new method that maps anycast catchments using active probing.
During this talk, Wes Hardaker will give a brief overview of the technique and
the results and discuss how the results may apply to development of connection
based protocols within the IETF. Specifically, Wes will discuss the results of
measuring anycast networks for stability for use with TCP connections and other
multi-packet based protocols.