These are unedited transcripts and may contain errors.
CLOSING PLENARY SESSION:20 APRIL 2012
11:00-12:30:
CHAIR: Good morning again. We will start now with the last session of this RIPE Meeting, which basically consists of two parts. The first part is a series of lightning talks, and then the second part is the usual housekeeping at the end of a RIPE Meeting. And for the first part, I hand the microphone and session chairing over to Brian Nisbet.
BRIAN NISBET: Before we get to the lightning talks, we have a totally and well?verified and checked counting procedure, and thank you again to the NCC for facilitating everything the Programme Committee does. The huge, huge amount of assistance and work and we simply could not do anything without that assistance, so thank you again very much.
The election that we had. Thank you all for voting and participating. And the winner ?? so the new appointee to the programme committee is Jan Zorz.
(Applause)
So, clearly, Jan is now expected to do exactly as much work for every RIPE Meeting as he did for the fantastic one we have had this week in Slovenia.
Now, lightning talks, just to clarify, these talks will be ten minutes long. If you wish to have questions during your talk, that means you need to talk for less than ten minutes. We will be ?? I will be physically removing people from the stage once we get to that point in time.
So, first up, we have Todd Underwood.
TODD UNDERWOOD: So, good morning. The sub?title of this talk is the secret Google switch revealed finally. I apologise in advance that we have not uploaded this presentation to the site. We'll get an approved copy uploaded next week but we weren't able to get it approved to be uploaded today. So, look at the screen instead of your screen because you won't find this elsewhere for some time.
So, OpenFlow at Google. Here is a summary. I am assuming, for purposes of this presentation, that everybody knows what OpenFlow is. That's probably a bad assumption but I'm going to go with it anyway. If you don't know what it is, there is a picture of a switch that Google made later and you should look at that. It's cute. And the rest of this won't make much sense to you. But in general, I will say that OpenFlow has helped Google improve backbone performance and reduce complexity and cost. The idea behind OpenFlow is to separate the control plane from the forwarding plain to enable you to make control plane decisions run in software, but on separate commodity hardware and also to enable global decisions about traffic engineering in a faster way. So, it's interesting stuff.
The interesting thing about OpenFlow and the reason you might care about this is the word on the street, including 20 or 30 people I have talked to here, is that OpenFlow isn't ready for production. It's an interesting idea, but nobody is doing anything serious with it. So I'm going to show you our global OpenFlow backbone that we have been operating for about the last year?and?a?half and convince you that perhaps OpenFlow is ready for production.
So, backbone scale, blah?blah?blah Google has a big backbone, you might have known that. Something, I think it's mostly about cats on skateboards, I am not sure what else, there is some other application that we do, but it's mostly the cats on the skateboards that we do. So when economics. Any of you who operate networks as they get bigger, know there is trouble as you grow, the costs per bit per second go up after some point in networking because of the quadratic complexity you have end points talking to each other and the management of becomes more tedious. Broadcast traffic, the core of your network gets more and more expensive as time goes on, not less. So this is troublesome. The solution is WAN fabrics. This is a hand?wavy solution, but if you can treat the WAN as a set of forwarding capabilities and not as a set of individual devices, then things go much, much better. Right now Internet protocols are mostly written to be box centric. This is because where we came from. Do I have to say router when I am in Europe or can I say router. It's mandatory, I can't do it, I am sorry. Devices and we really didn't have the devices had monitoring and management tacked on as after thoughts. The after thoughts sometimes work, sometimes don't. So, why a software?defined WAN. As I said it allows you separate hardware from software. You can choose heart wear based on the ports that you need. What size port do you need? You know, do you need some other combination of things? Do you need co?acts, 10 days 2 for your data centre, whatever you pick based on your needs. Logically, centralised network control. This is more deterministic, more efficient, dramatically more tolerant. It also enables to you do things with your network that you couldn't otherwise do. So, it enables you to make interesting kinds of control decisions and interesting kinds of network management decisions that any individual part of your network could not make.
So, Google's WAN. We have got let's just say at least two separate networks. So you have this Internet using facing network and this has had a sort of characteristic to it. It experiences diurnal shifts in user?facing traffic. It needs to be incredibly fault tolerant. It doesn't have lots of bursty traffic because large collections of people become statistically stable. The distribution of ?? the distribution of events with rare exceptions world cup in Europe is usually a problem, it causes us to think maybe something is wrong with our network, because there is a dig drop and then a big increase. In general, users do roughly the same thing in aggregate it at roughly the same time and so that's one kind of network. The data centre to data centre network is significantly different. This is driven by mostly not entirely, but mostly inter active application to application traffic and large amounts of bulk copy. So if you think about one of the biggest application that is Google has, it's a lot like Bing, it's the search engine and there is a box and you tie things into it and the results come out. This is pretty cool. So the way that works is indices are created and they are big, they are roughly the size of the parts of the Internet we would like you to be able to search to it's our goal for you to be able to search all of the Internet. So let's just say the index is approximately the size of the Internet and we need to build and ship it all over the planet as quickly as possible. This is a large amount of bulk traffic.
We have built two separate logical networks: The I scale network which is the user?facing network. It's designed to be bullet?proof and work perfectly. Never have any mistakes as always and the G scale network.
So, this is a cute picture of our network. This is one of the questions I took, I can't remember ?? I think it was Martin Levy says, yes, you guys announce this OpenFlow thing. You never talk about it. This is in a lab somewhere. No. Each of these is a full very, very high capacity OpenFlow defined node on our global backbone that's been in operation for quite sometime now. So, this is not in a lab. This is how we run or network. Here is the picture. Look. One of the things you will notice is that there is blinking lights and a lot of ports and things plug into things. It's a lot like other hardware. The only difference is this one's is ours. The main difference is this is merchant silicone ?? you guys are buying switches from people who build very similar hardware to this. This is not ?? if you have seen job postings as Google or any anybody in the industry talking about this, like recollect the Ethernet chip sets, the interfaces, the back planes, this is out there, there is nothing fancy, what's fancy about this is that the control plane isn't in this box. It's nowhere near this box. This has OpenFlow support and OpenFlow is used to install the forwarding entries under the device. Open source routing stacks derived from Quagga, BGP ISIS, does not have Apple talk nor DECNET. These are two things that upset me greatly. But I'm in negotiations to get those rolled back in. So, it's very important.
It scales to multiple terabits per second in chassis and lots of terabits per second in multiple chassises.
Data centres, and there is WAN and other data centres. I said this already. This is a slide to talk about the WAN usage, so, this is traffic dates and this is traffic on the G scale WAN, so the OpenFlow defined WAN. So we started rollout in January, February, of 2011 and it was fully deployed by sort of the third quarter I think of 2011 and we have been operating this network ever since and so and moving traffic on to this network as it is cheaper, higher capacity, it is not necessarily, nor is it designed to be more reliable in the sense of fewer faults or fewer outages. But it is designed to be dramatically cheaper and flexible and faster.
Here's the conclusions. OpenFlow is ready for real world use. Not only ready, but it is being put to real world use by people who operate somewhat large networks. Soft which are defined network it go ready for real world use. So, what this gives you is very, very fast feature development. It simplifies network management enormously because you can make traffic engineering decisions with global knowledge rather than local knowledge and any of you who have done work on network protocols knows that one of the central problems with making traffic engineering decisions is trying to devise a mechanism for making good decisions at each node, even though each node lacks complete information for what's going on in the entire network. This solves that problem by putting the control plane in a position to know everything about the network.
And our data centre WAN is successfully run entirely on OpenFlow, other biggest data centre to data centre is run on OpenFlow. Thank you. There is 58 seconds for questions if there are any. Walk faster, walk faster...
CHAIR: One question I think.
AUDIENCE SPEAKER: You mentioned you were using some open source BGP entire size implementation. I am wondering what this implementation actually is and second question, if I can, how ??
TODD UNDERWOOD: Quagga.
AUDIENCE SPEAKER: And second question is, how do you configure this beast?
TODD UNDERWOOD: It's configured from the centralised control plane which is derived ?? is that what you are mean.
AUDIENCE SPEAKER: Is it within a net ?? or what?
TODD UNDERWOOD: It's OpenFlow.
AUDIENCE SPEAKER: What about IPv6? As far as I know that's the OpenFlow 171 specification does not include IPv6, so are you using something else, something newer or don't you use IPv6 at all?
TODD UNDERWOOD: God, if Lorenzo were here, he'd kill me. That's a shame, I can't answer that question. Several of my colleagues are here from Google and we can answer questions about this outside now or later. Thank you very much.
(Applause)
CHAIR: For the rest of our lightning talk presenters, that's exactly how it should be done. Next up we have Alexander Lyamin, DDoS.
ALEXANDER LYAMIN: Hi, we are a Russian national filtering network and I want to talk about one thing that usually stays below radar for all you telco guys. It's a low rate http attacks. Because there is not a lot of packets but there is still quite destructible. So this is our numbers for Q1. You can see there is quite a lot of numbers, so we see this stuff a lot. And basically, Q1 is lowest season for DDoS. And this is big day distribution and only 3.5% of attacks are actually high speed attacks. And 22% attacks are not full connect attacks. They do not establish full TCP sessions. This is important. There is scary stuff like DNS service infrastructure that brings down whole registers DNS infrastructure in Q1, and whole data centres like Crock and [] Wahome, there is a high end invisible botnet that don't use centralised control centres, they are distributed, and there is a state of the art huge botnet named minor bot, but ?? actually what we have. 1,000 botnet count will cost you just 100 US dollars, and there is a readily available tool kit for that, more than 20 of them in free access, and this results in a fall of prices for DDoS services. You can rent DDoS attack for just $20 a day. That's achievement so we have to compete against these guys. It's not even school, it's kindergarten. And we'll lose. Because we do not expect these attacks to happen, low rate attacks.
Let's see what's on the market to with withstand this stuff. This old gentleman, motivator for Apache, as you can see it's frequency analyser with threshold ledge, logic, and it works. And it's Apache. Don't use patchy. It's old, it's outdated. You can't fix that. There is architectural problem with this software. Let the old gentleman rest. There is another fine use kernel filtering string matching like this. And it works. And it is fast. But it doesn't always work, if you fragment the request packets, it goes through. Same goes for hardware solution and it's not always fast because of its old body of matched packets and it leaves open sockets on a host system. It might be harmful. And it requires contract, which is dangerous, later on that topic.
And there is this guy, we can put http clients to a test, through several Javascript tests fitted AS cryptographic puzzle and check if it's comply or a cookie redirect loop with absolutely same logic, an it's NGINX module is simple to configure, and it works, it's NGINX is powerful and popular. It's already most likely installed. And it's predictable. It gives awe sharp control on the false flash positives. It's expandible. You can easily add you tests like flash mobility or Q, it plug incapability. It doesn't block traffic. It doesn't have to. You fail to bond whatever, your favourite one?liner. It alternates user experience. This is bad, but you can tolerate that. And it's not effective against full browser attacks. This is reduce only 10% of attacks or you're good to go.
And there is this final guy, utilise machine learning, you just drop requests in dictionary and build multi?dimension vector and stuff like that. There is a link down there you can read the details, Google will help you. It also works, we really like the approach. It may not work as a neuron network and the main student there is to ?? whatsoever.
And then there is the strange stuff to filter like that. And it also works, but Y TCP dump? You can ask internal nicely through Brocca test.
The results: Every presented solution works. Not always not for everyone. Fighting back is always helpful. Uptime it better than down time.
What we will consider as definition of happiness? Minimal false positives and no vulnerabilities on infrastructure on lower levels. And optical challenges.
Here we have a winner, and this slide presents that this 19 percent of a difference is actually TCP stack smashing, so you have to proof your TCP stack lower time?outs and stuff like that. There is lots of papers on this topic.
That's a fun ride and safer ride, wear a helmet and don't forget homework. That's it.
Questions.
CHAIR: Thank you very much, that was fast so we do have time for some questions if there are some.
AUDIENCE SPEAKER: Hi, my name is Carlos, I want to comment on your second point actually, no state fire wall, I like that because the conventional wisdom says if you don't do that you are some kind of out cast or criminal, can you elaborate on that.
ALEXANDER LYAMIN: State wall firewalls require to you make an entry for any help open connections so you can track it and it can easily be abused by attackers so they just push your record entry high and you just reduce to least search except for ?? so your hash doesn't work any more for you. It's really easy to abuse, even on high end hardware.
CHAIR: Anything else? No. Thank you very much. So, now Carlos will speak to us about early adoption of RPKI.
CARLOS MARTINEZ: My name is Carlos again. I will present you a very brief lightening survey of the challenges we have seen on the field that earlier RPKI adopters are facing.
This talk it biased because it's, it covers only experience in the LACNIC region. It's biased because my background makes me think that people should know their networks, which apparently you will see it's not always the case. So, please take all the things that I am going to say with grain of salt.
It's also not meant to be critical or hard on early adapters. Early adopters always get burnt but they provide invaluable experience in that process.
So, RPKI in the LACNIC service region. We are slowly getting there. People are starting to use it. The use of the system has been growing still, steadily during the past year. It's interesting to notice how the use of the system increases a lot right after our conferences. So people like, get, excited about it. Right now we have about 180 prefixes in the repository, and the ROAs created cover more or less 6% of the announced space, not the allocated space but the announced space. This is kind of good. We are second place behind the RIPE NCC by some measurements. And that has to take into account that our space is much smaller and our membership base is much smaller.
Nice, right, or not? The problem is that we started to find things that were kind of worrying. The quality of the data that people were putting into the repositories was not good. What do I mean by quality in this context? When you create an object in RPKI, you should do as the doctor says: First do no harm. So, whatever you create in the repository, you should not create artificial invalids. What do I mean by this? Once you create a ROA you are stating that some prefix is authorised to be announced only by certain, by a certain autonomous system. This means that if you get that number wrong, you are creating what I call an artificial invalid, which is people is going to perceive it as an invalid but it's not really invalid, because it's hard to tell the intent of your actual announcement. So the problem that we saw after we started gathering statistics is that our region was created almost 1,500 invalid, which was kind of a lot, so we started to do research on what was going on. So, after we contacted some of the worst offenders, and we got some feedback. Actually people were nice and were willing to work with us on this, which is great, I guess.
So, basically, there are two main, you will say, kinds of problems. There were network related issues. For example, people lack a lot of awareness on how a complex network is actually networking. What do I mean by complex? Complex apparently is any network that uses more than one AS number. So, the problem here is people sometimes fail to actually know what the originating AS should be for a prefix. It sounds strange. Probable everyone in this room thinks that everyone should know what their own network is doing, but it seems to be not case for every with un.
The second problem is flabbergasting levels of deaggregation. I don't know if the word flabbergasts is extreme, but I guess you get the picture. There are some few cases that certificate mentioned in his presentation, but there are some bad in it. People splitting /14s into single 23s and things like that. Sometimes for traffic engineering and sometimes for, I don't know, for some reason.
What happens is that this makes creating the proper ROAs hard. At least with the current tools that we are providing, which is kind of 50/50 problem, it's a problem with our members, it's also a problem for us. And then there are some system related issues. What we are seeing is that since people lack the awareness of how their network is working, they could use some previewing or prototyping tools. For example, some tool that will allow them to say I want to create this ROA. I want to see what effect will it have on the global system. Will it create a lot of in values. Will it do something else? This is kind of dangerous, right. Because you are actually trying to protect the routing system and you are offering people information based on the current state of the routing system. This means that you trust the current state of the routing system, which could be the case or not. It's a double edged sword in some ways.
And some people also lack awareness of the existence of tools like RIS, mean the RIPE NCC tool RIS, which I am sure you are all aware of, is a great tool. It's a tool that people could leverage to get their ROAs right and their network announcements right, but they don't know about it. When we mention it to them, they are surprised, they say this is great, I didn't know this existed.
That's also a problem that we are facing.
So, what now? Basically we took a two step approach. One is contacting all the worst offenders, we were quite successful with that, even even with one of them that I don't want to mention, actually corrected only one ROA and in that step, the amount of invalids created was reduced by 75%, overnight.
Plans for the future: Actually we want to provide better tools. Right now we are developing what we call informally RPKI version 2 with this internal project name, will have a different, more sophisticated user interface, we are going to provide some previewing tools on effect of ROA, pulling data from RIS, with a big note on how you have to be careful with what you are actually saying.
And then we need to provide BGP training. This sounds strange. Everybody probably thinks that BGP is something everybody should know by now, but it's not the case. People lack know how of BGP.
So, thank you so much. And I have like one minute 50 seconds starting now for questions.
CHAIR: Yes. Exactly. Any questions? Randy.
AUDIENCE SPEAKER: Randy Bush, IIJ. Both the RIPE and the RPKI net ROA creation of course looks dynamically at the routing table and says you issued this ROA, you are going to make that invalid. And so, I gather you are going to fix that. Router code is out. For Cisco there is some image releases. We'll see. If you ?? you told that it's a little difficult for people to issue all the ROAs for all the fragments they have created. Maybe if you could make it more difficult, they would generate less fragments and this would be good for us all.
CARLOS MARTINEZ: I agree with you, Randy. I am tempted to take a hard line on deaggregators, but I am not sure I can do that. Yeah, I think that right now what I can provide is better tools so they can create the ROAs for the fragments. In some situations, it's easy, for example the guys who corrected the 75%, because they were actually originating the van I will it's from a single AS. It was terrible deaggregation.
RANDY BUSH: TELMEX did that and they fixed it. Sometimes the system is perceived as experimental, and so somebody creates arbitrary stupid things and they go look at them in their router and say yeah, that's great, that's what I expected but they forget that it's starting to be deployed on the real Internet and other people's real routers are going to consider their real announcements as invalid.
CARLOS MARTINEZ: Basically, I am with you. And that's the message that we are trying to get through our members. Thank you.
CHAIR: Thank you very much. Finally, Alexander Isavnin on IPv6 in Russian domains.
SPEAKER: Hello everyone, I am not domain guy, I am just gurus. Because everyone talks about clients measurements of IPv6, how much clients use IPv6. I have tried to measure how much service for Russian domains provide IPv6 services. So, I just got a list of Russian domains and run some tools through this list.
Okay, current statistics for Russia. Russia related domains .ru and these. Overall we have 4 and a half million of domains. But first of all I want to show you statistics from a year ago which I collected on previous, at previous spring meeting in Amsterdam. From more than 4 million domains only 6,000, 6,500 have AAAA records and even less number of IP addresses were served such domains. And the more interesting, the most of the slash domains were served by Google. /IP addresses, Russian domains were pointing at one address, only one address and that was previous to World IPv6 Day. And exactly on World IPv6 Day, the situation changed and hasn't changed since that. Now, nearly 80,000 domains have AAAA records but they are pointing only to little number of real IPv6 addresses and even less, a number of hosts answer questions and all such addresses related only to about 200 allocations.
So, from all this, 80,000, only one company holds the most part of such domains. And for 74,000 of addresses they have 134 addresses serving.
The rest of companies, you can see these are a number of and you can see how much addresses they are using for that. Only three Russian companies from the, at the top the company who serves more than 100 domains are really in Russia. The rest you should know. And the strange thing for me in this study, because I finished it yesterday, that Google disappears from statistics. I don't know how it happens, maybe they don't serve my requests for AAAAs. So, to compare.
Number of hosts previously seen in Russia in usual IPv net in 1993. So if you think you forgot to do something in the Russian Internet you can try to do it now by IPv6. You have seen yesterday's slide from IPv6 RIPEness, the number of Russian ISPs handling web servers for Russian domains is even less as a number of two?star IPv6 RIPEness LIRs.
Also, such a comparable study by Hurricane Electric as passing zones of top level domains, but they do not include Russia. So if you ?? we could see that now the Russian domains will be number 6, and of all the domain and country codes, number 2 just below Germany.
This is the statistic provided by Russian ccTLD creator. This is percentage of IP requests served by ccTLD DNS service. You can see about 2% in Moscow or New York, Hong Kong and Prague and about 8 percent for Russian domain served in Amsterdam. Also, this is a comparable graph for APNIC. Advertisement measurements there showing slightly little number.
Also, Russia is a very open and democratic and transparent country. We exactly know which websites are funded by our Russian Government. So, I have checked through this list. From 6,000 of governmental or State sites, only 30 have IPv6. Russian Government contracts doesn't require IPv4 or IPv6. So, these guys are serving for Government IPv6 even without request.
So, thank you.
(Applause)
CHAIR: And are there any questions on that? We have a couple of minutes. No? No questions. Thank you very much. This concludes the lightning talks and indeed the programme committee's content, so I hand back to Rob. Thank you very much.
ROB BLOKZIJL: Don't walk away, Brian. This was the end of the technical programme of this RIPE Meeting and now we have a couple of housekeeping things to do and a couple of usual thank you notes and prizes.
The first thing is Brian, who chaired a meeting task force, or was at least a member, and you may remember that this was, I think, initiated two RIPE meetings ago or three RIPE meetings ago. The meeting task force has produced a final report which will be published next week and I hand over to Brian for more details.
BRIAN NISBET: Thank you. So, I'm not going to repeat the document which will be published as a RIPE document over the next we can or so. The meeting task force has wrapped up. We set out to try and investigate the RIPE meetings, find out why people were coming, why they weren't coming and what we could do to improve meetings for everyone. So, a survey which has been discussed previously, we set up the programme committee which is a single largest piece of that, and looking upon our works, we decided that we had, you know, we had done what we set out to do. We had found out useful things about the meeting. We had put a lot of that back into the process of setting up the meeting an indeed the programme committee as we have seen, has, these pro meetings is my first meeting on it, so, has done I think a very good job. So the task force has concluded at that point in time. We, as again you will see in the document, realise that there was some remaining work to be done. So, a new task force, because stop, so we'll start another one for a couple of meetings, has been set up to look at the Working Groups recollect the other happen of the meet. With our first action item and indeed something to be concluded for RIPE 65 is to look at mechanisms and a procedure and a very lightweight procedure to look at appointment, ratification and removal of Working Group Chairs. So that's the first piece of work and we'll present that at RIPE 65 or have that in place for RIPE 65. And then we will look at what other work relating to the Working Groups needs to be looked at. So there is some other things bubbling in the background, but we are going to do that first piece of work there.
So that's it. I don't think there is any question or otherwise. If you need to contact the Working Group Chairs of course in relation to any of this, you can and indeed the programme committee now and we'll talk to you at RIPE 65 about what we have come up to in regards to that, unless Joao has a question...
JOAO DAMAS: I just wanted to remind you, we had agreed we would actually be coming for some people.
BRIAN NISBET: Yes, we are not going to call for people right now. But the important point to say is that the task force will not be purely consisting of Working Group Chairs. We will be talking to some people and we will be getting some input on that task force from outside of the Working Group Chairs collective. If you are particularly interested in this work, then you can talk to me, talk to Joao, Kurtis, Bijal or Peter, who are the five people on it right now, but we will also be very definitely making an effort to get a couple of people on that who are outside the Working Group collective. So that's me, Rob. Thank you very much.
ROB BLOKZIJL: Okay, Brian. I may remind you that one of the conclusions of the meeting task force, or recommendations, has been implemented a while ago, and that is to have a well?defined programme committee. And I think for the last two meetings, and especially this meeting, you have all been enjoying the result of having a good programme committee because that reflected in a very good programme and I would like to take this opportunity to thank the members of the programme committee for a job well done.
(Applause)
Right. I see that about half of you are still glued to screens, probably looking at the outside world using a network and as you have been doing for most of the week. Traditionally, it's now time to have the RIPE network crew give a short report on how the network worked this week. I don't know who is going to report. Okay. If you need technical assistance...
RAZVAN OPREA: Thank you, Rob. Good morning everyone. My name is Razvan Oprea. On behalf of the technical people, I am going to present you the RIPE 64 technical report.
Our network, we had two uplinks provided by ARNES and Telekom Slovenia. We peered with them both, and we had 1 gigabit link from ARNES and 100 megabit from Telekom Slovenia. We tried, you tried actually to use them all, but you'll see later in the updates, it wasn't the case. However, we are pleased with the performance and it was a very good support that we got locally from both of them.
Everything that you have seen in this meeting in terms of patches, cabling, tape, power, was done by the technical team with the big support of the hosts. Registration desk, info hub, we had a big support for the Terminal Room where we had some big screens over there. The servers were [] /SREURT used as usual, we provided the HCP DNS, we had full dual stack, v4 and v6, and, on Wednesday, following the suggestions from you, we enabled also the IPv6, so we can get also v6 resolvers. We have used about 100 power blocks, hundreds of of metres of tape and you will see later who actually helped us with this.
We had the presentation system, we tweak it every single time a little more. We support PDF, PowerPoint, Keynote and OpenOffice. We appreciate whenever you present and use our presentation upload mechanism. It makes our life easier and most of you did so and we are grateful. It sinks automatically to all the presentation machines. We support the presentation that is you actually up load are being prepared at the technical support desk, one person is presenting and the next person, if the agenda is correct, is being uploaded in the background so we have a seamless transition and we do not waste too much time in switching presentations, for those who prefer to have a reach media presentations with movies or code demonstrations, we have also a laptop here on the left, you have seen it and used it and we also support you bringing your own laptop.
Remote presentations are never easy to perform. It depends a lot on us, but it depends on the remote side. We have been using Skype versus WebEx or other programmes because, in our experience, it just works better than most. You have had, today, as well a presentation, remote presentation via Skype and generally, it works quite well.
We have webcast and we have live stenography. We aren coding using H.264 and AAC for video. You can watch or webcast on v4 and v6, as I said, using flash container in RTSP, you can use programmes such as VLC and IRS devices. The streaming server itself is in Amsterdam. We could have with the bandwidth that was provided here we could have the streaming server here but these conditions vary from location to location. So basically the streaming server is in Amsterdam. We stream it over there and basically that's the connection point for all the clients.
Live stenography. You have all witnessed it. It just works very well.
STENOGRAPHER: Thanks. We're brilliant.
SPEAKER: On the wireless network, we have used the services with VeriLAN. They are the same guys that actually provide the wi?fi for IETF and ?? Cisco, about 30 access points were being deployed. And as statistics that we have for you, we can say that from the total bandwidth of about 110 megabit in a peak, 75% was IPv4 and the rest was IPv6. The average total was about 18.6 megabit. Again, 75 to 80% was IPv4.
In terms of associations to the wireless network, the peak was about 430 devices. I don't know if you can read the text over there, it's the active hardware addresses that have been seen unique in the network, 45% of all the clients are probably Apple. About 20% Samsung, 18% are Intel and 5% HTC.
We had some problems with the patching in the beginning in the setup weekend. It was a bit like brute forcing to see exactly which label matches with which connector, but, in the end, I believe we made it right. We had some problems on Tuesday. NTP time issues caused wrong timestamps in the DHCP leases file. It was a tricky one because not everybody was affected at the same time. It depended very much on when you got the lease. This affected also the IRC server. All the problems took about, let's say, 1.5 hours roughly, and they were fixed at the beginning on the lunch break when actually we could take more radical measures to fix it. We were able also to fix the server and the NTP and then we started with a clean slate of leases file.
Some other problems were amusing for some of you but not that amusing to us. Google believed that we are in Austria still and that you say because that's where we had our previous RIPE meeting, so the network was there. And time.apple.com believed that we are in Hawaii, based on the fact that probably that the same access points were used previously at a meeting in Honolulu.
I cannot stress enough that this is a team effort. You see here the usual suspects. There is a team, a core team of six people from the RIPE NCC that actually sets everything up. But this is not enough. We have had help from Brian, our IT manager, this time [] Zavir helped a lot, and [] Mikne, they are all employees of the NCC, but of course a lot of help comes from other companies and from you. You are the ones that actually report all the problems. We appreciate that. You are the ones that come with comments, you are the ones that actually write to the site and give your input. And we appreciate that. We look forward for your comments to make it better for the next time. Every single improvement, it's actually based on your feedback. As I said, VeriLAN was here. The three individuals that you see in the picture here are James, Brendan and the coffee machine in the back; that actually was a full member of the team.
We have also the hosts that were very busy in configuring the routers here, [] Matei, Pitor, Jan and Matas [], we thank them very much. As I said hundreds of metres of tape that you step on everyday is actually the result of their work and ours in equal measure.
And we also have to thank the stenographers.
To Doyle Court Reporters, Aoife, Ronan, Mary and Anna, they've done a great job, and we cannot thank them enough for understanding all the accents and dialects and all the Skype calls, and definitely, more times than not, they have understood the remote presenters better than we could.
And that was it for this time. I will see you next year. It's supposed to be Amsterdam, but let's see what the geolocation says next time.
(Applause)
If you have any questions or comments?
ROB BLOKZIJL: It's this year. But you did have problems with your time server, you mentioned.
RANDY BUSH: NANOG does something cute that kind of is helpful. You will notice there are a lot of people standing around outside during the sessions, and then they come in and oh, damn, I missed that. And if there could be a monitor outside showing the session, that turns out to be really helpful. And if the presentation laptop ran in split screen, then those of us who give you a key note or, what's the make soft thing ?? a PowerPoint, could use look ahead to better sequence our slides.
RAZVAN OPREA: It actually has that for this time. The presentation laptop, you are going to see your presenter slides with the notes and everything, and you have the big monitor in front of you that actually mirrors whatever is ??
RANDY BUSH: No, I want the look?ahead. I want it the mode I see the next slide so I transition easily. And then could you go back ?? you are already gone ?? I noticed on the operations team, the large number of women, and I really want to congratulate you for that.
Razvan: Any other questions? Thank you very much.
ROB BLOKZIJL: Earlier this week we had some discussions in the, I forgot which Working Group, about the early registrations, the legacy space and how to better represent that in the address registry. On behalf of Niall, I would like to show you a slide which is somewhere in this fantastic system. Niall, do you want to say a few words? You are more than welcome.
NIALL O'REILLY: I was going to say something ??
ROB BLOKZIJL: You are mumbling...
NIALL O'REILLY: I was too far away from the microphone. It's Niall O'Reilly. That wasn't my purpose. But here you see the details. You have to send an e?mail to that address. You can leave out the subject and you put in the body those two words, and you get a notification, as also with Bernard and me and we'll deal with it as quickly as we can. Thank you, Rob.
ROB BLOKZIJL: Right this one slide is an official presentation and you will find it on the web server.
Let me see...
You also prepared some slides with statistics about this meeting. If you could show them.
Number of attendees. That's people who were physically here this week: 410. That, I think compares very well with the last couple of meetings.
One third of you came for the first time. Two thirds of you have been at the RIPE Meeting before. It's always nice to see that people keep returning because otherwise I have the feeling we are doing something wrong. You came from many different countries, and, as usual, the host country always features prominently, this is one of the reasons why we aim to have RIPE meetings in different places.
For those of who you have been around for a long time, you may remember that when we started, it was almost 100% academics who were doing Internet technology, and now no, surprise, it is the commercial, the industry that is, is the biggest chunk of the representation at the RIPE Meeting.
Since quite a few meetings, we asked for feedback. So we'll do that again. And this time, there are prizes to be got. There are two Amazon gift coupons, which will be ?? we'll have lottery among the feedback received. Please take the time in the coming few days to answer a few questions about your impression of this meeting. I think it is clear that the more you react to this, the better we can react to your remarks.
Sponsors: It has been mentioned several times already, and you have seen it in the coffee areas. Without our generous sponsors, the socials and other extras around the meeting would not be possible. So, I would like you all to join me in thanking our sponsors.
(Applause)
It makes it possible a couple of, I think, very, very pleasant socials this week.
It has been mentioned already, the meeting itself would have been impossible, of course, without the incredible amount of work and effort put in by the hosts, and we would like to thank the hosts and especially Jan who has been around so obviously.
(Applause)
Is there somebody from ARNES sitting in the room? And somebody from LIFE?
(Applause)
JAN ZORZ: Actually, I got one complaint for this meeting. They said it only lasts one week.
ROB BLOKZIJL: Well, there is one solution: We might be back.
(Applause)
The next meeting is in Amsterdam, later this year, not next year. And very soon I expect that the registration will open, especially since there is a discount on early booking of hotel rooms.
Talking about registration and early registration, the good folks of the RIPE NCC who do the registration are always pleased when as many people as possible register early, and to encourage that, for those of you who have been regular RIPE meetings attendees, you know this is the moment that we give some rewards to the early registrants. And this year, the first one is Sergey Myasoedov, who has registration number 2...
And just to make sure that he got the price, registered twice, so he also has registration number 3, but...
Number 4 is Paul Hoogsteder ?? not here, gone. Okay. For those of you who are new to this game, the rules are very simple. You have a registration number in the corner on your badge and if you are, we go from low till high, and the only condition is you are present in the room. We don't ship these things.
So the next one is Andre Philip, I have seen him.
And the last one is Andreas Koch. No? He is not here.
Then, the next one is Brian Nisbet.
The secret Working Group...
ROB BLOKZIJL: After this report on the highlights of our intellectual working this week, there is only one small item that remains. Some of you have been very active in physical exercises at the football tables. I have been told that there is a winner of that competition. And the winner will be announced now. This is the little token that the winner can take home.
ROB BLOKZIJL: I don't think even on Slovenian Airlines this would be classified as hand luggage. So be careful.
SPEAKER: We are quite glad that it's not again a German winner, so we didn't have to ship it back, the winner is: [] Jenae, and Cleman.
(Applause)
ROB BLOKZIJL: Well, I think we are done. I have nothing more on my list. Did I forget anything? If not, then I thank you all for coming. You, after all, make these meetings. Once again, I thank the RIPE NCC, and after 20 years, they still know how to improve organising these meetings. These meetings, organising these meetings was one of the reasons why 20 years ago the NCC was created, and I think it's impressive how that work has evolved in running a very smooth meeting. So thank you for coming. Thank the NCC for organising it. See you all in Amsterdam. Have a safe journey back. Thank you, this meeting is now closed.