MAT Working Group Minutes - RIPE 87
Tuesday, 28 November, 16:00 - 17:30 (UTC+1)
Chairs: Massimo Candela, Nina Bargisen, Stephen Strowes
Scribe: Ties de Kock
Status: Final
Welcome
The presentation and recording are available at:
https://ripe87.ripe.net/archives/video/1168/
Massimo Candela welcomed everyone in Rome and shared the agenda, covering topics such as censorship, traceroute, QUIC, and an NCC tools update.
Measuring Internet Censorship with OONI
The presentation and recording are available at:
https://ripe87.ripe.net/archives/video/1170/
Arturo Filastò presented how the Measurement Aggregation Toolkit from OONI can monitor Internet censorship – the intentional control or suppression over what can be viewed online.
Maksym Tuliev from Netassist said that they are an Internet provider that tries to provide Internet access without any restrictions. He asked Arturo if there was a solution that could be used to learn about uplink censorship and that they should change over to a clean route if such a source is available. Arturo replied that running an OONI probe can help them collect this information and provide insight. However, this tool relies on testing lists created by regional and global experts; it cannot test all the sites. OONI can confirm what is blocked, not confirm that nothing is blocked.
An audience speaker then asked where OONI gets information for testing lists and specifically asked if they use country-specific block lists, possibly from open sources. Arturo replied that they monitor block lists (e.g. Roskomnadzor in Russia has an official list). However, these lists are far too large to scan from mobile phones. They make a selection of what is relevant and what is not. The OONI testing lists are not block lists; they are a curated representative selection of content that might be blocked and, if blocked, would significantly impact the countries.
Where the !?*! Are the Packets Going?
The presentation and recording are available at:
https://ripe87.ripe.net/archives/video/1171/
Luca Sani gave a presentation on their enhanced version of Dmitry Butskoy's traceroute that adds measurements based on QUIC as well as measurements that use packets within a TCP flow (“TCP InSession”) that are less likely to be filtered by firewalls.
Alexander Azimov from Yango then asked if there is the opportunity to see multiple paths while running the TCP InSession traceroute only once. Luca replied that you want consistency in measurements. TCP InSession works, but for multipath tracing, TCP traceroute is better. Alexander then suggested that TCP InSession could be improved by adding a flag that performed multiple sessions simultaneously and giving an output showing the different paths discovered with this session.
Ah, This Is How Packets Get Here! Measuring Reverse Paths on the Public Internet
The presentation and recording are available at:
https://ripe87.ripe.net/archives/video/1173/
Valentin Heinrich presented on (reverse) traceroute, which is an extension of traceroute, which only illuminates the forward path, with an ICMP protocol extension (“Augsburg traceroute”) that allows analysis of the reverse path. Their approach does not require new support in routers and minimizes abuse potential. Furthermore, according to the author’s analysis, extending existing ICMP types with new codes is deployable.
Alexander Azimov from Yango asked if the presenter felt they were reinventing RPC over an ICMP transport: Reverse traceroute is asking another device to execute an action using ICMP. Valentin disagreed. They want to extend ICMP to function like ping but incorporate this reverse traceroute functionality.
Alexander’s second question was about spoofing and service discovery. Valentin explained that service discovery is implemented by the client sending an invalid time to live in the request, which the client can easily distinguish from a typical ICMP echo response. This way, the client can detect that a server is running a reverse traceroute. There are no countermeasures for spoofing in the protocol; it relies on source address validation. However, the next release will add source network filters that can be used to restrict where the requests can be made.
Harry Cross (no affiliation) then asked if the implementers had considered adding authentication. Valentin clarified that they had not done so because they wanted to keep it as simple as possible.
ECN with QUIC: Challenges in the Wild?
The presentation and recording are available at:
https://ripe87.ripe.net/archives/video/1174/
Sander Constantin and collaborators investigated the implementation of Explicit Congestion Notification (ECN) with the QUIC protocol. ECN signals potential congestion to avoid packet loss. For ECN to work, cooperation between network layers is needed, and in practice, ECN support varies and faces issues. In QUIC, ECN support is mandatory, but in practice, it is inconsistently applied, leading to a low usage rate. The research highlighted that while some domains and hosts support ECN, many fail ECN validation checks due to network and stack impairments. The authors conclude a growing trend in ECN use and the potential for improved ECN usage with QUIC, providing a path towards enhanced congestion management in the future.
Nina Bargisen, MAT WG co-chair, asked if, if the current trends continue, and we reach a point where the ISPs are free of [ECN] re-marking, and all the QUIC stacks would mirror ECN, we will never see packet loss on the internet again. Sander clarified that if ECN is not impaired on the path, that does not mean it is working. It is hard to check if ECN is working. Routers must decide to set ECN. That a router does not impair ECN does not mean that said router does mark packets when they experience congestion. As a result, Sander concluded that packet loss is here to stay.
RIPE NCC Tools Update
The presentation and recording are available at:
https://ripe87.ripe.net/archives/video/1176/
Robert Kisteleki from the RIPE NCC presented an update on the RIPE NCC's measurement activities. The Routing Information System (RIS) team plans to change the routing beacons and reduce redundant data collection. The RIPEstat team is updating the user interface, replacing older technologies and introducing new widgets. RIPE Atlas’ developments focus on cost-conscious data storage (also presented during the RIPE NCC Services Working Group) and an updated user interface. Robert introduced two proposals in the MAT Working Group. The first is on the role of applications aggregating RIPE Atlas data, and the second is to review the data retention policies. Robert asked for feedback on these changes and proposals to help guide future developments.
Simon Leinen (SWITCH) said that he was happy that RIPE Atlas acknowledges the role of aggregators. Simon saw the RIPE NCC as the stewards of the Atlas data and hoped a pragmatic method could be found where the data and APIs are open, but the RIPE NCC does not lose visibility on the number of users. He continued by asking how you can measure that the cost of storing the data is sustainable. Simon said that with qualitative criteria, a manager can decide the value is not there, and that data could be thrown away. Robert replied that they are also asking for guidance on that area: what does the community think is sustainable? Keeping all data but not spending money on it is not sustainable. Robert wanted high-level guidance from the community.
Gert Döring from SpaceNet agreed with the principles proposed. Regarding the question of sustainability, Gert said that it would help to have numbers. Hypothetically, they are spending 50M for monthly data storage, but if they move it all to this drive, it will be EUR 10, or more realistically things. Gert expected fast storage in the cloud to be extremely expensive and a raid array somewhere else to be cheaper, but unsure of how much. This discussion on data storage is, of course, related to the NCC budget and discussions around the NCC budget.
Gert moved on to his second question about aggregators. If an aggregator can do thousands of measurements a day, the aggregator has to have credits. If they have credits, they provide probes, they provide value. Having the aggregator is a good thing because it brings measurement value. Gert appreciated formalising this in a useful way.
Randy Bush from IIJ research and Arcus clarified that he is a consumer and will not weigh in on these proposals. However, he has asked what view each RIS peer gets. This has been asked and discussed often, and Randy wanted this question to be kept alive.
Massimo Candela, as MAT WG chair, asked Robert what response he wanted to the proposal. Robert clarified that there is a forum topic for one proposal and a forum topic for the other. There is also the MAT WG mailing list. Robert encouraged everyone to provide feedback through whichever of these channels you prefer. However, it is not only feedback but also a discussion that needs to be had. They want to hear people's opinions and input.
Massimo continued with a reaction from his perspective on the role of aggregators. They are strongly opposed to aggregators. Massimo thought the topic of aggregators was raised due to lack of attribution and thought they should focus on that. The original deal was that a user had credits and could do whatever they wanted with them. They agreed to provide data on users of the aggregator. Massimo is opposed to a model where you are required to sponsor Atlas at some level of usage. For example, many Atlas users gain business value from Atlas when troubleshooting for work. Robert acknowledged Massimo’s position and that it made sense to him. But they need more input to conclude this is the consensus.
Cristel Pelsser from UCLouvain said that they are a large user of RIS and RIPE Atlas data and find this data very useful. Storing older data on colder storage makes sense. What Cristel has been working on with some PhD students and postdocs is a look forward on what data to store. The data has a lot of redundancy, so they are researching what data is redundant from the start and could be deleted immediately. Their submission at HotNets (https://conferences.sigcomm.org/hotnets/2023/papers/hotnets23_alfroy.pdf) may be interesting for the team.
Ivan Beveridge from LMAX commented that Robert is likely aware that some aggregators are potentially commercial while others are doing so for free and providing functionality. An aggregator does not need to have commercial gain. Robert acknowledged this scenario and said they must distinguish academic aggregation from non-profit versus for-profit.
Stephen Strowes concludes that continuing this discussion on the mailing list would be good.
Closing Remarks
The presentation and recording are available at:
https://ripe87.ripe.net/archives/video/1179/
Stephen Strowes concludes the session and mentions two important announcements. First of all, the PC elections are open. Second, he gave logistical details for the evening program.