Good afternoon, ladies and gentleman. I hope you're having a good Apple Developer Conference so far. My name is Stuart Cheshire and we're going to be talking about networking. We have a lot of material to cover so let's get right to it. This is going to be a two-part session.

In part 1, I'm going to give you some status updates about technologies that have been in the works for many years. Explicit congestion notification is a new way to manage flows through the internet without the cost of packet loss, and IPv6, as I'm sure you're all aware, is the emerging protocol for the internet.

We're going to tell you about some changes in the networking stack on iOS and some new facilities that are now available in network extension. And then finally, we're going to give you some very exciting news about multipath protocols. The iPhones that we all have are inherently multi-path devices. They have multiple radios in them, and for the most part today we only use one radio at a time. It's time we started having multipath protocols for our multipath devices.

After the break, in part 2 we're going to talk about some new advances in the URL session, family of APIs. We're going to give some tips and guidance for best practices and we're going to give you some news updates on upcoming developments on the horizon. So let's start with ECN, Explicit Congestion Notification.

You sometimes hear people talk about a network being congested as if that's a bad thing, but the job for transport protocol is to send as much data as it can through the network, and the way it does that is by sending faster and faster and faster until it's sending too fast. In a sense, it's testing the network to destruction.

So if the networks are programmed correctly it should be congested. On any path between two devices there will be one link that has the lowest throughput, the lowest capacity, and that's the bottleneck link. And the job of the transport protocol is to work out its share of the bottleneck link.

If you're sending twelve megabits into a ten megabit link, inevitably something has got to go wrong. For a short time, the package can be buffered in memory but when the device runs out of memory, it has no choice but to lose packets. And when it loses packets, that is a clue to the sender that it was going too fast and it should slow down a bit.

The problem is that losing packets is a very expensive way of communicating that information to the sender. It took battery power to send those packets if they're coming from a wireless device. It used wireless spectrum, a network capacity, to send those packets. And when you drop them, they have to be retransmitted. Now, those packet losses and retransmissions are invisible to your application because TCP or the transport protocol just handles it.

Or I should say almost invisible. The loss is invisible but the delay it causes is not. Your application will end up waiting for that retransmitted data to arrive, and that causes a slower, more sluggish, user experience. With explicit congestion notification, when the bottleneck gateway notices that a queue is starting to form, it doesn't wait until it runs out of memory, it sets a bit in the IP packet header saying congestion experienced, and that serves as a hint to the sender to slow down a bit, and that lets the network adjust the senders rate without the cost of losing data.

One of the side of effects of ECN is it also encourages deployment of smarter queuing algorithms in the network, which is also a good thing. If you have a very simple-minded device with a single shared first-in, first-out queue that fills up the queue until it runs out of memory.

When the next packet arrives it has little choice. It has to lose data. So you can't really use ECN with a dumb 5-0 queue. You have to have smart queueing, and those intelligent queue algorithms that keep the queues short and signal congestion before it becomes very bad, that's what helps keep delays in the network minimized and eliminate buffer bloat.

There are three participants that have to cooperate to make ECN work, the clients, the servers, and the network itself. I'm very happy to tell you that in our latest survey of the Alexa top million websites, almost three-quarters of them already support ECN. Now for the most part, this was not because the website administrator made a conscious decision to support ECN, it's simply because it's part of the default Linux kernel, so they get it for free. But the good news is almost three-quarters of the Alexa top million websites already support ECN, so that's the servers taken care of.

On the client side, we have been experimenting at Apple. In iOS 10.3, for all eligible TCP connections on Wi-Fi, Ethernet and selected mobile carriers, we toss a coin and half of the TCP connections will request ECN. We did this to gauge whether the internet was safe for ECN. Five years ago, this experiment would probably have produced different results. There were old firewalls and middle boxes that might have got confused by the ECN bits.

The good news is we did this experiment on a massive scale worldwide and we didn't hear any news, we didn't hear any customer complaints that the internet was broken. In the AWD metrics that gathered ourselves to monitor how the devices were performing, we saw no discernable difference in packet loss, retransmission, reordering, any of the other metrics that we care about. So it would appear that the internet is now safe for ECN.

Now we were not expecting to see any actual congestion marking happening because until the clients and servers are doing ECN, there's an awful lot of incentive for the network operators to start deploying it. And indeed, we saw very little congestion marking in most of the world. But then we looked a bit further and we saw in Mexico of all the device reports we collected 3% of them had seen at least one congestion experience mark on a packet.

In France it was 6%. In Argentina it was 30%. I'm not sure what they're doing in Argentina, but it would appear that they've already started deploying ECN, and if that's true keep up the good work Argentina. That's fantastic. So to summarize, servers are supporting ECN, clients are supporting ECN, and in iOS 11 now that we've determined it's safe, 100% of eligible connections will be using ECN, on Wi-Fi, Ethernet, and selected carriers. If you work for a carrier and you're not in this program, contact your carrier relations person at Apple and they can get you signed into this program to support ECN on your networks too.

So now the stage is set. The clients are doing it. The servers are doing it. Any ISP or network operator in the world can deploy ECN and see immediate user experience benefits for their users. One common misunderstanding about ECN is that it has to be supported end to end on the entire path across the internet, and that's not true. There is only one place that needs to support ECN for you to get the benefit.

As I said, on any path between two devices there is generally one link which is the bottleneck link, and for most of you at home with your residential internet connections that bottleneck link is an artificial one. You may have paid for 10 megabits or 20 megabits or 50 megabits of service and the way your ISP provides that service is they artificially throttle your data to the rate you've paid for.

So the one queue on your path for almost all connections is the one that exists at your ISP's headend equipment where they are artificially throttling your data. That is the only place on the path that needs to mark congestion by setting the bit instead of by discarding the packet, and your customers get the benefit of a faster more responsive internet. So with that, I would like to invite my colleague, David Schinazzi, to come up on stage and give you some more news updates.

Good afternoon, everyone. My name is David Schinazzi, I'm a core networking engineer here at Apple, and I'm going to start off by talking about IPv6, giving you a status update. And especially if you're writing apps that use the internet today, well you actually really care. So as some of you might know, yesterday was the 5th anniversary of World IPv6 launch.

So five years ago yesterday many content provider across the internet got together and enabled IPv6. And it worked well so they kept it on, but what's happened since? This is a graph of the client device adoption over the years. At the time less than 1% of devices supported IPv6. Now we're almost at 20%. And a really important point is that if you're writing apps for Apple devices, on the markets where we see most Apple devices these numbers are generally higher.

Especially in the case of cellular, almost all carriers that we work with now deploy dual stack, meaning that they offer both IPv4 and IPv6. And the great news is, it works better. So we've actually measured this based on a lot of the connections our devices make. The HTP request load in 15 to 30% faster, which means that if you actually have two apps side by side, you will notice the difference. Your customers will see a difference. So if you don't know if your server supports IPv6 today, definitely check, contact your server team and make sure they support IPv6. You can't afford to let this performance wane on the table.

Another important trend that I like to talk about is NAT64. So we started talking about this at WWDC two years ago, and then we made it an app store requirement last year but now it's here. It's in production for several months now on a major carrier in the U.S., every single device is v6 only.

They don't have an IPv4 address, they can only talk using IPv6. So that doesn't mean that you can't talk to v4 servers. Thanks to a box on the network called the NAT64, devices can still connect to those servers, however, you're not getting the performance benefits that we're talking about by using v6 natively.

However, what's really important is that the app needs to make sure it supports IPv6. If it tries to connect to IPv4, that will not work. So how do you do that? It's very simple. If you use our higher level API such as URLSession CFNetwork, the system libraries do all the heavy lifting for you.

You don't need to worry about IPv4, IPv6, any of that. It just works. What you really want to avoid is using Legacy IPv4 on the APIs, directly typing in an IPv4 address into your app, or using preflight checks. For example, if you check if the device is IPv4 address before making connection, that won't work anymore.

And why -- another reason why you should really care is that this is an app review enforcement. It's required for any app, either new or an update, to get on the app store. Every one of them is tested on an IPv6 only NAT64 network, and if it doesn't work you will not make it onto the store.

However, I really want to congratulate all you developers because you've fixed all of your apps and we now almost never have to reject anything. So great job there. If you want more tips on how to really make sure everything works, there is a great section on the developer website called supporting IPv6 DNS64/NAT64 networks. Feel free to also join us in the labs tomorrow and Friday with any questions.

Now I'd like to switch gears and talk about networking on the device itself, and introduce something this year that we're calling user space networking. You're probably familiar with the traditional model of a networking stack where a lot of the hard work is done inside the kernel. So protocol such as Wi-Fi, IP, TCP are all handled inside the kernel. Then there's a boundary called the BSD socket API, and everything else is handled inside the app.

And by that I mean inside the app process, not necessarily inside your code. It could be inside system libraries, but protocols like HTP and TLS are handled inside that process. What we're introducing for the first time with iOS 11 is we're unifying everything inside the app. And what this means is that the protocols can interact much tighter and everything is more performant. We've actually noticed great CPU usage reductions which allows you to spend more time on animations, but also at the end of the day users have more battery life.

One point to note is that you will only be able to get this if you're using a high level IPI such as URLSession. You will not get these benefits if you're still using like a CBSD sockets. And another point that I would like to make about this is that Network Kernel Extensions, which rely on these legacy BSD sockets inside the kernel, will soon be deprecated. So if you're using those, please start right now transitioning to the network extension framework and come talk to us if you have any questions about this.

Speaking of the network extension framework, I'd like to introduce two new APIs this year regarding Wi-Fi configuration and extending DNS. So the new framework was introduced two years ago and was built with four main temples, NEVPNManager allows you to configure the VPN stack on the device. NETunnelProvider allow you to build your own customer VPN protocols.

NEHotspotHelper allow you to customize how your device authenticates to Wi-Fi hotspots. And finally, NEFilterProvider allows you to build a secure on-device content filter. I won't go into more details on these four parts of the API, however there's a great WWDC session from two years ago that goes into more detail. So let's dive into any hotspot configuration.

You may have had this experience before where you bought a really nice smart camera. You take it out of the box and it tells you, oh join this Wi-Fi network on your iPhone to be able to configure the app. And so in the app it tells you, oh go to settings, Wi-Fi, type it in, and that's pretty cumbersome. The user could mistype the password. They could also not remember where the settings app is. And we had a lot of requests from developers for a better solution for this. And what we've added is this simple API that allows you to do everything from the app.

Now the user never has to leave the app anymore, they just get a prompt to make sure they will actually want to do this. They click join, they associate to the Wi-Fi. Simple as that. You can even set up this API to be temporary. So if you're building a configuration app for a smart device, you only really want to be connected to that Wi-Fi if you're inside the app.

So if the user decides to leave your app and go do something else, the device will automatically disassociate from Wi-Fi and join -- rejoin their other Wi-Fi networks. You can also use this API for the traditional sense of using Wi-Fi. For example, if you're building an app for chain of cafes and would like your users to automatically join the Wi-Fi in these cafes.

And of course, the CPI supports all the modes of authentication that our Wi-Fi stack supports today. To show you just how easy this is, here's a little code sample for these two examples. So if you want to configure a camera, just create a configuration with the name of the Wi-Fi and the password.

Set the join one's property to indicate that you want to dissociate when the device -- when the user leaves your app, and just apply the configuration. Then check the result value for success. In the café use case which is even simpler, just create a configuration, apply it and you're done.

Now I'd like to talk about any DNS proxy provider. The CPL let's you customize how the iPhone or other iOS device interacts with DNS, so this API allows you to, in its simplest mode, simply redirect all the inquiries to a resolver that you own. For example, if that resolver has better features, or you can even use this to get the individual DNS queries and send them over a custom protocol such as DNS over TLS or DNS over GTP.

So that was an update on network extension this year. As a quick reminder, this is a very powerful API so it requires X-code capabilities and entitlements, and also user consent for everything it does. Now I would like to invite Christoph Paasch on the stage to talk about multipath devices.

Thank you, David. Hello, everybody. My name is Christoph Paasch. I'm a networking engineer at Apple, and I will show you the new technologies we have in iOS 11 that will improve the networking of your applications on mobile devices. So, you have all experienced it. You are using your application and your application is downloading something from the internet, and while you're using it, you are walking out of your home.

Now as you're walking out of your home, you're also walking farther away from your Wi-Fi access point, which basically means the connection that you have created on Wi-Fi is getting slower and slower, and ultimately your application is actually getting slower as well because it cannot download the content from the internet.

And it will only be able to continue again when you have then created a new connection over to cellular link. Now, the reason why this happens is because the protocols that I use today have been specified several decades ago and they have not been designed with mobile devices in mind.

Now at Apple, we are aware of this problem since several years now, and we have technologies in iOS that try to address exactly this scenario. We have Wi-Fi assist since iOS 9, and now in iOS 11 we are pushing this even farther. We are introducing a new multipath transport protocol that is called Multipath TCP, and we will open it as a public API in iOS 11.

Now, let's take a step back first and let's take a look at what are the scenarios that we are trying to address here. So when your phone is connected to a good Wi-Fi network, what will happen is you create a connection and you will only download from the Wi-Fi network. Now as your user is walking out of the Wi-Fi, walking away from it, what happens is the signal strength will get lower and lower, and the connection will get slower and ultimately it completely stops.

What happens then is you will need to -- if you want to keep on downloading your data, you will need to create a new connection on the cellular link and from that moment on you are good to go again and your application responds again to the data that is coming from the server.

If you want to handle this kind of scenario, inside your application at the application layer, there are quite a few things that you need to do. First, you will need to record everything that you are doing because you never know when Wi-Fi is going to drop out so you will need to remember what you have been doing and what were the request that are in flight. Second, you will need a way to detect that Wi-Fi is getting worse, so you need to somehow monitor the progress of the Wi-Fi connection.

Now, once you have finally detected that Wi-Fi, it's no longer available and can no longer deliver the service that you need, you will need to create a new connection over cellular. That means you need to do a DSN handshake, a TCP handshake, and a TLS handshake. And only after all those steps you can finally send your request over the cellular interface and your application can make progress again. Doing this at the application layer is very cumbersome and that's one of those scenarios that we want to address.

Let's take a look at another scenario. It's basically when you're in a very poor Wi-Fi scenario. For example, you're sitting in a café and you're connecting to the public hotspot. Now, usually this hotspot probably works very well, however, sometimes there is some other users also in this café and maybe one of them is downloading a huge file.

And because very often there's a lack of smart queue management in the network, this download of this huge file will create a large chunk of buffer bloat inside the network, and this buffer bloat is making all other internet connections also very slow. And so it means basically your application will no more be able to download the traffic from the data, from the internet.

If you want to address such kind of scenarios inside your application, you would want to basically create a connection on Wi-Fi and on cell, and as soon as you realize that Wi-Fi is no more good enough because the delay is just getting too high, you want to send a little bit of data over to cellular network so that you can make progress again. And as soon as Wi-Fi is getting better again, you want to switch all your traffic back to Wi-Fi. Doing this at the application layer would be extremely difficult.

So, this brings me to Wi-Fi Assist, which is a technology that we since iOS 9 and that tries to address these kind of scenarios. Wi-Fi Assist is triggered whenever we are in a marginal Wi-Fi scenario, which means the signal strength of Wi-Fi is very low. And whenever the phone and iOS is detecting this, what happens is we will play a fittest wins out contest which between Wi-Fi and cell.

So when you are creating a new connection, we will first attempt to create disconnection on Wi-Fi. And shortly after that where if this connection hasn't been established, we will go on and create a connection over cell so that way we are able-- if cellular data wins, we will start using the cellular link.

So this will include a little bit of cellular data usage and so as part of Wi-Fi Assist we are limiting the amount of data that your application could use as part of this scenario. We have had great success with using Wi-Fi Assist, because it is able to establish a connection even if Wi-Fi is not good enough.

And we have seen a great reduction in the terms of the number of data stalls. If your application is using the URLSession API, you will get Wi-Fi Assist for free. It is just going to work. You don't need to do any changes in your API. You don't need to do any changes inside the servers, it just works.

Now the thing with Wi-Fi Assist is that it does this at flow creation time. And as I explained earlier, once a flow is established it will stick to this interface. So if Wi-Fi Assist was used and for some reason the Wi-Fi interface won the race, this flow that has been established on a Wi-Fi interface is going to stay there.

So even if Wi-Fi afterwards is getting worse, this flow is going to get slower and slower and it will eventually stall. So, the only way to address this problem is by creating new protocol that is understood by the client and the server. And this brings me to Multipath TCP. Multipath TCP is the protocol that has been designed specifically for mobile devices.

Multipath TCP is specified by the IETF as a standard, and it provides the exact same service as TCP, which means it is a reliable byte stream service. So if you are using HTP, if you are using TLS, HTTPS, Multipath TCP can be used just for that. Additionally, it is built on top of TCP, so it benefits from the years and years of experience that we have with developing TCP. And it benefits from the reliability and from the congestion control that TCP is providing.

What it does on top of TCP is that it provides a way to seamlessly move traffic from the Wi-Fi interface over to the cellular interface whenever it realizes that Wi-Fi is not good enough, and it also allows to move the traffic back again so that your application is not consuming cellular data. It is also able to choose the best interface if you have a latency-sensitive and interactive flow.

So, let's dive a little bit deeper into Multipath TCP. If you are building your application on top of the URLSession API, Multipath TCP sits just below this. So as you'll layer, you don't really need to worry about those different interfaces. Now what happens is, when you are sending data, you're sending something through the URLSession API, this data will go through your URLSession over the MPTCP stack, and the MPTCP stack is in charge of scheduling this traffic over either Wi-Fi or the cellular link.

Now how does it do this scheduling over Wi-Fi and Cell, well it does this by creating the so-called TCP Subflows. Those TCP subflows, one for each interface are actually full-fledged TCP connections, and MPTCP is in charge of making sure that the data gets sent over either of them.

It is also in charge of creating and destroying those TCP subflows. So again, at your layer on top of your URLSession, you are not even aware of those subflows. MPTCP decides when to create those subflows and when to destroy them again. Now, Multipath TCP is actually not that new. We have been using it since several years now at Apple in iOS, and we are using since iOS 7 for Siri. Now, Siri is a very particular application.

Many people, when they are using it, they are actually walking out of their home because, for example, while walking out of their home they are asking Siri to send a message to a friend, for example. And so Siri is very often in this scenerio where Wi-Fi is getting worse and worse and ultimately the connection drops. Now the thing is, this connection that Siri created to send the data to the server and get a response back, this data, this connection, is very critical because if this connection breaks, the response is not going to come back.

And so it's also very time sensitive because the user is often literally looking at the phone and waiting for the response. And it's also a very low volume connection. There's not much data being sent. So even if we incur -- send a little bit of data over the cellular link, it is not going to be a lot of data, only a few kilobytes.

Now, because of all those free characteristics, the way we are using a Multipath TCP for Siri is in such a way that whenever a user uses Siri, we create a subflow over Wi-Fi and a TCP subflow over the cellular link. And we make those subflows ready to send the data right away so that we get a very low latency response. When we are scheduling traffic we will prefer the Wi-Fi link, but if we realize that the latency on the Wi-Fi link is too high to get a quick response back, then we do not hesitate to send traffic over the cellular link.

Now, during all of this for Multipath TCP we have seen great success. In one particular metric which we call the time to first word, which means the time it takes until the user sees the first spoken word appear on the screen, this metric has been reduced into worse-case scenario which means when Wi-Fi was very bad, which we call like the 95th percentile, this metric has been improved by 20%. So in terms of latency reduction, we were able to bring down the latency thanks, to Multipath TCP.

And also as users are typically walking out of the Wi-Fi zone when using Siri, we have reduced the amount of network failures, and we have reduced it by 5 times compared to when normal TCP was used. So, we have seen great success with Siri and we also received a lot requests from new developers that we should open up the API for Multipath TCP. Now, in iOS 11 we are making this step and we are opening up the API for you to start using it.

So in order to start using the API, there are three things that I will have to talk to you about it, and I would come to each of them in a minute. First of all, because it's a new protocol we will need service support. Once you have the service support you can start to choose which of your connections would benefit from MPTCP.

And then once we've chosen the connections, you can then as a third step start opting into the URLSession API. So let's start with the server support for Multipath TCP. Now, it is a very new protocol and so by default most server infrastructures do not support Multipath TCP. This means that you will need to update or change your server infrastructure to start supporting Multipath TCP. However, there is good news. If you are using one of the many load balances from one of the famous venders, there's a very high chance that this vender already supports Multipath TCP.

So ask your server team, ask them to check the manual of the load balancer that they are using. Maybe ask the vender if they support Multipath TCP, and if they do all you have to do is you enable it in the configuration of your servers, and from that moment on you're good to go to start using Multipath TCP. If, however, you are using Linux on your server infrastructure, the mainstream Linux kernel doesn't yet support Multipath TCP, however there's the new Linux kernel which is available at this website that you can install and that will be able to provide Multipath TCP to your server infrastructure.

On this website, you will find AWS and instructions for Google Compute Engine to install Multipath TCP. And we are also working together with the open source community of this new Linux kernel to maintain it. And also we are working with the open source community to make this Multipath TCP code available in the mainstream kernel, so that all the distributions, all the Linux distributions are getting it by default.

Now if you have your server infrastructure and you have a bunch of backend servers that are sitting behind the load balancer, a Linux load balancer, all what you'll need to do in your server infrastructure to get Multipath TCP in this environment, is that you update the Linux kernel on this load balancer, you put an HTTP proxy on top of it like HAProxy or nginx, and from that moment on you're good to go and you can start using Multipath TCP.

So at the end of this week when you go back to your companies, go and talk to your server team and tell them to get the infrastructure ready for Multipath TCP. So, once you have your server infrastructure ready to go, then you can start looking at the connections that you have inside your applications and which one would benefit the most from Multipath TCP.

We are exposing the Multipath TCP service type which is providing two types of different services using MPTCP. The first one is the handover mode which provides a high reliability for your long length connections. The second is the interactive mode, the mode that we are using for Siri. And this one provides a low latency response for your interactive and latency sensitive connections.

So let's start with the handover mode. The handover mode is able to move traffic from Wi-Fi to cell and from cell back to Wi-Fi. Whenever you are in a network that has good Wi-Fi coverage and to choose to opt into the handover mode, what will happen is you will create a connection only on the Wi-Fi link and we will only be using the Wi-Fi link, no cellular data usage at all.

If however now the user is walking out of the Wi-Fi zone and the Wi-Fi signal is getting worse, when we realize that this is happening, we will bring up the cellular link and we will create a TCP subflow on the cellular interface, so from that moment on your application will be using the cellular data.

If now the user is walking back into good Wi-Fi, what happens is we will tear down the cellular link again and move all traffic back onto the Wi-Fi link. This allows us to basically minimize the cellular data usage at all cost. We encourage you to use it for your persistent and long length connections. Those kind of connections which you cannot easily restart or restart from the beginning, those connections would benefit the most from the handover mode.

Now, as I mentioned, Multipath TCP is being part of Wi-Fi Assist, and in Wi-Fi Assist we have limits that try to limit the amount of data that we are sending on the cellular link. So we encourage you to use the handover mode only for low volume connections, because if you hit the Wi-Fi Assist limit we will stop using the cellular link because we don't want your application to show up as the one that is consuming the most cellular data, so be mindful when you are choosing the handover mode for your connections.

Don't use it for your bulk data transfer where you are downloading gigabytes and gigabytes of data. And the handover mode is available right away in the first beta that you are getting since Monday. Now, let's get on to the interactive mode, the mode that is trying to reduce the latency for your latency sensitive and anti-active connections.

Whenever you're using the interactive mode, we will bring up both Wi-Fi and cell right away, even if Wi-Fi is in a good state, because we want to schedule the traffic in such a way so that we are reducing the latency. We will still prefer the Wi-Fi interface, but as soon as we realize Wi-Fi is not good enough, we will not hesitate to start sending data on the cellular link.

So use it for your very interactive latency sensitive flows, the kinds of flows that are not transmitting a lot of data, again, because we have the Wi-Fi Assist limit that we are applying and so if your flows are hitting this limit we will stop using the cellular link. Multipath TCP will try to reduce latency as much as it can for those kind of connections. It will incur some cellular data costs, and we will be giving this to you in an upcoming Beta release for you to start using it.

So now we have the server infrastructure, we have chosen which connections would benefit from the handover mode, which connections would benefit from the interactive mode. Now you can start using the URLSession configuration property to opt in your connections to this API. And we are exposing it in a very simple way. All what you need to do is you need to set the Multipath service type in your URLSession configuration property.

You can choose between the handover mode or the interactive mode, and from that point on you're good to go. Your connections will try to use Multipath TCP and they will benefit from it. Now in order to use it, you will need to add the capability Multipath in X-code so that you can start using it. Now, this brings me to one last thing that I need to talk about and this is the Aggregation Mode.

Now, imagine you're connected to Wi-Fi and it's providing you one megabyte per second in terms of throughput. On the other side you have cellular and it is also giving you one megabyte per second of throughput. Wouldn't it be good if you can combine both together into one big link that gives you two megabytes per seconds? Multipath TCP is providing exactly this. It allows for aggregate the capacities of multiple links into one byte connection.

So this Aggregation Mode is available to you for experimentation. And why is it experimentation? Well, if we are aggregating the capacities of both links together, we are consuming quite a little bit of cellular data. So we want you to think about what kind of connections do you have in your application that would benefit from a little bit higher throughput, at the cost of cellular data usage? If you want to use the Aggregation Mode, what you need to do is you go into developer settings on your phones, you flip the switch to enable the aggregation mode, and from that moment on you can start experimenting with the aggregation URLSession configuration property. This mode on customer devices, it will not be available. So you can start experimenting with the Aggregation Mode in an upcoming Beta release. So, let's recap.

In iOS we are very well aware of this problem of using multiple interfaces on mobile devices. We have Wi-Fi Assist since iOS 9, and we see a great benefit in using Wi-Fi Assist. Now in iOS 11, we are pushing this even farther. We are adding Multipath protocols into Wi-Fi Assist. And this protocol Multipath TCP is open as a public API in iOS 11. You can use it for the handover mode or for the Interactive Mode to improve your user experience inside your applications.

So with this, you will now have a little break. This was the first part of the networking session. After the break, you will get the second part. In this second part we will talking about new exciting APIs at URLSession layer that will improve the networking for your applications. Thank you.