QUIC: in Theory and Practice - Robin Marx | DeltaV 2018

[Music] so let's talk about quick which is a new network protocol and the name stands for quick UDP internet connections which I think sounds incredibly boring so I thought how about instead just for the day we say the quick instant means Aquaman Bruce Wayne and fastest man alive combined allow me to elaborate see before we can understand quick we need to understand the problems that it's trying to solve and when we talk about networks is usually in this form of kind of a layered stack or at least on the web we have HTTP on top then we have transport layer security and then we have transport control protocol TCP now I don't like to think that HTTP is kind of like Aquaman because he understands the fish language and it CP is a thing that tells us which kind of messages we can send on the web and who better to be in charge of security and the best detective in the world and for Transport we mainly want someone fast so we can get the job done that's cause perfect for Superman the reason for this layered stack is mainly flexibility doesn't really matter if we have Wi-Fi of 4G at the bottom layers everything else can say pretty much the same but keep that flexibility this layers of course have to be very loosely coupled they can't really communicate too much or we would lose the ability to swap them out this in terms leads to some inefficiencies because some of these protocols are going to want to do very similar things don't know that about each other and so we end up doing some things twice I'm going to give you an example we all know that Aquaman loves to write and here's a pen pal it's a white whale called frigate and when alkaline has written the letter U goes to Superman he says I think Richard is at about these coordinates would you kindly take this letter to him of course Superman's going to say no because he wants to first go out there and check that Richard is actually at those courts which takes him about one round-trip and when he gets back Batman is waiting for and he says how could we be no how can we be sure that's actually Richard how do we know that it's not a super villain dressed like a whale so he forces Superman to go back and get richest credentials and when they check out he has to go back again because Aquaman wants because Batman wants to have a super secret password to encrypt all the messages so we see that finally at six is about four round trips until we can finally get a response from our initial letter and Superman is quite fast but a transcontinental distances even he will take about half a second for this which is course quite slow the good thing is once this connection has been set up we can start talking about all kinds of things about it's a love affair with Wanda about the next week's poker game about what they're going to wear to SpongeBob's birthday party and just like a nice busy whatsapp group they're going to be talking about all these things at the same time interchangeably they're going to jump from one topic to the next and back again and the problem now comes that Superman is a bit clumsy he sometimes drops things so if you imagine please Superman flying around with a whole bunch of pages in his arms and he ends up at this location and he notices that one of the yellow pages has gone missing you all know if you have a long ladder one page is missing there's a high chance that the rest won't make much sense anymore so the only thing the Superman can do is hold back these other yellow pages while he goes back and fetches a new copy of the one he lost before he leaves of course he's going to give all these other pages to Aquaman who can start reading them because these are all independent topics so you don't need to have read one to understand the others is this kind of the best that we can get the best that we can do when we have some packet loss in practice however it's not that easy because what Superman sees actually looks a lot more like this he doesn't know about the colors he doesn't know about the different resources that is because he and Aquaman do not communicate because we're on the different layers he doesn't understand a fish language and this thing is encrypted anyway so for TCP this is all just one giant bit stream it looks like one big resource this means if one of these packets get lost TCP has no other choice than to block everything that comes behind it not just those two yellow pages that were actually impacted and this is what we call the TCP head-of-line blocking problem luckily for a very long time this was mainly a theoretical problem it didn't really happen all that much in practice and the reason for that is that Aquaman is a bit stupid it can be a bit dense I told you before that they're talking about all these things at the same time I kind of lied you wouldn't be able to mentally deal with that so HDPE one you can actually send multiple requests at the same time that's not a problem but the responses have to be delivered totally and in order of request this means if this first resource is slow for example it's very large all it has to wait for some database access to be generated it has the potential to block everything that comes behind it even though there might have been some time on the network to send other things but simply because HTTP one cannot deal with out of order responses and we call this very originally the HTTP head of line blocking problem right so the HDP head-of-line blocking problem now Aquaman is a bit dense but he understands that this is an issue and by now we all know what happens if you give a powerful orange man a difficult problem he's going to use his brawn rather than his brain and Aquaman is quite powerful he is a half God so he thinks is the ideal solution here is to open magical portals into parallel universes parallel universe is that each have their own copy of Batman and Superman that he can use and this suddenly enables him to do things at the same time because now he knows okay portal 1 that's a pink bottle - that's the yellow stuff and so on so if you're using HB 1 your browser is going to open up to 17 of these parallel connections to download things at the same time it does a second circumvent these head-of-line blocking problems it doesn't really solve them it just makes them happen a lot less because for example if we now have packet loss on one of these connections it won't impact the others they can just keep working as usual because they're completely independent Superman working behind the scenes this works really really well but has its own overhead because we have to set up and maintain all of these connections not to mention what we're doing to the fabric of space-time so let's summarize we have three main problems our connection setup is quite slow if we have packet loss things can be blocked even though they have already arrived at the client and if we have a slow first resource on HTTP that can also block things behind it the solution for these last two works if it has a lot of overhead by itself so let's try to solve these things one by one and start at the top Batman this is what I showed you before when I skarner the situation in TLS 1.2 which is the current version of the protocol it's most widely deployed we seen up to optimize this the simplest thing to do is to ask Batman to do is two things in one Ryan clip and that was actually care enough possible in some situations for TLS 1.2 and it's now the default for TLS 1.3 which is the new version of protocol very recently finalized and it's now being implemented if we want to optimize this even further though we need to start finally having some communication between these layers going on for example we can have Batman and Superman working together using a technology called TCP fast open which allows us to send some extra data in the initial TCP syn packet so this is great we've already had twice the performance that we had before what we really want a Holy Grail is of course to do everything in a single round clip as a bit of a problem with this though because Batman insists that everything has to be encrypted including this first HTTP request now we can only encrypt things if we have an encryption key and we have to get that from the server that's kind of a problem here so what's going to happen in practice the first time you connect to a server that's going to be the third column it's going to give you two encryption keys one for use now and one for use in the future so when you reconnect to a server that you already know and it also remembers you then you can use that second encryption key to also encrypt that first request this encryption isn't going to be as good as a corruption after that but it's more than secure enough to allow a wide range of interesting use cases online you will see this market is a zero RTT which basically means that there is zero overhead well before we had three LT T's of overhead for setting up this connection so we see that this is great and that most of this improvement comes from moving from one version of the protocol to the next we've gone from Adam West to Christian Bale and as always we ignore Ben Affleck now we all know that there's another protocol that has gone through a similar change quite recently because HTTP has also got a better smarter and sexier the nice thing about HTTP 2 is that the main thing ended us is solved at head of line blocking problem on this layer remember what we really want for HTTP is to be able to talk about multiple things at the same time that wasn't possible in this few one because it sends basically all resources as one big letter without any type of indication to which resource these individual pages belong so the main innovation HB 2 is incredibly simple it says how about instead of writing letters we're just going to start using index cards each paragraph we want to sent me write on a separate index card on the top of each index card we put too which resource this data belongs now whenever Aquaman receives in the next card he just has to look at the header it says ok this is the bank's stack this is the yellow stack this quite simple system now allows us to what they say is multiplexing of some of the multiple resources on that same connection this is great because now we don't need those 17 parallel connections anymore to be able to download things at the same time so HTP two kind of solves two problems at once they should be head of line blocking and the overhead of the mitigation that we did before so no wonder that this has been marketed so aggressively the problem though with this is that now we fall back to a single Superman we no longer have 17 we only have one and if you remember Superman had his own problems in the TCP head of line blocking if there is packet loss and so I have seen and done experiments that have shown that hb2 can be up to five times slower than HP one on that works with packet loss so that is a huge impact and it makes it very very important that we I only solve this TCP heard of line blocking problem and by now I think you all think you know where I'm going right which is going to introduce a new version this is kind of where my carefully crafted superhero analogy falls down because when this has happened on the big screen its kind of failed to materialize on the Internet there is no such thing as a tcp 2.0 it's not because we haven't tried we've been trying for decades the problem is that TCP is too popular it's too widespread we all know Internet this kind of an interconnected series of devices and they all have their own implementation of TCP running now most of the developers of these implementations apparently can code about as well as me which means these things are riddled with bugs and break easily this means if we want to change anything about TCP there's a very high chance that we will break at least some of these what we call middle box implementations so if we want to change anything we have to wait until all these implementations have added support for it people before we can deploy it at scale at all before about TCP fast open that has been in the Linux kernel since 2012 and even today is only very sparingly used because a lot of implementations are still lacking support for it so if you want to change if you want to solve the TCP head of line blocking problem we can't have two options we can either wait a full decade for everyone to catch up or we can make a bold choice a kind of controversial choice we can acknowledge that TCP simply isn't evolvable anymore and decide to replace it with something else exit Superman answer the flash aka in UDP if you don't know what UDP is it's kind of a bare-bones version of TCP the flash doesn't fly he doesn't shoot laser beams from his eyes he has no super strength he's really really fast UDP doesn't care about packet loss if another packet is lost it just ignores them normally that's not what you want because it means you have to deal with that in the application layer but here is of course exactly the kind of flexibility that we need and finally we're about ready to talk about what quick now really is on the Left we have the top of the line TCP stack the best you can get today and we see that quick kind of spans all the three layers it is a massive block of layer violations as it integrates all these three things together and in reality it kind of looks even more like this because quic is still going to use TLS 1.3 it still has all that Syria round-trip time goodness it that builds on top of UDP we implementing a lot of what we know and love from TCP and it still uses the hp2 semantics just not the exact implementations because with quic is going to do is it's kind of gonna steal that multiplexing idea from HTTP 2 it's going to steal that index card and bring it down one of the layers and then it's going to build on top of UDP custom packet loss recovery logic and the cool thing that this enables the main reason for quic is that these two can now finally communicate our command can finally talk to the flash directly the flash finally understands that we have multiple resources at the application layer and if one of them is experiencing packet loss all the rest does not have to be blocked solving of course a TCP head of line blocking problem but you see for this we had to do a lot of work we have to invent a completely new protocol over three different layers we implement a lot of things and we also see that most of what I've talked about today HTTP 2 and TLS 1.3 work perfectly well on TCP as well so is it really worth all the effort to do all that work solve that one DCP ahead of line blocking problem and not really the answer is no so the people who made quake said if we are going to do this effort anyway we are going to do it right we are going to solve all the other problems as well so quick it's kind of like a combination of everything that we've learned about networks over the past three decades all the best practices in one neat little package Maxim performance quick also focuses very heavily on security most of these all the protocols have been abused in the past by hackers for things like distributed denial of service attacks so the quick does by design is integrate in mitigations for almost all the known attacks into its implementation to make it much much more difficult to abuse and of course for those future security holes that we might find quick ones to stay very flexible to be able to change where needed we saw before that this was a real issue with TCP because these middle boxes were looking at traffic and making the wrong assumptions and that is mainly because we are mainly encrypting the data on the HTTP layer but not on the bottom layers all the TCP stuff is out in the open on the wire for anyone to read so the solution that quake does for this is to say we're going to encrypt almost everything including our own metadata things like packet numbers packet types that are normally visible with TCP are now also encrypted in quick which is of course great um the idea is that less these middle boxes get to see the less they can break that's of course great for quick and its users and terrible for people who make metal boxes so it's a very very political issue and a couple of weeks ago there has been a two-hour discussion about whether or not to add a single bit to be visible to the middle boxes two hours for one bit I'd say look it up on YouTube it's quite entertaining another nice thing I think about quick is that it tries to account for how people are actually using the Internet in a modern setting for example you're all here now on live fly but if you were to go outside you would switch to 4G any open TCP connections you might have will automatically close down and have to reconnect because you now have a new IP address so a quick does is instead assign you a unique connection ID that will remain the same no matter how many times you change your IP address and it takes this one step further it says oh you have Wi-Fi and 4G while not use them both at the same time two networks extra bandwidth and that's the idea behind multipath and that has been shown in a lot of research to be very very interesting for performance improvements quick does a lot of other stuff next to this as well that I don't really have time to go into today but my personal favorite is probably this custom congestion control if you don't know what it is it's mainly the mechanism that prevents you from sending too much data it prevents you from overloading the network normally again this is something that TCP does for us that's not always optimal TCP usually has a single general-purpose algorithm that it uses for all connection types that works well most of the time but it can be very detrimental in some specific edge cases so a quick allows is to say we can have the optimal congestion algorithm for each independent connection type if you combine this with something like the net info API which allows you to query the browser and see what type of connection you're currently on and how much bandwidth you have to use now you can start to tweak this and have the perfect micro optimization for each individual user at that exact moment and for the exact page you're trying to served which in turn can help with making things like HTTP to server push a bit more practically applicable so like I said I think this is one of the most interesting things about quick one of the things that I will be researching if you want to know more come talk to me afterwards because I think I'm by now most of you are craving some numbers right how much performance gain can we actually expect after all that work and the simple answer is we don't and the reason for that is that quick was originally developed by Google a couple of years ago they very very rapidly deployed this on their service and in Google Chrome and it's now serving over 7% of the total internet so quick has been battle tested at scale but really only by Google now we like Google we trust Google if Google says something works we say standardize it so that's what happened last year when we got the new IETF version of quick this version is very very similar to the Google version in concept but it changes a lot in terms of some implementation details now when I submitted this talk last year I thought we would have been much much further along by now I hoped that I would have some data from our own implementation to be able to share with you the boy was I naive there are currently over fourteen implementations that we know of and none of them is even remotely ready for any type of performance testing let alone browser integration and that's expected to stay that way for a couple of months still now I don't want to let you go home without anything so I suggested instead I gives you some data on the left version it should be relatively transferable to the standardized version because they're still quite similar in the bottom line most of the data comes from academic research papers and the first one is from Google itself and they test it quick on the Google Search app and they found about three point six to eight percent improvement when I first saw that I was kind of disappointed I was like eight percent for all that work until I realized this is Google search this is quite possibly the most optimized application in the these guys throw parties if they have a single percent consistent improvement probably and this is our average at the 99 percentile they measure up to 16 percent improvement which is something I'll sign for any day I really notice that most of this comes from that zero round-trip time connection setup and that also explains the worst numbers are mobile here because remember the zero round-trip time you can only do that to a server that you have already seen before mobile you're much more likely to be moving around and Google's load balancers might send you to different data centers that you haven't seen before so that's something that should be improvable in the future and you shouldn't have to deal with that much if you're not operating at Google scale so we see that Batman is doing its job quite well mission accomplished how about the flash how about the reason that we moved too quick in the first place is to be better for lossy networks again Google has tested quick on YouTube and it's found about 20 percent less rebuffering for video content on networks in India which is generally considered not to be of the best quality there's an old paper that says we get about a 14% of actual page load time improvements in the actual browser which is nice and there's another paper that tested quick on packets with and without networks with and without packet loss and of course quic is going to be a bit slower with packet loss but only about 20 percent well HTTP 2 is slower by over 200 percent in those cases the salts this sounds great but this wouldn't be academia if there weren't also papers that claim the exact opposite results so this one paper that says that quic is terrible for video streaming it consistently selects the lower quality it's on paper that says that if you have an inconsistent latency that will cause packets to be reordered and the current implementations of quick really can't handle with that and it's one of the older papers it says that you can have 20% slower page load times if you have a network that has packet loss but also a very high bandwidth now I'm not really here to tell you which one of these two to believe my interpretation is more like quick has a huge amount of potential but the implementations still need a lot of work until we can see consistent improvements over all of these use cases and that's another thing that shows from this quote from Google but I find that quick takes about twice the amount of CPU on the server than TCP does it's again it's because CCP is so old it has been implemented into the operating system kernel and sometimes even hardware what quic is so new it's still living in what they call user space which is a lot slower that's another paper I looked at that and the mobile device scenario and they found that in the case is that Cray performs sub-optimally most of the time it's because the network is waiting for the mobile CPU instead of the other way around which is completely bonkers now it has to be said that this user space implementation is exactly one of the things that allows us to evolve quick so rapidly if we have a new version we just have to have a new server and a new browser version that's it we don't need to update our OS or any of the middle boxes so this is a very interesting trade-off that we can make and of course this is expected to get better over time there will always be kind of a performance cost to quick even at the long run with that I'm kind of ready to summarize the main point of my quic is that it moves away from TCP into UDP it's allows us the option to pull in everything but the kitchen sink to focus on both security and performance and flexibility towards the future all at the same time for us it promises performance improvements on almost all use cases but especially on slow networks with a lot of packet loss aka emerging markets now what does this mean for all of us here today not that much you don't really have anything to deploy but if you're not currently on HTTP - it might be time to start thinking about switching unless of course all your users are at those emerging markets that maybe just switched HP 1s please look at your own data to make that decision of course one quick gun does arrive I think about late last late next year or maybe 2020 it'll probably as simple as changing a varietal in your server comfy just the way it was for HTTP 2 as well but the major difference with HTTP 2 is going to be what we're quick we're going to get a lot more parameters this week a lot more knobs to turn to be able to micro optimize our performance for individual users and like I said that is a part that I am absolutely most excited about now that's all of it for me and as a conclusion I just want to make you all a promise I promise that if I ever get to do a follow up to this talk I will do my very best to expand the cast to also include be incredible Wonder Woman thank you [Applause] you

Channel: DeltaV Conf

Views: 5,493

Rating: 4.7313433 out of 5

Keywords: DeltaV, DeltaV 2018, Robin Marx, QUIC

Id: B1SQFjIXJtc

Length: 29min 49sec (1789 seconds)

Published: Mon Jun 11 2018