Welcome to Networking In-Debt session. My name is Anil Vempati. I'm the manager of CoreOS networking team. So in this session we will be covering a few networking topics in depth. The first of the topics is IPv6. So you'll get to hear IPv6 in a nutshell and the things you need to know as developers and what is happening with IPv6 and also some of the recent improvements in iOS 5 and OS X Lion.

Then we'll go over some changes under the hood. And by this we mean is that networking APIs themselves haven't changed, but a lot of underlying functionality has. So we want to give you a preview of what to expect with iOS 5 and Lion. So if you see any different behavior, you can understand it and deal with it better.

Also, iOS 4 introduced multitasking. What that means is if your app has a network connection open and the user switches to another app, then what happens to the connection that was open? What are the things you may need to do after your app gets resumed? These topics will be covered in the backgrounded connections section, a part of it.

Then we have a couple of interesting tools, one for simulating more realistic network conditions so you can test your apps in realistic conditions before they're ready for prime time. And then we have a second app, a second tool for troubleshooting network connections. So these are the topics that will be covered in this session. So to get started, I'm going to hand it over to my colleague James Woodyatt to take you through IPv6.

Thank you. Thank you. My name is James Woodyatt. I'm an internet protocol droid in CoreOS Networking. And I'm here to talk about IPv6. And when I'm done in about 15 minutes, hopefully, you will all know why there has never been a better time than right now to get your apps to be IPv6 ready.

I'm also going to, in case you haven't been paying attention to IPv6 until it was clear that it was time to move, I'm going to give you the basic outline of what IPv6 is so that you're ready to get started. And finally I'm going to wrap up by telling you what's in iOS 5 and Mac OS X Lion to make it so that when you transition to IPv6 it will all be very seamless and ordinary users will never need to know about it.

I imagine most of you, for most of you, the only thing you really know about IPv6 is that it doesn't have 32-bit addresses like IPv4. But there's a lot more than that. And the reason we have to move to IPv6 is that when we first built out the internet, we didn't think it was going to last until 2011 with 32-bit addresses.

Anybody here ever tried to light up IPv6 on their home network? Wow, look at all those hands. Worked great, didn't it? You got to see the dancing turtle, and then after that you went, "Is that it?" Things are happening now. As you may have noticed, today is IPv6 day.

And what that means Oh come on, I didn't work that hard. What that means is that all the major content providers that you know like Google and Bing and Facebook, Yahoo, CNN, a whole bunch of them all turned up production ready IPv6 service on their front pages for 24 straight hours.

Now why would they do this? The reason they need to do this is that They need to figure out how to get their services over IPv6 instead of what the service providers, many of them who are resisting IPv6, would rather they do, which is cope with the fact that service providers are going to start aggregating subscribers behind carrier grade NAT and then telling content providers, perhaps you should think about locating your plex inside our address realm. And they're saying, well, we'd rather actually get to IPv6 first.

This is making the service providers in turn have to move to bring up dual stack IPv6 service. So if you've been following the news, you may have noticed that Comcast is trialing IPv6 dual stack networks in Colorado. And earlier this week they announced that they were going to be expanding their trial to San Francisco, Philadelphia, Chicago, and Miramar, Florida. And also you may have noticed that Verizon today will happily sell you a 3G wireless card for your MacBook Pro.

And then you can get IPv6 native service directly over that on Mac. That's a useful addition. And as I have seen when I've been participating with Apple in various interoperability events with the airport base station and seeing the various home gateways come through to these tests, I can see that... All of the major equipment vendors are adopting IPv6 capabilities so that they will be ready too. So with the service providers being pulled by the content providers and being pushed by the equipment vendors, IPv6 is happening now and it's time to get your apps ready.

So if you need to know about IPv6 because you've been waiting for everybody else to move, and now they have, let me give you a brief introduction so that when you're looking at making your apps IPv6 ready, you will know what you need to know about the protocol to make it happen.

So IPv6 is a lot like the original internet protocol. It still has the same basic BSD sockets API. You still open sockets, bind, listen, connect, send, receive, shut down. All of those are the same, but the socket address structures are a little different because they have bigger addresses in them. And the socket options that you use for controlling fields that are in the headers, they all change a little bit too.

But there are some important new things. Remember in IPv4 there was these addresses that looked like 10.0.foo.bar.desk and 192.168. Well, there's no equivalent of that in IPv6. The addresses are much larger. There's a universal routing realm. This means that if you have a routable address on your host, that routable address is globally unique.

You don't have to ask the network what address somebody else on the network should send to you. It's attached to your interfaces. And this has a couple of interesting follow-on consequences that I'll get into later. Also, there's an all-new internet control message protocol that replaces the one that's in IPv4.

And there's a bunch of features to that that I'll also talk about. I don't know if you saw that on another slide. But first I want to go back and talk about the address structures because, let's face it, the new addresses are kind of confusing. So they're a lot easier to understand if you know a few basic things. There's a hierarchical allocation model.

And the scopes are well defined. So in IPv4 the number space is sort of allocated by the IANA and then the regional registries and you get a subnet and you can split it up any way you want and when you're looking at an IPv4 address it's hard to tell which parts of it are what. Well with IPv6 that's a lot more standardized. And also part of that standardization is that the scopes are really well defined by the standard. So there's, and I'll talk about that in a little bit.

But first I want to tell you about the hierarchical allocation model. Here's an IPv4 address. It's 32 bits. It's pretty flat. There's not much you know about what's in it. But an IPv6 address is A, a lot larger, and B, it's really split into two parts. And this is important to know.

On the most significant bits are the network identifier, and the least significant bits, 64 bits, are reserved for your subnet mask. And hosts usually pick these addresses by any of several mechanisms. They can be derived from your Mac address. They can be manually configured. They can be assigned by a DHCP server. They can be randomly generated.

But the network IDs are allocated by the Internet Number Authority. Smaller blocks are carved out by the registries. Registries gives even smaller blocks to service providers. And then service providers give every subscriber a prefix that allows them to select usually some large number of subnets. And then each subnet has 64 bits of host ID.

So if you're looking at one of these big scary IPv6 addresses that's made out of hexadecimal numbers and separated with colons, it's easy to figure out what's going on here. There's a prefix that comes from your service provider, or you get it directly from the registry. Here's your subnet ID that as a subscriber you got to pick that. And then the rest of this, the number that I'm showing you here is a randomly generated one that I took off my desktop machine in Cupertino. And it's easy to figure out.

Going on further to talking about well-defined scopes, IPv6 has two scopes of unicast addresses. It's got link local scopes. In IPv4 those are 169.254.16, but in IPv6 they are the FE80 prefix. And what I'm showing you here is, A way that a TCP server that's listening on an IPv6 socket might initialize its socket address structure before it calls bind. You can see that there's the SYN6 adder field where you put in your host address if you're going to bind to a specific interface address. There's your port number. And then there's this third field in the socket address structure. This is important for link local addresses.

This is where you tell the socket address, "This address is for this interface." Because the scope of a link local address is just the link that it's connected to. Routable addresses, on the other hand, do come in a number of interesting flavors and it's worth knowing what they are. First there's the publicly routed addresses.

And then there's the unique local addresses, which are still global in scope, but they're not routed over the default free zone in the internet. They can be routed over bilateral agreements. And you'll also sometimes see them in Back to My Mac tunnel interfaces. Because Back to My Mac uses IPv6 inside the tunnel, and we use unique local addresses to address every host that's part of a Back to My Mac routing domain.

And lastly, you may also see some global scope addresses that are associated with the transition from IPv4 to dual stack IPv4/IPv6. And these include things like NAT64, protocol translation between the two protocols, v4 mapped addresses, which appear only on hosts, and the 6-to-4 and Teredo addresses. Lastly, there's a whole can of worms associated with multicast, but it's not really that bad.

And I'm going to have to ask you to look that up on your own time and consider it homework, but it's worth knowing about. Multicast is much more well-defined in IPv6. The new control message protocol. In IPv4, you have the address resolution protocol and a whole different protocol that you use over PPP links for configuring hosts with their addresses. But in IPv6, this all gets unified on the ICMPv6 protocol in a profile called Neighbor Discovery.

On routed interfaces, IPv6 addresses can be assigned by hosts themselves using router discovery, but DHCP is an option. Some networks will require DHCP for every host. Some networks won't offer DHCP at all. And some networks will offer DHCP in certain scale or stateless varieties or stateful for only those hosts that require individual configuration. But every host can usually find out about its, well, every host has to be able to find out about its routers through router discovery.

And finally, IPv6 has another interesting feature which is that IPv4 fragments packets at routers before they get forwarded, but IPv6 routers are not allowed to fragment packets. If a router gets a packet that it can't forward because the next link has a smaller MTU, it has to send back an ICMPv6 error message that says, "This packet is too big." Fragment at the host.

And that means that firewalls have to honor these ICMPv6 error messages, but the good news is that hosts get path MTU discovery for all of the transport layer protocols, not just TCP. And it's standard. You can rely on it. It needs to be there or IPv6 is broken.

So developers have a few things that they need to be aware of about IPv6 that make it a little different from IPv4. Because there's a universal routing realm, the network address translator from IPv4 that might be hiding your address and giving you a certain amount of privacy because your address is obscured from the global internet, well, your address is now global. And there's a different mechanism for protecting your privacy based on your address, and that means that your hosts may get renumbered more often.

This has much better support for automatic renumbering, but just be aware that your application may be sitting on a host that gets its addresses renumbered more frequently. Also, it's pretty normal for an IPv6 host to have multiple addresses per interface, and even multiple addresses per prefix. Routers might advertise more than one prefix, and your host may have more than one address for each prefix. So if you've got an app that iterates... ...through the list of interface addresses, be aware you're going to see a lot of addresses, and they'll be of different types.

I'll go into that in a little more detail later. And lastly, with IPv4, you kind of have to deal with NAT traversal a lot, and you might think that with IPv6 you don't have to deal with NAT traversal. But sadly, that's not quite true. As long as we've still got IPv4 in the real world, and we're going to have that for a long time, there are going to be these NAT64 protocol translators. And also, we've got proxies. And firewalls, and all of the usual things that can interfere with reachability by filtering the content of the network, even if they don't do protocol translation just to route.

put this slide here in my presentation because I wanted to take a brief break to recognize that In order to maintain this illusion that the internet is magic and that it just works, we have to really concentrate on the technology without really thinking too hard about all of the public relations associated with it. So it's important to not get distracted by what you might read in the press about IPv6.

Remember that the transition is really happening and the people inside this room right now are the ones that need to know about it. So keep an eye out for that. And if you want to go into more detail about IPv6, I'm going to go into a little bit more detail about it.

Everybody else outside this room is probably going to be better off if they never know that IPv6 is happening at all. So keep an eye on -- your job is to pay attention to the reality and the engineering problems of getting the transition to happen smoothly so that people outside who are just using your app don't have to care about whether they're using IPv4 or IPv6 or whatever.

So now I'm going to tell you about what we've got in iOS and in Mac OS X to make it possible for you to do it so that it looks like magic. First I'm going to start by telling you a bit about where IPv6 has been. It showed up in iOS in 3.2 when the iPad launched, but it's been in Mac OS X since the beginning. In iOS, IPv6 is just not visible in settings.

That doesn't mean it isn't there though. iOS devices will happily get addresses and use the IPv6 internet. There's IPv6 on the conference network here today. Your phones can surf to IPv6 websites. Try out ipv6.me if you don't believe me. But the settings don't show you anything about your IPv6 addresses.

If you'd like to find that information, there's probably great third party apps in the app store that should do that for you. In iOS 4.1 we improved it a bit so that you can get your DNS server addresses. Over the router advertisements using RFC 5006, we also added a stateless DHPv6 client for networks that might be operating in a v6 only mode.

iOS 4.3 added support for a stateful DHCPv6 client and temporary addresses. The temporary addresses are the way you get a certain amount of privacy in IPv6 that NAT provides you in IPv4. We randomly generate the host ID part of your address and add it to the network prefix that you're attached to. And we rotate those once a day and stop using them after a week so that when you move from one network to another, you'll have an address that isn't based on your hardware ID and you can't be tracked from hotspot to hotspot.

Now, in iOS 5 and 10.7 we have some improvements that I'd like to tell you about. First, we are routinely testing development builds of the operating system against the Tahi conformance suite, which is used for the IPv6 ready logo certification. And we've also taken great pains to make sure that all the apps that ship with iOS 5 and with Lion are as IPv6 ready as possible, so we're tracking all of that. We also run them on networks that are v6 only with a NAT64 translator.

We've also improved the way the system chooses destination addresses and source addresses for when they make a connection. We use the RFC 3484 default policy table as amended by recent internet drafts. And this helps if you're using, if you're coding directly to the POSIX API and using get adder info. This will definitely help make the transition more seamless.

My colleague Josh Graessley is going to come after me and tell you about the great new feature that is in the core foundation layers in CF socket stream where we will actually make concurrent TCP connections after making concurrent DNS lookups and we use the best connection available as quickly as possible.

So no more waiting for IPv6 to fail or IPv4 to fail before falling back to the other protocol. And we improved the sockets API to conform to the latest RFC from the IETF, RFC 3542. And I'll have some more detail about that in a minute. and the temporary addresses that I told you about in iOS 5, they're coming to Lion, so look for them there.

The new Sockets API has a couple of interesting things that you need to know about. It's not source code compatible with the older one. So if you've got an app that actually wants to use the special socket options that allow you to control the contents of the IPv6 headers and the extension headers, some of those options have semantics that are different. They have the same names, but they work differently.

Which means you may have to decorate your source code with pound-defined messages that say which one of these two APIs you're going to use. Because the kernel supports both, it's got binary compatibility for this. So you have to choose in your source code which one you're really using. And if you don't, then the compiler will probably complain about undefined symbols. If you still want to use the older API, same thing, you've got to put in the decoration.

Also, with these privacy addresses, you might be thinking to yourself, but I actually want to make an outbound flow, an outbound connection, using my persistent address rather than my temporary address. How do I do that? Well, there's a non-standard socket option we introduced that allows you to override for each socket when you do the bind, saying, I would like to prefer the persistent address.

It's also important to note that if you're iterating the list of interface addresses, that there's a flags field in the structures returned by that function. And on IPv6 addresses, those flags are actually going to tell you useful things. You'll know which ones are your temporary addresses. You'll also be able to tell which ones are tentative or deprecated, which are flags that come up when automatic renumbering happens and duplicate address detection.

So, if there is two things I want you to do after you leave here today, one of them is really go try to light up your home network with IPv6. It's good for developers to be early adopters of this stuff and one of the best ways to do that is get an airport base station or a time capsule and go get yourself a free account with tunnelbroker.net or 6access.net and configure your base station to terminate an IPv6 over IPv4 tunnel and get yourself up and running.

And the next thing I want you to do is if you've got any IPv4 only apps or apps that do networking and you haven't tested them on a v6 network, please get ready for IPv6. It's coming to a network near you and if you don't, your competitors will.

Three things I want you to remember, transition is happening. Please understand that most of your users don't care about IPv6 versus IPv4, they don't want to know, don't let them know. And if you can use the high level APIs that we provided that sort all of this out for you automatically, then absolutely do so. And for that I want to hand over the clicker to my colleague Josh Grassley who will tell you all about what's coming in those higher level APIs that are so great. Thanks.

Good morning. My name is Josh Graessley, and I'm going to tell you about some of the really cool things we've been doing under the covers to make networking work a lot better in iOS 5 and in Lion. So most of this work is all done down at the Unix-y Darwin Foundation. You don't have to make any changes if you're currently programming to the CF Networking Layer APIs or the Foundation APIs. You'll get to take advantage of all of this for free.

So we've got a number of changes. We've changed the way that we do address selection, both source address selection and destination address selection. We've changed the way that we handle Connect by Name. We've made it a lot more advanced in the event that we're using an API that lets you connect by name. We've added statistics for the network so we can get a better idea about how the network is performing and we can make better decisions about whether we should be using IPv4 or IPv6.

With iCloud we have a lot of extra background traffic that might be going on. So we've done a lot of work to introduce some throttling to make sure that whatever may be going on in the background, whether it's your application while it's in the background or iCloud traffic, that stuff is throttled so the foreground application remains responsive. We've also added some new TCP buffer sizing, which has some implications if you're working at the sockets layer.

Most of these changes were made to handle the dynamic environment that we find our devices in. We have devices that may be on multiple very different networks at the same time, cellular and Wi-Fi. We have a bunch of different kinds of networks that we can run into. We've got networks that have very fast and very good IPv4 connectivity, and networks that may not have such great IPv6 connectivity. For example, they may have IPv6, but it may be provided by a tunnel, and so v6 may be a little bit slower.

There are other edge cases that we find that we run into. Sometimes there are networks that have a device on the network that say, "Hey, I've got v6 connectivity. "Here's a prefix. "I'm the router. "Go ahead and send me traffic." And they don't actually have any way to get that traffic anywhere else, and they don't even let you know, "Hey, by the way, I wasn't able to deliver that." So you're just stuck waiting for things to time out.

Another thing that we've seen problems with is DNS, where we send out a query, which is the way of looking up an IPv6 record for a host name, and we never get an answer back. So we end up waiting for a timeout, which is a waste of time.

Eventually we'll probably have very fast IPv6 networks, and maybe v6 only networks, and v4 is only around as a legacy. But in the meantime we're going to have to handle moving between different networks where v6 may be better or v4 may be better, and communicating with hosts where a host may be on v4 and v6, but we don't know whether it's better to communicate with that host using v4 or v6. So we've done a lot of work to try and dynamically adjust to whatever environment we're in.

The first step was improving address selection. So we used the same API at the lower layer, get_enter_info. Get_enter_info takes a host name, so an application can tell the system, hey, I want to know what all the addresses are for this host name. And get_enter_info will do a DNS query for the v4 addresses and a separate DNS query for the v6 addresses. And when those queries come back, get_enter_info will then sort all of the addresses and try and put the best address to use at the very beginning of that list.

And it will return that to the application. And the application will usually pick one of those addresses and try and connect. The problem is if the first address returned by get_enter_info really isn't the best address, then it may take up to a minute for that connection attempt to time out. And most users won't wait around for a minute.

So we've changed the rules on how we do the sorting. Now we look into the routing statistics and we try and figure out about how long the round trip time is to each destination. And we'll go with the destination that has the lowest round trip time estimate. In the event that we don't have any statistics, we'll fall back to a very sophisticated policy table, which is based on an IETF draft, RFC 3484.

Most applications don't really want to connect to an address. What they want to connect to is a service, and they identify the service by specifying the host name of the host that the service is running on, as well as the port. And they have to do this in two different steps. The first step involves telling the operating system, here's a host name, please give me a list of addresses. But it doesn't tell the operating system what the application's going to do with those addresses.

And the next step is a bit arduous. It has to create a socket of the right address family, has to set options, and then it has to do the connect. And at those steps it just tells the system, I'm trying to connect to this address, but it doesn't tell the system what I'm really trying to do is get connected to this host.

So we've got a better way. Fortunately, we have an API already on the system, CF socket stream, that lets you specify a host name and a port. So it tells the system, I want to connect to this host name on this port, and now the system can do some very intelligent things.

So it's the same API as before, CFSocketStream, and everything built on top of CFSocketStream. Almost every CF network API or foundation layer networking API is based on top of CFSocketStream. there's some very new behavior. So in the past we would use getAdderInfo and it would do the v4 and the v6 queries and it would wait until those came back before it would give us any results. Now we perform the separate v4 and v6 queries and as soon as we get one of those answers back, we'll take all the addresses in that answer and we'll sort them and then we'll pick the best destination from that.

And we'll start a connection. And at the same time that we start a connection to that best address, we'll also look it up in the routing statistics and figure out about what the round trip time should be. So we have an idea of how long we should expect that connection to take and we'll set up a timer. So if that timer fires and the connection hasn't been established, we'll pick the next best address and we'll start a connection to that as well. So we'll have a bunch of concurrent TCP connections potentially going on at the same time.

We'll keep doing this until we run out of addresses or we end up with an established connection. So to look at how this solves some of the problems that we've run into, we have a diagram up here. Prior to Lion, in an environment where we had broken v6 DNS, where the DNS server wouldn't respond to quad A queries, we would have sent those v4 and v6 queries and we'd get the v4 answer back. And then we'd wait around because we didn't have the v6 answer yet.

And after some time out, we'd go, okay, we didn't get a v6 answer, let's go ahead and connect. But now we've wasted a lot of time. The user doesn't care if they connect over v4 or v6. So waiting around for that v6 answer really doesn't benefit them. On Lion, we send the v4 and the v6 answer -- the queries. We get the v6 -- sorry, the We connect to the v4 and we're done. The user's experience is much improved.

It's even more dramatic when we have a broken IPv6 network. There are some networks out there, like I said earlier, where some device on the network says, "I have v6 connectivity, please use this prefix "and send all the traffic to me." In that scenario, prior to Lion, we would send the v4 and the v6 DNS queries. We'd get the v4 and v6 DNS queries back, and then we'd sort them. We'd decide, okay, let's connect to the IPv6 address. So we send a send packet over IPv6, and we don't get any answer back. So we wait for a little time. We send another send.

We wait a little bit longer, send another send, and we keep doing this. So a minute later, we might finally get a timeout that says, "Okay, this isn't working out for us." Then we fall back to the V4 address, we send this in, we get the SYN act back, we've got a connection, we're ready to go.

But we've just wasted a whole minute. And I don't know about you, but I won't wait around for a minute. And when you're loading web pages, this is even worse because there are multiple connections involved. So that you have to wait a minute for each one of those connections.

On Lion, we have much better behavior. Send the V4 and V6 queries, we get the answers back, we sort the destinations, we decide, okay, we're gonna try IPv6 first. So we send the SYN, we also set up a timer. We send another SYN 'cause we haven't got an answer back yet. The timer fires, indicating we expected that we would have connected by now.

So we start a V4 connection as well, while that V6 connection is still going on. We get our V4 answer back, we've got a connection, we're all set. The user doesn't even notice that there's anything wrong on their network. The application on their phone or Mac responds, works very quickly.

It's a much better user experience. So to take advantage of this, all you have to do is use an API that lets you connect by name. The other advantage of this too, is because you're dealing with host names instead of addresses, you don't have to worry about the difference between IPv4 addresses and IPv6 addresses.

The APIs available to you are CFSocket Stream and anything built on top of that. So there's WebKit, NSURL connection, CFHTTP stream, and a lot of other APIs. When you're trying to pick which API to use, it's really important to try and pick the highest layer API available. The higher the level of the API, the more information your application gets to convey to the operating system about what it's really trying to do. For example, if you were trying to load some HTTP URL and you decided to do that with CFSocket stream, you tell it, I want to connect to this host name and port 80.

And then it would be up to you to put together all of the HTTP headers and parse all the responses and deal with proxies and everything else. If you move up to CFHTTP stream, that would handle all of the HTTP headers for you so you don't have to do the parsing of that. But it doesn't provide the automatic proxy support. So if you move up to an even higher level API, you can take advantage of the proxy support built into the operating system and it will handle everything for you.

In order to support all these new features, we've started collecting a lot more statistics inside of the kernel. So we keep track of performance of TCP sockets, of UDP sockets, as well as routes. Currently the only clients for this information are the Connect by Name API and a new command line tool online called NetTop.

NetTop actually started out as a debug tool for us to diagnose what kind of statistics we were collecting and making sure that our statistics looked correct. So I'm going to give you a quick demo of NetTop running on Lion. We found it was pretty useful, so we ended up shipping this tool with Lion.

So I'm going to run nettop-m. There's a man page. I know it's going to be a little bit hard to see. Unfortunately, it takes up the whole screen. But we can see-- and I will be talking about the process and each of the sockets underneath it. We have various information like the state, the packets, round trip times, lots of great information for figuring out what's going on in your network.

We can collapse it. Scroll down to the end, switch to delta mode and I can bring up and Safari. We can see all of this loads in real time. So here's our web process and all of the connections we've got established. You can see we actually connected over V6 some of the time. And then we can zoom in on San Francisco, maybe? Yeah.

and San Francisco. And we can see that on various sockets we're loading data as we scroll around and zoom in. So that's NetTop looking at sockets. We also have a routing mode where we can download We can look at the whole running table and all the statistics we've been collecting on all the hosts.

So we can see here we've got, and the default route, along with all the different hosts we've connected to over the default route, we have information about all the packets we've sent and bytes and we have things like the round trip times, we have statistics on how the default route itself is performing as well as some of the hosts that we're talking to.

So that's NetTop. I encourage you to go check that out. Oops. So in addition to all this network statistics, we've added network throttling. iOS 5 has a lot of cool features like all the iCloud stuff. But that can put a big load on the network. And we're very concerned that when your networking application is running in the foreground on the phone, we want it to be as responsive as possible. So in the event that you do have a networking application and it's running in the foreground, we'll go ahead and throttle all of the background traffic so that your application will remain responsive and the users will have a good experience.

We also needed to make sure that we didn't actually slow down the background traffic too much because if we cause the background traffic to take a longer period of time, then we have to keep the interfaces powered up in a high power mode which costs us electricity and the battery runs down faster and that's not good.

So there are a few conditions under which you will experience throttling. First, it's only going to happen to background applications and sockets, as well as sockets for iOS services that weren't initiated by the user. And then it will only ever be throttled if there is also a networking application in the foreground on iOS.

So we used two different techniques to handle this throttling. For the transmit side, we changed the way that we adjust the congestion window. Under normal operation, the congestion window starts out small. The congestion window controls how quickly TCP sends. TCP will start out with a small congestion window, which means send slowly, and it'll slowly grow it. So it'll basically send faster and faster and faster until there's some packet loss, and then it'll back off, and then it'll start sending faster again. And it does this to try and find the best throughput given the current network conditions.

In the event that we're throttling, we'll do what we would normally do where we grow the congestion with it slowly so we start sending faster and faster and faster. But we're also going to watch the round trip times because the round trip times have the biggest effect on the perceived responsiveness of the network.

So if those round trip times start to go up, we'll go ahead and slow down even before we hit packet loss. If we hit packet loss, we'll also slow down. But this should leave the network with pretty low round trip times so the foreground application will have a very responsive experience.

On the receive side, we adjust the receive window that we advertise to the remote sender. Normally the receive window is based on the receive socket buffer size. In the throttled case, we will actually measure the inter-packet delay variation and we will come up with an estimate of the round trip time and if the round trip time starts going up, we will advertise a smaller receive window so that the remote side will have to send slower.

So if you have a background process, you're going to go through a few different phases. When your process is first switched out of the foreground and goes into the background on iOS, for a short period of time, your application will be allowed to perform some operations. You get a chance to finish up your work. Normally you'll be going full bore. But if there is another application that comes into the foreground and that's a networking application, then your sockets will become throttled. So you may see slightly diminished performance.

After that short period of time where you're allowed to finish up your work, your application may be suspended. When it's suspended, the sockets will be shut down and the Bonjour records may be unregistered. What this means is when your application resumes again, it's really important to handle all the errors that you might get on your sockets.

If you try and perform any operation on one of these shut down sockets, you get a bunch of errors. You have to close the socket, create a new socket, and connect again. You may also need to re-register Bonjour records. There's a Bonjour session tomorrow that will cover that in much more detail.

The last new feature in iOS 5 that we're going to go over is TCP automatic socket buffer sizing. So a TCP socket has two socket buffers. There's a receive buffer and a send buffer. And normally these are set to fairly hard-coded values. But the buffers need to be large enough to handle a network that has high latency but very high throughput, but we don't want to make them too large or we end up potentially wasting a lot of kernel resources. So we've added code in iOS 5 to automatically resize the buffer based on the current round trip times and the current throughput that we're seeing.

This does require TCP timestamps in order to work properly. So if you're running a server that your application talks to please make sure that TCP timestamps are turned on. Also, if you're interacting at the socket layer with the socket and you're currently setting the SO send buff or SO receive buff socket options, those socket options tell the system, my send buffer or my receive buffer should be this size. And if you tell the system to use a specific size, the system will honor that request, but it means the system can't dynamically scale to whatever will perform best on the current network.

So to wrap up, if you can, use the highest level core foundation or foundation networking API possible. Convey as much information as possible to the networking stack. If you're already using these APIs, chances are your application already works with IPv6. If you have a networking application on iOS, it's really important to remember to add the UI requires persistent Wi-Fi property in your info P list.

This tells the system don't disassociate Wi-Fi after some period of time. It also tells the system when your application is in the foreground, the background traffic should be throttled. There is a power cost to this, though, so if you don't have a networking application, please don't set this.

Handle errors. You're going to run into errors when your application suspends and is resumed. You're going to run into errors as your application is running on a device that moves from cellular Wi-Fi or Mac, or MacBook that moves from Ethernet to Wi-Fi. Or even staying on the same network, you can have an IPv6 network renumbering event that can generate errors.

It's really important to handle these errors in the best way possible without getting the user involved for a very seamless experience. Finally, let the system pick the socket buffer sizes. The system will do a great job. It knows more about what's going on on the network than your application's likely to. So unless you absolutely need to, please don't use those socket options.

And while I've got your attention, I just wanted to remind you it's really important not to do any blocking network operations on the main thread. The main thread is really important for responding to the user quickly. If you have some blocking operation and it takes a while and the user is trying to scroll or do anything else in the UI, the UI is going to be unresponsive and that's really not a good experience. So to show you some of the tools available to help diagnose problems, I'd like to invite up Vincent Lubet.

Good morning. So I'm going to present a couple of tools, as Anil said, that were developed by the CoreOS Networking team, and I hope you'll find them useful. The first one is the Network Link Conditioner. So as its name implies, it's a tool that you can use on your Mac to emulate some networking conditions. So the idea is that when you start developing your app, you can, you know, often you develop in the comfort of your office.

Maybe you have a server on the same LAN with gigabit connection. Everything is fine. So over gigabit link, you know, it's very easy to do whatever. And also it's very easy to make mistakes that you're going to pay when you bring your application and, you know, get over Wi-Fi. Or even 3G networks and things like that.

So we developed that tool so that very early on when you start to develop your code, you can test, you know, into various network conditions. So that's the goal. And so NLC, or Network Link Conditioner, works for all application and, in fact, services on the Mac. And that also includes the simulator. So it's also for... for you iOS developers when you can... Before you test your application on the actual device, which is very, very important, this tool is not a substitute to actual real-world testing, but it's just a facility.

So what NLC can do? So it acts on all the traffic that comes in and out of your system, the APV4 traffic. It limits bandwidth, so based on the actual throughput, so it's going to, you can just set, you know, I want 10 kilobits per second. It can add delays to test with this latency that's really a limiting factor for most applications. You can add packet loss. Sometimes it's interesting, we found interesting to add some delays to DNS. And there are some side effects with that that may come. And you can specify different settings for uplink and downlink. You can simulate asynchronous links like DSL or things like that.

And you can create your own configuration and that's something I'm going to show you in a while. So the networking conditioner sits, you know, somewhere. It's a filter at the IP level in the networking stack. And it really affects all the traffic that goes in and out of your networking interface.

So to use that, we have a preference panel that you set up. You turn it on. And you can change some settings. And so when you turn it on, it's going to affect all the application, all the traffic going in and out of the apps of your system.

And that's what I'm going to show you. I'm going to switch to the demo machine. So to demonstrate that, I'm going to-- we wrote-- A little Cocoa application. So please, this is just a demo application. We are not UI. We are not Cocoa developers. We are more network guys. So this didn't go through any review. But it's just to show you what can happen in some case. So we have a little text field. And I'm running locally a web server. I can show you in the sharing panel. I'm running just a web sharing here.

So, and it's this demo, it's going to download that JPEG, it's a 3 megabit, or 3 megabyte file, sorry. And when you load it, it's very fast. And here, maybe you see at the bottom, the tab, it's making a blocking operation, but it's very fast, you know. We're doing the blocking, download, and SEL connection on the main thread, something that you shouldn't do. But, you know, on a fast network, it works pretty well. Now, if I bring the Network Link Conditioner, And just enter my password.

We have this little panel and that has some settings called profile. So we have a number, as you can see on the On your left, a number of preset profiles with some This is something that is kind of average representation of different conditions for 3G, Wi-Fi, DSL, Edge.

And here at the bottom I created a custom one, a custom that just adds delay. And it's going to add delay to all the traffic, whether it's on the loopback interface or Ethernet or anything. So I'm just adding 100 milliseconds delay for each direction. But because the packets, you know, it's going to travel, you know, a request response is going to take 400 milliseconds total time. Because it's going in, out, and back.

So now if I go back, clear the -- The screen, I have a little toggle button here that can show that the UI is responsive. And now when I have just adding that delay, a local connection is going to take a lot of time. And the UI is not responsive. I cannot type. And I just have to wait about 10 seconds for the download to complete.

If it's a non-blocking case, we have the other tab. I can do the same with the same 400 milliseconds round trip time. It's going to take about the same time, but while I'm here, the UI is still responsive. I can bring in the keyboard. The UI is still responsive. So that's kind of really the point that Josh made. Never, never make blocking operation in the main thread. Because latency that you just added is going to kill performance.

So with that, the summary for Networking Conditioner, it's a tool, it's just a facility to help you really develop your application and your networking, the logic of your network from the start. This is not a substitute for real-life testing, so also go out and test your application in various conditions. But also, the idea also is that we like to encourage you to be mindful of best networking practice. Do not block on the main thread.

Large I/O, so if you're doing bulk data transfer, do not read and write bytes one at a time. Even if it's sometimes it's easier to parse some traffic, do please use several K, 20, 30 K usually is good for bulk data transfer. And something that's very, very important, if you have a request response kind of protocol, try as much as you can to overlap the request and the response.

Do not wait for a reply to come before sending the next request. Thanks. So because the latency is going to add up and really, really bring a lot of delays. And it's always better to try to fill the pipe. TCP is going to behave much better if data is flowing than if it needs to restart for this transaction. So that was the networking condition now. So now I'm going to present something called the, thank you.

Another tool which we more for iOS developers. So it's new in iOS 5 and also it comes with the iOS 5 SDK. And it's simply a tool to, that enables you to capture traffic that go in and out of your iOS device. It's not possible to run something like TCP or Wireshark on an iPhone or an iPad, but with the help of a Mac you can now, you can with iOS 5, you can see what's going on on your device. And sometimes it's very useful to try to debug or diagnose what's going on with your application.

And how it works is that it creates, there's a little tool that you run on your Mac that's going to create a network interface to represent your iOS device that's attached by USB. And with that, because it's a networking interface, it will work with anything that uses BPF or lead pickup on your Mac. So you can run TCP dump, Wireshark or any other tools that uses BPF.

So what you need, so you need an iOS device, you have a Mac and a Mac and also USB cable that you need to plug. I didn't have time to show the plug, but the USB cable should be plugged to the iOS device and the Mac. And with that, I'm going to... Before going, it's relatively simple. There's a few steps to go through.

We have a command and tool on the Mac that's called RVI control. RVI stands for Remote Virtual Interface. And you can start and you pass the UDID of your iOS device that you can get, for example, in the Xcode organizer. And then after you can look what's, you know, the network, this virtual network interface that has been created with IFconfig. So you type IFconfig, you will see something called RVI, you know, and the number. You can attach more than one iOS device.

That's why the name is not fixed. And after you can run TCP dump or Wireshark. I'm going to show TCP dump. So you can run TCP dump. That's something we ship. And you pass the name of that interface. When you're done, you can simply pass the minus X option to RVI control and it's going to remove the virtual interface. and call back Anil to give a summary of the session.

To summarize the session then, you heard about IPv6, that IPv6 transition is underway. So please test your apps with IPv6 if you're not doing it already. There's a good chance they will be used in an IPv6-only network or with IPv4 and v6 on the network. So you want your apps to work great in that environment.

Changes under the hood. You saw the connect by name functionality. It's great. Take advantage of it by writing to the highest layer API possible so we can get as much information as possible and use it to give great experience for your app. NetTop is a great tool that's online. It can give you a preview of what the networking stack sees.

So again, take advantage of that. And background connections, now you know how they work. So be prepared to clean up and reestablish your connections after resuming. And also the socket buffer resizing. The system tries to do the smartest thing possible for the network environment. So that's a great takeaway. Don't set the socket buffer sizes unless you really have to and you think that's the right thing for that network.

And the two tools that you heard about, Network Link Conditioner, please use it early and often during development cycle. Not a substitute for real-world testing, but before your app is ready for the real spin, taking it for a real spin, you can see how it might perform in a lossy Wi-Fi environment or a 3G DSL and so forth, which is where your apps will be run by the users. So this is an early development tool for simulating realistic conditions. And then Remote Packet Capture, as you just saw, it can give you an idea of what the packets that are flowing in and out of the iOS device. Here's more information about networking in general.

These slides will be available shortly, so you don't have to write any of this down. But this information is there. The related sessions, there was one yesterday which went over the networking key principles. There's another one tomorrow on Bonjour, same place, same room. And with that, thank you very much for your time.