Main hall
RIPE 90
Tuesday, 13 May 2025
4:00 p.m.
MAT Working Group
STEPHEN STROWES: I heard a bell outside. Good afternoon, we are here for the Measurement Analysis and Tools Working Group, if you would like to grab a seat. If you are not here for the MAT Working Group, you are still welcome to grab a seat.
Good afternoon, and welcome one and all to the RIPE 90 MAT Working Group session. We are your friendly co‑chairs. I am Stephen, we have Nina and we have Massimo sitting down here at the front. You will hear from both of them as we work our way through the session today.
Before we dig into the content, before we dig into the meat, I am going to afford our it was a little moment to review what we consider to be the goals and the purpose of the MAT Working Group and a little bit of data data on how we think we are doing. We assume you are familiar with this, but maybe a bunch of people haven't been at the MAT Working Group in the past. The purpose of the Working Group is largely to try and bridge the gap between research work and operational or engineering work. That's a difficult gap to try and bridge.
If you are at yesterday's Plenary sessioney liaise a gave a really interesting talk on precisely this and has done a lot more actual research into the differences between these two worlds. We are in that sense, not necessarily experts, but we are trying our best as your friendly co‑chairs.
We want to bring in new people into the this community and we want to give people time on the stage to share their works, build new connections get good feedback, find work, etc., all those good things.
To that end, in this house we like data, I am willing to assert, so rather than data I'm going to look at some metadata for how we are doing in the MAT working group. This is a little bit of introspection. The data that we're looking at is from the last six meetings, this is fully unscientific analysis that we did within the last twelve hours. Massimo and I remember very jet lagged. If you have critiques on our analysis or opinions, please go to the mailing list or e‑mail us directly on the Chairs mailing list. I have six data points, graphs, percentages, etc.
.
First, is geographically where do we get our content from? And short version of of this is we are balanced a little bit towards the US based on the way that I am counting this data. I am looking at affiliation, not necessarily the geographic local of the person who submitted the work. So for example, if I had submitted something in the last six months, six meetings, I would have counted that as vastly, which is US. After that, there is the US bar on the graph is effectively the corporate end of the spectrum. The European countries are largely the academic contributions, that's where some of the real interesting stuff is. If your country is not on the graph, please consider submitting to MAT in the future. We would like to see this graph spreading out to the right.
How much peer review content do we bring in that's a content of the indication of the work having some substance to T like a community of researchers has reviewed the work and decided that it's good and ready for publication, and we're somewhere around about two thirds peer reviewed, one third not. Some of the stuff that we're carrying is in review, which means that it might not be published yet. Some of the stuff that we're carrying is work that we are kind of scooping before the formal presentation at a research conference, which is always nice to do. It's nice when people want to bring their work in here before they maybe present an IMC or a TMA.
We get to be a little bit selective in the MAT Working Group. We have more submissions than we can actually take. And our acceptance over the last six meetings is about 60%. I don't have a value judgment on what a good number is or is not but that's where we stand. So, we get to choose, which is a nice position to be in.
In terms of bringing people into the community, inaugural meetings, as far as we have looked at from the data, about 50% of the people who have stood on this stage at a MAT Working Group session in the last six meetings, about 50% of those, this was their first meeting. We think that's pretty cool. We think that's good evidence of bringing people into the community.
Are we bringing in academic or industry? This correlates with peer review versus not peer reviewed but we have roughly two third of the presentations are academic presentations. One third of the presentation is not.
And finally, you rate the talks. So this is our metric for are you happy? And our metric, our indications from the last six meetings is that people are scoring these high. Nobody is super bad, nobody is scoring anything down low like 2.0 or whatever. Our common ratings were 4.6, 4.7, 4.8. People seem happy with what we're putting forward here which is a useful reminder to log in and rate the talks during this session, if you are happy with what you are seeing.
We have an interruption. Which I will now ‑‑ thanks Massimo. I have two announcements to make from the RIPE NCC. RIPE PC election voting has opened as of 4 p.m. and will close on Thursday at 5 p.m.
And the second announcement is there are no buses to the venue for tonight's social. You can walk there. That's what they say. The venue is about 20 minutes away. Use public transport or take a taxi. The directions are on the meeting website. I think it is pretty close by.
That's enough from me. I'm taking up the time. We have an interesting agenda for you today. We have six presentations and we are ranging from low level hardware performance up to global consolation networks, our first speaker please.
He is a journey data scientist and his work focuses on end point monitoring and automatic detection of network anomalies.
JULIEN GAMBA: Thank you. Good afternoon everyone. We are going to take a quick break from BGP, IXP and all that stuff and focus a bit more on what's happening on the client. Specifically we're going to talk about.video applications which, I am not going to surprise anybody in this room when I say they are everywhere, I am sure everyone uses them at least weekly if not more. I use them everyday basically. My boss is probably watching right now using one.
And when we started working on these, we were trying to figure out houw you could monitor them, what's happening under the hood. So, we started looking. So, the good news is that it's easy, right, you have a call, you have a bunch of people, they are connected to the same media everyday they send you a video, they get video back, everybody is happy. We can look at what's happening and that's fine. Except no. In reality you do have that, you do have, of course, audio and video going back and forth but you also have a bunch of other things happening. You have telemetry, chat messages, you have the small green bubble that turns to red whenever you are trying to call. That's also traffic. When you look at it it from the client, before you can start thinking about monitoring what's happening, you need to start figuring out what is worth monitoring, where is actually the audio and the video. Usually that's pretty easy to do. You are just look at the RT P headers. That's the protocol you use to transport audio and video, just look for that if the packet has RT P in it, it's worth motorcar, if not ignore t except here we're looking at another thing. What happens if you don't have access to the payload. You just have access to UDP and IP headers, except in that case we don't have the full IP or UDP header, we basically have a 5 Tuple and packet timing information and nothing else. This is what we were working with here, and we're trying to think of ways to first identify the flows and trying to infer something interesting metrics from it. This is what I'm going to talk about now.
The first thing obviously is identifying the media flows because we want to know what's worth monitoring. So look at the traffic. The good news that it's pretty obvious what is happening which is eyeballing the traffic. Here each dot is a packet. And the vertical lines are user actions. So I was recording that on my laptop. I joined the call with no video or audio. The first vertical line is the moment I turned my microphone on and started talking. The top one is audio traffic. The second vertical line is when I turn on my camera, and so you will see here the video traffic and the third and fourth line actually when I turned screen sharing on and off. It's appraise ease to just eyeballing the traffic to understand even with zero information about the payload what's really happening under the hood. How do we go from that to some kind of moth we can use to automatically do TLA and identify the media flows.
We end up counting packets. So the clear blue line is actually in number of packets where you divide the traffic the window two seconds. You look at by Windows of two seconds, each window you count the number of packets. This is what it's showing. We have seen that actually just counting packets is enough to identify with accuracy the media flows, I am talking more than the 99% accuracy here. We count the packets and if for each, a window you have more than ten packets either sent or received for ten consecutive Windows, that's a media flow. That's all we have to do to identify the traffic, again with nothing, no information about the RTP headers, nothing at all really.
That was enough to just identify the traffic. But so that's cool, we know what we want to monitor, now what metrics can we infer from that.
So we're looking at this, we completely passively from the client so that that's an important thing to remember, because we want to be careful about battery life here. It's not like a big server or router where we can just blast something across all CPEs and get what we want. We have to be careful not to drain the battery completely, otherwise people are going to be angry at us.
So first thing we looked at, that's the obvious one to look at I guess, is trying to see, we identify media to know it pits audio or video. It turns out yes, that's pretty easy to do. This is a distribution of packet sizes, on the left it's old packets and video and audio, it's pretty obvious. It's not really surprising either. Audio packets tend to be smaller so we just find a good threshold in the middle, that is enough. We have tried that with a bunch of commercial applications, a bunch of different configuration from two participants to six participants, and also with adding artificial jitter and loss on the traffic to see if that changes things. Not that much. We can still, the threshold changes a bit, but if you pick something around 600 or 700 bytes that's pretty safe and that works in pretty much all situations.
So that was easy. Now for a bit more difficult thing. I think more interesting, we can actually infer the frame, the boundaries of the frames completely passively. You take a video flow, and you want to know where a frame begins and where it ends with again just the five Tuple and packet timing information. There is a number of things you need to keep in mind. A frame is usually almost always too big to fit into one packet and so it's split. The packets of the same frame will usually have the same size plus or minus 4 bytes in our experience. That's because applications use what is called forward error correction to first detect if some packets were modified by the transport and in some cases they can even fix it without having to ask for which transmission from the source. But consecutive frames will not have the same size, they vary a lot. This is because codex are small enough to not send the full frame all the time. Like take me, for instance, right now I am talking and moving around this area things are changing so you have to change the ‑‑ send the new information. But the background is not. So the codex are actually able to basically send the diff between the current frame and the previous one and that changes the size of the frame significantly.
So if you look at consecutive packet, you will see a bunch of packet with the same size. I have a very beautiful diagram at the bottom with a budget of the packet on the the left are 800 bytes and they are the same frame. Then you see a jump to 960 bytes, and that stays another 160 bytes. You can see that here this is what a frame, the previous frame, the first frame sorry, end and the second frame starts.
And again that works up until about 10% loss on the link. Then it starts having a built of issue. But still it, and that works with up to six participants on most commercial applications. This is pretty good because then we can actually measure the frame rate. We have to know if it's a video flow or not. Here, on the black line is actually the grant truth. We were running a WebRTC version in that case. You can get it from the brother exactly what the frame rate is. The orange line is destination. You can see it's not exactly the same. But it's still pretty close. We are happy still with the result here.
The last thing that we managed to do is measuring the video resolution. So, it shows that actually doesn't correlate with the frame rate but rather with the packet rate. You can see this is a distribution of the packet rival rate. The grey‑ish line, 240 P, the orange and red line are 360 P and the blue‑ish line are 720 P. And it's again clear that you have some, you can use some threshold and easily look at the packet rate over ten seconds for instance, you can just use some threshold to completely passively identify the resolution of the video.
Are and we only tried these three resolution because this is the ones that are supported by most applications. I am pretty sure you can get specific application to say get like 1080 P or something like this, but we are focusing on the one that everybody uses like Microsoft Teams, Cisco WebEx, you all know them.
And I think that's all I have for today. Yeah. Just to quickly sum up what we are trying to to here.
So, we are monitoring on a client exclusively. So battery life and efficiency are were of paramount importance to us because we do not want to deplete the battery and basically want to be as transparent as possible here.
Just using a 5 Tuple and packet timing information which is easy to get, you can actually not only identify media flow and classify them, you can actually get a metrics like frame rate. I think that's pretty neat and that's all I have. So now thank you for your attention and if you have any questions.
(Applause)
MASSIMO CANDELA: If you have questions, this is the moment. You can just go to the microphone and say your affiliation and name. Anybody? Okay ‑‑
DANIEL KARRENBERG: It's more a suggestion. The talk gives us what kind of things you can get from these five it up else plus timing information, but if you have to do the talk again I would like to see a matrix of what kind of things you derive from that, like the CDF, like the sizes and so on and say if you take this combination, you can derive that, if you take that combination you can derive that, it might be a bit more clear, just a suggestion.
AUDIENCE SPEAKER: So, you use the packet counts to determine the distribution between audio, video and screen sharing, right?
JULIEN GAMBA: No the packet size, the packet size to know if it's audio or video or something else.
AUDIENCE SPEAKER: And can you tell more exactly how single threshold in the packet size or
JULIEN GAMBA: Yeah. It's pretty clear if you look at the ‑‑ like, on the left you have the distribution of sizes of all packets for all B G F flows and this is pretty clear here that the video packets are larger. If you take a threshold here like 700 bytes, you are pretty safe to identify, classify the video types.
AUDIENCE SPEAKER: Okay, so how these things with the video and screen sharing, how the screen sharing would be similar to video?
JULIEN GAMBA: Screen sharing would be closer to video but smaller because it's ‑‑ the frame rate is much lower because again it doesn't change much, right, there is no movement really, if you just sharing slides for instance, you have a slides every minute or so, and you will not have a lot of movement. This is actually one thing we are trying to figure out right now because that works pretty well for screen sharing but there is some situations where it works a bit less and trying to find some other way to filter that out as well.
AUDIENCE SPEAKER: Geoff Huston. I am curious about this particular slide and what appears to be the maximum packet size, and I am not sure if it's packet or payload, of around about 1280, not 170. Did you see outliers that head towards 1470 or is it for some reason the Internet collapsing its maximum packet size because someone dieded that 1280 was the magic number?
JULIEN GAMBA: We didn't see many outliers, not really, no.
GEOFF HUSTON: Wow! I am suddenly feeling very old.
MASSIMO CANDELA: Thank you again.
.
(Applause)
.
And the next presenter. He will present actually is finding the company's behind the networks. Joshua is a Ph.D. student in the cybersecurity and private research group at the university of York. Josh is also part of the system lab and experimental laboratory on system proportionate. The stage is yours. (Interop) (interoperability)
JOSHUA LEVETT: I gave a presentation last year looking at Joe politics of the Internet architecture, that was involving topology measurements this kind of buildings on that taking some of that kind of data and approach and finding the weaknesses in it.
And one the questions earlier to one the earlier presentations was looking at sibling networks and the kind of impact that has when we do these measurements. This is a way of tackling that. It's based upon an exam he was marking where the students were asked to run a traceroute and identify where this particular traceroute might have jumped across to Australia and the expectation was they look at the round trip time and be okay, it's probably happened in that kind of gap then. But some of them take a more interesting approach where they started looking at registry information and looking at the pointer records if their traceroutes and taking a different angle at it. This was an interesting thing. I hadn't ‑‑ applying it to my research. That was kind of taking that idea and using it to measure the Internet a bit more.
I won't go quite into that direction, but I want to tell you how this bit works.
So, for instance, we have Whois look‑up much an IP address, we didn't know about it previously so we shove it in a Whois and we get back this kind of information. And as a human, I can read this and look at that name and think I know who that is, that looks like LINODE. Other suppliers are available. But if you are a machine, that isn't necessarily |intuitive This net name doesn't necessarily carry across all of this the Whois data. Instead you might dive in the org attribute and you get this information. But you say okay, problem solved. In this case, no need to look further, right?
.
Some of you might know the history of LINODE and already be clued on to where I am going next. Let's just take a traceroute measurement and see what happens. So we do. And as we look down, this is like okay, that last attribute down at the bottom there isn't what I expected. In fact, it's not really being used by LINODE at all it's been used by a customer probably, in this case it's Krystal hosting, other hosting providers are available. And similarly if you look further up you might be interested to see the other name that's appearing, because in fact it's not really LINODE at all, someone else owns LINODE. In fact they spent about 800 million euro buying them in 2022 I think. So we see it there Akamai name and we were living in a lie. We looked at Whois, we thought this was probably LINODE. Although that's trekically true but it's misleading because LINODE is owned by somebody else. If we were using this in our Internet measurement we might have assumed there were two separate networks, which wasn't correct.
So how can we do this better?
In this case, we are going to build a tool that hopefully can look at various points of information around what we were looking at originally and use that to facilitate a better negotiating measurement.
So we can take the BGP table, for instance, and look at the updates and see where the IP address looks like is being routed to. We can look at the DNS records associated and we could look at the registries and see if that can supplement our findings.
So looking at the first part of that.
This is the information we elect on the listened we see there is a DNS chain associated in this occasion the pointer record and the forward DNS are exactly the same destination, which isn't true for at lot of IP addresses. We also see this RDAP response, Most of which I must say is the terms and conditions of using the registry query which is just a whole load of nonsense and I can't understand how a protocol would be designed to give you a 10th of the information you require surrounded by all the other stuff. But that's another discussion.
In this case we can work out that that domain name is tied to this other company that we saw being resolved to at the bottom of that traceroute.
Interesting. So the right‑hand side now, we are building up an info bank of what we know so far.
We can also dive into the organisation attribute and we SOA that actually very few of these match. In this case it's very convenient that they contain the same string, but that isn't true, again for a the love these other will you pleases you might be performing, whether it's an IP address or an ASN or a domain name. Registries can't agree to all use RDAP together and some try and query and they haven't implemented it yet, sometimes it turns out they have all deprecated it which is a whole nightmare of its own. Some of this provides contact information which we will also revisit in a minute.
So this next step is taking all those records.and trying to piece them together. So, in this case, this is how we perform a kind of basic string match. So very basic language processing. We have the two names, the two entities associated with what we were looking at the at the beginning, the IP address, we see if we extract the punctuation we can do some matching, we can't do a whole string match because one of them contains this extra long string at the end. If we try and match a subset, that actually subset is tiny portion of the overall string of one of them, so we conclude it's probably not a match. That's not correct so we have to try and find other ways of matching. This is how we do it.
What we can look at is things like telephone numbers, if we keep the country code in, that's significant whether it matches or not. We can start piecing these together. We have made Linx between Akamai and LINODE. When we look at the e‑mail address we can try and match based on the domain but the whole e‑mail address isn't ‑‑ the main attribute you want to look at because the domain name itself is often shared across a lot of other one because they use anonymisers to try and get source junk mail and posing private e‑mail addresses.
In this case we are building aing picture where we can see that these two entities are connected to these data points, and that this domain name is a bit of an outlier. It's a separate company all together.
We can continue going in this kind of direction here so we can get a peering DP and see if they are any information we can learn from in particular, we can see what people refer to as their kind of network type and see it that way if we can work out who might be a parent network or an a child network. Similarly we can see if any of the organisations match from that as well as the information we found so far.
So, at this point we know two things. We know that the network is owned by, we assume, LINODE LLC, which is probably the same as Akamai. And we know that it's operated by, we assume a LINODE LLC but it's used by a different company altogether. We have got a chain of connections forming based on the information you find on the right‑hand side.
What we can do to go further and what I have implemented in my research but I haven't made publicly available, it's a UK specific thing, we can look up in company databases to see if we can associate a legal entity with the information we have. Whether it's matching names or addresses and whether for instance the post code in the UK case matches the same in both places. So we can work out effectively who is the legal entity is behind the network and similarly, we can work out if one company as been accumulated by the other or not.
At this stage what we have worked out is that Krystal hosting is a customer of LINODE LLC based on the fact they have got no other connections and all we see is one of these records is pointing to this IP address and surveys versa. Similarly we can see that LINODE LLC is probably a child of Akamai because we know that Akamai and PeeringDB have the largest connection of networks and LINODE was traversed to via the other networks infrastructure.
So how can we value date this? It's complicated and I would be reinterested in having a discussion with the RIPE NCC how they do this in the registry beyond manual verification, in this case I have 200 resources and tried to manually piece this together myself. It's a nightmare and difficult for me to do that on any sort of scale. So ideally we want to automate this as much possible. So taking these 200 attributes, which is a little bit biased towards people are run traceroutes through in RIPE Atlas, assuming that that's a fairly representative list, we can find that the tool that I built returns the correct parent‑owner name for most Zorz are, so either this is the company name and either being the main result returned or we think it's also known as and giving a string of a couple of other names that it could be. 83% of case it is gave the correct parent company name as the first result in the list, which I would say is quite impressive based on this kind of trying to find it through these two different approaches, the registry information and what the resources are connected. And in almost 96 percent of case it is found the correct data even if it didn't work out it was the parent company involved. It would have told us for instance that the two entities were connected, which is quite significant when it comes to working out when it comes to building a.toology that the two entities might be connected as well. So whether two networks might be peering with each other.
So in summary, Whois information at the moment, although technically accurate, isn't very representative. I don't really know the complete solution to that problem. That's probably a discussion for a different Working Group all together.
Tracking OpenSource across these registries is actually really hard, because a lot of them aren't using the same entity names. So in this case LINODE LLC and LINODE LLC without the comma. The same with Akamai in one registry and one else in another. Particularly when it comes to domain tracking across different registries is almost impossible because everyone gives different information to each registry they interact with. Although are the five RIRs shows a little information, changing day by day they can coordinate who owns these entities. That isn't true for domains. What we have found is basic natural language techniques give give us insight. So we can join them up. Which is a complicated research challenge and this is a step towards resolving that. If you want to look at the code, I have made is available on GitHub, so you can visit that link. With that, thank you very much.
(Applause)
NINA BARGISEN: Thank you very much, was interesting, and we have questions.
AUDIENCE SPEAKER: Geoff Huston. I have a helpful hint for you that will solve a lot of your problems, not all, but a lot. Do you know about the extended stats files? Do you know about the org ID.
JOSHUA LEVETT: Yes.
AUDIENCE SPEAKER: Do you know that if an entity holds a connection of the v4, v6 and AS numbers, they will have the same org ID in that RIR, and you can then know that that collection of resources is actually billed against the same entity by that RIR, which would save a lot of fuzzy text matching?
JOSHUA LEVETT: It didn't really show very well on these slides, but we were using that ASes a connection. We were using the organisation entity. That's how we worked out the AS number in the first place based on that IP address.
AUDIENCE SPEAKER: It matched the IP addresses as well.
JOSHUA LEVETT: That's what we were doing, but I glossed over that a little bit. But we were trying to do that as much as possible but why it doesn't track it where you go across registries which is slightly more complicated. This is what it was trying to iman at rather than within a registry. You are right, that's a very do believe thing.
NINA BARGISEN: I'll try again and now you can actually hear me. If there are no other questions, I actually have one. And that is: What can resources and registries do to help us who would like to derive that information that you are helping us combine in this tool, but what would be useful to make it easier?
JOSHUA LEVETT: It would be really helpful if when you did a merger and acquisition you updated your registry information to at least hint that you might be the same organisation, because I think a lot of cases where people are purchasing other organisations, the registry is probably one of the last thoughts down the line. Although technically they might be two separate companies, in reality when they are the same entity behind them, it would be useful to know. Similarly, if you could give them at least close text based or address or telephone number names, that would also be very big help for both our research purpose but also similarly, if might help you being able to transfers other people's networks and work out where connections have gone wrong and similarly when it comes to kind the law enforcement angle, being able to work out who the administrative entity they want to contact without having to go to the RIPE NCC and others would probably be a benefit to them as well.
NINA BARGISEN: Thank you very much.
(Applause.)
Our next talk now. This is about memory‑efficient and high‑accuracy approach for persistence‑based item look‑up in a high‑velocity data streams. He is a Ph.D. student candidate at the University of Edinburgh, specialising in data structures for traffic detections in high speed networks.
WEIHE LI: You had to I am going to present my work which was got accepted this year, and in this paper we propose a new sketch for persistence based look‑up in high vet strings and this work is a collaboration work with people were India networks and thanks to my collaborators.
First I'll introduce the background of this.
Here we have different items in data streams and some measurement strategy we can get some information which can be utilised for different applications. Such as user behaving analysis in making the content provider, and a better analysis is important so improve the user experience which can be further utilised for improving the company revenue. So .. has been persistently accepted by users, so it's kind of peer be reviews, they are indicates a... so the common provider can give users more like this type of content to attract users' interest.
So, now we use this to show you the definition of persistence, so here is a data stream with different items and this is divided into three type of Windows, for item E1 it appears in the first time window and second time window is it's persistence is 2. So even though it appears three times, but they all appear in the same kind of window. So, its persistence is only 1. So detecting persistent items is to look up those items with higher persistence.
Doing this thing is not easy. Because it has two challenges. The first challenge is the data stream. Typically like transmit in very high speed. So we need to process each incoming item at a very high speed, and in the current platform, on the fasted processed speed, memory is quite limited. Like for the L1 catch, a 64 kilobytes memory is still very common to see, so it is impossible for us to track the information of all items and then to retrieve like the persistent items is not do believe.
So, sketch has been proposed which is approximately an approximate met structure based on hashing technique. Here is an instant of a very classic sketch called on‑off sketch. In the sketch is a two‑dimensional table. We have tier ratings and in each rows we have L counters for the off sketch. Each counter is recorded as a bucket contains two views. The first view is a flack on or off. And the second view is a persistence counter. So, our use this instance to show you how sketch works. So like when you through this, you first use three different hash functions and locate through different buckets in different rows, and for the first row, because the counter, the flag is on, it means that this packet has not been accessed in this time window, so its counter will increase by one from five to six. But for this bucket, the flag is already off, meaning that in this time window, this bucket has been accessed by other incoming items so the persistence will not be... we call that no matter how many times this item arrives, its persistence is only be increased by one in this time window. So for this bucket because the flag is off, so nothing changed. So, in the end, we can summarise the information of all items in a small table. So, we can do them like proximate computing to retrieve this estimated persistence. Like for all of sketch in the end, it will use the minimum value and all the hatch bucket is estimated persistence. So, that is the working process of sketch based on the hashing techniques.
The limitation is twofold. The first limitation is, in practice, the traffic distribution is very highly skewed. So it means that most items their persistence is very low, and we conducted a data analysis, we used four traces and divided the traces into 1,600 time Windows, and we found that over 85 percent items persistence is no more than 10. So, because sketch is based on the hashing techniques, so when the memory is limited, the hash collisions are severe. So, the persistence items will be easily evicted by numbers items easily from the packet which release to low detection accuracy.
And lastly you will also propose a new state of the art called Stable Sketch and those were accepted and we got the best student paper award, and in this paper we introduced a new metric called bucket stability to provide more protection to like a small number of persistent items, but introducing new metric, like, requires more memory usage, so low memory efficiency. So I wanted to deal with these limitations and to propose a new moth for persistence item look‑up with high accuracy, high memory efficiency and a fast processing speed and also it can be practical how we like a Tofino switch. We propose Pontus. The structure of punts is also straightforward. We contain rows and each row has double columns and in each bucket here is a bucket with just four views. The first view is for tracking the is item key, the second view is for tracking the persistence and the third view is the arrival flag. It's similar to on off sketch, which is reset the flag to on at the beginning of each time window. And we introduced a new metric called collision decay flag. Different from Stable Sketch which requires two buys in each bucket. For Pontus it only requires one beat. So our use, so for instance, to show you how Pontus works.
So, here we have a sketch with two rows, and when you one arrives, we use the first hash function to locate bucket in the first row. Because this bucket is empty, so, because there is like the something is none. You want row insert into this bucket and the key food is at 31 and the persistence counter was at 2.1. Pause a 1 has already arrived in this time window, so the red flag in this window is set to force and it will also set the collision decay flag to force. I will introduce this flag later in the talk, so this the first case.
And the second case is when E8 arrives we use a first hash function to look at the bucket in the first row, because this bucket has been occupied by E2, so we will try to look at the packet in the second row with the second hash function, and this bucket has already been occupied by E7, so E8 experience hash collisions in all rows. So in this case, E8 rollback a packet with small counter, so in this case 4 is smaller than a 5, so a 7 will be selected and E8 will try to evict E7 from the packet based on the probability. So in this case we calculate the probability rate based on you one over P plus 1. So it's 1 over 5. So in this case it has two cases.
It has like one over five chose the deck an is successful, and four over five the probability decay is not triggered. So in this case nothing happened, and in this case, the counter of E7 will decay by one to three because the counter is automatic to zero so E8 will not replace E7, and in this case the decay flag was at 2 force. So basically, if the items has a higher persistence, they chose of is counter indicate to zero is low, so it will decay psycho in this bucket.
And the last case is when E 6 arrives, and use the first hash function, collision happened, and it found a bucket in the second row because the decay flag is fourth. It mean that this bucket has already been decayed by another incoming item so when E 6 arrives, its persistence counter will increase by 2 instead of 1. For more accurate precision tracking and the flag was set to fourth means that a 6 has already arrived in this time window.
So, in the.end if we wanted to retrieve persistent counter, wanted to an I think is he will scale to find, to check whether the persistence counter is over, than the different threshold, if it's over than the threshold, it is a persistent counter. Otherwise it is not. And we contact our evasion on software platform and our own platform with traces and we compared the F1 score on different member packets and we find that Pontus ourperforms in this methods and different memory budget in different cases.
There was a test of speed. Because the strategy for Pontus is pretty straightforward, so, it, like, increased the participation compared with the other moth significantly.
It also implement our method on the Tofino switch and our rmethod only like that in the limited overhead overall the usage is not over the 8 percentage. So like it's still leaves enough, enough like memory for other applications.
So in this paper we also include more results including the formal analysis and we also have results on different tasks, including the persistence estimation, and we also have more results on the CPU platform and the Tofino switch. If you are interested, please look at the paper and the code is also OpenSourced if you want to play with Pontus, feel free to use this link, and that's my presentation. I am happy to answer your questions. Thank you so much.
(Applause)
STEPHEN STROWES: Thank you very much. I realise it can be difficult presenting to a blank screen times. Do we have any questions from the floor? If we don't, I do have one here.
Do you have any suggestions for improving what is detection accuracy?
WEIHE LI: Yeah. The our step we used inaudible counter for allowing Pontus we used different counters for different views. Like for the flag we used four bytes and four the persistence counters we used two bytes. In practice, because the traffic is something skewed, for most packets they are persistence role is ten, you use like... so, we can use like academic counterpart to work in Pontus on bit level to further improve the memory efficiency so we can have more space to accommodate more persistence item so we can further improve the detection curve in this way.
STEPHEN STROWES: Are you going to be working on that next?
WEIHE LI: Maybe, maybe yeah.
STEPHEN STROWES: All right. We have no questions in the queue, so, you know, that very much for the presentation.
WEIHE LI: Thank you.
STEPHEN STROWES: The next talk today is about frontiers of Leo space networks. He is an assistant professor in the Delft University of Technology in the Netherlands, his interest edge computers, orchestration... physical systems, satellite networks and wide scale Internet measurements. And I believe he has open Ph.D. positions coming up in the near future. If you are interested in working on this stuff, talk to him afterwards.
NITINDER MOHAN: Thank you. Good afternoon everybody. Pleasure to be here. So, today I'll be talking about Leo space networks. We'll move a bit far away from it and look into how Internet works from 500km registers from the earth. I will start of a bit of disclaimer. This particular talk will be into starlink.adverse specifically but because Starlink is the only consumer facing Leo SIP at the moment most of the other competitors that are coming up now like one web, even European initiative like Util Sat, will likely going to follow the same architecture and design that Starlink is proposing because they want to be compatible. Most of the bits that I am going to be talking about is going to have a much larger coverage in the next coming few years.
All right. So, with that out of the way. Before I jump into the measurements and the pretty little graphs, let's first understand what is Leo's satellite operator, specifically Starlink. Like the name suggests, these ISPs are enable to you Leo satellites which are those low earth orbit satellites. They are operating at about a 5 hundred kilometres above the Earth. Starlink has specifically been trying to deploy more and more satellites since 2020. Now it has about 6,000 satellites operational. It plans 60,000 in the next few years to come, few years in the order of next decade. And then the satellites are essentially revolving around the earth in, takes one revolution every four hours or so. And the idea about Starlink specifically is that it can provide now lowand high bandwidth communication to anybody around the globe because you deploy a satellite anywhere above and it aches a circle wherever in the globe you are.
And it tries to essentially compete against terrestrial ISPs and if you go to Starlink website and you look into now they also boast what latencies you can observe, it's going to highlight that most of these regions you get about 20 to 30 milliseconds of latencies in some regions they they might report 50 miliseconds of latencies. They trying to be as competitive as possible.
But we have to understand how this works behind the scenes. One of the arguments that I am going to make is all of these Leo satellite operators are not space networks but ground networks. They are space satellites are only the last mild connectivity option. At some point in time they have to come back to earth. Before we get these that let's try to understand what the space operations are.
So most these Leo satellites are essentially arrangeed in multiple or bits. These are arranged according to the angle that they have to the equator of the earth the Starlink deploys their satellites in three different or bits. The 53, 730 and 90 degree or bits. You might ask why? And things become much easier to understand when you flag a picture of earth you see that the 53 degree orbits are covering different parts of globe. Essentially that covers most of the populace areas that are around the earth right now. So, a lot of your consumers that are going to be using Starlink are coming from the satellites which will be connecting to the 53 degree orbits. Then you have a few set of orbits that are going closer to the poles, so you can still cater to the consumers in the you king doll, up in the North Pole and south Poland that's why you see the deployment in different orbits as well. Most of the satellites are deployed in this. There are a few less than 5 hundred satellites which are operational in the other orbits.
Another claim err that I want to give, that all of these slides and these results are from last year, April. And within one year, those numbers have changed drastically because Starlink has been putting a lot of infrastructure both in space and on the ground which is changing these numbers. I'll try to move along and keep you updated about how things are looking at from a performance perspective today.
Now, these satellites are going to be a point of contact. You get essentially a dishey, which is like a Starlink dish, you deploy it and that than obstructive view of the sky that's how you connect. What happened behind. Starlink and most of these Leo ISPs will follow something like a bent pipe model. The bent‑pipe is that if you have the Starlink terminal, you connect the terminal to wherever the slight is. The slight beams down your network to a ground station and this ground station is a frowned infrastructure that Starlink has to can he employ all across the globe so that it can provide you connectivity back into the earth. When you get your connectivity to the grouped station you pipe it down to the point of presentation which is earlier was co‑locate with Google Cloud facilities, but this is mostly co‑locate with a lot of popular IXPs and that allows you to get access to the Internet.
For people where you don't have access directly to the ground station in one single hop or just one single bent pipe you can also use the inter slight Linx between those satellites to bridge connections across. Then you can essentially from a multihop Linx on the satellites before you get to a ground station. This is very valuable in principle for not, nor consumers in North Pole, or for example, people on the islands which do not have ground stations and have to get more POP LAAS‑CNRS regions. You don't have to put up ground infrastructure so much. We'll see the impact of that.
This particular talk is going to be covering a bunch of works that my team has been producing for a while. So, the very first work was published last year in the web conference. This work also won the IETF applied networking research price this year. They are going to be presented in the next IETF meeting in Madrid. There is also one RIPE blog runners up award as well. So very thank you for the RIPE community to give us that.
Before I tell you about what we did. So, we have to talk about the measurements that we did. How we did we get the access to the starting data.
Number one to get them as best picture around the globe as possible we relied on the multistream lab data. That's operated by Google. If you search for speed test you are using on Google and then you do a speed test in the Google widget using measurement lab if you are not familiar with it. All of that dataset is public. We used that and we filtered based on the Starlink AS number to find out the Starlink consumers over the starting period of time.
But the problem with that is only gives you end to end connectivity. We wanted to figure out how the connection is traversing, what the route is following. We relied on RIPE Atlas. Thank you. We have about 100 probes that we used. We were quite surprised about the growing numbers of Starlink probes on RIPE Atlas and I hope more people if they end up using Starlink they end up putting their dishes on RIPE Atlas. We used about 90 from 21 different countries and we targeted about 145 data centres owned by seven different Cloud operators.
We also tried to look into the application performances which why we looked into specifically Zoom performances and then also Amazon Cloud gaming performances. And then we also tried to understand how CDN performances worked. For this we relied on the CloudFlare speed tests because those are served by CloudFlare CDN service. We can get to see which CDN suffer is the best map for any Starlink customer. We used about 22 thousand speed test measurements for this. We also deserved our own browser plug inwhich users then installed and ran measurements directly from the browsers. We were collecting web browsing details of measurements and also video streaming performances. Then we also started to build our own test bed which allowed us to do more intrusive measurements, more than what RIPE Atlas would allow. Essentially we could run any container on these probes.
With that out of the way, let's jump in the numbers.
Global performance is first. How does the Starlink perform compare to the top three mobile network operators from every country around the globe. We see two graphs here. Will the blue means it's better and we see that most of the terrestrial IPs are actually performing better than Starlink, pretty much everywhere globally. US and parts of Europe are a few places where Starlink performed very, very well. That's because Starlink has a significant amount of ground infrastructure presence in those regions to get maximum amount of consumers. You will also see Nigeria in Africa which does quite well and performs similar to the terrestrial infrastructure. We'll dig into this deeper, what's happening behind the scenes. But other parts of Africa are actually performing much worse on Starlink. And essentially they have very long tails and latencies as well on Starlink compared to you would get if you were using a terrestrial IP in those regions.
The reason why we see those different latencies is because of the ground infrastructure that Starlink has. This map shows all of the ground stations that Starlink is using to beam the connection back an then also the point of presentation locations where users get access to the Internet. You get to see that regions where you have high ground stations above the presentation of availability obviously get better latencies that's why you see for example Ireland doing really well because it connects to the points of presence in London. You also see better connectivity from US for example, Seattle for example doing quite well. Then you have regions like Mexico city, which is suffering because it connects to Brazil and other regions, and so on.
If you look in the performances across this continent, you will see that the US, you get fairly consistent performances over Starlink. In Europe, your performances depends on if you are close to POP or not. If you are close to a POP you get really good performances. Otherwise Starlink does some really weird routing as of now, we will you saw for example customers from Italy from connect to go Spain to connect could it. Even though there was a presentation in Italy available. So there can be a load balancing policies in place.
You have significantly high latencies in South America, that's because there is a lot of long distance fiber Linx or terrestrial Linx that you have to take if you were to get from the ground stations to the point of presentation which is only deployed in a few regions in this very vast continent.
I also want to talk about the ground impact of ground infrastructure by this one use case, especially focus on Philippines here. So for example, before 2023 only had a ground station but it was using the point of presentation in Japan. Which is why if I look into the latencies here you see that all of the connections, they went to the ground station in Philippines, but then they could access the Internet but there was in Japan, which is why the latencys to Japanese servers were much lowers if you were to access a Philippine server, because then the connection had to come back to the Philippines, then you had to go back, come back, go to satellite linking, it was a weird routing accusationment after 2023 started...... that's why you SOA that the strength...... now, you have good latencies to local servers and if you were to go to general practitioner an, then you only have to go to the sub‑sea a cable because of that. Otherwise you pretty much dominate locally. This is what we observe also in Africa since earlier this year as well. So, earlier all of the connections in Africa were traversing to Germany and using the point of presentation in Germany, but starting from 2025... African collections are within Africa well. Which brings in an interesting analysis about the Syrian usage because most of content that people end of using especially the popular websites might not be available in those Syrian locations. And which is what we also see here, we see that terrestrial connections, if you are using your ISPs, your local servers, they are always better than if you were using Starlink.
Starlink shows some weird performances as well where, for example, from Africa you had significantly longer distance through your CDN access which you are connecting your connection access from. Even in places where you had small dance to get your access, you had significantly higher latencies because you is still interest to go to the space, come back and then go to the point of presentation. Where as for sell rather operators we are figured that out better and those latencies in the last mile are significantly lower.
This was what we observed here. We also observed this from Africa which is what I want to show case here. In Africa what we observed is that especially from Mozambique we see that from Starlink if you were to fetch your content from Frankfurt, you have significantly lower latencies than if you were to fetch your content from CDN servers within Africa, because because you go to Frankfurt point of presence and then you have to use your terrestrial connections to come back to Africa, get your content, go back to Germany and then use the Starlink Internet connection to get to your customer. But if you were fetching from Frankfurt it worked very well. Which essentially means popular content works but regional contact with suffer. And but this problem doesn't really present in international networks which means you get content from your local regions as well.
I am going to finish this talk. We are still doing a lot of measurements, Starlink is evolving, now you have more new ISPs also evolving. But we still see that there is a huge dichotomy between how Leo operators tend to provide Internet connectivity and how they integrate with the other terrestrial connections as well. We have to we think about your content server and your Cloud services are going to be served for your customers which are coming and using the ISPs. We also can think about practitioner what end IPs you want to use, what do you want to probably think of satellite...... if you are interested in helping out the research, please if you get a Starlink or any other Leo connections, please put your probe for your RIPE Atlas. We are also organising if you are a researcher, a workshop in sit come this year around, if you are doing some research on this or you just want to give a talk, reach out to me and we'll be happy to host you. Thank you so much.
Canned can thank you very much it's time for questions.
AUDIENCE SPEAKER: Blake Willis. Thanks for this. I'd like to take a moment to thank the late Dave at that time who passed away about a month ago who did a significant amount of work to actually make this function. A good chunk of that latency you see there is buffer, because the satellites stay in view a lot less time than the average duration of a TCP session so they can handing off sessions between each other constantly, and the, Dave spent a significant amount of time and effort getting that buffer blow management Lieber QS technology into the Starlink system to make it work. And he passed away about a month ago.
NITINDER MOHAN: I would also like to add to that, Starlink is notorious in not sharing any details and keeping things hidden. And if it was not for Dave, I would have not started doing this research. So Dave has been the one who has been a huge source of motivation, putting up the mailing list, connecting people and we want to honour him this time around by naming our Beth paper award in Leo net on his name. So posthumously, thank you Dave for helping us do this.
(Applause)
AUDIENCE SPEAKER: I knew Dave personally, I was saying maybe we should all remember him and his work, too bad he can't see it. I am thinking he gives a bit of the meaning of the words geolocation. I was wondering did the test with v6 versus v4 performance and generally how transparent is... for this travelling mesh, you can see the intermediate hops. We can see probably the ground station, but I imagine that ‑‑you already said transparency, is that a strong point of the ininstillation, but how level you can tell which station you talk to, I guess you cannot identify the satellites.
NITINDER MOHAN: No, no, you can't. That's a really good yes. Thank you for asking that.
One remark to adhere. The connection from your Starlink dish all the way up to your ground station behind a carrier grade NAT. Do you not see any connection here? This is over IPv4, if you use IPv6, you do see your connection to the ground station as well. And but you still don't see a satellite. So, satellites don't show up there as well.
But there has been a lot of excellent work that has been coming along from university of Victoria that are trying to understand the backbone of Starlink connectivity by mapping IP address spaces to different regions, Starlink also publishes its due IP feed for every single point of presentation location which allows us to give proximate location which is why if you go back to the slides you will always see I am pointing to specific cities when I am talking about measurements, and that's because the geoIP feed only opponents to the capital of a country when it is trying to geolocate users from that country so. We do not have more visibility about where exactly the connections are, we only get visibility from a capital perspective or where the point of presence is placed.
AUDIENCE SPEAKER: It's like Mumbai, Washington DC, no details, all right? Thanks.
AUDIENCE SPEAKER: At this moment on from. Very quick question: So, the main arguments that were made for these satellite networks at least from the perspective of high frequency traders or from people that wanted to get low latency connections between continents was that the satellite to satellite communication would be faster. Have you seen any indication that this is actually taking place yet or is that still hot air?
NITINDER MOHAN: Thank you for asking because I can use my backup slide set now. What I can say is that it is very difficult to identify if there has been satellite to slight connectivity because like I said, satellite connections with behind the CGNAT. We looked into specifically one case from the union island where there is no way that a satellite could connect this particular dish to the point of presence and ground station in Germany where the distance was around 9 thousand kilometres. So a satellite only has a visibility of about 1,200 kilometres. It is possible only if it's using ISL Linx. I'll jump directly to the results here. What we do see is that if you were using terrestrial ICed B connections from union island, you are going to be much worse than using Starlink which is this blue line that you see. If we were using ISL connections you are better. But only slightly. If you are look into the latencies we are still above 150 milliseconds. There's no way you can do Hi frequency trading on these latency links. For other parts of the globe like US and Europe you are a good number of ground station and point of presentation availability so you never get to use ISL Linx.
AUDIENCE SPEAKER: It doesn't help that. Will
NITINDER MOHAN: No, not at all.
AUDIENCE SPEAKER: Robert kiss. On your slides we see will 88 probes and as a five minutes ago the 9 so people heard you. Did you know?
NITINDER MOHAN: We did know, this was 105 about a month ago, so a few probes went out as well. For those folks, please bring them back. A canned conditioned the next presenter. Before doing that, as my co‑chair Stephen said some of our speakers they are actually look are for a job and before I forgot to say that Joshua, which presenter is actually one of those speakers that is looking for a job. Now let's go to the presenter. Florian, a research associate and PhD candidate at the Technical University of Munich.
FLORIAN WIEDNER: So, now we are jumping a bit back to different types of latencies back on the ground. So basically, what we were looking into is okay, when we use normal systems and normal Linux based systems on common hardware when we already have one house an one application running on them professing the packets we are already over one mill second in worse case or in tail latency. Which you basically see here in the diagram, with the latency on the the Y access and where you SOA he in web circles all the lines that we are already over one millisecond.
And the issue here is when we want to go towards other reliability and low latency. We have to stay below 1 millisecond end‑to‑end. In 99.999 percent of all cases, which is a lot, And with this we would not be able to reach is in nearly, and we see they are happening irregularly over the whole measurement, and what we basically wanted to analyse okay, is there a way that we can use virtualised systems in packet processing so that we are able to share the newcomer between multiple persons on service level requirements and enable resource sharing because this is something which is needed today. We cannot any longer have one half a machine for each service level requirements. This will not work, economically, this is not even works in universities.
What I want to show today is basically yeah, it's possible to use low latency, with virtualisation on commodity hardware. We need to plan careful for this and carefully optimise the system because otherwise we see the same in the first slide. We are rreaching high spikes irregularly over the whole period which is harming especially when we talking about realtime networking.
I will go over what optimisations we have used, how was our measurement setup that we can ensure that the measurement setup is not provides those high latencies and what our measurements show.
For this we have analysed two different types of virtualisation, one is containers which are sharing the same kernel and we used LX Cs A on the other side we are used KVM virtual machines which are having these whole operating inside. So providing much higher overhead.
And what are the authentication? Where are we coming from? The most are coming from inter‑op peace. So from Interop basis IP put output for example the Linux NAPI, on other soup features like energy saving, virtual cores, and dynamic shadow link of process onto the different core so the switching between cores of the packet processing is harming our system a lot. And when we are now talking about virtualisation, the exit of virtualisation and the input output two words... system is providing a massive additional latency.
And what are we doing to free vent this? We are first using realtime Linux system, we are using a polling buys input output, basically DPDK in this sense. We disable energy saving mechanism, we disable multi‑threading and we statistically allocate our packet processing, but especially only those responsible for low latency to the course of the processing to ensure that we are not switching between different cores and to ensure that we always are the first in processing the packets.
But how did we be able to measure this? This is why we built three machines setup where we basically have one device on a test where one container or one virtual machine is running, which is receiving the packet from the outside, using single router... ensure that we are removing the virtual machine IO over the hyper advisor, and on the other side we have a load generator which is not to have the influence from a load generator on the node and this load generator is running on a different machine standing inside get can out again and we are running a basic application on Layer2 on the machines. We just want to analyse the latency of the machine not the application itself. And to make sure that we now do not have an influence from our load generator. We basically use passive optical splitters which is splitting our connection to the device and from device in the test as input direction into the cards from Intel which allows us to time stamp each packet in hardware. And with this, we can retrieve our resolution of around 1.25 nanoseconds and can make sure that our 1 millisecond spikes are not coming from our measurement infrastructure. So also basically stress the system we are using UDP traffic with 64‑byte packets, on a duration of 160 seconds. And with M packet rate from 1 million packet her second.
What we first analysed okay, do we see when we have our optimisation, do we see any deference when we sues a van la Debian 11 image or if we use a realtime kernel? Aine we see on the average doesn't make any difference. When we look at the tail latencies, we see a clear spike in the end. What we see here is a diagram is Tuple logistic access on the Y axis showing the latency and one on the X axis showing the percentiles, otherwise we would not be able see or 99.99 percentile. What you basically see here when we only use our optimisation and do not change the kernel, we are already rising nearer to our 1 million second but we are staying below it. This is always in an LXC container.
When we now compare this to basically do not have in this container and having it between optimised scan and a non‑optimised van la system, we can basically see here that when we do not opt mice it, the LXC, which has a bit of isolation in it, is performing better with the bare metal we would already each our 1 millisecond. When we look into optimised version, both are performing similar. So basically we can then reach with bare metal and LXC almost the same latency. But we have to think about that we are on a system with only one host, and therefore, we still have to think about when we have more systems, the influence on LXC will be much higher than when we use for example virtual machines or separated hardware machines on them.
What we also have done is comparing container versus virtual machines and here we basically see then the same thing, when we do not optimise, we can technically reach with the VM a lower latency. But we reach a much here latency on a lower percentile. The same is when we optimise it, but then we can reach around 100 Mike seconds in the tail latency on the VM and the LXC. In our measurements here, we could see, you cannot see it on a logrhythmic access but the LXC is slightly lower in the tail latency than the virtual machines.
When we now it compare them, as I have said before, we have the user space networking fork our measurements, we now want to compare okay, how ‑‑ what influence do we see when we now use kernel space networking in Linux and we basically see when we do not optimise, we are already reaching 10 milliseconds with the non‑optimised kernel networking without having any other applications and just a bridge on the system. When we optimise it we basically clearly see on average the kernel networking will be worse. When we look in the tail latencies, we come to a similar performance, as well, there is a performance, there is a measurement here was done on LXC containers, we have done in our paper similar measurements in, in other systems as well, so, in virtual machines as well it's just for timewise that I cannot show all our graphics here, but if anyone is interested there is everything public available.
.
Especially, we have, I have put together here a lot of things of different publications. I have done over the last five years of my Ph.D. So basically we have analysed containers, we have analysed topology, so not only using one host I was presenting now but also different hosts we have also analysed what influences we have when we have LXC in lines and have one to 64 containers in a line, what influence do we see there? How important is topology, is where you set it? And basically we also see here that we have analysed bare metal in the end of this is where we started.
Coming to everything that I have presented here and much more is publicly available. It analyses all of the PCAPs we have measured, we have made them available on different locations so that you would be able to basically retrieve from the raw data all our diagrams again and see okay, how does it behave and could even do much more analysis there.
And with this I want to conclude, yes it's possible to use virtualised system for latencies. It's really hard to make sure that you can optimise is in this way, you have to optimise them that you can be able to achieve it. It's a matter of resources and because optimising them means you need nor resources per packet.
The influence of the shared OS in lightweight systems is a bit bigger.
Aine, we have done some additional analysis here, and especially we have our papers are available, all the recommendations are available, and with this I want to thank you for link, and I am opening for questions.
(Applause)
NINA BARGISEN: Thank you very much. Any questions? Okay, I have one. Which is say that I am an operator and I want to use this tool and I want to improve my own network, so what do I need to consider if I'm doing, I want to use this very optimised system?
FLORIAN WIEDNER: The first thing is to look up our paper because we have described in the different papers we have described in detail what links we have used and what things we have used. We have not used any system which is basically special ICed in any way and we have just used basic Debian systems, so basically everything is available and everything could be used at some way. The other way is we also have published some of the things directly OpenSource and we also publish for a conference in two weeks a mini version of using those virtual machines and containers within a topology measurement tool because this is what we also want to achieve that we can have on a single host, topologies with realistic latencies, which is really hard to achieve, otherwise, Aine this is what we are doing here.
NINA BARGISEN: Thank you very much. And thank you. Now, I want to introduce our last speaker, Robert from the RIPE NCC is going to talk a little bit about updates to RIPEstat and RIPE Atlas.
ROBERT KISTELECKI: Hello everyone. Iing work for the RIPE NCC mostly on RIPE Atlas, but I am also the messenger today for the other tools that are in this slide set.
So, the tools generally you probably know them. RIPE Atlas for active measurements, DNSMON powered by RIPE Atlas to modern the route zone RIS for BGP data collection and RIPEstat for showing most of these aunt Internet that for IPs and ASNs.
So RIPEstat. There are some people from the RIPEstat team outside, and generally at the venue. So please talk to us if you have feedback, if you'd like to have features and so on. One of those things is that we actually talked to you recently about how you use and perceive the system and thank you very much for all of of who you participated in that. One of the outcomes there is that we took all that input and created a kind of hybrid between the two UIs that we had before which is now supposed to be the one that will stick around, and from now on we are going to add enhancements to that. You can already check it out. It's live its there. One of those enhancements is that we just released a new version of the LookingGlass. So you can follow that link. It goes to/LG on stat and you will see it's nice, it works, and it's performing.
RIS. I think Nina also said in one of her presentations that they have a selecting peering policy. So does RIS. The goals for I say is to be able to cover under Serbiaed and under covered areas, and to see if the remote peering actually helps or injures this effort. We also want to look at route servers and target them a bit.
Every now and then we have noisy peers in RIS that clogs up the pipeline, which generally speaking is not that useful. Sometimes we depeer them to reduce the noise. We will be documenting them, if you are interested in what are these artifacts you see in the system. If you want to analyse the data you should be aware of these, talk to us and you will be able to pick it up in the documentation as well.
Lastly, just like RIPE Atlas did last year, RIS is, and stat combined, are looking at how to revitalise the big data backend system because we have a lot of reviews and updates messages that we store and present back to you, and we want to look at how to do that in the future.
Finally, RIPE Atlas. If you are using RIPE Atlas, you probably seen this evolution, but gradually we replaced all of the mailing pages inside RIPE Atlas to be more modern, measurement probes, maps, all of those things are new, and we expect them to be perform better than they used to.
And the team is now looking at the remaining bits and pieces, there are so the auxiliary processes that we still need to do. After that we are going to look at the what we call the tools inside RIPE Atlas. There is...... I just put up some images on the left‑hand side, you see an RTT change over time. And you can zoom in inside the interface, and when you see such an I think this, you can actually click on it and you will see the traceroute before and the traceroute after. So you know what changed. So that's kind much useful. On the right‑hand side you see any one of the improvements.
What's happening: Less visible to users, that we are still working on a backend, renewing the machinery, so to speak, and we expect that it work will be concluded somewhere during the summer is the current expectation. Then I already reached out to some of you. I am inviting more of you. I want to talk to you and generally the team want to talk to you to see with a we can do and what we can change to improve the value, in particular for members, but also for various use case that is you know this is a thing that we with would like to do and SLAs is close but not close enough, if you only did this, this and this, then it would be way more useful to us. This would be something that we we would really like to hear.
Finally, we just released binaries for the software package, the firm way for raspberry pies, it's time you reach into the bottom are drawer, you can install the software probe on your unused raspberry. That's it. Many of us, multiple of us are around and we are really interested in your feedback for RIS, RIPEstat and RIPE Atlas. But if you don't find us or you don't want to find us, you can still contact us on those e‑mail addresses.
Thank you.
(Applause)
MASSIMO CANDELA: Thank you. Any specific questions.
AUDIENCE SPEAKER: Thank you for making the building measurements available on RIPE Atlas. Those are a life safer.
ROBERT KISTELECKI: You're welcome.
MASSIMO CANDELA: Thank you very much Robert. So we are over time a bit but we are going to immediately conclude.
This edition of the MAT Working Group. So the if I remember thing: Remember to rate the talks basis wasted on your rating we select further presentations. So it's actually important. Ity also good feedback for the speaker themselves. Many speakers that we have are maybe new to presenting so it's actually good to also receive feedback. Send back to the Chairs if you want. We have a mailing list, we will receive them. Or just participate in the mailing list. We always receive this feedback. Mailing list are not anymore an I think this, we should do whatever, we receive a new thing that we should use, but we still have for now the mailing list. We will start at some point discussing about our channels but for now that's the mailing list.
So, I think that's all. Thank you very much, and see you in Bucharest.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
