`Main room 11 am
.
Closing Plenary
RIPE 90
.
BRIAN NISBET: Good morning. Welcome to the Closing Plenary session of RIPE 90. Take seats, or take conversations outside, whatever works best for you which doesn't involve chatting in the room.
Anyway, welcome, I am Brian, and along with Max, we will be chairing this Closing Plenary session. So a couple of things to talk about before we move onto the excellent lightning talks that we have.
First off I am going to do the announcements at the beginning because at the end of this session generally gets a little bit fluid. So just to remind people that the RIPE NomCom will hold their office hours during the second half of the lunch break from 13:15 to 14:00 local time. It's the room on the first floor to speak in person to the committee.
And the other thing is just the, also you can still share feedback on ICP‑2, we could talk about it again but it's been mentioned once or twice this week, but you can share feedback on ICP‑2 from 13:30 to 14:00 at the meet‑and‑greet desk as presumably the entire meeting is torn down around you in a sort of Miss Saigon sort of way.
So, what else, we have one more election result to announce. And just to say that the result of the PC elections, so two spots, and both Clara Wade and Amedro Beck Peccoz were elected.
(Applause)
So, thank you so much to everyone to put themselves forward, we hope that you will continue to do so, maybe think about standing again in the future because it's really important to get people in to the PC to do all the important work that needs to be done to build the meeting. And of course, do rate all of the talks, so the PC can understand what you would like or don't like for future meetings.
So, I think that's all of the administrivia. And the bell has happened now so lots of people have come into the room, which is all good. We will move on it the meat, the content of this meeting and we have our first talk.
ONDREJ SURY: Hi, so, first of all, the algorithm isn't my work, it's work of young searcher, she is post doctorate at the EDH in Zurich, I don't want to be a man taking woman's work for my own, I implemented this in BIND.
.
So, LRU, least recently used algorithm. This is software engineer talk but it's interesting research so don't run away.
If you have a cache and there is a cache miss, you just evict something that's at the end of the queue or buffer or whatever, and put it at the beginning. That's the normal LRU. On cache hit you just move it to the beginning and you go on. This is the disadvantage that for both of these operations you need to lock the list which comes, holds the other threats or other processes that wants to use the same cache. For the SIEVE, on the cache miss, there is this algorithm that just ‑‑ there is a little hand, it's called SIEVE hand, and it looks at the space in the cache, and the yellow one is like visit the flag. So if it has a visited flag it unmarks it and moves on. And if there is not a visited flag, it just evicts it, same as LRU, and it is locking and it puts the stuff at the beginning of the queue.
However, on TTL cache hit, it just like raises the flag, you know, so we are trying, there is a request A and we already have A in the cache, so we just raise a flag, which means we only log the individual item. It doesn't have to be even locked, it could be operational or something like this.
What's the effect of this? By the way there is a long video of how this works with more examples on the algorithm web page with ‑‑ I invite you to read. Because this is like lightning talk and I don't have much time.
So, it has these two properties. Lazy promotion. So, it only promotes the cache objects at the eviction time. So it delays it to the last possible moment so it doesn't slow down the, like the fast path. And the other thing that's important, the other properties, quick demotion, so, it removes not like objects that has been inserted, quicker than the one that's left in the cache for a longer time. These are both ‑‑ there is a paper on this, and this is really like exciting research.
So what's the effect?
So, I did an implementation in BIND 9, and as you can see, well it's much shorter than it was before, so, I only like added 144 lines but deleted 400. So the algorithm is simpler, and much more efficient. So this is BIND 9. This is our test lab. If you haven't been to my other talks, I'll just explain what this means. This is reverse algorithmic graphs. So basically you want the lines to be S to the left and as to the down as possible, because in the Y axis there is seconds, and on the X axis is the reverse algorithmic percents, so which basically means that the straight line at the bottom is stuff that has been answered under 1 millisecond, and for the orange one, that's the original are algorithm, the original RRU, you probably don't see the numbers but there is a little .7, number 7 at the X axis, which means that 93% of the queries were answered under 1 millisecond and go on. So, at the top there is like it matches the number 1, which means that 99% of the queries were answered under 2 seconds. But as you can see with the new algorithm,s with the very small cache, like 128 MEGS is not a big cache for DNS, you should not run DNS with such a small cache but you can. It just pushes the limits to even further. So, 99.6 percent of the queries were answered under 2 seconds, and 96 percent were answered under 1 millisecond, to there is like 93 versus 996, there is like 3% difference just by changing the cache eviction algorithm alone. And this is called cache. So, there was nothing in the cache in the beginning. For the hot cache, wow, the effect is even stronger for the small cache.
Again, you know, you want this to be as to the left and as to the bottom as possible and I think this shows the good the algorithm is for the DNS caches.
.
And the memory effect, again, it helps this is the CPU, as you can see the orange one is the original, it was spiky, we were doing a lot of work evicting stuff from the cache, now it's like more ‑‑ it's less spiky, so, it means that the CPU is doing less work in these cases.
For the the normal cache, there is a little bit effect because there is a little bit less locking even on the, even when you are not doing the cache eviction because it's not needed because we didn't fill the 30 gig in it test, but there is still some small effect that helps with the normal operation, so the hot path is doing less stuff and there was a cold cache, this is the hot cache. For the hot cache there is no difference basically.
The memory, CPU.
So, what's good about this algorithm, it's not like something that you just exchange RRU, there are a lot of ‑‑ if you dive into the field with a cache eviction algorithms, there is a lot of them and you can actually use SIEVE to help even those other algorithms if you replace some of the internals of the other algorithms with ‑‑ from LRU to SIEVE, it helps even them. So, this, like this could lead to even better algorithms in the future, but the algorithm itself, the simple one is much better than the original LRU.
The one thing that it's not suitable for everything, because it's not scan resistant, because when you like raise the visited flag every time you visit and if you scan everything then you set a visited flag on everything and then, you know, the algorithm doesn't basically work. But there is some, there was some talk about how to solve this, like not have just flag but a counter and stuff.
So, there is an option to have like future research in this area, and this is it.
(Applause)
.
And the applause really goes to the algorithm author, not me.
AUDIENCE SPEAKER: Shane Kerr. Did you measure cache hit ratios with this? Because it changes the heuristics, right?
ONDREJ SURY: Well it's the same dataset, so ‑‑ well ‑‑
SHANE KERR: I mean you are picking a different thing to evict. So, it might be better or it might be worse in terms of the actual usage and ‑‑ you ‑‑ I mean, I didn't see that measure.
ONDREJ SURY: But basically this means that more stuff has been answered. So, we don't have the metric to measure the cache hit ratio, but I think we can deduce from this and this that the cache hit ratio is better because there is less outgoing queries because you answer these from cache, because they are much faster.
SHANE KERR: It's a plausible explanation that I would like to ‑‑
ONDREJ SURY: I get your question but we don't have that metric but I think we can deduce from this that... yeah.
MASSIMILLIANO STUCCHI: I don't see any other questions, and we are running out of time. So thank you.
(Applause)
.
Next speaker:
ALEX SEMENYAKA: I have some questions for the audience and I rendered them a presentation. It starts a couple of months ago when Google announced that they added a native Linux terminal to Android to this pixel devices, and I had exactly such a thing so I decided to take a look, and how it looked like. We have to enable this option, install the Linux terminal, and it was just a normal Debian. So I decided to take a look a little bit deeper, and I found this environment, whereas with a lot of functions are available in, you know, a virtual state. It's like a virtual machine inside this guy. And it's not the only possible thing. It's a whole framework to do such things on the modern Android. But with this terminal, obviously it was possible to create ros rockets, to play with it a little bit via the network, so, I decided to hit some craziness and to check if it's possible to install the Atlas probe on this device. And I went for the standard process It was easy, it took like three minutes and I found yes, I can do it. And actually, you know, I had a lot of discussions for the last five, probably five years, with, you know, different team, who were interested in, you know, such a thing, in the mobile probe, and actually ‑‑ sorry, it works. This is my probe. I am brave enough to show the probe number because I am going to shut it down. But you can check, you know, the geography for example, yesterday it was France because I am using the mobile Internet from French Orange. But, yeah, the day before it was still Lisbon.
So, all these discussions went to this section on our site where we are expecting that we are not supporting such things and we will not. However, to be honest we are living in the mobile world. That's true, and probably with 5G we will have less these home devices and more different, you know, mobile things, and I decided to reflect a little bit on what's going on here. Actually right now, we had the big decision, it was completely fine and correct like five years ago but, you know, right now we already have some experiments for that, for example in Rotterdam my friend from Paris gave a talk how they installed the software probe on to a Linux notebook and they did mobile research going through the central Asia and makes different measurements in different places.
So, it's already here. And basically, we are losing the capabilities from mobile world like number of mobile devices and different pieces of information like GPS, GPS is not available in this virtual terminal for example. So, people will probably still do something under the table, which is not that good because we have contaminated data, we don't know how to interpret them in a proper way. And simultaneous, we have, know this additional information that can be useful for us.
.
So, I decided to ask the question, do we need to go this direction? Is it doesn't mean that I am proposing to go this direction, I mean that it's necessary to think about it, but think about it with, you know, all aspects in mind. And some arguments listed on that page, most like better (inaudible), that's a completely valid point but it's probably not necessary for such and I think this, it's not necessary to run probes all the time and have a permanent connection probably with everything, interaction with controller, and use different strategy and probably user can choose among them. So, it's not a huge issue, it's still important thing to remember, but it's not a showstopper.
And of course this data, because you know it can be connected, as I said, it was connected to this network and it was in Lisbon, then it was connected to French network, it was in Paris, so this, obviously these things should be treated completely differently and it it mean might be that researchers have to explicitly ask for this set of probes to use them and they should not be, probably should not be mixed with other probes. It might be, but, you know, here it's again something to think of. I mean it's not a showstopper.
And we have the toughest part actually: How to relay that, because using this low level thing with a non‑virtual environment is not that easy and Java does not support it. So, either we have to go for the bundle applications, and it means that we are losing a lot of parameters we have now in RIPE Atlas probe because bundling applications does not allow such an amount of parameters, where we can go for the combination of something virtual binder and non‑virtual binary. Binary will do this packet stuff and the second part will take care of everything else but it's quite a difficult architecture. And the last option go for native development GIT, which is really, really hard to use but there are some guys who tried and succeeded, for example, developing native traceroute for Android. So we can use their probably their code a little bit. But it's still not easy, and there is a lot of work.
So, I gather some pros and cons. First of all as I said I don't want to be tracked because I have this mobile probe, probably if you go this way and the way to gather data and provide the.results for researchers should be completely different in some aggregated style without any probe IDs, of course, and the parameters we can use probably will not be that reach, as we used to have. And we should not expect that one probe will provide a decent number of results. It will be results from different probes and they have to be treated correspondingly, so it's not that easy, but from the other side, we will have the such information as GPS, so we will be able to geolocate networks for example in a direct way that what Google and Apple are doing all the time but we have no such capability and it might enrich our data and we can add a LAC, and so on, so it might be really useful for different research, simply it can open our, for us the opportunity to cooperate with mobile researchers and mobile operators and maybe even ‑‑ no regulators, I'm not sure about this, but it might be. And, you know, with the number of these devices, much larger coverage can be provided.
So, pros and cons and if we go this way, it's a lot of work. It's extra money. And probably it's reasonable to, you know, volunteers to jump in and to help that, to develop that, because you know it's completely different world for Atlas team. So, just presenting what I have in my mind, that's it. You know, if you have any opinions, probably express them in our mailing list to continue this discussion and to make, you know, decision well grounded.
BRIAN NISBET: Yes, thank you.
(Applause)
Please do engage on this. There is no time for questions here though unfortunately. So...
.
To move on to our next speaker.
ANNA WILSON: Thanks Brian. Maria Farrell's talk on rewilding the Internet was the perfect opening for this meeting, wasn't it? I mean I have been hearing people talking about it all week, that's exactly what you want. And here is the thing. Over the course of the meeting, as we have been talking about things that we can do to help, I have started hearing a lot of reasons why we can't help. Company A is too big, all my friends and family use app B, we're never going to be able to prise control out of the grip of platform C. And it reminded me of a talk at a RIPE about ten years ago by someone who looked a bit like me but had a different first name and her gender wasn't quite finished yet, which touched on disruption theory, not disruption like move fast and break things, but this is about how huge unstoppable incumbents can be entirely obsoleted by competitors that are small, strange and worse.
The lesson here is there are things that large companies can't do even if they want to.
Here is of the 90 second explanation of disruption theory. I am going to talk hard drives, times on the X axis, drive capacity is on the Y axis. Clayton Christianson saw that many computers typically ran using 8 inch drives and over time, those drives got bigger and they got bigger faster than mini computer customers needed. That's good right, you want the technology to be improving faster than your customers' needs. And then the manufactures of those drives started to develop smaller, slower, five and a quarter inch hard drives and tried to sell them to their existing mini computer customers who weren't interested. Why would they use something that's like slower and crappier, maybe it's a bit cheaper, but it's not enough, it's not going to make a difference to the cost of the mini computer. Their existing customers wouldn't stand for it.
So that left an opening for a bunch of small companies to make personal computers, and compared to mini computers, these things sucked, they were trash, practically toys, you could not use them for serious work. But they bought the five and a query inch drives, it was less money in the industry, but what happened is that personal computers got better faster than mini computers got cheaper. And that wasn't a technology issue. That was a business choice. The mini computer makers were trapped into chasing higher profits her unit so they kept trying to improve their product far beyond what was useful to the customers until the PC got good enough for those customers and everyone switched at once.
That's disruption when a company gets big and profitable, there are things it becomes incapable of doing but we already know this. Because we have done it too. We're networkers, we work in layers of abstraction. Geoff Huston is here somewhere, said the reason the Internet took off is, isn't because it was the first way to send messages or pictures or even video over the phone line. It's because once you connected your modem you didn't need permission from the phone company to run any application you wanted. We built a layer independent of the layers below and which others could use to build layers above but there are more layers out there than this model.
If you haven't seen me around the last couple of years it's because I was sending some travel budget goings to software aware development events. You can learn an enormous amount about our networks by the way that developers use them of. The end‑to‑end principle at the IP layer isn't really important to them. They have their own networking model and it looks like networks of servers or containers fronted by load balancers and DDoS protection, serves client networks covered by NATs and NAT PT devices and yet because everything is layers of abstraction they have still found ways to pull off global end‑to‑end communication, innovation is still happening. I think a great example is web push, this is just a regular web standard, web page CA, with your permission, wake up device, send you a notification and then the web app in your broswer in JavaScript re‑establishes communication and you have an end to end‑to‑end link again. That is way more straightforward and power efficient than trying to maintain and always on IP connection with every device on on the planet. We don't need to fix every layer in order to fix one layer, that is literally the concept of the TCP IP. Outside of this room, there is way more layers out there than we think of in the OSI model. Web standards alone move way more quickly than anything we do. In fact, if you are not already following web talk technologies, I'd say start. Not because you are going to be programming with them, you are not going to be deploying them yourself, but so we can understand what modern applications look like and how nature network needs keep changing. The same day, last Monday, that Maria gave her talk on rewilding the Internet here, a new version of Safari came out which had an enhanced version of web push, and enhanced version of standard to make it easier to use. I got interested in all these crazy things like, you know, web technologies and aviation safety and improv theatre, because I think that the very best results what happened when disciplines crash into each other. That's a thing large companies can't do.
They have become a really amazing machine at their specific discipline and they are incentivised against following you up on things that might lower revenue.
But, I really wanted to come up here at the end of the week and emphasise this because I am going to tell you, please forgive me Marie if you are watching and I know you are, I am going to tell you the dirty secret of public speaking. It kind of doesn't work. It feels amazing standing up here and giving a talk that gets huge applause and people are talking about it. Talking isn't doing. It's very rare for someone to give a presentation that actually gets people to stand up en masse and start doing things differently. Maria talk on Monday is the closest I have seen in a very long time.
I heard the reactions in the room, and so did you. But if we spent this last week persuading ourselves that we, the people in this room, the people watching op Meetecho can't find any way to help, that is an enormous lost opportunity.
I was lucky enough to share a stage with Maria nine years and I said this for the specific things that we do, it's not just that we can help, we are the only people who can help with that thing. And any one thing we do is not going to be enough. We know that. But remember what else Maria said, building an ecosystem is not just about planting seeds, it's not just about growing your patch. You build ecosystems by connecting them to other ecosystems and there are so many interesting ways to connect ecosystems these days.
If you have something in mind that you'd like to do and if it feels hopeless because the biggest companies in the world have employed legions of really smart people to just dominate that sector, remember there are things they are incapable of doing even if they want to.
.
Start planting your garden, and then whatever you do, connect it to others. Good luck, we're counting on it!
.
(Applause)
MASSIMILLIANO STUCCHI: We have time for just one quick question, if anyone has one. I don't see anyone. Do we have any on Meetecho? No. Oh, we have a question.
AUDIENCE SPEAKER: Blake Willis. Thank you, this is super well aligned with the theme. I'd love to add to that the Internet is the only utility that became an utility by incident, it's the only utility that has somebody going where do we put the billing here.
MASSIMILLIANO STUCCHI: Thank you very much. That was really interesting.
Next up we have the Code of Conduct team giving us a report.
ROB LISTER: Hello. It's a quick update from the Code of Conduct team.
Every time I do a presentation, I sometimes learn how to make my presentation better for the next time, and what I learned ‑‑ I was going to give this update in Prague at the last RIPE meeting, and what I learned there was your presentation will go a whole lot better if you were actually physically in the room when you were supposed to do it. So, yeah, so... and of course I was sitting somewhere outside and focusing on something and then my phone went ping, Rob where are you? Of course I ran to the room to find Franziska had got up and done the presentation that I was supposed to do. So sorry for that.
Okay,
This is an update from older cases that, reports we have received. So before this meeting, there were two cases that we had open, and those have now been closed, concluded. We did get feedback from one reporter to say thank you for doing that but you took way too long, because it was quite slow for us to respond, and yeah, I think we were too slow, and I think a lot of what I can see is we're quite slow sometimes because we want to make sure we're following the process correctly and we're going sure we're doing the right thing and it takes some time, you have to talk to somebody else or wait for them to reply, so, if we go away from here and have to do things over e‑mail or calls, then it is quite slow. But we picked up on that and it's all quite new still, and we are getting quicker at responding to things, it's much better if we don't leave people hanging and we reply as soon as we can.
.
Both cases were concluded. We decided at the time that they were a violation of the Code of Conduct.
One was a violation of the yellow lanyards, the photography policy, and witness was, I suppose what you could categorise as bullying, and those have been concluded now.
So, RIPE 90: We did receive one report during RIPE 90, and we followed the process and looked at it. One team member I think, we thought there might be a conflict of interest, so they were not involved in this report. We contacted both of the parties involved. We have concluded it during the RIPE meeting. So we just made the subject of the complaint aware, and they acknowledged their behaviour, and they didn't realise that it was a problem and so they have agreed to take action so we didn't take any further action. So, yeah, if we can deal with it during the RIPE meeting, it's much faster and easier. What we find a lot is, though, people don't necessarily report it during the RIPE meeting, but they will report it after the meeting. We'll get an e‑mail maybe within two days. You know, I have now reflected on this and I don't want any sort of serious consequences but maybe you can just have a chat with this person to say that wasn't cool, can you not do that.
One of the things we noticed were voices from the community. This is kind of interesting in what people have been telling us whether they made a report or not. These are all different comments we picked up on. It was a very unpleasant moment and I just wanted to forget it. As a newcomer, I did not feel entitled to use tools and mechanisms in place.
It was unclear to me what reporting would mean in terms of exposure, next steps and to what extent I would have to share what had happened.
I wasn't sure if I will make a report.
I think someone came to me and told me that somebody had spoken to them and said oh, I have just spoken to somebody who is thinking of making a report, and what they said was: Well, maybe the moment you start thinking about that, probably you should report it.
And the last one is: Maybe because I studied at a university where there were only a few women and a vast majority of men, I am quite used to some jokes, it didn't even cross my mind to report it.
And so we're listening to all of this and we're trying to find that balance. We would like the Code of Conduct to be a little bit more visible, especially to newcomers, especially to newcomers. And it's a little bit striking that balance between being visible but not over the top visible if that makes sense, and just being present but making people aware that we're here but not being over the top with it, and I suppose I could make the analogy that if there was a small fire on this stage right now, what would I do? Would I be able to put out this fire myself, would I be confident to do that? Or I could go to the back of the room and press the big red button there and both of these things are a good option, right. Somebody else might not be confident to tackle that small fire, they maybe never had to do it before so they go to the room and press the big red button. But then maybe hesitate and think oh, I don't know what's exactly going to happen when I press this big red button, are all the alarms going to go off? Or is it one of those quiet alarms where the hotel will send somebody up quietly just to check it out before everybody... so it's that not knowing what's going to happen when you press the big red button. Both of those are completely acceptable options, but the hesitation to press the big red button, but what happens if I do neither of those things? I didn't feel confident to tackle the small fire, I didn't want to press the big red button either. And in a similar way sort of the Code of Conduct. Do I make a report? Do I say I can deal with this myself, I don't need to involve anybody, I am quite used to dealing with this myself? What happens if neither of those things happen? Maybe a smoke detector will go off somewhere. The system will detect it automatically. And that is like the community. Maybe somebody else in the community saw what happened and will... and what do we do about that? So, it is things we're thinking about, taking all of that on board. I want to think that we're not the big red button. So, please don't think of us as the big red button and don't worry about what's going to happen if you make a report because we really want you to feel, if you want to, you can. Don't think of us like the big red button, don't worry about what's going to happen if you make a report.
All things, we will take it on board and listening to. How do you report, hopefully you have seen these posters everywhere on the website and there is actually a web form you can fill if or you can send us an e‑mail. You can just go to an individual team member, if you would prefer, just to speak to one of us individually. That's fine. And we all have e‑mail addresses on there which are private to us, nobody else can see that. That's another way. It's up to you if you want to report it to the whole team or you can just talk to one of us individually.
More information on ripe.net/COC.
Code of Conduct team. Who are we? These are the people on it. We have got a new person this time, is he in the room. Theo. So welcome to Theo. And that's who we are.
We're looking for new people to join the Code of Conduct team. Randy, as we have just heard, is now elected to the Executive Board, so congrats to Randy but that now means that he will be leaving the Code of Conduct team. So thank you Randy, we'll miss you.
(Applause)
So, we are potentially looking for people. We have done, since the last RIPE meeting, we have done a bit more training with an external training provider. So we don't have to do it all on our own. It's made us a bit more confident, both to sort of on board new people to the Code of Conduct team which gives us a bit of a refresher, maybe a little bit more confidence in how we're applying the process and speed us up a bit.
Expect QR codes. Expect a very short survey at RIPE 91. We do need your feedback.
I think that's it. Any questions?
BRIAN NISBET: First of all, thank you for the work that you and all the team are doing.
(Applause)
Very, very important and I really love that analogy by the way, I think that was very useful. We have time for maybe one question.
AUDIENCE SPEAKER: Tobias. I would like to remind the community just because we have a Code of Conduct team doesn't mean that we are absolved from our duty to act when we see something to report to the Code of Conduct team and to continuously keep doing the right thing to keep the community the community we want it to be.
(Applause)
BRIAN NISBET: Thank you very much Rob. And now the presentation you have been waiting all week to hear.
ANDREA DI MENNA:
STENOGRAPHER: And he is going to speak so slowly for me!!!
ANDREA DI MENNA: Hello everyone. I am very proud to be on this side of the stage. I usually, I started seven years ago to be in the tech team, and I started like pulling cables and taping them down on the carpet. I still do that, but now I also get to report to do the presentation basically.
Last time, we were here was in 2009. I wasn't around, but I found out some things are exactly the same.
So, we got an IPv6 assignment delegated to the RIPE meetings and we are still using it. We have the same flight cases full of tape, and we still eat a lot of food.
The technical team. This is the technical team, and the event team. We work very closely during the weeks. They are a group of amazing people and many of us come from different departments in the RIPE NCC, but we come together twice a year to make all this possible.
We do some preparations in advance once the venue is decided. We start with a site inspection, which is almost two or three months in advance. That means we check the hotel infrastructure, and we look at the meeting rooms and we test the patching ports.
.
We also do an inventory just before, like a month and a half in advance, so we test all the equipment, we check that everything is still there, and we update our servers and we also ship the routers and the switch to the hotel so we can get the connection running before we come here.
So, during ‑‑ as we get closer to the event, we ship the flight cases with the courier, in the picture you can see our heavy lifters who help to load the truck. The weekend before the meeting we come to the venue and we start setting up. During the Friday, we usually get the network started running and then Saturday and Sunday we set up the presentation system and we do the last things. Usually on Sunday afternoon, we have a rehearsal to double‑check everything.
This is the list of the equipment that we bring. Fits in about 14 flight cases. We usually start with a very tidy inventory, but by the end of the week this is how it looks like. So everything around the ops room.
So this time, speaking about the shipment, we got a little issue with the delivery. The truck with our kit took a while to arrive to the hotel. So, this time we couldn't start before or work. Actually, when the truck arrived, it was too tall to fit in the parking space, so we ended up rolling the flight cases down to the ramp ourselves, and I really hope this afternoon they manage to send a van not taller than 2.6 of metres, otherwise we might need some volunteers.
Talking about the meeting infrastructure. This is how it looks like. Actually, when we got the flight cases, the setup went pretty fast, as the hotel infrastructure is really good, and their patches are all labelled correctly and they work. And so this is how it is.
So, the physical infrastructure. The hotel allowed us to place the equipment in the server room. So not this server room but this server room. You can see the switch is sitting on a comfy chair and this is the other server room, patch room.
We are looking into replacing some of our access points with something more modern which can enter more clients so we can bring less of them and still provide very good experience. However, the three new access points we got at the beginning of the week didn't give us the best experience that we are used to. They get very hot and they cause some intermittent issues with the 6 gigahertz capable devices. So we replaced it on Tuesday morning.
Those are the details on the wi‑fi networks. Unfortunately the hotel couldn't switch their wi‑fi in the conference area because they run their infrastructure over it, so maybe some people are still using the hotel wi‑fi, even if you have to type the password like 100 times a day. We still see a few people using the legacy network and we are very curious as to why you do that. So if you are one of them, you can approach us or send us an e‑mail about it.
The IPv6‑mostly wi‑fi is being adopted by other events and we are very proud of that. If you haven't done so, go look at the presentation about it in the IPv6 Working Group. There are still some very small issues, like for example the macOS content reboot from the Internet recovery. For some secure reason, we don't know yet.
Everything that we use is OpenSource technology, and you can see the details.
The presentation system. This is how it looks like. Those are the components that we bring in each room. And so the brain of the system is the HDMI switcher, the big thing here. And where we input the use those for the stenography. The outputs are then sent to the major projector and the side projector, and so we can switch the provides when we want to change the presentations. The HDMI over ethernet extenders are used to bring the video to the lectern screen, which is here, and also we provide an HDMI cable here so that the presenters can use the laptop to make exciting demos.
Some statistics.
Those are the number of the network usage during the week. Unfortunately, we don't have IPv4 versus IPv6. Will this is not available on Linux, so when we switched from FreeBSD to Linux we lost this data. We still have to figure out how to do it.
The number of devices that needed dual stack are decreasing. We see a little trend here, and they are around the 20%.
Those are the NAT64 sessions. We use 256 IPv4 addresses for the NAT64, but we could still fit behind one single IP address if we want.
Interesting figure here, like a like a middle finger, on Monday ‑‑ we wonder if somebody did it on purpose, so maybe...
You can see that virtually every device now supports wi‑fi 5, which is the AC standard, you can also see a significant support for some newer standard on Monday, and Tuesday morning before we removed the new access points. So in here.
Those are the number of connected devices. You can see something up on the Wednesday night, I wonder what is that.
And those are the access points. Same as last meeting, the one near the coffee station is the most used one. It's also where we place the new access points initially, because we knew that would happen so we wanted to stress them a little bit. So, you can see the new one is the yellow one and we replaced it with the blue one after that.
We haven't got any complaints about the wi‑fi. So, also probably because the toilets were well covered also this time.
And it's the first time we put an access point on the terrace on the first floor. That was a successful trial. And actually, we did get one complaint, that the network was not available on the roof top pool. So, we're going to learn from that.
Those are the finally the barista stats. They talk about themselves.
So, I want to thank our other teams that work during the meeting, Meetecho, we work very closely with them, they do an amazing job, and they are also using OpenSource technology, Antonio and Tobia are on site. Thank you very much guys.
(Applause)
STENOGRAPHER: Don't clap too much, save it for us.
ANDREA DI MENNA: The stenographer team, that they always do a very nice job.
STENOGRAPHER: Louder louder louder louder!! Okay okay okay okay that's enough now.
ANDREA DI MENNA: I love when they do that. So I don't know...
.
Lastly, the host Dora, an Assis, who got the connection running during the week before the meeting, thank you very much.
(Applause)
.
And one last thank you to all our colleagues who were in the Amsterdam office, they work also with us to prepare the meetings, and they support us during the week, so, thank you very much guys.
I can get a few questions.
MASSIMILLIANO STUCCHI: We have time.
AUDIENCE SPEAKER: I am so hopeful that increased member fees can allow the technical team can bring the roof top in, I appreciate the service: I am expecting that to be at the very next meeting, right? I think you can do it. After the truck incident, you know... seriously, thanks a lot for the wi‑fi, I didn't use the one in the toilet. Thanks.
AUDIENCE SPEAKER: Maria, a graph chart enthusiast. Would you please also the next time bring a chart of the barista over time please?
ANDREA DI MENNA: We'll do that. I didn't have time for that but I will do it, yeah.
AUDIENCE SPEAKER: Will, wi‑fi user and legacy user, actually. It was I think you stumbled on a bug that we had some phones that doesn't see the 5G network and that's why I used the legacy. But all the rest did work really, really well, thank you very much for that.
ANDREA DI MENNA: You are very welcome. Thank you.
MASSIMILLIANO STUCCHI: I see no other questions, so thank you very much for the presentation and for whatever you do during the week.
(Applause)
STENOGRAPHER: The tech team are brilliant!
MASSIMILLIANO STUCCHI: So this concludes the part where the Programme Committee decided the content, and now I will hand it back to Mirjam. So thank you very much everyone.
MIRJAM KUHNE: Thank you, thanks for running this morning's session.
Before I start, I want to apologise for a piece of fake news I apparently spread yesterday about the barista, magically they did show up this morning, even though we were told that they weren't available so I am sure you were very happy about that.
And I think Niall the Vice‑Chair is also here in the room. I don't know if he wants me to announce it but he became a grandfather a couple of days ago during this meeting. Very exciting. First grandchild in the family, so...
.
Right. So let's get started with some statistics.
You see here a number of attendees, on site and online, really good numbers. Also in the top five countries, Portugal, luckily, obviously that's why we're here, to reach out to the local community and we also had a lot of newcomers and also a lot of involvement from newcomers in some of the sessions, the DEI sessions, the mentoring discussion that is we had, that's great. I am always interested to hear feedback from newcomers particularly, also from others of course.
We also had two local hubs that I announced in the Opening Plenary, thanks for organising them. Here is a picture of the one from Poland and, they were participate a couple of days during the week, together as you can see there, I am sure that was fun.
Again, the RIPE Code of Conduct team. You already saw the presentation here. Again thanks to the team for, you know, keeping us, helping us to keep safe during the meeting and again special thanks to Randy who has been on the team from the beginning when we set up the Code of Conduct team, and he was a great help on the team.
More thanks go to some outgoing Working Group Chairs, William Sylvester, the Database Working Group Chair who has served in this role for a long time, I don't know if you are in the room? William, I don't see him. Then there is Peter, the IoT Working Group who stepped in in Rotterdam to serve one term and he stepped down again now and the IoT Working Group, I don't think he is at the meeting. We have Doris Hauser in the DNS Working Group. Doris, I have a little gift for you. I have a little gift for William as well but he is not here to it thanks Doris for serving in the DNS Working Group for a few years.
(Applause)
.
Then, onto the incoming Working Group Chairs. We have three women, in DNS Doris will be followed by Yehveniya, she wasn't here, she participated remotely, so these probably not in the room maybe following remotely. Then we have Anna Maria in the IoT working group who was here earlier but had to leave. And then Franziska is joining as a third Working Group Chair. So thank you for agreeing to serve in these roles from now on. We'll hear more from you I'm sure.
(Applause)
.
So, that means the whole group of Working Group Chairs at this point from this meeting on you can see here on this slide. And they will be working on the agenda and the topics for the next meeting of course.
And again, a big thank you to the PC, the Programme Committee, who was responsible for a fantastic Plenary programme I think this time. I had a lot of good feedback about this, so thank to the PC for a great programme earlier this week and until today also.
(Applause)
.
There were two slots, or two terms ended at this meeting, it was Clara's and Doris, and they were, they can serve another term, so in fact Clara was reelected on the PC, so, I'm not going to give you a gift quite yet I think, and Amadeo was selected to replace Doris on the PC. So thanks again. Also thanks again to Doris for serving in two roles at the same time.
Please don't forget to rate the talks. You can rate both the Plenary talks and also the Working Group talks. You can see a link on the main website. It will then, the main RIPE 90 website which will guide you to the meeting plan and then you can rate the talks on the meeting plan, and each session.
We'd also like to hear from you, and like you to give us feedback, so I'll leave that up for a little while if you want to copy that link or scan that code so you can do it straight away, so we don't have to send you reminder afterwards. Of course you can also come talk to us, talk to the meeting team at the registration desk or to myself.
I don't see anybody pulling ‑‑ I see some people are pulling out their phones and scanning the code. So I learned that from Hisham last time, he kept the slides on and on so people started scanning the code so we got a good share of feedback for that meeting.
Please tell us what you like, didn't like, what we can improve next time obviously.
And yeah, at the end, I would really like to thank all the hosts and the sponsors again, the Dutch PT people they were a great help as Andreus already mentioned in preparation of the team and I think I have a gift. Where is ‑‑ I have a gift for the hosts and I also have a gift for the platinum sponsor, AWS, and there is Kajal. This is a gift for you, for the office maybe, to put it in. Thank you so much for being the host for RIPE 90.
(Applause)
.
And we have a gift for ‑‑
STENOGRAPHER: I thought it was a picture of me.
MIRJAM KUHNE: Also, I have a, a token of appreciation for AWS as a continued platinum sponsor. Clara.
(Applause)
.
And that brings me to the last slide. Next RIPE meeting will be in Bucharest, RIPE 91 in October, and I believe we have as the next speaker, the host of RIPE 91, so I am happy to announce that InterLAN will be the host for the RIPE 91 in Bucharest and Eric is already standing there. This is it for me, I hope you enjoy the rest of the day, the lunch and have a safe trip home or a great weekend in Lisbon. A question? It I don't have a question slide.
AUDIENCE SPEAKER: Since we have a nice photographer here, where do all the pictures end up? Because I think we have a lot of nice pictures, right? I also would prefer a social media platform.
PHILIP OLDHAM: Yeah, from they will end up on the RIPE 90 website in a couple of days. Please check and as always give us feedback. Thanks.
AUDIENCE SPEAKER: Ulka: Just adding something to what Phil said. We publish the photos in lower resolution, if you are a speaker, we have been told by the web team it helps pages load better. If you want a higher resolution for yourself, please e‑mail us.
MIRJAM KUHNE: Thanks for the responses there.
If there are no other questions, then I'd like to hand over to Erik. I hope you had a great week.
ERIC ANDREI BALEANU: So, where are we going next? Of course, RIPE 91 will be in Bucharest, Romania. So, we will travel from southwest Europe to southeast Europe. Bucuresti, the Romanian spelling ‑‑ the capital of Romania and the largest city in the country. It has a population of almost 2 million people. It's a major tech and business hub in eastern Europe. It has a rich history and diverse architecture. Maybe too diverse. And it's known for its vibrant night life and cultural event, and of course it is the host city of RIPE 91 in October.
Romania is a country at the crossroads of central and eastern Europe, and it's known for its natural beauties like the Carpathian Mountains, Danube Delta and the sea side, and it's also home of the famous castles and fortresses including medieval brash castle which known as Dracula castle. Peles castle and also fortified churches in Transylvania.
It's a nation with rich cultural and historical heritage, it's shaped by surrounding cultures, which is reflected also in its traditional cuisine and/or award winning wines. It's a member of the European Union. We are and major cities like Bucharest and the others are also important centres for business, research and culture.
Now, a few words about your next host.
InterLAN was founded in 2005. It's the most ‑‑ the largest Internet exchange platform in Romania. We bring together more than 130 ASNs from Romania, from the region and beyond. We are hosting some key infrastructure, root servers, TV exchange, route collectors and of course are a proud supporter of the RIPE community. And we, InterLAN Internet Exchange is operated by an InterLAN association which is a not‑for‑profit organisation of dedicated to support the Romanian Internet service providers and we are excited to welcome RIPE 91 in Bucharest.
As part of our community involvement, we hosted a lot of events until now. We host the RO NOG meetings since 2014, we hosted Euro‑IX forum, RIPE meetings, ISOC meetings and this year we will host major events in Bucharest the European peering forum in September, and of course the RIPE 91 in late October.
And we instant to propose for the next FC meeting to have the meeting in Constanza at the sea side, but it's only a proposal, so stay tuned until an official announcement will be made.
This is our team that will be present at the next important events. So, if you have questions about the next meeting, the next RIPE meeting, the next meeting that we are hosting about InterLAN's Internet Exchange or just about the Romanian market, you can find these guys at the most important events, including the two events that we will host of course.
So, see you in Bucharest, and we look forward to welcoming you. Thank you.
(Applause)
MIRJAM KUHNE: Thank you so much Erik, we are looking forward to that. And last but not least I'll give a big applause and thank you to the RIPE NCC meeting team who is actually made all this possible in the background.
(Applause)
STENOGRAPHER: Brilliant work ladies!!!
MIRJAM KUHNE: We have Hafsa, Sandra and Kajal, and they are the magic in the background.
STENOGRAPHER: Behind every good RIPE meeting is a woman! Or maybe a lot of women!
See you in Bucharest.
