WWDC2016 Session 714

Transcript

[ Music ]
[ Applause ]
>> Good afternoon,
ladies and gentlemen.
It's great to see
so many people here.
How many of you are here
for the first time at WWDC?
Wow! That's incredible.
Well, welcome.
I hope WWDC is going
well for you.
Now we're going to talk
about some networking topics.
I've got five things
to cover today.
We're going to give
you an update
on Explicit Congestion
Notification
that we talked about last year.
We're going to give you an
update in the progress on IPv6.
We're going to talk a little
bit about international text,
We're going to talk a little
bit about international text,
which is becoming
increasingly important.
We're going to explore
how you control access
to network interfaces
to avoid running
up big data bills
for your customers.
And we're going to finish
off with some discussion
of network quality of service.
You may have heard
about the Apple Cisco
Fastlane announcement.
We're going to talk a
little bit about how
that might apply to
your applications.
So let's start with ECN.
To recap from last year,
we showed how Smart
Queue Management
and marking packets instead of
dropping them can lower latency,
reduce delays due
to retransmission,
and improve the user
experience for all applications,
and especially for things
like streaming video.
In iOS 9, we did not enable
ECN for TCP connections,
but in an unrelated change,
the VPN software would pay
attention to ECN markings.
We found one ISP in Germany
that marked all packets
"congestion experienced,"
which was bad for VPN.
The good news is they
fixed their network
within a couple of weeks.
We had no reports of any
problems anywhere else
in the world, and what that
tells us now is we rolled
out iOS all around the world,
found one problem, fixed it;
the Internet is now
safe for ECN.
And because of that, in iOS
9.3 and OS X El Capitan,
five percent of TCP connections
at random are using ECN,
and we're using this to gather
performance data and check
that the Internet
continues to be safe for ECN.
In the Developer Seed
that you have already,
In the Developer Seed
that you have already,
100 percent of Wi-Fi connections
and 100 percent of connections
on these three carriers
are now using ECN.
So last year, I reported
that 56 percent
of the Alexa top million
websites supported ECN,
which is a pretty
impressive support number
for a technology
no one was using.
I talked to my good friends
at ETH Zurich, and Brian,
Brian Trammell and
Mira Coolwind,
and their colleagues reran
the experiment for us.
This year the percentage
is up to 70 percent.
And if you only look at IPv6
sites, it's up to 83 percent.
So this is a call to
action to ISPs and carriers
and their vendors who
sell equipment to them.
The clients are now doing ECN.
The services are supporting ECN.
It's time for the
network in the middle
to start marking packets
instead of dropping them.
It gives you a better
user experience,
it reduces delays due
to retransmission,
and it makes more
efficient use of your network
because you are avoiding
wasted bandwidth
retransmitting packets.
Our next topic is IPv6.
World IPv6 launch was
four years ago last week,
and it continues to grow.
I looked at a variety of
statistics, and I'm going
to show you just a
small sampling here.
I looked at accesses to Apple's
home page but coming over IPv6.
In Belgium, it's now
up to 39 percent.
On T-Mobile USA, we're
up to 54 percent.
On Verizon, we're
up to 74 percent.
On Verizon, we're
up to 74 percent.
So it's pretty clear
now on these carriers
that IPv6 traffic
is the majority.
And the reason is clear.
IPv6 is simpler,
it's more reliable,
it's less expensive to operate.
So it's very clear why the
carriers want to move to IPv6.
But at what cost to
developers and customers?
Is IPv6 less mature?
Is it slower?
Is there less capacity
allocated to IPv6?
These are important
questions, and content providers
and developers pay
close attention to this.
They use statistics
gathering in the web browsers
to measure things like page
load times for every single one
of their users viewing the
web page and report that back,
so they can tell how well
their product is working
in different countries around
the world, different ISPs,
different carrier networks.
LinkedIn reports that now 10
percent of their traffic is
over IPv6, and they find the
page load time on average is 10
to 40 percent faster
than over IPv4.
They theorize that that
is due to less overhead,
setting up connections through
overloaded large scale NATs.
Facebook found similar results.
45 percent of their
traffic is now over IPv6,
and they reported recently
that on average ATP GET requests
are 15 percent faster over IPv6.
If you only look at the iPhone
data in that collection,
it turns out to be
30 percent over IPv6.
So IPv6 is better for
network operators.
It's better for users
and content providers.
And that's why Apple is 100
percent backing the move
And that's why Apple is 100
percent backing the move
to IPv6.
And you will have all seen
this announcement last month.
We announced last year we were
going to be requiring all apps
to be compatible
with IPv6 networks,
and we said we would be testing
all apps on our own IPv6 network
with the NAT64 Gateway.
Starting this month we started
enforcing that requirement,
and we looked very
closely for any evidence
that this was causing
an increase in the rate
of application rejection,
because if that were the case,
we would have to look into
it and work out what to do.
But the good news is,
look as hard as we can,
we don't find any change
in application rejection,
so what that really tell us is
that 99 percent of you have apps
that are working just
fine with IPv6 support,
which is what we expected,
but it's still really good
to have that confirmed.
Now, if you've had
an app rejected
Now, if you've had
an app rejected
and you think it might be to
do with IPv6, then come on down
to the labs today or tomorrow.
You can test your app here
at WWDC on the NAT64 network,
and we can help you troubleshoot
what might be going wrong.
Our advice continues to
be, as it always has been,
use the high level APIs that
are address-family agnostic.
If you have to use the
low level BSD APIs,
then there is extra work that
you are going to have to do,
which is why we really advise
using the high level APIs
that do that for you.
Another key piece of
advice is use hostnames,
not literal IPv4 addresses.
Because IPv4 addresses are
inherently tied to IPv4.
And let me give you a
little picture showing why.
This is a typical situation
from a few years ago.
This is a typical situation
from a few years ago.
You have a client on IPv4.
You have a server on IPv4.
The packets make their little
detour via the NAT Gateway,
and that's how you
connect to the server.
Nowadays, many more carriers
are rolling out IPv6 networks
with a NAT64 Gateway, and the
packets still make their little
detour through the NAT
Gateway and connect
to that old legacy IPv4
service on the Internet.
Now, if your data center guys
bring up dual-stack services
but you're still using
v4 literals in your apps,
then the packets are going
to make that same detour
through the NAT to get to the
v4 interface at the service.
But if you look up by hostname
and they put the IPv6
quota records into the DNS,
that's how you get the straight
through data path without going
through the NAT Gateway.
I talked about literal
addresses.
We now support using
IPv4 literal addresses
in selected APIs.
And if you use one
of those addresses,
we will actually do the DNS64
synthesis for you locally
on the device, create a
temporary IPv6 address
corresponding with your v4
service on the Internet,
and then connect through
the NAT64 Gateway.
Now, remember, using literal v4
addresses will prevent your app
from ever connecting
to an ATV6 server.
But that said, if that's what
you need to do for your app,
here is an example
of how you do it.
If you're writing
code using Swift
and the high layer
Cocoa APIs, this happens
for you automatically.
But if you're writing
UDP code today
and you're using BSD
sockets, the API you need
to use is getaddrinfo.
You pass in the address
you want to connect
to as a literal string.
You pass in the port you want.
Here https is a synonym
for port 443.
You loop through all
the addresses you get.
Remember, don't just
take the first one.
You'll get back an array of
multiple addresses to try, and,
of course, free the memory
when you're finished.
Another question we
get from developers is
about the Internet of things.
There are developers
writing apps that interact
with the device that
they don't make,
and some of those devices
are not very modern.
Now, we'd like those
devices to support IPv6.
And if they don't support
IPv6, we recommend that they
at least support IPv4
link-local addressing.
So even on a v6 only network,
devices can use v4 amongst
themselves to communicate
with link-local addressing.
Now, if the device
can't do either
Now, if the device
can't do either
of those things, that's okay.
Inform app review, when
you submit your app,
that is not grounds for
rejection of your app.
It probably is grounds
for putting one
of these stickers on the device.
[Laughter] And remember, all off
link communication still have
to be compatible
with IPv6 and NAT64.
So to summarize, we recommend
you support both IPv4 and IPv6
at both ends, in the
clients and the servers.
We recommend you use hostnames.
That way you can get a v4
address on a v4 network
and a v6 address
on a v6 network.
If you do need to use
literal addresses,
those are now supported
in select APIs,
as long as you do it properly.
But remember, imbedding
v4 literals will block
communication to v6
servers in the future.
So that brings us to our next
session, international text.
You may have started to
see things like this,
and if you're a native
English speaker,
this can look pretty
daunting and scary.
And what I want to talk
about today is how
simple this really is.
International support in
your application doesn't need
to be a big task.
In fact, it really is no
harder than supporting ASCII.
So even though the title of this
session is International Text
and Networking, really we
can scratch the networking.
For now I just want to talk
about how you support
international text in general.
I'm going to start
with some background.
Not because many of you will
need to encounter this day
to day, but I want to
de-mystify some of this
and make it less scary,
because it really isn't any more
complicated than ASCII.
So the first concept
we have is Unicode.
Unicode is a big list of
numbers, and corresponding
to each number a human
visible character,
and it's like a big
phone directory.
In fact, it is available
in book form.
It's a big, thick book
with page after page
of number and character.
And that's an abstract concept.
You have integers and you have
the characters they represent.
Now, to use those integers in
our computers, we need some way
of representing those
numbers, in memory,
on disk, over the network.
One way of representing
them is UTF-32,
which is just a 32-bit number.
And like any 32-bit number,
you have to be concerned
whether it's big endian
or little endian.
And it takes up four times
as much space as ASCII.
UTF-16 is more compact.
It uses 16-bit numbers.
It still has the same problem of
little endian versus big endian,
It still has the same problem of
little endian versus big endian,
and because it's only 16-bits,
it can only represent
65,000 values.
So you have to use
the surrogate pairs
to represent the values
outside that range.
So that's a bit cumbersome.
UTF-8 is an 8-bit
byte-oriented encoding.
Because of that, there
are no byte order issues,
and this is really what makes
it the ideal encoding to use.
So let's dive in a
bit deeper into UTF-8.
It was invented late night in
New Jersey 1992, and it's one
of those rare pieces of
computer science genius.
And when I first
heard about that,
I immediately saw,
this is the answer.
This solves the problem
for international text.
So I want to tell you guys a
little bit about how it works
so you can understand
how simple it is.
The Codepoints in Unicode from 0
to 7F are exactly the
same as the ASCII values.
to 7F are exactly the
same as the ASCII values.
And UTF represents them using
the exact same bytes in memory.
So what that means is if
you've got a disk full
of plain ASCII files, I can wave
my magic wand over it and say,
I declare you to be UTF-8.
Not a single byte
on disk changes.
The meaning of the
files doesn't change.
You have automatic backwards
compatibility with all
that legacy of ASCII, so
that is a wonderful thing.
UTF-16, UTF-32, other encodings
don't have that property.
For the values that are
outside the ASCII range,
they are represented as
multi-byte sequences.
But all those multi-byte
sequences only use byte values
above 128.
So there was no overlap
between the ASCII characters
and the multi-byte encodings
of the higher value
Unicode Codepoints.
That property is not
true of other encodings
that re-use the high code
bytes to mean something else.
that re-use the high code
bytes to mean something else.
UTF-8 has three flavors
of bytes.
It has the plain ASCII bytes.
If a byte starts with the
most significant bit being 0,
that tells you it's plain ASCII.
If the top two, three,
or four bits are 1s,
that tells you it's a two,
three, or four byte sequence.
And if the top bits are 1 0,
that tells you it's
a continuation
of a multi-byte sequence.
So I'll show that in context.
The ASCII characters
stand alone.
The bytes with two leading
1s signify two byte sequence.
Three leading 1s is a
three byte sequence.
Four leading 1s is a
four byte sequence.
And this gives it a wonderful
property that you can jump
into the middle of a UTF-8 file
anywhere, and by just looking
at any old byte, you can
tell what you've got.
Does this stand alone as ASCII?
Is this the start of
a multi-byte sequence?
Did I land in the middle of a
multi-byte sequence and I have
to skip forward or back to
find the character boundary?
So it's very, very robust to
insertion and deletion errors.
It's an encoding that is
efficient enough to be compact
but has just enough
redundancy to be very reliable.
Another useful property it
has is in an UTF encoding
of a string, there
are no 0 bytes.
And C treats 0 as the
string terminator,
so that's a very
useful property.
UTF-16 strings have
zeros all over the place.
And another nice property is
if you do a naive simple
byte-wise string sort
on UTF strings, they
sort in the same order
as if you sorted the
Unicode Codepoints directly.
So a whole bunch of really
wonderful properties,
and this is why just six years
after Ken Thompson invented it,
the IETF issued a document
saying that from then on,
all new Internet
standard protocols had
to work with UTF-8.
And that philosophy has
been embraced on the web.
Four years ago, Google did a
survey and found that 80 percent
of web pages were UTF-8, and
that includes a small percentage
that were old fashioned,
plain ASCII,
which is of course a
compatible subset of UTF-8.
Last month that number
is now up to 87 percent.
And because of that, the
W3C, just like the IETF,
also recommends that we only
use UTF-8 for everything.
And this is wonderful.
There is, however, one catch.
For some reason,
lost in history,
the DNS community
decided not to do that,
and they invented a
different encoding
that they call Punycode.
And Punycode re-uses
existing ASCII byte values
And Punycode re-uses
existing ASCII byte values
to mean different things.
So those are the byte
values that correspond
to letters, digits, and hyphens.
A result of this is that if
we have a block of bytes,
I can interpret those bytes as
ASCII values and get something
like that, or I can interpret
them as being Punycode encoding
and get what they're
meant to be.
And that dual interpretation
of the same bytes can
be very problematic,
because it becomes unclear what
you want to display to the user
or what the user meant.
If we contrast that with UTF-8,
the first thing you notice is
the encoding is more compact.
It takes fewer bytes,
and there's also only
one valid interpretation.
So there was no ambiguity there.
The good news for you guys
is you don't need to care
about this, because
we handle it for you.
about this, because
we handle it for you.
In iOS 9 and OS X El
Capitan, if you tried
to ping a UTF-8 hostname on the
command line, it would fail.
You type in UTF-8, those
characters pass through the tool
to the APIs on to the network,
but that name was not put
into the DNS as UTF-8
and it fails.
Starting now in iOS 10 and macOS
Sierra, the same ping command
on the command line with
the same UTF-8 input,
we will now translate that
automatically to Punycode,
do the query, and it
will be successful.
Now, here the ping command
is taking that Punycode
and displaying it as if it were
ASCII so you get this gibberish
on the screen instead of the
actual name that you meant,
and that's part of the problem
of having dual interpretations
of the same string.
of having dual interpretations
of the same string.
But the good news
is all the Bonjour
and DSA APIs will now accept
international text input
in UTF-8 format, because --
[ Applause ]
Thank you.
Because the Punycode
format is quite restrictive,
it doesn't support even simple
things like spaces in names,
and we use DNS for Bonjour
search discovery, we don't want
to be that restrictive.
So the way the algorithm works,
which is what's documented
in RFC 6763, we will
first try UTF-8 as is,
and if the DNS administrator
put UTF-8 into their zone file,
which is very easy to do, and
people were doing that back
in the '90s, we do the
query, we are successful,
we get the result,
everything is fine.
What's new now is that if we
fail, instead of giving up,
we will do one more try with
Punycode and see if that works.
So we support both
in the same API.
So we support both
in the same API.
Email addresses are
also becoming
internationalized today.
And this is also not hard to
do, but users face problems
for a silly, trivial reason.
Many apps, when you sign
up for an account or you go
onto the website to sign up for
an account, they try to validate
if the email address is valid
and they check whether it ends
in .com or things of that form.
And users with perfectly valid
email addresses are not allowed
to sign up for accounts because
their email address is rejected.
So we need to remove those
ill-advised validators.
Really the only thing
you can check
for in an email address is
it has to have an @ sign.
And if it's got that, it could
be a valid email address.
If you want to know if it's
valid, send a validation email
and have the user respond
to confirm that it's live.
If you're writing an email
client or an email server,
If you're writing an email
client or an email server,
there are a bunch of RFCs you
are going to need to look at.
But for the rest of you, you
don't need to worry about that.
Let the user enter their
email address as UTF-8,
stick it in your
customer database,
and have the mail server send
that out correctly encoding
with the email standards.
So to wrap up this section, we
recommend UTF-8 for everything.
Makes everything
so much simpler.
Don't worry about Punycode.
We handle it for you.
And be liberal about
accepting user input
in this new international
multi-lingual world.
That brings us to
interface selection.
Now, Wi-Fi Assist is something
that we introduced last year.
Really, this is not new.
This is the way things
have worked
since the very first iPhone.
If I have Wi-Fi, I want
my phone to use it.
If I don't have Wi-Fi, that's
why I pay for cellular data,
so I have network access
outside the home as well.
And the first iPhone did this.
What we changed last
year is we did it better.
We were smarter about
making that determination,
because there's always
this gray area right
on the edge of a Wi-Fi network.
And mobility factors
into this as well.
We have a situation that we
call the parking lot problem,
and it happens at the end of
the day when you leave work.
You leave the office, you get
your phone out, you have Wi-Fi,
you're walking out to the car
and you want to check maps
or weather forecasts or
look for movies or something
and your phone thought
it had Wi-Fi.
It had Wi-Fi a moment ago, but
you just walked out of range
and it hasn't realized yet.
With Wi-Fi Assist,
we will detect that.
We'll try to use Wi-Fi.
If it doesn't work, we'll
use cellular instead.
But like any new feature,
there's sometimes a tendency
for the new thing to be the
whipping boy that gets blamed
for people's problems.
Everybody hates it when
some app uses a ton of data
and they get a big bill
they weren't expecting,
and it's human nature to
blame the new feature.
But if you actually look
at your Wi-Fi Assist data,
you will probably find
they are very small.
Wi-Fi Assist is normally
not the problem here.
Now, apps have the switch.
If you don't want
that app using lots
of data, you can turn it off.
But that's very crude.
That's kind of an all
or nothing switch.
And a lot of apps want to do
something a bit more subtle.
Say you have a video
streaming app.
You may want the user to be
able to browse the catalog,
see little thumbnail pictures,
read the descriptions
over mobile data.
Doesn't cost very much.
But you may want the
setting in your app
But you may want the
setting in your app
that says don't stream
videos over mobile
because users may
not want to spend
that much money on mobile data.
And if you have that, you're
going to want to be able
to differentiate between getting
the thumbnail, which is allowed
over cellular, and streaming
the video, which is not.
A lot of developers have
done things like this.
They use the reachability
API to say, am I on cell?
Yes or no?
If I'm not on cell, go
ahead and do that download.
Well, things don't stay
the same in networking.
Things change from
second to second.
And between you checking
whether you're on cell
and actually doing
the connection,
the user may be walking
across the parking lot.
So this is not the
right way to do it.
The right way to do it
is to express your intent
to the networking layers, and
we will honor what you tell us.
The first step here is don't
bother with preflight checks.
The first step here is don't
bother with preflight checks.
If you want to do a network
transaction, just try it.
If that's a transaction that you
don't want to use cellular data,
then you can express that
to the networking layers.
Using the CoreMedia APIs,
you set the allow cellular
access key using NSURLSession.
If you set allows
cellular access to false,
then we won't use
cellular data connection.
Nice and simple.
[ Applause ]
If that connection fails,
you can ask the user,
do you want to stream this
video over mobile data,
or you can just wait, subscribe
for better route notifications,
and when the phone comes back on
Wi-Fi, you'll be told about it
and then you can retry your
connection once Wi-Fi is
available again.
So to summarize, don't
assume that because you're
So to summarize, don't
assume that because you're
on Wi-Fi now, you will still be
on Wi-Fi one second from now,
or even half a second from now.
Conditions change.
Express what you want
to the networking layers
and we will respect that.
Our last topic is
networking quality of service.
Last summer, we announced
a partnership between Cisco
and Apple, and I'm going to
tell you a little bit about one
of the new APIs that you can
use to express your needs
to the networking layers.
There are different kinds
of networking traffic.
99 percent of what
we do is good,
standard Internet
best effort traffic.
We want the best
throughput we can get,
and ideally we'd like low delay.
But we definitely want as
much throughput as we can get.
This supplies browsing
the web, sending an email.
Another thing that we
do is online backup,
uploading photos to iCloud.
And that also wants to have
good throughput, but not as good
as the priority stuff.
We'd like to be able to upload
all of our photos to iCloud
in the background without
disrupting our Netflix TV binge.
The photo upload should take
place when we're sleeping.
It is what we call
scavenger-class traffic.
It uses the otherwise idle
capacity of the network
that would otherwise have been
wasted, but it is second class
to sending emails,
browsing the web,
anything that the human
is actively involved with.
The third class of
traffic is telephony,
interactive voice and video.
And I say interactive,
because that's the key thing.
When we're having a
conversation, I speak,
you hear me, you respond,
you speak back, I hear you.
If that round-trip is more than
a couple hundred milliseconds,
human communication breaks down.
When people talk about voice and
video, it's important to realize
that watching a YouTube
video may be video,
but it's not interactive.
It doesn't need that sub 200
millisecond round-trip time.
Listening to a podcast
may be voice;
that doesn't mean a
podcast is voice traffic.
It's not interactive.
So that's why I labeled this
part of the chart telephony,
because this is interactive
voice and video.
For that traffic you want the
lowest round-trip time possible,
and it's very small throughput.
It's a few kilobits per second.
You don't need 50
megabits of voice.
So marking your traffic
as telephony tells the
network keep the latency low,
but you also don't
have a big queue.
If you try to do any kind of
bulk transfer as voice class,
you're going to lose
most of your packets,
because a very small amount
of the network capacity is
allocated for that traffic.
So one of our FAQ
questions people ask us,
will Fastlane make
my app faster?
And the answer is no, it
doesn't make it faster.
It will lower the
latency for voice traffic.
You may be wondering,
how does this relate
to the Smart Queue Management
and Explicit Congestion
Notification
that we were talking
about earlier?
And the answer is those
technologies improve the delay
for all traffic across
the board,
but telephony will probably
still be an extreme case
that wants the very,
very lowest latency
and doesn't mind sacrificing
throughput to get that.
Starting in iOS 5 we had the
network service type API,
and that lets you express some
of these needs to the network.
But many of the developers
writing apps like Skype
and Facetime that
are doing this kind
and Facetime that
are doing this kind
of voice telephony
are using UDP.
And to use UDP today on iOS, you
need to be using BSD sockets.
So we now have a socket option
that exposes the
same functionality
so your UDP clients
can benefit from this.
We know some developers had been
previously setting the IP type
of service bits in an attempt
to get the same effect.
The problem is those type
of service bits are
not well defined.
They are not specified anywhere.
Some Wi-Fi chip vendors will
look at the type of service bits
and use that as a hint to
set the Wi-Fi traffic class
to voice, video, background.
But the problem is with no
standard definition of the bits,
that interpretation
is not consistent.
So you may test it in your
office and think it works fine,
but for a customer, it
does something different.
And that's why we have
the new socket option
And that's why we have
the new socket option
that gives you reliable,
consistent behavior
across all devices.
If you're writing Swift code,
you can set the network
service type property
to voice, video, or background.
Or if you don't set it at all,
then that is traditional
best effort.
If you are using
the socket option,
we have the same options.
We have about another seven
more than this, which is more
than most of you will need.
These are the four
interesting ones.
When you set these options,
a couple of things happen.
On the device itself, there
are multiple outband queues,
and the type of service you set
for your traffic controls
which queue it uses.
On Wi-Fi interfaces, it
will also set the wireless
multi-media access category.
This is supported on all
devices, iOS and OS X,
and the outband queue
selection also applies
and the outband queue
selection also applies
for Ethernet as well as Wi-Fi.
Now, if your device is on one
of these new Cisco Fastlane
networks, we will recognize that
and we will also set the IP
layer differentiating services
Code Point so that you get
that handling that you want,
not just on the first
hop leaving the device
but in subsequent hops
through the enterprise network.
I want to stress this is not
something that you all need
to feel obliged to go
away and change your code.
If you're writing an
online backup app,
definitely set background
traffic class.
If you're writing the next
Skype, then set the voice class.
But for the rest of you,
standard best effort is almost
certainly what you want.
Some other things you
ought to remember:
The outband queue
selection and Wi-Fi layer,
quality of service marking
is supported on all devices,
quality of service marking
is supported on all devices,
but remember it only
applies to outband packets.
The packets coming in have
to be marked by the thing
at the other end sending them.
And the IP layer marking is
also only for outbound packets.
It's today only supported
on Cisco networks
with compatible hardware.
It's only on iOS.
It's not supported on Macs
or Apple TV or anything else.
And for now it's only
supported on Wi-Fi.
I know most people don't use
Ethernet with your iPads,
but if you do plug in
an Ethernet adaptor,
the quality of service is
not supported on Ethernet.
And finally if the
administrator chooses
to install a management
profile on the device,
then that management profile can
restrict which apps are allowed
to use this type of service
option, and only apps
that are listed in the
profile will be able
to set type of service.
It will be a no op
for all other apps.
So to summarize this section,
most of your traffic should
continue to be best effort.
If you are doing
large, bulk transfers
that are not time critical,
background traffic is a way
for you to be less disruptive
and be a better citizen
on the network.
Remember, it's not
a priority level.
There isn't a ranked
ordering here
of high priority
to low priority.
It's a web expressing whether
you want low throughput
and low latency or high
throughput and moderate latency.
So that ends our session.
Thank you for coming.
We've talked about Smart Queue
Management, and this is a call
to action to all the ISPs and
carriers and network vendors.
The clients are supporting ECN.
The servers are supporting ECN.
If you start marking the
packets in your network instead
of dropping them, you will
make your users much happier.
The message for developers
in the room is IPv6 is now
the majority of traffic
in the room is IPv6 is now
the majority of traffic
for many carriers
on many networks.
Support IPv6 in your
applications.
Support IPv6 and
IPv4 in your servers.
For your text, UTF-8
is the new ASCII.
It's no harder than ASCII.
It's really very
simple to use it.
All of our devices
now have good support
for all the Unicode
characters in the fonts,
so you should have no worries
about supporting UTF-8
without hesitation.
And finally, we have new ways
for you to express intent
to the networking layers.
You can control when you don't
want to use cellular data,
and you now also
have finer control
of the throughput latency
characteristics of your data.
So with that, there's a link
where you can find
more information.
We have other sessions
that you can watch on video
that you may find interesting.
We have sessions
about networking
and security, which
is important.
We have a couple
of other sessions
about internationalization.
We have some sessions
about higher layer networking
applications, like HomeKit.
So with that, thank
you for coming to WWDC.
[ Applause ]