Session Date/Time: 23 Jul 2026 14:30
[00:00:05] Dave Plonka: The sound from your laptop muted. Alright, everyone. You're at the measurement and analysis for protocols research group meeting. In a momentary lapse of reason, we invited 10 speakers to talk today in two hours time. So there's on the what's that? It's good to have goals. Yeah. So this is gonna be a whirl the good news is it's gonna be a whirlwind thing. If you don't like what's going on now, wait five or
[00:00:34] Speaker 1: ten minutes and it'll be a
[00:00:35] Dave Plonka: completely different presentation. So that means we only have about ten minutes to spare. So I apologize in advance for cutting you off. But it means that when you see the timer up there, most of the time to ask questions or contribute comments is during the timer being there. We'll tell you if if we're out of time. But like I said, it's about ten minutes to spare. So let's see. Let's get through the the boilerplate here. The IERTF observes the same oh, I should say we should we should introduce ourselves. Getting ahead of myself. I'm Dave Plonka. I'm the co chair of the measurement analysis for protocols research group.
[00:01:15] Mirja Kühlewind: Hi. I'm Mirja Kühlewind. And if somebody in the back could close the door, that would be nice.
[00:01:20] Dave Plonka: And if we have newcomers, we are a measurement group that brings tools and measurement results about the operation and the design of Internet protocols in the IETF. So we get to do quite a survey of different topics. I believe this is the tenth year of us meeting possibly this meeting. So it's been going a long time. Thank you for being here. The slide that's up right now, the intellectual property. The IRTF uses the same intellectual property agreement as the IETF. If what you're presenting today has intellectual property and governments, then you're you need to tell us about that soon after the presentation if you haven't already. More boilerplate to note. Let's see the we're being recorded, of course. So if you're up at the mic or whatever, we are this and whether you have the red lanyard or you're you're equesting to that. And we have a privacy and code of conduct. Behave yourselves at least as well you have have earlier in the week, please. And the goals of the IRTF, we run a little more loosely than the IETF, but largely we're a research organization, not a standards development organization, but happen to be able to be co located with the IETF. There's a slide here with where you can find our mailing list if you aren't joined already. It's very low volume. If you think you wanna present at a future MapRG, it's a good place to be because most of the talk on it is about inviting is our call for contributions. So that's how you get there. There's links to the other tools for this meeting here, but you probably found those already via the agenda. Keep your video and audio off when you're not presenting. Those of you that'll be presenting, we're gonna put up your slides, we'll pass slide control to you. So the agenda, I've got some timings just for my own sake in the agenda. I said ten presentations. We kinda do three kinds of presentations here. Full presentations about either published work or quite mature work where you get, in this in this case today, ten or fifteen minutes. We're gonna do a couple of heads up talks to let the community know about what kinds of things are going on. That there are short talks just because that's the only time amount of time we had in the meeting today. But it's to let you know or it's to help us measure or engage interest in the group and those things.
[00:03:39] Speaker 1: And
[00:03:39] Dave Plonka: then lastly, the other kind of presentation we do, which is similar to the heads up, is if you wanna offer us a slide, we'll show it in front of everyone. So we have one of those here. I won't go through the agenda in detail because you've seen them as they're coming up. But Tom Vaughn from Common Crawl has done a nice piece of work about I p six adoption, showing us a small uptick in adoption over the last couple months. There's a QR code here, and you can also find the URL to the full report for that in the chair slides, the first slide presentation.
[00:04:09] Mirja Kühlewind: Yeah. Tom, are you here? Can you raise your hand so people can talk
[00:04:11] Johannes Zirngibl: to you?
[00:04:12] Mirja Kühlewind: But I'm not seeing him. We might be late. Alright.
[00:04:17] Dave Plonka: So on time thus far, first up, we have Johanna Moran. And I'll bring up your slides, Yohanna, and we'll pass control to you.
[00:04:31] Johanna Rooney: Thank you.
[00:05:03] Dave Plonka: Alright, Johanna. I passed the slide control to you, and I'll start a timer as soon as I find the button to do that. Yeah.
[00:05:12] Mirja Kühlewind: But you can start.
[00:05:16] Johanna Moran: Okay. Give me one second. Sorry.
[00:05:19] Mirja Kühlewind: We can hear you.
[00:05:23] Johanna Rooney: Okay. So hi. I'm Johanna Moran. I, will be doing our talk today, which is towards a common measurement framework for large scale deployments using CBOR based, verifiable telemetry. So the networking layer of large peer to peer networking deployments has matured, but own but our measurement, infrastructure hasn't kept pace. Every ecosystem observes the network differently, which makes results hard to compare or verify. And so we're proposing a common measurement architecture, built on portable cryptographically verifiable telemetry. So, slide two. So here's the paradox. Many decentralized ecosystems already share the same networking substrate, libp2p, but every project builds its own observability stack, which its own metric, logging formats, and semantics. The result is fragmented. So the two deployments can observe the exact same protocol event and describe it completely differently with its own metrics, logging formats, and semantics. So there is a so today's observability tools are one second there. Today's observability tools are built for operation operators, dashboards, logs, and traces are great for real time debugging, but they're poor scientific artifacts. Dashboards disappear, log formats change, schemes evolve. What we actually need are portable observations that stay meaningful long after they are first collected. So I'm just gonna go. So this is our proposed architecture. At the bottom sits independent implementations and applications, each generating observe observations locally. Those observations get normalized using common measurement vocabulary then encoded into standardized telemetry objects before being shared with researchers, operators, and AI systems. Key point implementation stay independent. Only the measurement representation becomes standardized. So this is the core contribution of the framework, the verify verifiable telemetry object or VTO, and each VTO packages are observation together with standardized metadata, time stamps, providence information, cryptographic identifiers, integrity protection. So instead of digesting whoever produced the measurement, anyone can independently verify that it hasn't been altered. The telemetry object becomes a portable unit of scientific evidence. To make these artifacts portable, we need deterministic encoding so that we use canonical CBOR. Identical ident identical observations always produce identical serialized representations, which gives us stable hashes, digital signatures, and content ingestion. Compared to JSON, CBOR is also smaller and more efficient, to process. So in insert the, Internet of Agents. Okay. This matter sorry. One sec. Oopsie. So this matter is even more for autonomous agent systems. Modern agent infrastructure involve thousands of independent independently deciding software agents. The traditional logging isn't enough. Portable telemetry gives us a common evidence layer for the we got debooking, accountability, and coordination across heterogeneous agent ecosystems. So our conclusion here is, let me go to the buying side, our central argument is simple. Measurement interoperability should evolve alongside protocol interoperability. If decentralized systems are to be, scientifically reach visible reach visible, comparable, and trustworthy, we need standardized measurement artifacts, just standardized protocols. By combining common measurement schemas with CBOR-based verifiable telemetry objects, we believe we can establish portable evidence layer for the next generation of decentralized and autonomous networks. Thanks so much for everyone. Happy to take any questions. Appreciate the five minutes we got today. Thanks a million.
[00:09:35] Mirja Kühlewind: Thank you, Johanna. So you were initially looking for a longer presentation, but we've had a lot of requests this time. But, like, we wanted to give you the opportunity to present this work if anybody's interested so they can reach out to you and work with you on this, and then maybe you can come back later in time with more results.
[00:09:53] Johanna Moran: Yeah. Thank you so much. I really appreciate it.
[00:09:56] Dave Plonka: And, Johanna and, Manu, please, put your, contact information in the public chat if you want, or let us know how you want people to reach you.
[00:10:05] Manu Gupta: Sure. Just did that. Thank you so much, Dave. Really appreciate it.
[00:10:08] Dave Plonka: Yeah. Thank you. And, Paul, you can come up.
[00:10:20] Paul Carlton: Hi, everyone. I'm Paul Carlton. I work at Anthropic.
[00:10:24] Dave Plonka: Hold on a sec.
[00:10:25] Paul Carlton: I'll just give my intro while we're
[00:10:26] Speaker 1: Yeah. Yeah.
[00:10:27] Paul Carlton: Yeah. Short on time. So I'm one of the core maintainers of MCP, and I'll be talking about MCP's profile of OAuth 2.1. So for for some background, MCP wants to support clients and servers in OAuth that have not seen each other before being able to connect to each other. So what that means is to avoid the preregistration step that is typically in a normal auth deployment. The way we the way we recommended to do that in March 2025 was with dynamic client registration, which looks something like that. I don't have time to explain the whole diagram. One of the issues we had with this recommendation was around client IDs becoming stale and being purged in the authorization server. So you would try to authenticate and or try to authorize, and you would get back an invalid client grant and then have to re go through the registration step. So in November 2025, we started recommending client ID metadata documents instead of dynamic client registration. So this instead of doing registration step, you provide a URL as your client ID, and the authorization server goes and looks up the the data there. So I've got some data for how that's going at at Anthropic for our our client. So this is the adoption growth we see of client ID metadata documents. This is for connector authorizations. So in the last thirty days, we saw about 14.7% of of these sign ins using client ID metadata documents, which is is great to see. And then well, I guess it's only great to see if it actually solves the the problem that we were seeing. And the nice thing is we do see a lot fewer of these requests hitting the inbound client requests. So we see DCR hits this on about two about point 2% of refresh attempts, where static client ID is also hit at a lower rate, then CIMD is is point o o 2%. So it's, you know, about a 100 times less than the than you see with DCR. Yeah. That's what I've got. Thanks.
[00:12:47] Mirja Kühlewind: Perfect. Thank you. You are also coming because more more data next time, I guess. Any quick questions? Otherwise, Paul is here. Talk to him. Alright.
[00:13:03] Dave Plonka: So next next we have up Dan Silva. And this is, in a way, a a different methodology, but it's a follow-up to what we did a year ago when we had a session specially dedicated to crawler traffic. And let me get your slides up here, Dan, and pass the control to you. And you'll have ten minutes. And thanks to Paul, we'll have a little we'll have some time for questions and comments too.
[00:13:31] Dan Silva: Great. Thanks, Dave. Yeah. As Dave mentioned, I have he said there's a it's been about a year, and there's been an upswing in bots bot traffic. So this is kind of an a exploration of that a bit. There's, a couple interesting projects that this was kind of inspired by. Nefantis is a traditional slow tar pit for, bots to kinda get stuck in and move slow. And then there's other flavors of, bot traps. Like, the library of babble is essentially every single, book and whatever that would ever be written, so every character and combination of that. And then if you kinda go on to the, more scientific scholarly articles. There's a couple tools out there that have fake information and and that kind of thing to kind of poison the the well. So the idea is, like, what happens if you publish a valid robots. Txt file and then you have a, theoretically, an infinite amount of content and you don't manage the traffic at all or block or throttle the bots. So that's kind of the approach we took. And this is the site that we came up with. It's American Corporation for Public Well-being. It's not a real company. It attempts to be authentic and authoritative, and it's very text heavy, easily crawled. It's a simp there's a simple structure to it. It's got all kinds of fake business things that kinda represents this, like, think take business. So we we kinda went towards more quantity than quality, so we're not trying to poison the well. We're kinda just seeing how much content we can serve, how fast we can do it. Some of the AI models have been able to sniff this out where there's something this detect something's wrong, but they don't really explain why it's how it is. So here's the results. We we spun this up about five months ago, in mid March. And as you can see, these bots just don't seem to wanna leave it alone. In July so far, we're averaging about 5,000 requests per minute. We just crossed about 1,000,000,000 requests served in those five months. The top five bots represent 75% or greater than 75 of requests. Most of those URLs in the 1,000,000,000 are unique. And with the way the site's structured, that's kind of on purpose. About 2,000,000 hits on robots tech tech. So we're they're most bots are checking that, most are following it, and the peach peak traffic has been about 1,500 requests per second. And before gzip compression, that's about one and a half gigabits per second. I did not expect to have to build up a small cluster for a site to serve basically what is garbage to bots, but here we are. Here's a kind of a breakdown of some interesting bad crawler behaviors. Most of the bots are not completely out of control, but one in particular is far more aggressive than other others, and that's Quan, which is an Alibaba cloud project. It's extremely bursty. We've seen sudden peaks of over a thousand requests per second for, you know, one minute or or less and then nothing at all. It also is not truthful about its user agent. It sends a basic web browser user agent and always sends a Google HTTP refer. Some bots also ignore HTTP redirects. So if you're trying to change paths or move things around in the site, they just it they just don't follow that. And an additional note about the Clenbot is if your site goes down for an extended period of time or even a little bit, it does not do any kind of exponential back off. So it will come back and possibly with even more traffic. So recovering from an outage is interesting after, Quentin Cogs is one. Here's kind of a quick breakdown of some of the numbers. If we got about a billion requests, Quentin, it's about about a quarter of them, about 30 actually, it's probably higher than that. I think it's more like 30%. And then that's followed by OpenAI and Tencent and and Clawd. Here's kind of the layout of the app. It's just a very simple, web app. Traffic ingresses into a basic NGINX load balancer, which then fans out to, a cluster of Django workers that generate the content pretty much. And then stats flow into Redis, which is processed later. That that's all async. So it's really very simple simple setup. One discovery that we've had is subdomains seem to amplify traffic for some bots. Some of the content is actually segmented into into separate subdomains. So the theory here is that the subdomains are treated as a separate website for some of these bots. And when you're routing traffic in them, they obviously are rate limiting those deck differently somehow. And there was definitely a jump when we enable the subdomains of some of the bots doing something different, which was kinda interesting. One, there's a bunch of different pieces for the site, and I don't have a lot of time. But the one that gets the most attention from these AI bots is what we call the archive, and there's about 600,000,000 requests served for that. The archive kinda works in a way that the URL actually seeds a lie it it picks there's a library of pregenerated content, and the seed from the URL, which is made up of a bunch of different pieces, actually selects random stuff from the library. And that that seed is consistent over every page view for that one specific URL. So it's if you go back to the same page, it's the same content. So that's kinda how most of the site works, and it's all just pregenerated random text that's kinda glued together. It's very fast. It's about ten ten milliseconds per page load. So Cloudflare has their lava lamp experiment for generating entropy. We kind of built a similar thing where we're using AI bot traffic to generate random numbers. So there's a separate spin off-site that gets live requests from ACPWB. And the the concept here is we're using the bots as a source of entropy. Not sure it's totally kosher and for random, you know, numbers or whatever. Probably wouldn't use it for that, but that's what we got. Future experiments, we're currently kinda implementing internationalization just to see if that changes things, if the, you know, the the bots that are not primarily English or expecting English do anything different or are more aggressive or interested in things. But that's what I got. I'd like to thank Anton Capella. He donated compute and network resources for this project, and just let me know if you have any questions.
[00:21:15] Mirja Kühlewind: Thanks a lot. I can say the talk was well appreciated in the room.
[00:21:20] Dave Plonka: Thanks. Laughter at all the right places. So go ahead, Stuart.
[00:21:26] Tim Chown: I'll be really quick because I know we're down
[00:21:28] Oscar: by time. We should hear from our
[00:21:29] Dave Plonka: Our time is really is pretty good. Mark.
[00:21:30] Robert Story: And I actually came up to
[00:21:31] Tim Chown: say exactly that thing. I wish you were in the room because people are almost falling off their chairs laughing here. This is spectacular. It's fantastic. Thank you.
[00:21:39] Lorenzo Colitti: Great. Thank you.
[00:21:42] Dave Plonka: Dan, maybe I missed it. I was curious to know what challenges you had, if any, with identifying what the company or the bot was because I think I heard you say that they lie about who they are. What what what what what are we presented with there?
[00:21:58] Dan Silva: So there's there's you can you can kinda you can look up the the network that they're on, and sometimes that tells you. I know some of the Alibaba cloud stuff actually goes the you do Who is for that, and it it tells you exactly who it is. But they also seem to be getting new subnets in other places that are not as
[00:22:21] Ibrahim Morah: easy to
[00:22:21] Dan Silva: look up. So you can kinda identify it by the, you know, the obviously, they're always sending Google as the referrer, like, every single time, same thing for every request. So that's pretty a pretty good tell.
[00:22:32] Dave Plonka: That's pretty interesting. The so it's kind of a fingerprinting exercise, really.
[00:22:36] Dan Silva: Yeah. Yeah. Yeah.
[00:22:38] Dave Plonka: The the and then you mentioned the you were able to look up the ASN there. Two anecdotes. At my small research and education network, we've had to block traffic from outside The US temporarily while we're trying to figure out how to deal with the the the deluge of of requests to our public sites. And so that's an anecdote of what's happening to some people. The other one I know about, a geology or a geology department at university, they were seeing these kind of requests from tons of what looked like residences. So have you seen anything like that where, clearly, they're trying to hide it as as normal users?
[00:23:17] Dan Silva: It seem it seems to me most of them come from a pretty the same IPs. Like, there's there's a couple IPs that are you know, for for client, it's always the same blocks, and they kinda rotate occasionally. But it's not residential at all.
[00:23:33] Dave Plonka: Alright. Thank you. We got a couple more people in the queue. Robert, you're up.
[00:23:37] Robert Story: Yeah. Thanks. Robert Storr, USC ISI. I see you have a GitHub repo here. Is this open source, like, we wanted to reproduce it? I can put it back up. I took
[00:23:47] Dan Silva: it down because I wasn't sure if the bots were gonna start sniffing that out, but I can put it back up.
[00:23:52] Robert Story: And my second question was, you talked about introducing languages as a way to maybe see if it would slow them down. Have you tried other things to see if they noticed, like, if you're rate limiting or other things like that, or you're just keeping it wide open?
[00:24:05] Dan Silva: It's wide open.
[00:24:07] Robert Story: Okay. Thanks.
[00:24:11] Dave Plonka: Thanks. And next in the queue, have Tim.
[00:24:19] Tim Chown: Sorry. Hi, Tim Chan. Yes. Yeah. This is great. Thanks. I'm a bit naive in this area. Just how much more aggressive and out of control are the AI bots than the normal callers? Presumably, you still want to have your wonderful website appear in Google and Bing or whatever they're called, and you wouldn't wanna block that. That's useful. But
[00:24:40] Ibrahim Morah: just Yeah.
[00:24:41] Tom Vaughn: I don't think
[00:24:41] Tim Chown: What's what's the relative craziness?
[00:24:45] Dan Silva: That's a good that's a good question. I mean, I I went back to the slide with the stats here, and you can see Google's at the bottom. And the five I think it was about 5,000,000 requests from them out of a billion. So it's a pretty small percentage. The legitimate search engines that are, you know, the traditional search engines, they're a drop in the bucket for this.
[00:25:08] Tim Chown: But does number four suggest that twelve percent of the hits people reading your site and maybe believing it's true, the brand
[00:25:15] Johannes Zirngibl: So
[00:25:16] Dan Silva: that that's something I haven't totally explored, and I I that is part of the problem with Quen is I have to, in the software, actually tell it subnets that Quan is on, and a good chunk of the other browser one isn't that's not totally accurate because that's just unclassified. And it's I need to do more work in this in this, but yeah. I mean, the traditional traffic from search engines hasn't really been significant.
[00:25:45] Max: Okay. Great. Thank you. Really good.
[00:25:47] Dan Silva: Thank you.
[00:25:49] Speaker 1: Out of curiosity, did you also try different top level domains like .net, .com, and then maybe country specific ones?
[00:25:58] Dan Silva: Not yet. We haven't done that. I have a few more, you know, the $10 domains laying around for abandoned projects that I probably should try, but, no. I have not.
[00:26:08] Robert Story: Okay. Yep. Thanks. Yep.
[00:26:10] Dave Plonka: Alright. Thanks a lot for joining us, Dan. I appreciate it.
[00:26:13] Robert Story: Thank you.
[00:26:14] Dave Plonka: Oscar and Max, I think we have you up next.
[00:26:26] Oscar: Yeah. Thanks. Hi. Wrap this. Yeah.
[00:26:32] Robert Kisteleki: That's fine. Almost there.
[00:26:34] Oscar: So yeah. Hi. Oscar and Max from the Firefox networking team. And, yeah, we're kind of just here to share some data with you today. We'll try to be brief. And how this works? Great.
[00:26:46] Dave Plonka: Yeah. So, basically, yeah, this
[00:26:47] Oscar: just says, yeah, we do collect telemetry data, and it might be relevant for the ATF. I think the last point is the most important one. The low resolution of this is entirely public, and you can sort of just look at all the probes in a low resolution aggregate. And that's also what we kind of want to, like, motivate people to do. So, yeah, this can easily easily be looked at. Let's get into it. So we've kind of just prepared a a few fun things that we thought surprised us, might surprise some of you. The first one is just OS share. And so, yeah, a lot of our traffic is Windows. What might surprise you is about a third is still Windows 10, and and then we have 6% that are even older than Windows 10. And in general, we also have, like, a very long tail of machines that are slow and old, and I think that's something that we as devs maybe often forget that not every machine out there is a dev laptop. So, yeah, for example, you can see here we have 11% on four gigabytes of RAM, and we have 7% still running 32 bit. Then for mobile, so on Android, we see a split of 60% on Wi Fi, and then about 30% are on mobile, which might be interesting for some of you. And then at this point, I'll give the mic to Max.
[00:28:19] Max: Okay. So I'll walk up the stack a little bit. All of these metrics are rather fun facts to, like, keen your interest. You can dive into each of these, and you can download the slides, and you'll find the links to all the different metrics, explore some more. And Oscar will go into detail how you can find all of them. So if we walk up, on the IP layer, right now, Firefox still sees very little I p v six. 20% of our requests are over v six. The remainder is over v four. This is with Happy Eyeball v one, which are our current release numbers. We are currently implementing Happy Eyeball v three. That's in Firefox Nightly, which is our alpha version. But there, we don't really see a big change in this number. If we walk further up, contrary to I p v six adoption, HPS is pretty much universal or we consider it pretty much universal. 89% of our requests are encrypted. The remainder is basically half and half, either plain text or request to local domains where we're not so worried about this not being fully encrypted. I assume a lot of the unencrypted part is enterprise setups, but there, I'm not I cannot validate that on the outside. If we walk further, we we use HEBS to encrypt the actual goodput. What is relevant for us is to encrypt the SNI, the server name indicator. You can do that with the ECH, encrypted client hello. That is we see very, very low deployment of ECH and definitely below 1%, around 1% sometimes. We see more ECH deployment on h p three, but I think that's simply a correlation, not a causation, where those hosts, which is basically just Cloudflare free customer offering, we mostly connect to them via h p three, and thus we see more ECH on h e p three. Talking about HP versions, h e p three is around 17%. We mentioned this in various other venues here. The majority of our requests are still h e p two. All of these numbers are page loads and not actual number of requests. Why I chose this metric here is if you, for example, go to any major use news site, you'll make one connection to the news site and then a 100 connections to various ad trackers. So I'm excluding them here by simply measuring page loads. There are other perspectives on the number of h e p three. So for example, Cloudflare rater reports roughly 30%. And for those interested, that was the more quick how site meeting with a lot more information on this. Now discovering h p p three is a little bit difficult. You might remember when we upgraded from h p one to h p two, which I guess we're still doing, the upgrade would happen on the TCP connection via APN in the TLS handshake, so you can reuse the TCP connection. That doesn't exist in h p three as that is using QUIC, so there's no shared TCP connection. So we need some signal from the website operator that they speak h p p three, and there are two ways for that, either via an out service or an HPSRR DNS record. The former, we would first have to connect via h one or h two, and we see actually that happening in most of the cases. Around 35% of our upgrades use out service. And then via HPS records, we can connect via h three on the very first connection, which is wonderful for us as we do way more h three three as a browser, but that only happens in very rare cases. In addition, we shipped QuickV two recently. We see roughly 0% deployment of QuickV two on the Internet. There are some caveats to this, and we discussed this in a quick working group. So find me if you're interested in learning more about QuickV two and maybe how we can progress that long term. A gotcha from for for me, just to interest all of you. So we run our own QuickStax, thus we have access to round trip time measurements and various other metrics around our QuickStack. And what was very surprising to me was that our median is currently around twenty five milliseconds. I would have expected way higher, around fifty or seventy five. And I think these kind of numbers, maybe not this in particular, but in general, like rounding yourself in data can inform your next protocol design, and this is definitely a helpful one. One caveat here is, we landed this metric only recently, so this is only for our Firefox Nightly population, which is around 15,000 users. This will hit release soon, and then we'll have the roughly 200,000,000 monthly active users on the metric as well. I mentioned we run our own QuickStack as we handle UDP. Thus, we're also in the business of deciding what MTU to run on the Internet. But we also see, as we're mostly downloading as a client, what the servers use. Now most of them used twelve seventeen. That's, I I believe, 1,080 on the IP layer with IP headers. But we also see some brave souls running one four four eight and sometimes more. If you're curious about that, the metric is, again, linked below. With that Yeah.
[00:33:52] Oscar: And so now we'll move on a bit to our send path. So, yeah, we're a browser. So, obviously, we're sending a bunch
[00:33:59] Robert Richter: of get
[00:33:59] Oscar: requests, but we also do actually send data. So about 6.60.5% of our connections actually ever grow their congestion windows, so they ever send enough to not be application limited. And then of those 6.5%, only five to 6% send enough to exit slow start. We also only see congestion events in the ninety fifth percentile and up. And then in the ninety nine dot ninth percentile, we see six congestion events for one connection. So really, of our connections never really enter steady state of congestion control. And then to move on, we also implement ECN. And so we can see we set EC to zero, and so we can see how many paths support e c n. For us, we see about 60% of e c n capable paths and then about 40% where the e c t zero bit that we set is actually stripped. We only see 2% of black holes, so that's good. Ideally, it would be zero. But yeah. And one thing that's really interesting is that for us on our send path, we do actually see 15% of our congestion responses are coming from CE marks. So, yeah, somebody's out there and marking CE. So, yeah, in general, of course, it's good that those CE marks exist because it's nice to have a congestion event without a packet loss. And we also implement alternative back off, so we react less to ECNCE than we would to loss. And then I have something that's very new. So we implemented this during the hackathon, and it's a new telemetry probe because we can also observe the receive path of ECN. And so we can kind of see how many servers support ECN. And so this is very fresh data, like first day data from Nightly. And, yeah, we see that about 4% of connections that we receive have marked ECT zero, and of those, zero dot seven dot five zero dot 75% then actually have observed in ECN CE Mark. And then the same thing again for ECT one. So this is quite nice because this metric can be used to kind of observe the rollout of l four s eventually on the networks. And then, yeah, we're almost out of time. So you can query a lot of this yourself. There's some different links here, mainly GLAM, which is our public dashboard, and then some curated dashboards and stuff like that. And so, yeah, for the higher resolution data, if you do bring a research question and add an interesting browser vantage point, then feel free to contact us, and we're happy to help you find the right probe. And yeah. Thanks.
[00:37:04] Mirja Kühlewind: Thanks a lot. What is this mic doing? Thank you. It's it's really nice to see all this data and have them available. I have a very quick clarifying question on the previous slide because you said out of those nearly 4%, it's 0.76 at CEE, or is
[00:37:21] Oscar: it Yes, sorry. Then I misspoke.
[00:37:23] Robert Story: Okay.
[00:37:23] Oscar: So it's 0.76% seeing ECT zero and ECN CE, So about, like, 20% of those that set ECT zero C CE. So maybe just motivate some server implementers to implement ECN.
[00:37:43] Robert Kisteleki: You had a slide hi, Robert. You had a slide about v 20%. Is that number of proportion of connections or proportion of bytes?
[00:37:51] Max: This is requests. We do have connections. I don't know whether we have bytes. I can provide that if you want.
[00:37:57] Robert Kisteleki: I I would be interested if the difference is major or not.
[00:38:00] Max: I don't know, but I think we have per connection. Yeah. Also, something I I forgot to mention here. This is global. Kasim asked me to to to raise this here. This is the global number. We can drill this down by country. And so that might be something interesting, but that requires more work from our end.
[00:38:20] Dave Plonka: Alright. Thanks so much, Oscar and Max. Johannes, if you could come up. So, awesomely, Johannes will be presenting a piece of work that's already been accepted for IMC in October of this year. And the two reasons that's cool is, first, you get to scoop an academic conference, but, also, you have opportunity to help them improve the work potentially before it's published. And also, if you're a researcher, think of bringing it here so you can learn what the community reaction to it would be before you present it. Johannes so so this is a full paper, so this has fifteen minutes. And you can let's see. Did you get Yeah. Yeah. You got the clicker already. She's ahead of me. Go ahead.
[00:38:58] Johannes Zirngibl: Cool. Perfect. Thanks. Yeah. This is joint work with Sebastian and Anya from MPI and Tobias here from Technical University of Vienna. And what we looked at is trace routes. So I guess most people here use trace routes at some point in their life. It helps to debug what is happening or see paths on the network. Also, most people, I guess, know that they are not always perfect. Sometimes TTLs are not properly reduced, or there are tunnels that are hidden in trace routes. The thing is we didn't expect is that trace routes or TTLs in IP packets are completely rewritten and jump to a drastically larger value. When we look at this in an example, we have a small network with multiple hops. We wanna do a trace route from source to destination. We send a probe with TTL one as normal. It should be dropped, and an error message is returned. Now second probe, two hops. Third probe, three hops. So far, so good. Now what happens if node two does not reduce the TTL but rewrites it to 255? Well, the packet travels through the whole network, directly reaches the destination, and if we get a response, we get a response. So what we would infer from that is basically that we have sourced the destination with two hops in between, and it hides a complete AS and parts of a second AS. And the thing here is we actually found this. So this is happening. This is not just a theoretical example. And this impacts research, but I guess also operators that need to debug something and look into networks. So in this work, we looked into this. We checked how prevalent this is, who is involved in this, which networks, and whether this is new or exists for a longer time. How did we do this? We started with a controlled measurement. We set up a node in Germany where we can capture all the traffic and see incoming packets. And then we used Drive Atlas to run trace routes to this probe and check what we see at the end. We did this in twenty twenty five, November, and we were able to run trace routes from around 11,000 I p v four capable probes and 5,700 I p v six capable probes, one trace route, per probe to our destination. And what we find is what we find is, yes, that for 365 of those trace routes, we see a TTL rewrite to a drastically larger number, and those probes are in 63 different ASs. Also, this is not only I p v six or I p v four. We see this in both protocols. This is not a drastically large number, but it's still a relevant number, and can have widespread impact. Now this could be our vantage point that does this on ingress or something, and not be a problem of the Internet. So what we did is we looked at the last visible hop that we saw in the traceroute before it reached our target, and we find that this hop is, in a lot of cases, for example, AT and T or Orange. So this happens in tier one providers. We find this in smaller networks or in content providers. So Microsoft or Cloudflare, we also wrap Atlas probes are hosted, and this happens. And when we look at the rewrite location, so how where is the probe related to this last hop, we see that it's mostly in the source AS. So it's mostly for those probes that are actually in AT and T or Orange, and you only see whatever happens in those networks, and then you directly reach the target. And in those cases, we are sure that this destination has no direct link to all those networks, and we receive, traceroute probes with a TTL of 240 to 250. So there happens a rewrite to 255 in those cases. We not only see this in the source AS. We have a bunch of trace routes where the last hop doesn't really respond, so we only get an asterisk, basically. So we can't map those two targets. And in some cases, this happens on path. So Arelion, for example, does this also for transit traffic through their network in some cases. This mapping to an AS is obviously not perfect, mapping IP addresses in trace routes, ASs, but this is the best we can have. And we didn't use any existing methodologies to to improve this, like alias detection, because in those cases, we don't really have the relationship between hops anymore, and the existing tools break. Now this is only a small set. How can we increase this to a larger scale? What we did there is we used all existing Rob Atlas measurements, that are freely available online. For those measurements, we don't have the capture point, so we don't directly see the incoming packets. But whenever the trace route results in an ICMP error message different to a time exceeded one, so port unreachable, destination unreachable, this error message should contain the original packet that was received, as a quoted packet. And in that quoted packet, we see the TTL, so the quoted TTL, and can use that value as an indicator what the destination actually saw. So when we do this for one day, we see out of around 200,000,000 trace routes they publish on that day, for 2,000,000, we see an ICMP error message by the destination. And when we look at the results, we have the quoted TTL on the x axis, and we have the number of traces with a logarithmic scale on the y axis. For most of those traces, it's correct. So the value is one, how it should be in a traceroute once it reaches the target. However, for 86,000, it is larger than one. Still, around 75% of those are between one and a small number. I assume it took a different path with a different length, or it was not reduced, at one hop, so we don't consider those as rewrites. However, for the remaining 25%, so in this case, 23,000 of those traces, We see a rewrite, and we see those rewrites, to three basically different groups of values. And we have one around 64 and slightly smaller. We have one around one twenty eight and slightly smaller, and the majority is at 255 and slightly smaller. One caveat here is if you wanna use this yourself, Ripe Atlas, the trace route, for example, has a liveness check. So if five consecutive hops are unresponsive, the trace route tests if it can at least reach a target and for that sends a probe with a TTL of 255, but that is indicated in the results and can be filtered. So we see that. One interesting case here is, the gray dot at around one twenty eight. So those rewrites are not only, into a larger direction, so it's not only setting it to a larger value, but in some cases, if the, TTL is around 200 something, it also reduces it to one twenty eight. Or that path was incredibly long, but I don't think that was a 127 hops long. With that, we can now this do this over time, based on the historic Red Atlas data. So what we did is we took one day per three months since 2018, and this is not a new phenomenon. So this is happening for a long time already. What you have is on the x axis, the respective dates. On the right y axis, you have the black line, the number of traces with a quoted packet where we can extract the TTL. So it's increasing from a few, trace routes that have this information to around those 1,800,000 that we saw. And then on the left, y axis, you have the percentage, how many traces are impacted, where it starts at around 0.1%, so very small number, to around one percent by now. This increase does not necessarily mean, that this is happening more often or in more networks. It could also be that more traces are conducted on a regular basis, and it's just captured more often. So, this is basically what we found here. We also saw this in KADA ARC data. The most prominent node there is an I p v six or multiple I p v six probes in AT and T, and all of them are basically blind and can't run traceroute. So the rewrite is happening for all outgoing connections. So this is happening. This impacts research. This also impacts operators. I had a discussion here where this case was seen this week and reported to them, that Arelion has suddenly a new link to them, which they don't have. So using this might be difficult. It's out there since 2018. We don't know for all cases what it is. We don't know for most cases what it is. We talked to some operators and some vendors that there might be bugs or misconfigurations, that, for example, a multilabel MPLS stack might not be properly popped or not both labels are properly popped, and then the wrong TTL is written to the packet at the end. With that, I'm at the end. If there are any questions, let me know if you wanna discuss this afterwards or have ideas why this happens. We are open for any ideas. Thanks.
[00:48:47] Lars Eggert: Last second, Mozilla. I love a mystery story, so thanks thanks for sharing this. This is probably wrong, but I'm gonna say it anyway. Are these just bit flips? The checksum would be invalidated, but it the the patterning of your of your, clusters makes me wonder.
[00:49:06] Johannes Zirngibl: I don't think they are bit flips because then I mean, we saw this also outside of trace routes. So it's not always when the trace route would or the probe would be reduced to zero, and instead of zero, they set it to 255. So I think if it's a bit flip, then too many bits need to be flipped.
[00:49:25] Lars Eggert: I meant random corruption in the TTL.
[00:49:28] Johannes Zirngibl: But also then multiple bits in sequence Yeah. Okay.
[00:49:31] Lars Eggert: Need to be This is why I said it's probably wrong. Thank you.
[00:49:38] Robert Kisteleki: Go ahead, Robert. Hi. Robert for Ripe Atlas. We have data going back to twenty ten ish. So I would I would be curious if you actually went further back than 2018, what would you see?
[00:49:49] Johannes Zirngibl: I you arrive atlas. Like, the online data is not complete historically because of some API changes, if I'm not mistaken.
[00:49:58] Oscar: No. No. It's there.
[00:49:59] Johannes Zirngibl: You can hear it.
[00:50:00] Robert Story: I maybe, you know, we
[00:50:01] Robert Kisteleki: can talk offline. I can can help you with that.
[00:50:03] Ibrahim Morah: We can definitely
[00:50:04] Robert Kisteleki: The the other observation is, yes, indeed, the network has been growing ever since day zero. So, you know, some of those numbers go up naturally, but I'm happy you do proportionally as well. And I would encourage you to do more of that because, you know, we do more more and more dense measurements. Yes. The same network is also doing more, but it's also growing. So I wonder what the effects of that are.
[00:50:26] Johannes Zirngibl: Yes. Also, Riot Atlas is not running the same trace routes every day, so that might also impact the data over time. It's not a perfect time series, but yes.
[00:50:39] Dave Plonka: Oh, thanks, Johannes. Oh, we got somebody else. Benjamin, you can go.
[00:50:48] Ben Schwartz: Hi. Ben Schwartz. Not a so as I understand that TTL was originally introduced as a defense against routing loops, against eternal packets when you have a routing loop. And what you're showing here is that, actually, there are a lot of paths on the Internet where the TTL doesn't decrease. So, I wonder, do you think that this do you think that there are pads out there that that have eternal loops as a result of this? And if not, do you think that the original purpose of TTL is is moot? That it turns out even without TTL, we're doing fine.
[00:51:32] Johannes Zirngibl: Yes. So I don't know if there is a case where it loops infinitely, because then the rewrite has to happen somewhere in the loop. I mean, it might happen. We've definitely seen some cases where the trace route ended in a loop, and it looped at least for, I don't know, 200 something hops. So even there, the the packet will stay longer in the loop. I still think TTLs are valuable and should be further used. And I guess most operating systems don't use 255 as a default anymore, so all of those packets have an impact on the network, not only on trace routes, but in general, increasing that to drastically larger value, is a problem. I don't think it's on purpose, or I don't hope it's on purpose for some networks. In most cases, I guess it's a bug or misconfiguration. Yeah.
[00:52:30] Paul Carlton: Thank you.
[00:52:31] Dave Plonka: Alright. Thanks a lot. Next up, we'll have Nalini Elkins, talking to us about some measurements about post quantum TLS. And then we need you got ten minutes.
[00:52:57] Nalini Elkins: Okay. I'll talk fast. Okay. So everybody you might be walking around. Everybody's talking about post quantum this, that, and the other thing. There's a lot of algorithms be that are being developed. A lot of arguments are being had. One of the arguments is about the the signing keys, how they're gonna grow. The stuff in the red is kinda what we're doing today, and you can see that both the bytes in the signature and the public key are going to grow. And so they're coming up with something called Merkle tree certs where, you know, you have a tree hash and you're not necessarily saying you know, sending everything, you know, over it and how you're gonna, you know, keep track of stuff. So so the question is how are we supposed to deal with that in terms of of deployment because enterprises use certificates for a lot of different things. And so I did some deployments of what are enterprises doing today. And I did the financials horizontally. That is large banks in US, India, and Latin America, and health care vertically. That is we have private health insurance in The United States and the hospitals and healthcare. So if we just look at post quantum hybrid adoption, so you'll see, I hear a lot of people say that we've got 69% post quantum for ML-KEM. And so why are why is anybody even talking about it? And that's only true of the large Internet companies. You can see that some of the other regions let me see if I can focus in on some of this. It's like some people are approaching what is that one? That, you know, maybe Latin America or the hospitals are doing real well. But one of the and this is measuring public websites. But what other people tell me is, you know what? This doesn't even matter. I mean, there's people that are using TLS one point two and one point one today and who cares if the website is hacked anyway? Banks need to convert their back ends. Who cares if the website is hacked? Well, I don't know so much. So one of the other things I did is I looked at the certificate composition with MLDSA 44, which is the biggest key size. And you can see it's going to start taking up quite a bit of the cert now. But you can see that the average handshake time is which is now what we have. Right now what we've got is that the cert time, time to process the certificate is maybe about 25% of the total handshake. And that's gonna grow to about 50%, which sounds real bad, but still for a lot of handshakes, that's only like maybe a 150, two hundred milliseconds. So the question is is like, you know, is there is there really, really a problem with this whole stuff? And do we does everybody have to do Merkle Tree certs? I also measured the the cert chain composition. You know, who's sending big cert chains and maybe even if we just got rid of one of the intermediate search that would might buy us back that hundred and eighty milliseconds that we were concerned about. So, you know, so how are we going to do this at enterprises? Our our browser is gonna they're probably gonna do MTC. What do we need to how do we need to handle that? Our enterprise is gonna do plain certs. Yeah. So this is interesting, and we had an interesting discussion in plants about it. And we're thinking about putting up some of our own test websites so we can enterprises can test some more, get some more learning and start to do more things. That's it. I went fast.
[00:57:21] Mirja Kühlewind: Yep. You saved us some time. Thank you. We do have time for questions, if anybody. But I guess this is also you just started to work, so this is ongoing work.
[00:57:31] Nalini Elkins: Sure. Yeah. Yeah. No. I mean, we're gonna keep doing it if there's and certainly, we can bring it back if there's interest. You know, as I say, I've gotten mixed reviews. Some people think this is real, real interesting, and other people say, well, you know, I mean, these banks are doing TLS one two or one one, some of them anyway. And so like, you know, I mean, people get what they get, right, for doing that, which you can't when you can't say no. But there you are.
[00:58:01] Mirja Kühlewind: So thank you.
[00:58:14] Dave Plonka: Alright. Next up, have Robert Richter bringing us understanding DNS dynamics over the Starlink network, and this is another ten minute presentation. And overall, we're we got about ten minutes to spare, so there'll be some time for questions and comments after this. Let me
[00:58:30] Robert Richter: get Alright. Hello, everybody. Thank you. So first of all, thank you very much for the opportunity to be here. We're going to do a little twist now in terms of what networks we're looking at, and we're looking at Starlink, DNS here essentially now. This is work that has been published at the IFIP networking conference a couple months ago, so this is quite new. And first, let me elaborate a bit on why we actually do Starling studies, even though most of you probably already have heard enough Starling talks, also during this IETF. But first, a little story that I had while flying here is actually that in the plane I boarded, there was free Starlink Wi Fi accessible for everybody, and it was quite decent, actually. So hot RFC talks was were quite watchable during this time in the plane. Maybe that's the future. I don't know. But I know that Starlink has rolled out a big mega constellation by now of over 10,000 satellites. So, yeah, it's quite worth studying by now. And, actually, what I did a couple months ago or quite a while ago now is also just have an exploratory measurement in Ripe Atlas, over Starlink. Because Ripe Atlas, if you don't know, has more than a 100 probes by now deployed operating, yeah, over Starlink, so you can do quite some measurements there if you want to do some studies on Starlink. And what I learned there is basically, yeah, Starlink DNS is decent, but it's still bit of differences by country, and I just wanted to learn more about it. And that's what I'm going to bring to you here, what I learned, during this time. And so what did I actually want to find out during this study? So first of all, I wanted to find a bit of what actually Starlink does in terms of, DNS, especially what does Starlink default to, and what are you as a user going to use when you use Starlink. And then, of course, I want to learn how does Starlink actually or Starlink users observe latency if you try to do some queries there, and where does this latency actually come from. So yeah. And in the end, I will give you a little overview what we can here as IETF community learn from that. So let me first give you a bit of an overview how resolvers, users of Starlink see resolvers in Starlink. So basically, if you didn't know, you can use Starlink even if you don't pay for it. So there's still Internet connectivity in there for exactly two sites, and that's starlink.com and spacex.com. Probably you can see the use case here already, which is just, yeah, you can resubscribe and pay for Starlink. So that's a whole use case there. And you can get basically this connectivity over this little resolver there, this 34145127Dot1. So this is nothing that I came up with. It's just documented by Starlink. It's not really a strong resolve. It's just something there for those unsubscribed users. But also, the more interesting thing here is basically how do actually resolve a set by default for users that actually pay for which probably are most of them. And here, you have basically a choice between setting yourself a resolver, just a public one like Cloudflare or something, or use, the SpaceX provided infrastructure for Starlink. So yeah. So now let's look at what we actually can see for Starlink users in terms of latency. So, how fast will it be for you? And for that, as I already said, we use the Ripe Atlas infrastructure, so there's, quite a bit of vantage points possible. But of course, Ripe Atlas, as most of you probably also know, doesn't offer every single DNS protocol that we maybe want to study. For instance, here, all sorts of DOE protocols. And those measurements, we basically do with our own Starlink antenna deployed at our university. But, of course, it's still only a single vantage point. And what we see there is, first, we look at the historical measurements from 2025. And the good news is if you are European and use DNS, it will be great. So very good performance here, especially the upper parts of it. I hope this works. Yes. Here, these are basically all European countries, and latencies are very, very low, probably. But if you're not in Europe, the all latencies are way down, even for DNS over UDP, which is the most basic protocol probably here. Maybe I want to draw your attention to the lower parts here, like North America even, but also South America and Micronesia, so those places where we don't have really lots of terrestrial internet, infrastructure. So yeah. But let's look further into this. So we want also now to catch a bit of performance in Starlink over the different DOE protocols. So they are really new stuff. And the nice thing is so this is all recorded from our own dish, which is connected to the Frankfurt POP. And the nice thing is they work quite well. So this is to be expected, actually. Each of the DOE protocols works quite along the number of round trips they actually require, with DNS over UDP being the baseline here, with about twenty to thirty milliseconds of latency. Yeah. Let's advance further here to the interesting stuff. So let's talk about what actually causes all of this DNS latency in Starlink. And here, we, use a little methodology that is, by now, used by a couple of researchers. So we use the property that Starlink employs a CGNAT. And what that means, that you can run trace routes, essentially, and see this 100 dot six four dot something. And we assume, and others probably as well, that this is a first terrestrial hop. So the Starlink constellation in itself is SAP IP layers, so you can't really observe it using trace routes. But looking at the latency that you get from those trace routes to the CGNet hop, as I call it, likely this is the first thing on the terrestrial segment that we can observe. And we use it basically to dissect the difference between how far or in terms of latency, how far is the first hop distant to the user antenna compared to the whole latency. And what we see here, again, for, the European probes from Starlink here on the left side, it works well. So again, Europeans are privileged here. But if you're in Philippines, Jordan, Colombia, and stuff like that, you will still have a big overhead from the terrestrial part. So where do I want to go from that? Actually, is actually already what we should work on in the ITF. And that is that this whole thing is similarly also observed for CDNs, and this is a routing problem likely. So we are uncertain how well chosen the POPs here are. And in many cases, these POPs are ill chosen. So, we have a large routing problem here that produces a big overhead also for those props in more distant countries or more distant positions. So yeah, I want to motivate here a lot of the work around the satellite routing. And we also already observed quite a bit around this. So we had a site meeting on LEO satellite routing. I'd also in IPWOSEN, and I think there was also a talk in space working group. And with that, I'm open to the discussion, and thank you very much.
[01:07:04] Dave Plonka: Alright. We got a couple people in the queue. Lorenzo, you're up.
[01:07:08] Lorenzo Colitti: Lorenzo, there a reason you didn't I don't see any I p v six measurements here, but I looked at the Starlink. You know, the IP address is provided by Starlink link that you have on one of the slides, and they do provide it. Did you did you you just didn't bother to measure it? Or
[01:07:25] Robert Richter: So we didn't measure it in this case. Likely, I wouldn't assume there's a big difference here observable. Of course, our trace route measurements wouldn't work this way anymore. So we couldn't do this anymore because we don't have the CGNAT. But that would be future work, essentially.
[01:07:43] Lorenzo Colitti: Presumably, the CGNAT is where the v six traffic egresses as well. But it sounds like you just could have measured it, but you just didn't do it. Okay. Thank you.
[01:07:53] Dave Plonka: And, Ben Schwartz, you can go.
[01:07:56] Ben Schwartz: Hi. So am I understanding correctly that the conclusion is that, essentially, SpaceX appears to be operating DNS resolvers at a subset of the peering locations.
[01:08:17] Robert Richter: So sorry. Can you repeat your question? I didn't quite get it.
[01:08:23] Ben Schwartz: So my question okay. If if there were a DNS resolver collocated with every SpaceX terrestrial peering location, then we would expect to see, I guess, what you see in Germany, where the latency to the DNS resolver equals the latency to the first terrestrial hub. So do we conclude that resolvers are just present at a subset of those, of those locations?
[01:08:54] Robert Richter: So, first of all, the SpaceX, resolvers itself, they are not public, so we didn't, actually target them explicitly, to get it out of the way. That's something that we would still have to find a methodology for. It's probably possible by doing it over the Ripe Atlas probes that haven't defined a specific resolver. But yes, of course, we also don't know if they are co located actually with the POPs. Probably they are. And yes, then we would probably also see what we saw for the German probes. But that's also something that we, in the end, found that would be quite interesting also in regards to the capabilities of those SpaceX operated resolvers.
[01:09:47] Ben Schwartz: You said you didn't target them explicitly. I guess now I'm confused. I thought from the that you were measuring latency to the SpaceX provided DNS resolvers.
[01:10:02] Robert Richter: No. Not explicitly. No. We mostly use those resolvers, publicly accessible.
[01:10:11] Ben Schwartz: Okay. So you were then then let me re reinterpret this. It sounds like you are saying that Quad nine or other public DNS resolvers appear to be approximately co located with the SpaceX peering points at a subset of the peering points, including in Germany. And so and so in the German example, essentially, Quad nine or other public DNS is at a is essentially on at the same location in the network as the peering point. But in other places, it's farther away.
[01:10:43] Robert Richter: Yes. Essentially.
[01:10:45] Ben Schwartz: Okay. Thanks. That's very helpful. Yeah. For what it's worth, I work in DNS, and I would be interested to learn more about about the behavior and network topology of the SpaceX operated DNS resolvers.
[01:11:04] Lorenzo Colitti: Yeah. I just wanted to follow follow-up. I think that's what Ben is asking. We basically basically, what we're seeing here is Anycasting. Right? If if the if the Anycast resolvers are close to the Starling pops, then the number is low. Otherwise, it's high. And that's kinda you're just, figuring out how closely the the the Starling network interconnects with Google, Cloudflare, and Code nine. Yep.
[01:11:31] Robert Richter: Yes, to some degree, even though anycast also showed some deficiencies, like in earlier work on CDNs. But I won't don't want to put myself too much out there because I don't have everything in my head for that.
[01:11:46] Dave Plonka: Alright. Thanks a lot,
[01:11:47] Robert Story: Robert. Up
[01:11:49] Dave Plonka: next, we have another published paper. Newton, you can come up. This this is a paper from PAM 2026, published in March of this year on the future of DNS privacy, another ten minute presentation.
[01:12:09] Newton: Good evening. I'm going to present this paper, the future of DNS privacy, basically.
[01:12:16] Dave Plonka: Could you point the mic up a little closer to you or be a little closer to it?
[01:12:23] Newton: Start better? No.
[01:12:24] Robert Story: Thank you. Also take it out.
[01:12:26] Newton: Okay. I think I'll take it out. Okay. So I'll be basically presenting a paper where our research group was looking at the impact of encrypted DNS on user experience as the core outcome. So I basically was the presenter for the paper, but not one of the co authors. So the question is, why do we want to study this? Because when we look at the interaction between what DNS lookups result into versus what the user gets out of it, there is the high likelihood that there may be an experience felt when they are browsing. So we all know that with a UDP without encryption, we expect it to be fast. But what happens when you introduce the encryption? So, basically, we are looking at DOQ and DOH three. And the main thing we want to find out is do users actually experience performance differences due to any encrypted DNS enhancements. So the research looked at three core questions or was trying to answer three core questions. How ready exactly is DOQ and DOH three deployments for production use? And in specific because we are looking at DOQ and DOH three, we are actually looking at how they implement QUIC in in the protocol. Then the second thing, we wanted to see how the web performs when you have or the web performance when you have encrypted DNS. And, also, we also wanted to look at the impact of complexity when you have on on web complexity when you have encryption. And so, basically, what we are trying to answer is what is the performance penalty of encrypted DNS on user experience. So the measurement campaign proceeded in four phases. So we did the setup where we had basically, the scan the initial scans were done using ZMaps for I p I p v four and a heat list for IPv6. The second phase, we had the resolving of the measurements. So we looked at the RTT, zero resumption and zero RTT, both for DOH three and DOQ. Then we looked at the web website performance. So basically, here, we move from large scale measurement to actually real user experience simulated, so to speak. Then we have a website complexity analysis. So these are the measurement values. We have 3,000 plus DOE resolvers, 75,000. DNS queries, about 1,900,000 page loads, and about 570,000 websites which were accessed. So we our first major finding has to do with DOQ deployments, and we noticed that they are, in essence, more mature, if I may use the word, than expected. So when we look at the values we got in terms of DOQ and DOH three, we actually see that from the data that we collected, DOQ performs far much better than DOH three. So in terms of session resumption, we got 94% actually show that they actually have session resumption, 65% on the other hand for DOH three. And our DOH three measurements did not show support for we did not observe zero RTT support. And due to q median latency was much, much lower than due h three. So in essence, one of the things we noted with due h three was that we had about three hundred and ninety one failures, which was about seventy percent of the data which we collected. Then we also noted that from the d h three dataset or portion of the dataset, there was about eighty five percent, which was attributed specifically to AdGuard resolvers. And this had a major impact on the results of the DOH three values. Our second finding was that resolver deployment matters more than protocol choice. And this I will explain further. When we look at the results that we have, it's very clear that, number one, I need to mention this, that we actually looked at how the resolvers work in separate. And we also had a small subset of resolvers, which is what we call the all resolvers, where all three protocols, UDP, DOH3, and DOQ were implemented. And what we noted is that when we look at that small subset, they outperformed all the others when they were looked at separately in general. So one of the observations we make was that DOQ in general was much had much lower average RTTs than DOH three, but, of course, not as low as UDP. Then we also noted that, and this is very important, that multi protocol resolver deployments actually outperform single protocol deployments. And then the third thing we noted was that the AdGuard resolver outliers resulted in a long DOH3 long tail. So we also noted that 95% of the DOH 53, the UDP resolvers that were in the intersect sublet, so the subset that was had all the protocols responded in less than thirty sec thirty milliseconds, which was really good. We also noted that the subset DOQ outperforms average DO 53. And this is very clear when you look at the graph. It shows that QUIC, which has which is under the intersect resolvers, actually performs much better than UDP. Actually quite clear from the from the graph. And then the question then is why is it simply because the multi protocol resolvers were outperforming the single protocol deployments? Then the third finding we found was that encrypted DNS has a negligible impact on user experience. And this does not mean that page load time is negated. But what we actually look not page load, but DNS querying time. But what we're actually looking at is what's the difference when we once the DNS query is complete, does it affect page load time? And we can actually see there's barely any difference. So whether it's UDP or DOQ or DOH three, it didn't matter. The difference was very minimal. And the time difference, in essence, was less than plus or minus 1%, so two to sixteen milliseconds. And in essence, we actually can say longer DNS lookups does not necessarily result in slower web pages. Then the question would be why? And the simple answer is because browsers actually perform there's some browser parallelism which actually hides the DNS latency. So as the DNS lookup is going on, various aspects of the page are being loaded. Then the final finding was that website complexity does not actually amplify the DNS overhead. So for this, in terms of website complexity from our data set, we had about 572,000 website websites which we looked at. Each had about, on average, a median of 1.2 megabytes, loading about 42 median objects, contacting about seven DNS servers, with five of them on at a median being external with a median page load time of zero point nine seconds. And what we noted is that of that time, only about twenty five to ninety three milliseconds were actually attributed to the DNS query. So this is really small, and the user will not even notice that. And we also noted that in terms of complexity to performance correlation, there's about a negative sorry, a 0.45 correlation or less. And we would actually say statistically that there's a weak to a moderate correlation, but it has a very little impact to the user, as you can see from the actual values. And also, similarly for the MIME type correlation was about negative 0.2 to 0.3. So, similarly, we can see that those are very weak correlation. So, in essence, we say that website complexity increases overall page load time, but it does not have a relative cost effect. It does not necessarily mean that the encrypted DNS impacts the page load time. So what takeaways do we get? Number one, we say that deployment in terms of comparison, DOQ would actually perform or does actually perform better than DOH three. We also see that the protocol in terms of performance, multi protocol performs better than a single protocol deployment. And lastly, user experience is basically is negligible impact because of the encrypted DNS. I do have one more slide, but because time is over. Yep. We got it
[01:22:37] Shyam: all set.
[01:22:38] Newton: So where do we move from here? So from that work, we are actually currently looking at DDR deployments. We're looking at various aspects, but one of the very interesting things when we're looking at the DDR deployments is that the very same results we saw that DOQ is actually better, but DOH three is being deployed. Moise actually there. We can actually see from the dataset that we currently have collected that Duque is barely being implemented by major major providers while d o h three is implemented. D o h two is implemented. D o t is implemented. And this is the same across I p v four and I p v six. So this is being prepared for a different paper. Currently, we are working on it. So this is what I would say is currently ongoing works.
[01:23:28] Speaker 1: I think that should be it.
[01:23:31] Dave Plonka: Alright. R z, Rob.
[01:23:33] Lars Eggert: Hi. Larsen at Mozilla. One of the things I do is I help run the TRR program, which is when Firefox uses the door server. And I think what you've done here is is nice. Right? You have a nice setup to to measure these servers. I think the the flaw is that you scan the Internet to find them. And so you're finding a lot of small servers on questionable links, and then you probe them. And and those are not the servers that the vast majority of clients are actually gonna choose. So, for example, like, we see DOE resolution times of of ten to fifteen to twenty milliseconds, and anything above that, I would consider broken. And yours, like, was 80, and you and you had a p 95 of almost a second. Right? So and and and as you see on this slide, like, there there's actually no DOQ deployment by any of the large providers. Right? And so I think the statement that DOQ is mature and and faster than DOE is very questionable. It'll be interesting to see what you find. So I think the methodology you use is fine. I think you're just applying it to the to the wrong set of servers. We have a bunch of measurements from Firefox telemetry. Was a talk earlier. There's there's dough measurements in there that we can talk about. So so I think the the methodology is great, but that the set of servers you're applying it to is is questionable, and therefore, results, I would be careful with. Thank you.
[01:25:01] Speaker 1: Okay. Thank you. I'll take that.
[01:25:05] Lorenzo Colitti: Yeah. Lorenzo Claudio, I would I would second that. If you if you just ask them random servers that you find on the Internet, you won't get, you know, performance that is comparable to what an actual deployment is. So I think I it it looks like you've built some really cool tooling for measurement here, and I would love to see the results of this tooling apply to actual DNS servers that you can find that are intended for use. Because these DOQ servers, I don't know what they are, but I don't think they're, you know, expected to be used by users. So if you point these at, for example, various I if you point your tooling at various ISP servers or maybe the well known ones that you have here on the slides, I think that would be very interesting. For example, in Android, we decided not to implement DOH2 at all because we think it's going to be slower than DOE sorry, DOU, right, because it has connection establishment overhead. And that would be really good to see. So if you could take your tooling and look at the popular DNS servers, which are deployed close to users and so on, they're to be used and they're intended to be high performance, it would be still very good to see. Because on those, you'll see and, ideally, you could compare within each resolver, you could compare how the different protocols go. That would be very interesting to see. Whereas I think, like I said, the the data like Laura said, the dataset that you have is kind of flawed because of the these servers are probably you don't know what they are in. Anyway, I look forward to if you do that, it'll be very interesting to see.
[01:26:38] Speaker 1: Thank you. Thank you for the comment.
[01:26:40] Eric Nygren: Eric Nagrin, clarification question. So when you're finding these, are you confirming that they are recursive resolvers, not authoritative servers? Because at least some of the people planning to deploy DOQ are deploying them as authoritative servers, which is a which is a very different, footprint and use case, than the recursive servers that are doing DOH three. So I would expect them to be set up fairly differently, but would not mirror the behavior you would expect for a user resolver.
[01:27:09] Newton: Am very sorry. I barely got what you said. You checking
[01:27:13] Robert Story: if these are user facing results? Are these first resolvers that actually are used for users? Are they checking it at some?
[01:27:21] Newton: I'm not sure, really. I'm not sure. Okay. I don't know if I'd say yes or no. What I suppose was that from the dataset, what was collected was what was then analyzed. So some could be fast resolvers. Some could not be. It's highly likely.
[01:27:42] Eric Nygren: Specifically, authoritative servers versus recursive servers.
[01:27:45] Newton: One of the things the paper in the paper they were trying to do was look at the connection between authoritative and recursive. So there was a portion where it it it was considered, but eventually, in the analysis, they looked more at DOQ, DOH three as opposed to looking at the authoritative versus the recursive.
[01:28:07] Eric Nygren: Oh, I mean specifically because some because many of the DOQ things you're gonna find are authoritative servers implementing DOQ. Uh-huh. Because I think the the use case for DOQ or the primary use case for DOQ is not for recursive servers. It's for authoritative servers
[01:28:24] Speaker 1: k.
[01:28:24] Eric Nygren: To implement DOQ. So that might be a big part of the skew you're seeing.
[01:28:28] Dave Plonka: Alright. Thanks, Eric. And thanks, Nelson. So you've got some good hints about characterizing the the the resolvers for that next paper. Thanks for bringing this. Sorry. I had to kick Tim and Jason out of the queue. We promised fifteen minutes each to the next two speakers, and we've got about that much time left. So next up, we got Chaim. If you could come up, his work is detecting and characterizing exposed BGP routers. Both these are published papers. I'll share the link in the chat comments.
[01:29:00] Robert Story: I
[01:29:03] Dave Plonka: can I'll put the timer up.
[01:29:10] Shyam: Alright. Alright. Hello, everyone. I'm Shyam, a soon to finish PhD at University of Toronto. Today, I am going to talk about our our work on exposed BGP routers. In this work, we ask just simple questions. How many routers that run BGP, which stands for border gateway protocol, on the Internet are exposed publicly to the Internet. We may all know that BCP runs on port port TCP port number one seventy nine. So realizing the importance and criticality of BGP, RFC seven four five four recommends to restrict that port to its configured peers only. Slow. However, there are there are many routers in the Internet which accepts TCP connection from any host on the Internet. They accept BGP open messages from them. For your note, BGP open is the first message that a router sends after TCP connection is established. Then those routers respond back to those host with their open messages followed by notification message or just notification messages. If it is an open message, it reveals or it contains many useful information such as AS numbers configured in that router, VGP ID, which is also called as router ID configured in that router. If it is not, then in the case of notification message, it simply tells the initiators to terminate the connections by sending notification message. In our study, we define such routers as exposed routers. Now to detect such routers, we developed a tool and named it as scan one seventy nine. So the first step of such detection is finding the potential routers on the Internet. Since there is no complete and authoritative list of BGP routers on the Internet, we used ZMap and scan port one seventy nine in the Internet. That gives us the potential routers that are running VZB. Then the next step is we created a custom VZB speaker that contains s number of our institute, BGP ID, and many other necessary things that are compliant with BGP's RFC four two seven one. Then we say that that custom BGP open message to all those one seventy nine responders. Then we collect the responses from them, analyze them, and find find their route find the corresponding routers, AS numbers, and many other interesting features, which I'll discuss later. And it was one such Internet wide IPV four measurement. Let me present our finding in a high level. So we found around 6,250,000 IP addresses that responded with g map scan for port one seventy nine. And we found three main categories. If you see in the leftmost leftmost side, five percentage of them were BGP responders, which means they responded with BGP compliant message. And the BGP compliant message means either they sent with their open message either they sent their open messages or they just send notification messages. We found a higher number of open responders compared to notification only responders. And there are other two categories. The second category is non BGP responders, which is 86 percentage. Non BGP means they allowed the TCP connections to our probe, but when we send BGP open messages, they either send TCP reset or they did not send anything at all. And you see the third category, which is a pre TCP responders. It means they didn't did not allow TCP connection to our probes. So ideally, the last two categories are the required responses from BCP routers as per RFC seven four five four. Then the next step is we identified who are the ASAs deploying or managing such routers. If you remember, we had two types of BGP responders, open end notification. In the case of open responders, it's relatively straightforward. We check whether though whether those messages contains public AS number. If it is public, then that is the one managing the router. If not, then we use IP info data to map to map the interface IP to the ASN. In the case of notification responders, we we we again relied on IP info. It is because notification doesn't contain information like AS number or many other details as of open message. That's why in the case of notification, we say it's in for ASN because we cannot confirm it. Then the next step is grouping those responders IP to routers because generally a router has multiple IP addresses configured on it. So the key idea is to look at BGP ID configured in those open messages and the AS number because as per RFC six two eight six, VGP ID is unique per router in an AS number. So we used the combination of VGP ID plus AS number configured in open messages to group those responder IPs to router. And in the case of non public open ASN, it means open it means the open message contains ASN number other than public, such as private or reserve, because some ASAs use their use internal ASAs for for their internal configuration, also known as AS configurations. So it means nonpublic ASN could be used via multiple ASNs on the Internet. That's why we use the combination of VGP ID, Open ASN, and Interface ASN to group IPs to a router. Then the next step is we classified routers as internal and border. For example, in the case of internal router, we check the AS number whether it's non public. Since those non public ASNs cannot participate in the global Internet, so we can say that they are internal routers. And we define our router as a border router if it is having an eBGP pairing with another router, means having BGP pairing with router in another ASN. For that, the first condition is that the AS number configured in its open message in its open message should be public, and the second condition is that at least one of its interface IP has to belong to another s number. This is based on a heuristic that in a point to point connection between two routers, these two routers share this subnet that comes from one of those two participating ASNs. However, there was another category where where they have a public open ASN, but all of its interface IPs map to the same ASN. In that case, we couldn't distinguish its role as border or internal. It could be either IPCP pairing router or the or it could be the host AS providing the IP to its peer. So we made it as unclassified category. Here in this figure, you see the summary of our results. We found around 141,000 exposed IP addresses, which correspond to around 20,400 unique routers. Most of them are internal routers, which is 16,000, and there are around 1,127 border routers. And all these routers are managed by around 4,200 ASs. Then the next step is we measure how critical those routers are. So we measure criticality by distinguishing again two types, border and internal. In the case of border router, we we use how many we use the connected ASAs as the metric for for criticality because instability of that border router will affect the connected ASAs. As you see in the figure, around 75 percentage of border routers were connected to only one ashes. There was an there was a border router which connect which which connects to 21 ASES. So you can imagine the criticality of that router. And for for internal routers, we use we use number of number of IPs configured as a heuristic to measure criticality. It is because number of IPs means number of subnets. So higher the number of interface IPs, higher the subnets, and the instability of that router affects that many subnets of the router. And you see that 60% is have one IP and 90% is have fewer than 10 IPs. And we found that 10% is of internal routers with maximum up to 1,208 IP addresses. There are many other interesting results which which you can read in our paper. So to to summarize takeaway to summarize our work, we found a nontrivial number of exposed BGP routers that violate RFC seven four five four. And there are there may be multiple reasons for such exposure. We also investigate into those routers. For example, we talk to one operator who thinks that having extra protection for TCP one seventy nine is not necessary because RFC as per RFC forty seven one, sending notification only message is sufficient and other operators, they think that there was really a problem and when we informed them, they were happy to fix their routers. And the other reason could be the routing stack of BGP routers where where the where that where the peer check happens after the TCP connections is established. So so I expect more reasons from the audience in this group, and you can read more in the paper. And as a final note, since I am a final year PhD, and I am in the job market, so you can check my personal website if you are looking someone like me. Thank you very much for listening to my presentation.
[01:42:22] Dave Plonka: Thanks, Lashayam. Any comments or questions? Alright. The we got one more paper coming up.
[01:42:31] Shyam: No question answered?
[01:42:33] Mirja Kühlewind: No. There's no question.
[01:42:34] Shyam: Okay. Thanks.
[01:42:34] Mirja Kühlewind: Yeah. Please please read out. Reach out to them.
[01:42:42] Dave Plonka: And, Brima, you can come up.
[01:42:51] Ibrahim Morah: You wanna hold it? I think I can put it here. Let me try this.
[01:42:55] Robert Story: I think it's yeah. Push it like this.
[01:42:57] Dave Plonka: Yes. So this is another published paper and another fifteen minute segment of the meeting about route views data. I happen to be working with the Open Science Data Federation. This data is also not just available through route views now, but it's also available through Open Science Data Federation. And your topic is particularly timely because it's about kind of how much chaff is there in the BGP data that's there. So go ahead. You got fifteen minutes.
[01:43:26] Ibrahim Morah: Good evening. I'm Ibrahim. I'm also a finally a PhD student at the University of Toronto. So this work was a joint effort with was a joint effort with folks from Takeda, Casey Klaffey, Thomas Krenk of IIJ, and my supervisors from the University of Toronto. So, generally, like, we have a subset of ASCs like the previous presenter mentioned. The Internet consists of different ASCs, and then a subset of these ASCs called RAG collector peers dump their information to collectors. And this data is really essential for both operational and research purpose. For instance, operators use this data for monitoring their traffic and also for troubleshooting or traffic engineering. And researchers like myself use the data to have a better understanding of the Internet ecosystem, for instance, like security research, operation management, and the likes. So, typically, routers should only trigger updates if there are configuration changes. For instance, newly announced prefix, withdrawn prefix, or a route failure. So looking at this simple topology, we have a s x and y, and they announce each announce a prefix to a x z, which is a collector peer. So in a s z's rip, we have these two prefixes and also from the the the origin ASZ. So at the end of five minutes, if the route collectors collect this data, we expect to see a single copy of these routes in those route collectors. So I don't know. Unfortunately or interestingly, like, buggy routers or misconfigured routers could lead to not a single copy, but many copy. For instance, taking the same topology again, let's assume router six of s z got noisy, and for some reason, it just continuously send whatever it is in its rip. So at the end of ten minutes, instead of having a single copy of that route, we have 51 copy of exactly the same information. And this is a problem, of course, for both operation and also for researchers because we are having a single copy of the same information that doesn't tell us any new information about the route. So our motivation last year around 2,000 on, February 2025, an email show files in Nanook mailing list complaining of few prefixes that were unnecessarily, like, generating a lot of updates or announcements. And also, Ripe NCC, who also, like, run a collector peer sorry, a collector project, which is the libraries. One of their operators, sent, like, wrote a block, a a ripe, a large block, where they kinda emphasize the importance of libraries, but also talk about the pressure that they have in terms of storing this data. Aside from that, if you look at the there were some folks who did some research in, in Strasbourg, and they sent a survey to researchers to ask them if they have challenges processing this data. And you can see a large amount of respondents actually acknowledge that they have the challenge of processing this data. So our main objective was to kinda look at the makeup of this route collector data, specifically for route views. So to put something into context, noise can be a bit controversial, but in our study, what we mean noise is that if we receive an announcement from a prefix within the space of, let's say, one minute without any change attribute, we consider that noise because it's not just giving us any new information about that route. And this of of course have a problem, like I said earlier, it increases router processing load and also unnecessarily inflate these MRT files that are used by researchers. So to to kinda look at this, what we did was look at more than, like, a decade of data from route views, which consists of, like, 2,600,000,000,000 of updates, both announcement and withdrawals. Considering that we cannot also dig deeper into over a decade of BGP data due to processing reasons, we use, two months of recent data, which constitute of, like, 83.7 one seven billion updates. So our first goal was to kind because route views were different kind of collectors, our first objective or, like, goal was to measure the distribution of, like, updates across all these collectors that are run by route views. To do that, to summarize our methodology, what we did was, like, we count the daily update counts for each collector, and then we we aggregate this into six months, like, let's say, bin o interval, and we complete the average and rank these collectors based on this average, then decide which are the collectors that are really contributing a lot of data, and then we aggregate the rest. So looking at the results here, on the y axis, we have the update count per collector, and then on the x axis, we have the dates from 2012 to recently. So out of the statistics collectors, like the top five collectors contributed over half of the data that is collected by route views. And if you put this into context, out of these top five, only Perch and Links collector contributed over 30 like, almost, like, like, over 30% of the of the data. And when we look at this, we found out that most of this data were repetitive announcements with very few withdrawals, telling us that this is not new to sorry, this is not due to the changes in those routes, but for some other reasons. And we found out that, like, let's say, over one third of the disk collectors were each contributing, like, just about 1% of the data of route views across 10. So specifically during this time, like, the port collector happens to be the collector that collects the largest routing event ever in 2021, which is like 3% of the over a decade of data. So the main takeaway here is that update distribution across Redwood collectors is highly skewed, and somebody might be saying maybe this is due to the peers that are that those collectors have, but we look at this and then it's not that is not the reason. So now that we know that, of course, out of these 36 collectors, not all of them are equal in terms of the objects that they're collecting, we wanted to look at, is this due to the peers that these collectors are having or some other reasons? So to do that, we construct a daily update time series for each collector peer peer, and then we run this on each day because we wanted to know the heavy contributors. So in each case, we put these collector peers into quantiles like the top 5% to the lower 50%, and then we we determine or we quantify the top contributors. So looking at our results again, on the x axis, we have the total updates per day. And again, on the y so so on the y axis, we have the total updates per day, and on the x axis, we have the dates. So during, like, over decades, out of 2,600,000,000,000 updates, like, we only have the top 5% collector peers, which on average is just about 16 peers per day, contributed over 50% of the data across the whole ten years. While the lower 50%, which on average is about 160 peers per day, contributed just like 5% of the data. So this tells us that out of the peers that route views is having, we have very few peers that are dumping a lot of data to the collector. So if we drill down into this few collector stop sorry, collector peers that are unnecessarily noisy, you can see a very interesting patterns, and that is we have noisy peers across the whole ten years. Sometimes, this peer will be noisy and went quiet, and the other one comes to be noisy again. So the key takeaway here is that noise in BGP data, or at least for our views, is both prevalent but very unpredictable for the simple fact that a collector could be noisy today, and in maybe one week time or few days time, it went quiet, another collector will be noisy. So now that we know out of the peers that Radveals have, not all of them are noisy, we wanted to also dig dig deeper within this noisy peers or all the peers to see if this is driven by just a few of BGP sessions, prefixes, or AS parts.
[01:52:47] Shyam: So to do that,
[01:52:49] Ibrahim Morah: what we did was we compete per minute of this year for each BGP session over the two months, and we use some statistical methods to quantify concentration and variability, and concentration here help us to kind of quantify the dominant sources, meaning sessions and prefixes and AS parts, and variability help us to kind of determine the fluctuation of updates across the sessions, prefixes, AS parts. And we apply the same methodology also to prefixes and airspots. So if we look at the results here, again, on the y axis, we have the permanent update set for session, and on the x axis, again, the dates for the one month. So we found out that only 19 session, which is just 2% of all the sessions we found in BGP data, constitute of, like, seventy one percent seventy one point three percent of the updates for the month of December 2021, whereas a huge amount of the sessions were just very quiet during this time. So we found the largest routing event that we mentioned earlier happened in during during this time. We found it lasted for, like, from almost about twelve hours, and then this leads to a large MRT files. And when we pass these MRT files, we found almost like a complete routing table, which is like a 730 k unique prefixes, and in each of these files, we were having around 32,000,000 updates. So what we speculate or assume is that there was an router that was continuously sending whatever it is in RIP. So this the, the main takeaway there was that out of all the sessions that we have within those noisy peers, there are just a few sessions that were unnecessarily noisy. So if we apply the same methodology to the prefixes, we just have the top 2% of the prefixes that account for, like, 74%, like, almost 75% of all the updates within this during this point, whereas the remaining prefixes were mostly quiet. So the key takeaway is that noise in BGP data is both prevalent but very unpredictable. You cannot know which peer is will be noisy today or tomorrow, and it's mainly driven by a very few set of peers. Also, have few sessions, prefixes, and AS parts that contributed large amount of updates which are mostly redundant, because they're not telling us any new information about route to those prefixes. Also, prefixes are not universally noisy. It is often confined to a few collectors. For instance, like, oftentimes, in the literature, they call prefixes or origin s is noisy. But in this study, we look at it, which found out that a prefix could be noisy from one vantage point and not surprising from the other vantage point. So we out of these findings or observations, we conclude that these noisy prefixes are mostly due to faulty or misconfigured routers and not inherently from the origin test that originate the prefix. And all these redundant updates, it just unnecessarily inflates MRT files without giving us any new information about the routing state of those prefixes. So we found all these interesting things from the data, but it's still difficult to kind of quantify what is the root cause of this behavior, aside from communities and route flapping. So, we seek feedback from the operators who can help us to kind of validate if they observe this kind of behavior in BGP and what could be the reason for some of this observation. So you can read our paper for the full details. And thank you.
[01:56:48] Mirja Kühlewind: Yeah. Thanks a lot. So for both this and the previous paper, please, if you have any insights, reach out to the authors and get in touch with them. But thank you for presenting. It looks like we don't have any questions. Okay. So that's the end of our scheduled talk, but we have now Tom in the room who where we showed the one slide about the I p v six data in common crawl. Tom, do you want to come to the mic and see something? We have a minute left for you if you want to.
[01:57:19] Dave Plonka: Three minutes.
[01:57:21] Mirja Kühlewind: Yeah. Actually, three.
[01:57:26] Tom Vaughn: Hello. Yeah. This is something we did last month to measure how actually accessible things are over v six. So we did this at the beginning of the year from one vantage point in California, and we did it on the top 100,000 hosts ranked by Harmonic Centrality. And we decided to do it again, but on the top 1,000,000 hosts, and also from five different vantage points in three different continents. And the results are basically nearly the same, like exactly the same, which is
[01:58:07] Newton: kind of
[01:58:07] Tom Vaughn: embarrassing. But anyway, it's it's helpful, I think. But, yeah, there's a report, like a full report on the thing in that QR code in the top right corner. But also, nicely, my colleague Sebastian at Common Crawl is pushing an update to this thing called CC statistics, CC crawl statistics, which is a thing that we push after every crawl that we do. We are now going to include plots of metrics, comparing the counts of things like HTTP protocol versions, TLS versions, and IP versions. Happy to answer any questions if there are any. But if not, cool, and enjoy.
[01:58:58] Dave Plonka: Thanks, Tom. I have a a quick question. One of the things I've been interested in is how much the the largest content deliverers play a part in I p v six content being available. With the what the data you have, if you haven't done it already, maybe you haven't even looked in in detail, can you tell, for instance, like, at the Cloudflare, Akamai, whoever if somebody uses those to host their stuff from their origin, how much are those players bringing v six content to us? Is that something we can find?
[01:59:30] Tom Vaughn: Yeah. You can kind of find that. There's, like, a nice plateau of Cloudflare content in the original report. Actually, you go to that report, it's the top link that shows you this nice chart of that stuff. But I mean, it kind of it it varies from CDN to CDN. Cloudflare seems to be pretty good at it, as in pushing basic support. Fastly is also pretty good at it. But, yeah, you can you can see that from the results
[02:00:04] Dave Plonka: Thanks.
[02:00:04] Tom Vaughn: From the data
[02:00:04] Dave Plonka: as well. Some of that came from their default policy. Right? They I think they got earlier into it was on by default.
[02:00:10] Tom Vaughn: Yeah. It seems so anyway, unless, you know, by some crazy chance, like, millions of people are going, let's turn on v six, like, deliberately. That'd be nice, but, yeah, I don't know how likely it is. Well, thanks so
[02:00:25] Dave Plonka: much for closing our meeting for us.
[02:00:27] Tom Vaughn: Yeah. Thanks, Dave, and thanks, Myriah.
[02:00:30] Mirja Kühlewind: Yeah. Thanks to all the presenters and everybody who asked question was in the audience. That's the session. Thanks.
[02:00:48] Dave Plonka: Well, that was good. Yeah.
[02:00:50] Robert Story: It was It worked very well. You can start squeezing to me.
[02:00:54] Oscar: Yes. Wish I would have looked