MAT Working Group Minutes - RIPE 79

Date: Thursday, 17 October, 14:00 -15:30
Co-Chairs: Nina Bargisen and Brian Trammell
Scribe: Ulka Athale
Status: Draft

The stenography transcript of the session is available at:
https://ripe79.ripe.net/archives/steno/47/

Introduction

The presentation is available at:
https://ripe79.ripe.net/archives/video/264

The Co-Chairs Nina Bargisen and Brian Trammell welcomed attendees and thanked the RIPE NCC staff for their support. In his opening remarks, Brian said that to some extent the MAT Working Group provides advice to the RIPE NCC about how tools like RIPE Atlas and RIPEstat are used or how they could be used in the future. He asked the group to think about whether they should explicitly make time for this feedback on the agenda.

Decrypting QoE in an Encrypted Internet – AI to the Rescue

Sarah Wassermann
The presentation is available at:
https://ripe79.ripe.net/archives/video/267

Chris Woodfield, Salesforce, representing ARIN AC, said that Sarah had mentioned an issue with not being able to do chunk detection in video streams, presumably because the payload is encrypted and she would not be able to see the HTTP GETs. He asked if she could possibly detect chunks via traffic pattern analysis? Most responses are likely to be TCP ACKs, which is encrypted but has a certain traffic pattern as opposed to a full-sized HTTP GET request. Is this something that was attempted and failed, or considered?

Sarah replied that she tried this chunk detection by looking at different packets and the inter-arrival times, but it was quite error prone and takes time. They wanted to be as lightweight as possible, avoid errors, and it was more complex to do.

Atlas and Ark Data in Google BigQuery

Stephen Strowes
The presentation is available at:
https://ripe79.ripe.net/archives/video/268

Qasim Lone, TU Delft, asked if Stephen was doing anything with traceroute loops in mailing, because CAIDA’s data shows that they also have mailing loops.

Stephen replied that he wasn’t sure if he would need to break out into user-defined functions and write custom code, but it can be done. He added that he wasn’t doing this yet as he was wary because traceroute data is messy.

Robert Kisteleki, RIPE NCC, pointed out that this was an enabler for researchers who want to combine Atlas datasets or Ark data sets with any other datasets they already have in BigQuery, which inflates the value of the datasets tremendously.

Stephen added that this was obviously in there with matching against BGP tables. For smaller dataset they could throw in the metadata for probes e.g. queries of the form “give me measurements from probes in a particular country”. You can add what you like and match.

Brian asked how long it took to generate adjacencies, the time to find adjacencies etc. and the computing time. Stephen replied that SQL is not his native language so it took him time to learn to use it. He spent a lot of time figuring out how to do prefix matching, but once he got there it was quick. Building the adjacencies for one day’s worth of traceroute data, re-running the graphs take between five and ten minutes. None of the graphs took longer than ten minutes to generate even from scratch, while dealing with two months of traceroute data. He added that he wants to share code because he would like to put down examples for how he built the graphs.

Brian asked if Stephen would write RIPE Labs articles on BigQuery SQL because he would find it useful as someone who hasn’t learned it yet. Stephen stated that he is planning to write such articles in the form of a tutorial.

Analysis of Periodic Behavior in Network Measurements

Massimo Candela
The presentation is available at:
https://ripe79.ripe.net/archives/video/271

Brian remarked that it was very fun research, because Massimo found a particular phenomenon and a whole bunch of different ground causes for it, with the majority not really easily explicable. He also asked if he would continue the research because that could help understand the biases in the platform.

Massimo answered that roughly 40% were not explained, and said he welcomed contributions to possible answers. He added that they would and also asked if others could contribute ideas.

Blake Willis, referring to the slide correlating Atlas probe data with Control plane, asked if there is a way to ask the Atlas people to spread out the tests that are firing on the lists more cleanly. He asked if Atlas could be a cause of the problem.

Massimo said that they were already working on that, and there was a mechanism in place. He would investigate it. It could be connected to how the measurements are scheduled.

Philip Homburg, RIPE NCC, commented that if Atlas was working correctly then every time a periodic measurement was run, it should take a time interval of roughly 7 seconds and then pick a random spot in that time interval to run the measurement. It should be roughly periodic because it’s an interval of 15 minutes but the exact times should vary, but there could always be a bug.

Massimo pointed out that different measurements might overlap in that case.

Measuring Micro-Dependability

Olav Kvittem
The presentation is available at:
https://ripe79.ripe.net/archives/video/274

Ivan Beveridge, IG, asked whether he had any ability to get his upstreams to de-preference his traffic rather than just having local preference sending traffic his way.

Olav replied that he hadn’t done anything to traffic flows and he wasn’t sure if he understood the question.

Rayhaan Jaufeerally, Google, asked if it’s possible to use this ICMP backscatter to pre-emptively switch to a less-preferred route if you know that there is unreachability.

Olav said that it was a good idea, if you have a multi-session transport protocol it would be interesting to try a new address if one fails. He suggested trying this out during a hackathon.

Chris Woodfield, Salesforce, commented that increasing reliability doesn’t come for free, he asked what the return on investment would be when it comes to taking the necessary steps to do this. He also asked that if the Internet was more reliable than it is today, what currently unviable use cases would become viable. This context is useful while thinking about what needs to happen to make the Internet more reliable.

Olav replied that high-quality low delay video doesn’t accept even small outages, and if people want to fly less, we need high-quality video, so there are reasons for doing this.

Tools Update

Robert Kisteleki
The presentation is available at:
https://ripe79.ripe.net/archives/video/275

Randy Bush commented that he believed in giving credit where due. A group of them played with the Atlas probe on software, led by Marco Sinaro, with the goal of supporting it to a Pi, LoRaWan gateway.

Leslie Daigle, Thinking Cat Enterprises, said that she appreciated the need to worry about scale and scope from a standpoint of people who might install this on their laptops, and then have bouncing probes. She asked if the infrastructure was ready for something like an architecture in which a network operator decides to insert with software probes.

Robert replied that the infrastructure was designed with scalability in mind, but they do have bottlenecks, and they were committed to finding them and fixing them as they go along. That said, they would also look at what provides value to the community, and whether it was valuable to have lots of probes with the same provider. There are likely to be limits imposed but he could not predict the how exactly it would work in the future.

Massimo said that he loved the idea of software probes. He wanted the community to know that RIPE Atlas rocks in the terms of reliability and latency measurement, also related to geolocation for example. He suggested to keep going with physical probes if they are also going with the software ones.

Robert replied that they would continue to maintain hardware probes for the foreseeable future. People might want to replace their hardware probes with a software probe. He believed that over time we might have more software probes than hardware, but for the moment they had no intentions to stop.

Randy Bush stated that Stephen Strowes is trying to compare two Atlas software probes that are located on the same LAN as a hardware probe. Robert replied that they had done something similar with VM anchors where they compared hardware with the virtual.

Brian asked if there was a plan once this goes to general availability, to be able to tag a software probe as being adjacent to a hardware probe? That would give the ability to differentiate between the two and look at variations in them, in the production system.

Robert said it was good research question to see if they could be differentiated at a distance.

The co-Chairs thanked everyone and concluded the session.