 All right, everyone, let's play battle. PJ, here's going to start. There we go. PJ here is going to get started. Tell us all there is to know about the game. Go for it. Cool. This slide doesn't mean anything, but I think it's one of the funniest things in the world. If you do need to make many copies of an IP packet, you have to press much harder. Otherwise, it won't work. I'm Tom Jones. I'm a researcher at the University of Aberdeen. I work on internet transport. The neat project that I work on is trying to build a new API for accessing the network. With this API, we're trying to abstract the way transport to make it nicer for programmers, so all of you guys, so you can build applications without worrying too much about network details themselves. I'm going to talk about QS and deployability. Yeah, so this is it. Everybody's taking a picture of it now. Yeah. It is that great. It's on both of my talks today. Good. So before we can talk about QS, we need to talk about packets. The simple model that's exposed by the soccer API and a lot of programming APIs is that we have our client, we connect through to another side, and then we send data, and then we get a stream of packets that goes all the way through, and it all works, and it's all great, and there's no issues with this. In reality, though, we're connected via a router, and on this router, there's probably NAT. This router is connected to a router at your ISP. The traffic in your ISP is trunpped through MPLS. It goes all the way through, and eventually it will propagate out to a router to the other side. Each of these routers is a middle box. For all of these routers, we send traffic to them. They receive and buffer the traffic, and as they take in traffic and as they buffer it, they have to make many copies. As they make copies, they make modifications. They might take shortcuts to accelerate this process so they can handle more stuff. All of these middle boxes on the internet can cause trouble when we try to deploy something new, and the use of QoS on the internet is somehow quite a new idea right now. The way packets are treated without any sort of QoS considerations is called the default forwarding behavior. It's hard to talk about the default where there's no QoS for the QoS class. We think of default forwarding as everybody is the same, the same way we want to be treated on the metro, everybody gets on the train, everybody gets off the train. There's no priority for any special people. There's no separate classifications. There's no difference between the packets we send. In reality we have packets that we do want to be treated differently. Much of the web workloads we do might be best effort because we don't particularly care about it being treated better or worse, but when we start wanting to do real-time voice where we have hard latency requirements for the data, we want it to have a preferential treatment in the queues and routers so that if there is a large queue we can get through it slightly faster, but maybe there's a trade-off for this where our packets get dropped more frequently. And there's also the behavior where maybe we want a lower level of classification for traffic. Maybe we want to use the network when it's not being used as much as possible, but as soon as an active participant comes online we want this traffic to go away. So now in the ITF we're trying to deploy scavenger traffic which can take advantage of the network as it's idle. Okay, so the new picture. We have our flow of packets and we tag them differently. They get passed through to routers. As they go through routers they get put into different queues. The different queues by the middle box means that the traffic is treated in a slightly different way. And we get our nice EF marked traffic all the way through our nice and quickly and everything else gets queued reasonably. So for this there are lots of different power hop behaviors we can talk about. QoS is implemented optionally for each hop on the network. So we have the default as I said. We have expedited forwarding which we would use for latency voice. And we have 12 classes of assured forwarding traffic. And these are set up in different priorities based on how you want things forwarded and how you want them to be treated in the network themselves. But all of these are implemented just depending on the hop itself. For the internet we implement differential services with what used to be the type of service field in the IP header. It's now being broken out and split down into a diff serve code point and the ECN bits. So we now have a six bit code for representing QoS. We have a two bit code that the network can use to signal congestion to a receiver which is great, you should look at it, but well out of scope. But because we're reusing an old field we get strange behaviors in the network. And we can't, whatever we do anything in the ITF which involves changing the wire protocol or the interpretation of bits, people suddenly ask is this going to work? Is it going to be deployable? Is it going to be blocked? ECN took years to get deployed at all on the internet because there were a lot of middle boxes that bleached the bits or dropped traffic with them set. With accurate ECN and fallback which was fixed. If this happens again for DSCP then QoS is going to be a long way from being deployable. So I am an academic so we did some tests and we wanted to figure out how code points that are being recommended for use now by the ITF are being treated on the internet. We want to see if there's any pass fail, if there's any number you can set in a DSCP that will stop packets getting through. And we wanted to verify that the treatment for each of these groups we have is fair for the groups. We can't tell if they are being treated correctly but we can tell if they are fair between the different groups themselves. On the internet we expect four different treatments for our packets. They pass through fine which is great. If all of DSCP marks always get through to the other end then we have something useful we can use. If they get dropped it's the opposite and we can never use this. More likely we are going to see bleaching of bits either the whole field set down to zero or certain sections from the old QoS field set down to zero and remarking on the internet is actually a great thing. It means that operators are actively processing the traffic based on what you are buying from them. This is what we thought we would look for. To generate a set of points we looked at drafts in the ITF right now. So there is an 802.11 draft which is trying to fix mapping from DSCP to 802.11 access classes. This one is quite an easy one but we are just trying to make sure all of the bits land the right way. If you want to go today and use DSCP for QoS you will get benefit from this straight away. Your Linux wireless router does this. It's great. Your FreeBSD wireless router does this. It's great. Anything else I don't know. Give me the code. MPLS is the core protocol on the internet. It's used for lots of interconnects. And unlike 802.11 where they are really nice and they don't touch our packets, MPLS reads the IP header, generates a label, takes it through the network and then resets the IP header based on the label that gets through the other end. So MPLS networks change lots of IP headers as they pass traffic. Really troubling. And then the last one which will be common for everyone here will be WebRTC. There is a draft right now for QoS setting on WebRTC. It offers 12 points I think. So you can set one of three types and then four priorities for each of them. There's implementation in Chrome. There's nothing in Firefox. If you want this implemented in Firefox there is a bug tracker list. I had confirmed this week if people bother them they will do this. So if you want to bother these people it's great. So I went and read all of these. I generated this list of 21 points. If you can't really quickly you'll see there's more than 21 things here. And I've spilled these out into classes. So on the left we have our best effort default class. We have EF, nice fast latency stuff. And in brackets we have LBE. And this is an effort we're trying to do right now so we can have scavenger background traffic. We're not sure from the measurements we've done if this is going to be feasible. But if it is, it's really cool. I have graphs. So what we've done to generate these is we've done a sort of traceroute style ring search through the internet for a selection of hosts. We've done measurements right now I know from the course so from digital ocean servers to top 100 websites. We have a testbed called Monroe which has lots of 3G connected nodes in Spain, France, the UK, Norway. We're not sure on the measurements from those but they look quite promising. So this tool, it sets TTL low. Well the first thing it does is it tries reachability. It reaches, we do a TTL low and we send packets marked with a certain DSCP. When the TTL hits zero, routers will stop forwarding packets and they generate an ICMP time exceeded message. The time exceeded message contains the original IP header. This is so end hosts can reconstruct flows and we use this to detect where code points are changing in the network and what they are. So with this tool we can't actually see the far end. We can see one hop away but we can make quite a lot of conclusions from this. I just have two slides on this. I have 300 of these graphs I've sent this week but if you want to see them I can show you but they all look very similar. Yeah, so the one we expect, this is a graph for BE traffic. So this is a DSCP of zero set. The plot is showing the percentage of marks at the last hop and at the top we have average number of hops before first change and then average number of hops per path. So the paths were like seven or eight hops. Yeah, so this is the behaviour we expect to see. We see a lot of our BE traffic get through. Most of the remarking in the internet is bleaching down to zero anyway so this is a combined number we get. Well, that's three. The more interesting one is to look at CS1 which is DSCP8. This is what is being suggested right now by the ITF to use for scavenger traffic so you can use this as background. And we see 53% of it gets through but we see 45% of it is marked to BE. Now for most QoS classes it's actually okay to remark because you reduce priorities so you're not asking for something implicit but with this BE remarking we're getting promoted. Now if you started doing a Windows update and you only wanted it to have access to traffic when you're not trying to do useful stuff and it's getting remarked to BE in the network then you're going to see a lot more bandwidth use than you expected when your network might not be able to take advantage of this. Okay, the interesting one. All of the rest of the known code points look like this. So we see about 50% work. See about 13% get marked to BE and then we see some other bits. This is actual remarking. The other two are bleaching of bits based on the old IPTOS field. We couldn't figure out why so many routers in the internet were doing this until we went and looked at the Cisco config and the Cisco recommendation for switches and routers hasn't changed in a long time and the default rule just says leave these three bits, wipe these three bits and this is where we get traffic like this and we can see this consistently for all the marks we feed into the network. Okay, enough science. How do I use this? From C, you decide to use a DSCP. I've done this in hex because I like hex. Pick out an ECN. Shift your DSCP mark up two bits so we hide the ECN field or with your ECN value and you call a setsock opt. Great, nice and easy. The project I work on, we've decided that the CAPI is old and crusty and we need to fix this so I have something much bigger. And here we are. Here is... Looks easier. Yeah, so here's the picture we sent to the EU. And you get your mark. Yeah, yeah, bureaucracy. So this is what we sent to the EU. This stuff, I don't tell them but we're not going to do it. You do really like your address, right? Yeah, no, they'll never find out. So the new system offers a LibUV-based CAPI to the network. So we've taken LibUV and we've given it nicer networking primitives. We've also given it loads of magic. Underneath we use traditional sockets but we can also have a... We have a pluggable transport system so you can use any protocols. Currently we support UDP, TTP, SCTP, SCTP and user space as the forming protocols and we can do security transparently on top of all of these. So if you don't like open SSL, you don't have to use open SSL. You just give us a certificate and everything works. It's great. Yeah, this is a smaller picture but it's the same idea. Over on the left and right we have a diagnostic and statistics interface and on the right we have a policy interface. The neat system has a daemon that runs in the background and it gathers up interface statistics, interfaces as they come and go throughputs, successful connections, successful protocol probing and then we have a policy system that can use this gathered information to apply with heuristic based algorithms, selection choices for what you want to do. As an application you can say, I want datagrams and we can figure out if you can do SCTP and if you can't do SCTP then you get something and maybe it's UDP. Or you can say I need reliable transport, this is it and we'll do happy eyeballs choices between IPv4 and IPv6. SCTP, TTP, we can do probing for security on the server so the applications will have to do it. We can do all of this cool magic so that things are automatic and they fall back so the API is nice and easy to use and I don't care about this one. This is what an application looks like. I've taken out all the error handling. We set up a context and we initialize it. We have a context as our main threading primitive. We're dealing with this right now if you want to follow our GitHub issues. We create a flow. The interface for a flow is the same for every transport. We set up properties. I left the old C bitmask we have to do properties via JSON. We set up some callbacks and then we do an open and the open does everything for you. You get your unconnected event and you have a working flow and you have a working connection and if you've asked for something reliable then you have a working stream protocol but we might have negotiated SCTP for you and you have multi-streaming loads of cool stuff. Read and writes. Do you have an example of the server side? The difference between the client and the server is the neat open is neat accept. Exactly the same. We do virtual accept for UDP. We have some stuff to make UDP look a bit more like a connected protocol and then it's all the same. It works great. Neat for QoS you can set the DSCP value directly because we didn't want to remove this for people who actually had an idea of what they wanted to do. You can set it by name or you can set it by abstract high level primitive. If an application asks for a high level QoS then we can do lots of interesting things. If we know your network is going to have issues with certain marks we can choose other marks. If you have multiple interfaces and you choose a QoS for low latency and you have a satellite link. We do a lot of satellite research. If you have a satellite link and a Wi-Fi link then we can pick the Wi-Fi link for you while we set up the QoS. We have tons of hooks and integration into SDN infrastructure. If you choose a high level QoS in your data center and you have normal cheap links and you have expensive low latency links we can pick this for you and do automatic provisioning well together. All of our science is happening in the public. All of our papers are open access and available. The EU deliverables you don't want to read them but you could specify the architecture are all available online. All of our software development is happening in the open right now. We have public GitHub issue trackers, build bots. We will take patches from anyone. We want people to be involved and play with this. This is a really nice way to access the network and we can do so much more. Thank you. We have three minutes for questions. I think when you slide you're saying that about half internet will destroy the QoS header but if it doesn't destroy the QoS header how many of those people actually honor it? Perhal behaviors are a recommendation but if I set QoS and I'm at home and I have my home wireless router and I'm speaking to you and you have your home wireless router and my packet can get all the way across the internet the QoS header intact. Our home routers are going to use this for 802.11 access classes so we're going to get our traffic if we're doing EF for voice we're going to get into the highest priority bin so we will get QoS data through. What about the hops in between? The hops in between will do what they will. So they will ignore it? Well, they might ignore it. They might treat it differently. They might have their own values for dealing with this. There's a lot of active Q management that happens so it's probably going to be okay. I don't know. It would be nice to try. The problem with this is you can't stress the network and then see what happens. It's great at the endpoints so just that is a good enough reason to use it and if it gets through then it works great. So your library would it allow usage with other event groups or event reactors? If you have a run once we have an example application that does RTP streams with G streamer and we tie run once into the UV event loop so it gets run once for every spin of the UV event loop. If you have more suggestions I would love to hear them because it would be great to be able to integrate more. We have integration with Firefox right now which isn't public because they're weird but this is definitely embeddable and other stuff. Thank you so much for your presentation. Oh awesome, I have a t-shirt. I wore mine on Monday but yeah that's awesome. Yeah, well I have a microphone on. I'm curious as to if you need to make changes to it. We haven't actually, it's been okay? Oh yeah, that's good. Oh thank you, that's really nice. Can I pinch one of your stickers then? Yeah, you can take many. Would you like a bundle of them? I have a lot.