RIPE 81
Plenary session
27 October 2020
.
(Screen playing video)
CHAIR: Hello! Can anybody hear me?
HANS PETTER HOLEN: Yes, loud and clear.
CHAIR: Now we can also hear you Hans Petter. If I saw that correctly, you just handed me this?
HANS PETTER HOLEN: I did. And it still works.
CHAIR: It works. It's safe. Thanks for handing it over to me. I'll keep it safe here on my desk.
Right. So, I guess that means with the handover the Internet, thanks to Hans Petter for doing this, officially opening the RIPE 81 meeting, and I will share my screen.
It's not there ‑‑ there it is.
Okay, if all is well now, you should see my screen, because I don't see you any more. And I don't hear any complaints, so I guess it works.
Welcome all to the RIPE 81 meeting. We would have loved to do this in person, and officially the handover of the ‑‑ of Hans Petter of the previous RIPE Chair to the new RIPE Chair, me, was also scheduled for this RIPE meeting. But since Hans Petter started his new job a few months ago, we kind of did it a little earlier, and so the vice‑chair, Niall O'Reilly, we started in September already. Thanks, Hans Petter, for all the good work you have done over the last five years or so. As I said, we'll keep this in safe hands and make sure it will work.
As of this morning, we had over 1,000 registrations for this RIPE meeting. This was the second virtual RIPE meeting, we would have been in Milan now I believe, unfortunately we are all sitting at home still, so, let's make the best out of it.
As most of you will know, the RIPE meeting is open to everybody. It's great to see so many of you joining this morning, and, as always, we bring people together from so many different countries, backgrounds, cultures, genders and we want the community in this meeting to be a safe and respectful environment. And so therefore, we'll have this Code of Conduct. That's on the website. We want to treat each other with tolerance and respect and don't bring harm to everyone and respect everyone with their different backgrounds, beliefs, ethical backgrounds and so on and so forth.
And we trust that you will follow this Code of Conduct throughout the week.
Should you experience any violations of the Code of Conduct or anything that, you know, you are concerned about, please do not hesitate to contact the trusted contacts, there are two contacts at the moment, Rob Evans and Vesna Manojlovic and they have been trained for this role and you can contact them at trustedcontacts [at] ripe [dot] net or also individually, and they are also set up on the phone, you can set‑up a Zoom meeting with them if you want to talk privately.
We are actually working on the next version of the Code of Conduct. There's been good work done already by the diversity task force over the last few years and we have formed a small task force; they have sent an update to the RIPE list earlier last week, and there will also be more information later in the week during the Community Plenary about the status of this.
This is the RIPE meeting plan. It's three‑and‑a‑half days. Starting as of today, today is mostly Plenary sessions with some socials at the end, and then Wednesday, Thursday are the Working Group sessions and then a bit more community and Closing Plenary sessions on Friday.
Each session starts at the full hour always, it's easy to remember, it usually runs for 45 minutes with a short 15‑minute break at the end and then except for the slot before lunch; that will be a little longer, it will be an hour slot and then we have lunch break. But the thing to remember is the session always start on the full hour.
Here is a slide full of friendly faces from all the twelve Working Groups that we have at the moment. These are the chairs of the Working Groups. And you will hear more from them throughout the week mostly on Wednesday and Thursday.
These are the Programme Committee members and they have put together the programme for this Plenary sessions today and on Friday. And there are actually two slots will become available. You can still nominate yourself or someone else today until 3:30, and then please all vote for the candidates, they are already some candidates so you can find them linked from the front page, there is a link to the Programme Committee elections, front page of the RIPE 81 meeting, I mean.
And then the elections will run until Thursday and results will be announced in the Plenary on Friday.
And I would like to thank the Programme Committee here also for putting together the second time this virtual Plenary sessions, I know this is not easy for all of us.
Now, to come to a more logistical information about this meeting. So I said this is the second time we're doing this virtually. The first meeting, RIPE 80 we ran on Zoom, but we actually had some feedback after the meeting that quite a significant number of participants could not or did not want to use Zoom for various restrictions they had, and so we tried something new this time, it's called Meetecho, and you have made your way on to it, you had your unique link sent to you by e‑mail, you registered and you are now on the platform. If you have been at the IETF and you might be familiar with it, it looks a little different, they have done a great job in customising the platform for our needs and the Meetecho and the RIPE NCC meeting team have put a lot of work into this.
You have everything on platform. The main goal for us was to get everybody together on one platform, compared to last time, where some people were on Zoom, some people were on the live chat.
(LOST VIDEO CONNECTION)
CHAIR: I guess you missed half of this. Can somebody please tell me how much you have actually seen of my presentation?
Okay. Missed bit there.
The same icon you can have a personal chat some speakers will use that during the week. You will see the icon will turn red and you click on it and a you see the poll and you can participate.
Just briefly, on Friday there is a Community Plenary where we will talk about things that are relevant for the community at large, like, rather than a more specific topics in the Working Group sessions. And this time Niall and I will give you an update of what we have been up to so far and what we are planning next and there will be a number of reports also from the tas kforces of the support organisations and then the RIPE nominating committee and hopefully we'll have time for interaction and discussion swell.
There will be some social events today in the afternoon, you can hear a bit more from the RIPE Chair team from Niall and myself right after that social with the Executive Board, and, on Thursday, we'll have a virtual dinner again like last time, it was very popular.
Some other ways to interact with each other, is another new tool we are trying a SpatialChat, you can use to meet during the coffee breaks and also meet with the speakers there and have like little side meetings, there are multiple rooms and things like a maximum of 50 people per room that can meet there.
And you have a mail sent to you with the link and the password for your entering that tool.
Then also, you might be familiar with the networking app, that's still available, the RIPE NCC has been building that over the last few years and on the phone you can also find attendees ‑‑ the attendees there and you can arrange meetings for them on the side and the attendee schedule and the meeting plan is also there.
And last but not least, on the attendees list, many attendees have also left their contact details there, you can find them on the RIPE 81 website.
And yes, I was going to say, or should have said but nobody heard it; in the normal meetings, Niall would be there with me on the stage, we're doing this together, we are there as a team, and you will see Niall also in the rooms, in the presentation, the plenaries, and he will also be happy to answer any questions you might have. Here are some e‑mail addresses you can reach us as a team or also individually.
And very last slide here, we would very much like to thank our sponsors. This time, of course, you have no lunches or coffee breaks they could sponsor, but they helped us with the tools so they made it possible that you could use these new tools and thank you to all the sponsors.
And this is it from me.
Don't tell me you still didn't hear me this time?
(Virtual applause)
Over to you Jan, I think.
HANS PETTER HOLEN: He is on mute.
So, thank you very much, Mirjam and Jan. I'm here not as local host, it must be virtual host since we're not doing a physical meeting, it's a virtual meeting. I think in order to save some time here, I will make this very short and just say welcome to this virtual meeting, we're on the new platform this time. That's what the Internet used to be about, experimentation and testing. Let's hope that the rest of the meeting goes really well and I'll have some presentations on Wednesday, if you wonder what the RIPE NCC is up to, and you can also see a lot of my colleagues in other Working Groups and in the Plenary. So welcome, everybody, to this meeting.
And back to you, Jan.
JAN ZORZ: Okay. Thank you very much, Hans Petter. I think it's Franziska, I think it's your turn.
FRANZISKA LICHTBLAU: Now that we have dealt with technical difficulties, I will give you a short introduction to the PC.
Mirjam already said most of the things, but again, this is the Programme Committee I was working with in order to present you with the Plenary session. We have come up today. And you will get 5‑minute slots, our timings are quite tight, so please be precise with the questions. We will have a microphone queue, so please make sure that your microphone is correctly unmuted, that you don't have that much background noise, and mute yourself once your question is finished again.
We will have five full presentations for you, two short presentations and three lightning talks.
And if you want to help us making the Plenary as good as it is usually for the next meeting, please go ahead and rate the talks. You can find the rating button once you have been logged in with your access account next to the Plenary sessions, just click there and rate, so we get feedback on what you want to hear next time.
And again, we have two seats up for election. Maria Isobel are stepping down, thanks for your input and help. Here again you have the overview, please, please vote.
And, with that, I hand over to Susan. Is Susan there and is she a speaker already?
Let's kick off the Plenary, we already noted in the chat, timings will be of interest today we will overrun this session, we are sorry, we had some technical difficulties and we don't want to cut the time from our speakers, so you see here, Susan, and she will talk about RPKI adoption in IPv6. Susan, the floor is yours.
SUSAN FORNEY: Okay. Can you see that? All right. Thank you very much. So, I am here to talk to you today about RPKI over IPv6, and what the progress has been made.
This year, we saw a lot of progress among ISPs deploying RPKI route origin validation, but the attention on RPKI adoption focuses on IPv4 prefixes. While global adoption of RPKI for IPv4 is important, I thought it was going to be interesting to look at IPv6 to see how it was stacked up.
So, to start out, I thought, well, you know, you can't ‑‑ a ROA is no good unless someone is paying attention to it. So let's take a look this year about how ISPs have progressed in doing route origin validation adoption in 2020. And it's been a pretty good year actually. We started out the year with PCCW, Tata and AT&T continued filtering their peers for invalids. In February, Telia began dropping invalids and Hurricane Electric started dropping RPKI invalids for all of its peers. In March, NTT announced that it had introduced RPKI and was dropping invalids.
In May, GTT, Linx, Terahost, World Stream also deployed RPKI; then, in June, Hurricane Electric achieved zero RPKI in all of its network and Cogent began filtering for RPKI as well; in July, Telstra, GRIX deployed RPKI; in August, Google and HKIX; and, in September, NetFlix and Swisscom deployed RPKI.
So what that means is that, in 2020, we saw a 16 ‑‑ not 16, 6 large ISPs and a number of content networks add RPKI which greatly increased the landscape of networks that are filtering for it.
So, let's take a look at what happened with the creation of ROAs over in 2020. I started looking at IPv4. In March 2020 I had a slide where I was looking at our development that showed that we had 24%, or rather 20% of ROAs prefixes in the global table with valid ROAs, or ROAs, period, 19% valid and 1% invalid. So 20% had ROAs created for them. By September of 2020, that number had increased to 24% in 2004, and I thought that was pretty good because a 4% increase over six months is good, but also the IPv4 table grew by 20,000 prefixes and it kept pace with that and added to total percentage of prefixes with ROAs. So not bad.
Then if we look at what happened as far as that ROA increase and how it broke out over the six months. That 4% increase was generated ‑‑ about 5 of that was increased by prefixes in AFRINIC. APNIC had about 18%. ARIN had 9%. Logic Nick had 42% and RIPE had about 36%. So that's pretty good for RIPE, doing great.
So, then how does IPv6 stack up to IPv4? Well, again, we're looking at that, 24% of prefixes in IPv4. But for the same period in our 100,000 prefix table for IPv6, 30% of the prefixes have ROAs. So, IPv6 actually is doing pretty good. And that tells us a couple of things. I mean, first it tells us that IPv6 is alive and well because you wouldn't go to the trouble of securing a prefix and creating a ROA if you weren't going to use it. So, the fact that a large percentage of the table has prefixes is really good for both right and security and the health of the protocol.
So, now, if we're going to understand what's going on in IPv4 or IPv6, it helps to understand how many ‑‑ how the prefix announcements break out by RIR, what I did is here, in this graph, I am looking at the number ‑‑ the amount of prefixes in the global table as they are distributed by each region. So, for the blue boxes, the blue bars are IPv4 and the orange are IPv6, and in AFRINIC, 3% of the global table is ‑‑ an IPv4 is from AFRINIC. 1% is of the IPv6 is from AFRINIC.
.
In APNIC, APNIC has 23% of the table for IPv4 and 26% of the table for IPv6.
ARIN has 36% of the table for IPv4 but 23% for IPv6.
LACNIC has been 10% of the table for IPv4 and 20% of the table for v6, and RIPE has about 26% of the table for v4 and 28% of the table for v6.
And RIPE is the largest region ‑‑ has the largest amount of the IPv6 table for the regions.
So, then what I did was, I thought, okay, well, let's look at the ROAs as the percentages of the tables.
.
So for ‑‑ again, blue for IPv4, orange for IPv6.
.
7% of ‑‑ in AFRINIC, 7% of the prefixes that they announce have ROAs, but about 1% for IPv4 ‑‑ or IPv6, rather, 24% in AFRINIC of IPv4s have ROAs and 23% in ‑‑ 23% have IPv6 ROAs. In ARIN, only 12% of IPv4 prefixes have ROAs and only 13 IPv4 routers have ROAs and 13% have IPv6 ROAs.
33% of IPv4 prefixes have ROAs and in LACNIC and 20% in IPv6 and then 28% in RIPE and 48% in IPv6 in RIPE.
.
So that's how it breaks out.
.
Now, then, if we turn around and we look at ROAs as a percentage of prefixes by RIR, then we see that the blue bars are the percentage of IPv6 ROAs and the orange bars are the percentage of the prefixes. So, basically what I'm looking at here is how significant is the amount of ROAs that you have created in your region, because how much of the IPv6 table do you have?
.
And in AFRINIC, it's about even with about 1%. APNIC has created slightly more ROAs than their percentage of the table with 26% of the ROAs.
.
ARIN has about 23% of the ROAs.
.
ARIN only has 13% of the ROAs in the IPv6 ‑‑ in IPv6 created, versus having 23% of the table in LACNIC is about even, with 20, and RIPE has about 40% versus 28% of the table.
.
So, again, RIPE leading the way, looking pretty good.
.
And if you were wondering what was going on with the tables for IPv4 and IPv6, I threw in this slide which ‑‑ the blue bars, the blue bars are still the IPv6 ROAs and the orange bars are still the percentage of the IPv6 table. But the grey bars are the percentage IPv4 ROAs per region and the yellow bars are percentage of IPv6.
.
So you can see that social security a little bit different for IPv6 than it was for IPv4.
All right. So, after we looked at all that data, the observations I had was that RPKI adoption for IPv6 prefix is making a lot of progress. 30% versus 24% of the table, that's not bad.
.
RIPE is leading the way and, you know, I credit the evangelisation efforts that they have been making over the past few years to get people out there to create ROAs. It's definitely paid off, you can see it in the amount of percentages in both IPv4 and IPv6, it's working. And overall the amount of prefixes with ROAs is continuing to grow. All of this is good news for routing security.
.
But, routing security we need to do a little bit more, so while I am here, you know, RPKI definitely worth implementing, but we need to do a lot more than that.
.
First we still have to maintain IR records as accurately as you possibly can. Because as we saw 70% of IPv6 prefixes and 76% of IPv4 prefixes do not have ROAs. So the only way you are going to be able to validate the original of those prefix social security by looking at your IRR records, so you need good ones.
.
Also you aren't going to be able to document path with RPKI. So you are going to need IRR records for that too. So you still have to maintain those as well as your ROAs.
Also, I would caution people to look for old ROAs. I have seen quite a few people get caught out by IP address space that was new for them and find out that the person that had it before had created a ROA and it was causing the routes that they were trying to announce to be invalid because they hadn't created ROAs. So, check for old ROAs and create ROAs for all your space because that will keep from having problems.
.
Next you should be filtering for bogons, don't advertise a step you are not supposed to. And use AS path filters or peer lock to you don't advertise your upstream routes to somebody else or you don't accept ‑‑ you should be announcing all your IP space because if you are announcing it, it makes it harder for people to hijack it; you should be setting prefix limits on all of your peers. That's just the practice.
So, to demonstrate why, you know, we need to do more than just ROAs. I am going to look at a couple of route leaks and see how ROAs have impacted them and remember, the first one is the Google route leak from November 12, Google and a couple of other services experienced a 74‑minute outage because a small ISP accidentally advertised about 500 Google prefixes that it learned from a route server.
Well, RPKI can't help here because when they readvertised those prefixes, the origin was Google. So, that's not a problem. They're veiled. It was all valid presentations that Google was advertising, so it's not ‑‑ that's not going to help you.
.
AS path filters and peer lock would not have been useful because the problem wasn't that it was upstreams that ‑ the leaks. IRR part works should have helped because this network should not have been advertising Google prefixes and if you were looking at path validation you would have dropped those records. And maximum prefix limits would have helped especially if the buffer you have for the prefix limit wasn't more than the 500 routes they were leaking. So, again, reasons to do it.
My second example is Horizon's route leak in June of last year, you might remember that that was caused by a small customer of Horizon's that was using a route [opt mitre] making, advertising all of those routes to Verizon and so it was more specific paths it made them the preferred path for a large quantity of Verizon's network.
Now, RPKI, certainly would have helped a little bit. It would have dropped any invalid origin routes and prefixes with invalid links, which, you know, since the more specific routes were a problem that cop helped some ‑‑ than current IRR methods of filtering. The paths would have been still been a problem. You would have had to be filtering forecast paths because ROAs wouldn't have helped you there. Maximum prefix limits would have should down those sessions before they caused any damage because obviously as ISP was advertising a lot more routes than it should have. So, all of those things would have worked.
Not that the ROAs are bad, but there is a little more we need to do.
Obviously it takes more than RPKI to secure your network. And we need to get it more universally adopted. We have six new ISPs this year but as we know there are let's of ISPs and we need to encourage more of them to adopt it. And progress has been a little bit slow, but on the other hand, we do have 24% of the IPv4 and 30% of the IPv6 table in ROAs, so we are getting someplace.
Routing security is important.
What does it take to get us why we need to go? Well, it takes leadership.
So I was talking to my colleague at Hurricane Electric about security route validations and he got to thinking about how things worked in his region, because he didn't really know. So he went back to APNIC and downloaded a bunch of their statistics to find out how many ROAs were being created in his region in general, and in India in particular. And he had a graph that looked something like this. Where you can see progress is being made, you know, it's not spectacular, but things are getting better. So, then, what Anrog did was looked at India in particular and he was surprised to find out that while about 25, 24% of the global table had ROAs, India only had about 12%. So he looked at ‑‑ he went to his local NOG, the India Network Operators Group, talked to his community and said, hey, you know, what ‑‑ we could be doing a bit more for route security inside India. Everybody got excited about it, about getting better security for India and started to do ROA creation. What you see in this graph is the progress that they made in three months for creating ROA in India.
And what that looks like is, they went from 12% of their network with having ROAs to 32% of their networks having ROAs, their prefixes in India having ROAs, and that is over a three‑month period. So remember, in 2020, we made pretty good progress in IPv4 by going from 20 to 24% over six months. India went from 12% to 32% in three months. That is really spectacular.
I know you are wondering what's happened with IPv6? Well, 12%. Still not, you know, not as good as the IPv4 but watch this space, they are promising that it's going to get a little bit better. And the reason why I wanted to talk about this is, I thought it was reasonable inspirational, they really took initiative, went out there, evangelised ROA creation and got their networks a lot more secure with 32% of ROAs out there. So it's a really great achievement.
So, what's next? Well, I'm putting the challenge out there to you. Go out there, be like India, talk to your NOGs, and get more ROAs validated and we can cure things better.
That's all I have for you today. Are there any questions?
JAN ZORZ: Thank you, Susan. This was really interesting. Are there any questions for Susan? You can ‑‑ yes, people is asking to send audio. Let me see. Okay. First one is Patrik Tarpey, and I will allow the audio. Let's see how that goes, we are all learning? Patrik, you are on.
AUDIENCE SPEAKER: Morning Jan, morning everyone. Thanks very much. Very interesting presentation. Patrik Tarpey, off come in the UK. Could I ask inspired the Indians to sign so many ROAs?
SUSAN FORNEY: Well, it was because they were looking ‑‑ it was, you know, just basically looking at how the rest of the world was going and then looking at how they were doing it and seeing like hey we're at 12% and the rest of the world is at 24, and you know honestly, I remember Anrog talking to me about six weeks ago and saying hey we got to 24% just like everybody else. But then they decided that they were just keep going until, you know, they could see how many they could do and when I looked at their stats, you know, last week, it was up to 32%. And so, it was just a matter of, you know, they knew they needed to make it better but they didn't stop when they got you know the same as everybody else, they just kept ongoing to see how high they can get it.
AUDIENCE SPEAKER: Thank you very much.
JAN ZORZ: Okay. Nathalie is the next one, let me see if I can just get the audio. Nathalie, you are on.
NATHALIE: I am security programme manager at RIPE NCC, and thank you, Susan, because this is a topic dear to my heart. I just wanted to tell people here that are watching that if you he had need any help getting your ROAs, we have a whole team available at RIPE NCC that you can reach out to if you are not sure which buttons to click or how to start or what you should be doing. We are here to help you, you can reach us on rpki [at] ripe [dot] net. That was it. Thanks.
JAN ZORZ: Now it's Gordon.
AUDIENCE SPEAKER: My name is Gordon from the Swedish Royal Institute of Technology.
.
So the question that I have is for Susan ‑ first, by the way, lovely presentation, thank you very much for looking into this.
.
Do you plan on doing any measurements on route origin validation, the adoption of route origin validation?
SUSAN FORNEY: That was something that I think would be a really good idea to look at. Maybe I should do a talk on that too.
AUDIENCE SPEAKER: It is my master's thesis topics, so any information that would be very, very welcome and I would love to, you know, do some cooperation with all you folks.
SUSAN FORNEY: Awesome! Ping you later.
JAN ZORZ: Thank you, Gordon. Elvis, I assume you will ask your question that you put in Q&A here, right?
ELVIS VELEA: So as far as I understand, an IP block ‑ is certificate address would be revoked, well the research is no longer associated with that member, LIR or whatever, now, if that is the case, why would the receiving party have issues announcing without the ROA, the offering party has used RPKI?
SUSAN FORNEY: Well, what I noticed is that I see this happen, you know, just in my, you know, work at Hurricane Electric, quite a few times where people, you know, let's say that you have an allocation, you know, from an RIR and you create a ROA for it and then you let that allocation go. The ROA doesn't go away. When the RIR reassigns that allocation, it's up to the person that gets the allocation to go back, look for the ROA and get rid of it or create a new ROA that, you know, that is for them, which is what honestly in those cases I always try to tell people to do, go ahead, just create your own ROA, don't just delete the old one.
.
But it does happen and so I caution people just, you know, if this IP address space is new to you, it never hurts to look and make sure there isn't a ROA there.
ELVIS VELEA: I agree, but there shouldn't be one there.
SUSAN FORNEY: There shouldn't be. Oh, I... you know, from a perspective, I think you are correct. I think it would be great if the RIRs did not allow IP space to be reallocated and leave the ROAs there. That would be awesome.
ELVIS VELEA: Because this is a surprise to me, I didn't know that ARIN does that. I am sure that at RIPE, I have tested that and I don't think ‑‑ as soon as an IP block it transferred from an entity to another I don't think the ROA stays. That's my experience. Maybe Nathalie can help here, but that's my experience with the RIPE NCC. I didn't know that in ARIN or maybe it's not ARIN who does this, I don't know.
SUSAN FORNEY: The next time that ‑‑ I know the first time I saw it happen, I think I actually pinged Nathalie about it because I was curious. I didn't think that would happen either but I have seen it happen since then, and, you know, the next time I see it happen I'll definitely document it a little bit better, but you know, it is, it is an odd phenomenon and you are right, I think it should never happen, if I were king, it would never happen.
JAN ZORZ: Okay in the interests of time I am moving on.
Rudiger, please ask your question.
NATHALIE TRANAMAN: I just wanted to confirm for the RIPE region, but within the RIPE region, in case a transfer. We will remove all the associated ROAs and LIRs to create them again, I am not sure how that, works in the other regions. I hope that answer your questions on confirms your thoughts.
JAN ZORZ: Whenever I granted you the microphone, you kept disappearing. Thank you, Susan. This was, this was really good. And I don't know where is the clap clap button.
(Virtual a pause)
JAN ZORZ: Right. Oliver.
OLIVER GASSER: Thanks so much, I am a postal researcher at the Max Planck institute for inform MAT IX. At this presentation I will present our findings on what we call the lockdown effect, namely what are the implications of the Covid‑19 pandemic on Internet traffic.
So let's get started.
Right around March, most of the population went into lockdown, meaning that they were working from home, they were teaching and also learning from home, and even parts of the social life went online. And in all of these efforts the Internet is essential, so we asked ourselves how well, that's the Internet cope.
And the goals of this presentation is threefold. First we want to understand what the the impact on the Covid‑19 pandemic on different types of networks there and therefore we will present the networks at the core as well as the edge. And we also want to get your experience as network operators, how did your network do during Covid‑19, during the lockdown and therefore as Franziska already hinted at I will try to make this presentation a bit more interactive by also using the poll feature of Meetecho.
All right. So, during our study, we used quite a lot of data, and we used data first from an edge network, then from a core networks, we used 3, data from three IXPs, one located in central Europe, one had in southern Europe and one at the US east coast, and finally, we also used flow data from an academic network; namely, REDIMadrid, which is a university network in the Madrid region.
And to process and analyse all this data, we used quite a lot of people, so this was a collaboration of twelve people from different institutions and companies.
So, let's get started. How did the traffic actually change during the lockdown in different networks?
So what you see here is on the X axis you see the progression of time and the time goes from January 2019 to June 2020, and it is measured in calendar week and you also see a vertical line which denotes the break between 2019 and 2020. And on the Y axis you see the traffic volume. So whenever basically the line goes up you see an increase in traffic volume, whenever the line goes down you see a decrease in traffic volume.
We also highlight on the the right side with grey background, the period of the lockdown and later also of the lifting of the lockdown. And what we see with this blue line is the line for the traffic volume of the ISP, is that right around during the lockdown we saw a 30% increase in traffic which this large increase would normally span over multiple months.
If you look at the IXPs on the other hand, all of the three IXPs also see a similar behaviour for the lockdown period and for some of the IXPs, we even see elevated traffic levels well beyond the lockdown.
And now coming to a completely different network, namely the mobile operator network and what you see here is that this actually behaved differently to the other networks that we have seen before, namely we see a decrease in traffic right around the lockdown, which makes sense, because as people were staying at home, they were not going outside any more so they were not using their mobile network during the commute to work, or in their free time and so on.
And again as soon as some of the restrictions were being lifted, right around mid‑April or so, we see kind of that the mobile traffic starts to pick up again.
Now that we have looked at the overall big picture of how traffic changes during Covid‑19, let's have a look at how traffic patterns within the day change, and what we want to look at here is how do workday traffic patterns compare to weekend traffic patterns and what you see in this graph is on the X axis you have the traffic volume for each hour of the day, and on the Y axis you have basically the traffic pattern.
And the blue bars denote the ‑‑ a specific working day, this was before the lockdown, so it was February 19th. And what we see, which is quite typical for a working day, is that you have a strong increase of traffic in the evening hours. If we compare this to a weekend day, also note that this is also before the lockdown, so it was February 22nd, we see traffic, more traffic during the daytime and then not such a drastic increase in the evening hours as people had more time to use the Internet during the day.
And if we now compare this to a working day, during the lockdown, which is denoted by the purple bars, we see that the work days actually start to look more like weekends, and this is now a good example, so we picked three dates, but how does this look in a larger scale.
.
And to look at it in a larger scale, we actually want to classify the traffic patterns for each day depending on whether they look more like a working day or more like a weekend day. And in this graph again on the X axis you see the progression of time, and on the Y axis, you see the normal traffic volume but the important part of this graph is that whenever you see a blue bar, this means that the traffic has been classified correctly for the correct day and when you see an orange bar, it has been classified incorrectly.
.
So what we see leading up to the pandemic and note that on the upper part you see weekends, on the lower part you see working days. And as I said, blue bar is correct classification, orange bar is incorrect classifications.
.
So leading up to the lockdown, we see that almost all of the days have been classified correctly either as a weekend day or as a working day. But once we go into the lockdown period, we see that most of the working days now start to be classified as a weekend day, and that's why you see all this orange bars showing up at the top of the graph. Now, if we look a little bit further and go into the period of June where some ‑‑ most of the lockdowns started to be lifted again and people are kind of moving back to a pre‑lockdown behaviour, we see that there is some kind of recovery going on right around the June period where more days start to be classified correctly again.
.
Now, that was the data that we see at the ISP. How does this look at the IXP? On the right side you see the data for the IXP and we see a similar pattern here at both of the vantage points during the lockdown. The work days are mostly classified as weekends. For the IXP we even have a let's say a slower kind of recovery when we look at the lifting of the lockdown where at the IXP most days are still being miscalculated.
.
So let's get started with the first poll.
.
I have shown you basically what we have seen at these networks, so how did your network actually change during the lockdown? If you just see an increase in traffic, let's say more than 10%, or did you see no significant change which I would classify as traffic between 0 and 10% increase or did you actually see a decrease in traffic?
.
And if you are in full screen mode, I think you need to exit full screen mode in order for you to access the poll.
.
We see an increase in traffic with 56% of people seeing an increase in traffic, that's basically obviously this depends on the type of network that you are operating and also on types of clients that your network is using, but this kind of also underlines our finding that, for many of the network, there was actually an uptake in volume when we talk about the period of the lockdown.
.
Okay, cool. Let's move on with the presentation.
.
Now, in the first part of the presentation, I have shown you how the overall traffic volume changes. But we all know that traffic is composed of different kind of applications. So in this part I want to look at more specifically what part of the traffic went up or went down. To do that, we classify the traffic based on the transport port and sourced some destination ASs into specific classes, and the classes that we used in our study you can see on the left side here, so, for example, we used web conferences, collaborative working, e‑mail, video on demand and so on. And in this graph, this shows the base week at the IXP and what we call base week is a week in February, basically before the lockdown happened so that we can compare against kind of the normal traffic pattern.
And on the X axis you will then see different days of the week, and the darker the colour in this graph is the more traffic volume we see for specific hours of this day.
And, for example, what we see is that e‑mail is mostly used during working hours and not so much on weekends.
.
Video‑gaming and social media is mostly used during evening hours.
.
And we see hardly any web conferencing traffic at all.
.
And now we want to compare this to the lockdown periods and what we do here, we use our base week and we compare it with March, basically, and we see ‑‑ we want to see whether there was an increase, which are the yellow to dark red colours, or whether there was a decrease in traffic at this specific time, which would be the light blue ones to the dark blue colours. And I want to focus on some specific classes where we saw a large difference and, for March, this is the web conferencing class, for example, where we saw quite a large increase. The same goes for video on demand and gaming and we also saw a partial decrease for some of the days for educational traffic.
.
Now, if we look at April, again I want to highlight some of the classes. We see a very, very strong increase in web conferencing traffic, and, again, a decrease in CDN and social media traffic. Basically the same is true for June as well.
.
Another important application that is important for you if you are working from home is VPN, and we want to identify VPN traffic but it's not so trivial obviously because ‑‑ well, the VPNs that are using a well known portal exclusively, that can be easily done, but if your VPN service is using TCP/443, you have to be careful that you're not misclassifying HTTPS as PPN traffic. So what we did was, we used the domain‑based classification in addition to the placed one and, for the domain‑based one, we basically looked for IPs that had a domain associated with them where one of the labels had something in them with VPN, and we also excluded IP addresses which had the dot‑dot‑dot.
What you see in this graph is the result of our VPN classification, this is the data for February, so before the lockdown on the upper part of the graph, you see the working days and on the lower part you see the weekend days. And on the X axis you see basically the hours of the day, and, the higher the bar is, the more traffic you see for this specific day.
If we compare the February graph with the graph in March, we see that there is a 200% increase of VPN traffic during the working hours.
.
And comparing that again to April, we see that there is a slight decrease, if we compare it to March and a little bit decrease again in June as well. But nevertheless the overall VPN traffic is still well validated, it's still well above the traffic that we have seen in February.
So, let's come to our second poll. And this is now asking you how did your network change based on certain parts of the traffic, so did you also see, for example, an increase in VPN traffic? Did you also see a decrease for certain parts of the traffic or did you see an increase as well as a decrease or no change at all?
.
.
All right. So let's have a look at the results. We see that ‑‑ interesting... there is quite ‑‑ it's quite, almost half and half. 46% of the people who answered the poll said that they saw an increase for certain parts and the other half also said that they ‑‑ or 39% said that they saw an increase as well as a decrease. So this kind of extends the results that we have in the first poll where people said that they generally saw an increase in traffic, but this poll also shows that it's not only an increase, it's also a decrease, it can also be a decrease for certain parts of the traffic as well.
.
All right now, let's have a look at the completely different type of network. Up until now, we mostly looked at ISP networks or IXP networks or in the beginning also at the mobile network. But how does an educational network change during the lockdown?
.
And what you see in this graph is the daily connections for different traffic classes at the REDIMadrid network in Spain. On X axis again you see the progression of time and on the Y axis you see the relative change of daily connections. So if it goes below 1, you have a decrease in traffic; if it goes up on 1, then you have an increase in connection sessions.
.
And on the grey background denotes weekends, and what we see here, if we look at the web and VPN traffic, both incoming, then we see quite a strong increase for the educational network and this is due to obviously, if people are not on campus and people are doing remote teaching, they use the websites that are located on the premises of the campus more and obviously also if people are working from home, for the universities that are networked and they will also use VPN. And interestingly you can also see kind of the weekly patterns for VPN traffic where we have a lot more traffic ‑‑ a lot more connections during the week compared to weekends.
.
And one other fact is that if we look at outgoing QUIC traffic, which is normally being generated by students and also staff which are on the campus and are using their phones, for example, to stream some movies or ‑‑ so that sees a significant decrease, because basically the campus was locked down and people didn't go to the campus any more so they stayed at home, they didn't obviously ‑‑ you see a decrease in the QUIC traffic.
All right. So let's start to wrap this up. What did we find?
.
So we found a 15‑30% increase of traffic within a few days. The difference between the workday and the weekend patterns starts to vanish. And the certain applications, especially for remote work, education, VPN and video conference saw a significant increase in traffic and also the absence of users as we have seen in the previous REDIMadrid plot, can lead to a decrease in traffic.
.
So, the impact of the Covid‑19 pandemic is directly reflected in changes to Internet traffic and that's where I come to the final poll, kind of as looking into the future poll, and I want to ask you how well is your network prepared for a potential second lockdown? Are you better prepared than for a first lockdown or are you similarly prepared or are you just hoping for the best?
Okay, that's interesting.
.
It's quite encouraging that not a lot of people are just hoping for the best. They are actually ‑‑ many of them are similarly prepared as for the first lockdown, so, this kind of speaks to the RIPE community you would say that they did their due diligence in order to be prepared for this kind of drastic changes and we also see that about a third of the participants are now better prepared for the first lockdown, which is encouraging as well.
.
All right. So in the beginning of the presentation, we asked ourselves the questions, how does the Internet handle these drastic societal changes? And what we found at our vantage point is that the Internet was able to cope with these major demand changes as well as major application changes.
.
And now I want to engage in a discussion with you also via the Q&A obviously as to how was your experience? How well did your network cope? Did you see any changes in traffic patterns? Did you experience outages? Congestion or something like that or did you have to provision additional capacity and is this actually the new normal that we're seeing?
.
There is also a paper available where we have more in‑depth analysis as well, it's on archive, you can click on the link in the presentation or also use the QR code. That's all from my side. Thanks for listening. I'm looking forward to the Q&A.
CHAIR: Okay. You can join the Q&A or queue yourself in the microphone queue and we have one question on Slido. Daniel Karrenberg from the RIPE NCC is asking:
.
Are you aware of the work of Massimo Andela at all? They use indirect measurement, one of the results is that we increased in the evenings, did you not see that?
OLIVER GASSER: What did increase in the evening?
CHAIR: Video delivery.
OLIVER GASSER: So, I am aware of the work, so video delivery, meaning video traffic ‑‑ let me go back to here maybe.
.
So, what you can see here is that there is actually an increase in video traffic during the evening hours, right, so whenever this is kind of orange or even red, there is an increase. Obviously there are some days where you see a decrease, but this kind of depends as well on the base week that we used. Or you can see it quite nicely here that there is quite a large increase in the evening hours as well.
CHAIR: A little bit sad because they have faded but we actually did see something like that, but I just think not to strong.
.
Okay. So, next one is Benedikt and he is in the audio queue, so, Benedikt, I will give you audio and tell us your question.
BENEDIKT: We have a situation in Germany that, for end users, the upstream /downstream bandwidth are not exactly symmetric, to put it politely. Do you see any effect that as soon as people are using web conferences at a large scale for business from their home uplinking or from network connectivity ‑‑
(LOST VIDEO CONNECTION)
JAN ZORZ: I think it would be a good idea to end this session. So ‑‑ the tech people can figure this out. Right.
CHAIR: Nevertheless, we hoped you enjoyed the session. We had two really, really good talks, and let's hope that we were just the guinea pigs and the rest of the meeting will go mostly well.
JAN ZORZ: This is what happens then technology goes belly‑up. And thanks very much everybody and see you at the next session and I hope that things will work better. Cheers!
(Coffee break)
