 Welcome, my name is Ricardo Schmidt, and in this set of slides I will give an overview of Internet measurements. Let's start with the definition of what the Internet is. At its lowest granularity, the Internet is a set of interconnected autonomous systems. And autonomous systems are a set of interconnected networks, which consist of a set of interconnected devices. And every device runs a set of applications that can somehow make use of all this interconnectivity. But what can we measure from all of this? Well, basically everything. But there should be reasons for measuring the Internet at any level. And these reasons vary greatly. From network management operations to planning and traffic engineering, and to the best interest of this MOOC, network security. And that's why it's important for us to learn some basics about Internet measurements. But what do people measure? This can also vary. There are multiple metrics and targets we can measure in the Internet. These range from connectivity between autonomous systems and networks to packet loss and even reliability and applications usage. It depends on what, why, and how we are measuring. And speaking of how, there are two types of Internet measurements. Active and passive approaches. We are now going to learn a little bit about these two approaches. Let's start with active measurements, which can be quite intrusive by generating additional traffic on top of the production network. Active measurements are typically done by probing a certain target to achieve the desired metric. The most common tools in active measurements are ICMP requests, also known as PING, and trace routes. One example of study using active measurements is the Internet census from researchers from the Information Science Institute at the University of Southern California. They have been periodically probing the entire IPv4 space using ICMP requests. It is important to highlight that along the years they have adjusted their probing strategy and tools so that they can perform such large-scale measurements without becoming too intrusive. Their measurements opened up many doors for interesting problems, from basic IPv4 mapping by enumerating the IP blocks from the V4 address in space that answered the PINGs, to the visualization of the Internet alt-edge caused by natural phenomena, such as the Hurricane Sandy and the East Coast of U.S. in 2012, and to the visualization of worldwide Internet characteristics, such as the urinal patterns across the globe. However, it is not easy to deploy such a nice measurement infrastructure as our colleagues from California have done. But there are multiple measurement platforms that we can use for research. Two of these are RIPE Atlas framework and the Planet Lab. RIPE Atlas and Planet Lab are very different. Size-wise, currently, Atlas has more than 9,000 active probes, while Planet Lab has a bit over 1,300 nodes. They are also different on the way that we can use them. RIPE Atlas provides a limited set of possible measurements, works on a credit-based system, and these credits can be earned by hosting one of their probes. Planet Lab provides us with a virtual machine at the measurement locations, from where we have the freedom to customize and create our own measurements. Its use is more restrictive, though, since you have to host a node to be affiliated to the Planet Lab project. An example of research using the public data from RIPE Atlas was the analysis of the impact of a large distributed denial of service attack targeting the route DNS service on November 2015. Using the Atlas data, the researchers could show how the different route DNS servers, each one defined by a letter, handled the attack in different ways, mostly by leveraging their NICAS deployments to absorb the attack traffic at multiple sites. The picture on the right shows an example of this analysis. Atlas probes are set to periodically probe the route DNS. The drops in the plots indicate how much each route letter suffered because of malicious traffic that was consuming their resources. Note that there are several ethical issues involved in active measurements. It is important to probe politely, being careful to not abuse someone else system. It is also important to check beforehand whether other initiatives already produce or have produced data you are interested in. There are many places where to search for measurement data, such as the datasets openly shared by RIPE Atlas, Kaida, ISI through the Internet Census Project, and many others. As we said earlier, an alternative to active measurement are passive measurements. Passive measurements are not intrusive. There is no additional traffic generated. Measurements are done by simply observing the target. Commonly used approach are packet capturing, using for example TCP dump, and flow measurements. Packet capturing provides us with the most complete dataset we can possibly have. However, at high speed links and current transmission rates, capturing packet demands expensive and many times dedicated hardware and software. A good alternative to packet capturing is measuring traffic at the flow level. A flow is defined as a set of packets that share common properties, passing at an observation point. The main challenge of working with flow data, especially for security applications, is that flows only report summary of communications, abstracting information about individual packets. Every flow is identified by unique flow key. The definition of a flow key can vary, but the most known and probably also the most used one is the default definition for net flow version 5 from Cisco, which consists of source and destination IP addresses, source and destination ports, and the transport protocol. At the measurement process, flows are measured in terms of flow records. A flow can consist of multiple exported flow records, and these flow records are defined by two timeouts. The active timeout defines the maximum measurement duration of a flow. Once it is expired, a flow record is exported and the measurement counters are reset. And the inactive or idle timeout defines how long the measurement process should wait since the last observed packet for a given flow, before considering that the flow has been finished and exporting the flow record. To better understand the importance of timeouts, let's consider in the following example, where the time unit T defines the size of our measurement interval. During the measurement period from T to 5 times T, 11 packets from the same flow pass through our observation points. If our active timeout is greater than 5 times T and our idle timeout is greater than 1 T, we will see this flow being exported within a single flow record. Using the packet data to create a time series, we will clearly see the traffic peak that happens at T and 3 times T intervals, as well as the drop to 0 at 4 times T interval. Now, using the flow data, we only have a flow record that tells us that 11 packets were transferred between T and 5 T. And the maximum we can calculate is the average number of packets seen through the measurement period for that flow. As you can see, missing individual packet information can be very problematic. And when using flows, one must find ways to compensate and overcome for this problem. In a real example using flows, we calculate the required bandwidth capacity to be allocated for a given link based on measurement traffic for 15 minutes. The blue field curve shows the traffic monitor at the packet level. We can clearly see traffic burst that happened throughout the measurement period. The two flat dashed lines represent the computation of required capacity given the very same traffic measured at the flow level. The simple example shows how a flow-based approach has difficulties to account for outliers due to data granularity. And in this case, completely overlooks the traffic burst observed at 100 seconds. In the next part of this lecture, you will learn specifics of components involved in the flow measurement process and how they work together from the moment of observing a packet to storing the data in a flow collector. In this lecture, we learned that there is not a best approach for internet measurements. Active and passive approach have their respective pros and cons, and many times they complement each other. We have seen that active measurements can provide a good view of measured system. But depending on the measurements target and goal, it might demand the setting up of large infrastructures. Also, we have to be careful on probing through the internet so that our measurements do not disturb others. For passive measurements, packets provide a complete view of what goes in the network. However, packet capturing can become very expensive or even impossible due to traffic rates at current high speed links. Flows are a scalable alternative that comes at the cost of coarser data, which have to be somehow compensated or corrected.