Transcript
[ Cheers ]
[ Applause ]
>> 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.
[ Applause ]
>> 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.
[ Applause ]
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.
[ Applause ]
>> 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.
[ Applause ]
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.
[ Applause ]