Good morning. Thank you for joining me this morning, bright and early. My name is Brett Halle. I'm the Senior Director of Engineering responsible for Kernel and Networking Technology. Today I want to spend a few minutes and chat with you a little bit about some of the new features and capabilities we've put in Lion and iOS 5 as well as talk about some of the key principles that you'll need to be thinking about as you're writing the next great app.

So first I think it's worth kind of putting ourselves in the right context that networking has really been part of the human experience for quite a while now. Whether you go back to something as archaic as the telegraph, you still dealt with many of the same challenges and problems. It still was never fast enough. You had to deal with compression of data. You had to deal with data loss. You had to deal with latency issues and being charged by the byte. The problems were very, very similar then as they are now.

Just the scale has changed. Certainly networking from the perspective that we care about really started in the '70s, certainly in the creation of Unix and certainly BSD and sockets and other things. There was a lot of technology that came together at that time, but it was all based on a model that was based on the idea of the technology that we had at that time. It was a model where the computers of that day were big. They took up large amounts of room, big air conditioning, generators and other things to help keep them alive, and a big coax cable coming out of the back that ended up hooking into the network.

There were lots of people who were involved in administrating it and making it all work and dealing with it when it didn't work right. It wasn't until the Macintosh really that networking became manageable by mere humans. It was possible to hook up something very easily using Apple Talk and hook a couple of computers or a set of computers and printers and things together and not worry about things like IP addresses and domain name registration or any of that kind of stuff. It was all about just hooking the computers together and using them and taking advantage of the services that were there.

It was really remarkably easy. Not terribly fast, but remarkably easy. Along came the iMac, and the real key advantage there was making the experience of getting on the Internet easy. Remember the ads of the day? It was all about how quick you could get from the box onto the Internet. If you remember, the computers of the day, certainly in the PC world, you had to deal with going out and buying a networking card and dealing with configuring.

I think there were things like IRQs and all sorts of stuff that had to be configured and config files and all sorts of stuff. The experience that we have has always, of course, been about making that experience easy and something that a user doesn't have to deal with.

iPhone came around and fundamentally changed the way we deal with the network. Up until that point, things were remarkably static, but the iPhone has really changed the way we experience the network. People take the Internet with them. It's in their pocket. They expect that experience. Certainly with the iPad, not only do you get that experience, but you get a very immersive multimedia experience to go with it.

People expect the ability of streaming video and being able to deal with things that are very interactive. That's all fine and interesting, but the scope of this has grown dramatically. We're now dealing with hundreds of millions of devices moving quickly towards billions of devices. When we started this little exercise of networking, it was a few thousand maybe, hundreds or thousands. We're now talking hundreds of millions and billions of devices.

It really proposes some particularly interesting challenges. Today, we're going to focus a little bit on the technology that all the networking capability of our systems are based on. We're going to talk about CoreOS networking in particular. This is where all the plumbing is for networking and all the core capabilities are. This foundation is common, is the same between iOS and Mac OS.

It's actually the same source code base that we use, the same engineers. We all build the same technology in both these levels. The things that we're going to talk about here really apply across the board. Certainly, the principles do. First, let's talk a little bit about what features we've been adding to Lion and iOS. We've not really added IPv6. We actually put IPv6 in back in 10.1, but you may have noticed, watched the news over the past few months, that we've somehow or another run out of IPv4 addresses, or at least kind of at the top level.

The reality is it's not something to panic about at this particular point, but it is becoming a bigger and bigger issue that v4 address space is really running out very quickly and that v6 is becoming more and more important by the day. You may be aware that tomorrow, in fact, is v6 day, where a number of sites on the Internet will be turning on v6 capability. It'll be interesting to see how well that goes, that experiment.

Again, we added v6 back in 10.1 and added support in iOS for mobile devices back in iOS 4. We've added a lot of support for mobile devices back in iOS 4. We've added a lot of updates to this code base with these releases coming up, particularly syncing up these code bases with the latest from Kame and BSD. There's an enormous amount of changes that came with that, support for a number of new features, things like RFC 506, which allows for using router advertisements to be able to get DNS information, as well as support for things like DHCV v6 stateful and stateless.

Stateful is DHCP like you would expect for v4, where addresses are vended out to the device. These are really only typically used now in enterprise environments where they want to manage their devices. We also support DHCP v6 stateless, which is just handing out of the ancillary information, again, like DNS and other things that are used to help configure the device.

For v6 configuration for most people is dealt through the mechanism of router advertising. It's an awful lot easier to deal with v6 configuration, but we've added ways to integrate better into the enterprise and other environments. Brett Halle For v6 configuration for most people is dealt through the mechanism of router advertising. It's an awful lot easier to deal with v6 configuration, but we've added ways to integrate better into the enterprise and other environments. so that you get anonymous connections.

We've put a lot of work in the plumbing for the system to support v6. Basically if you're using the CF socket stream APIs or above, we'll take advantage of actually picking the best route to use, whether v4 or v6, based on a number of different statistical analysis things that we do and performance analysis that we do for the connections so that we ensure that we get the best connection v4 or v6.

We don't specifically prioritize v4 or v6 over the other, but rather actually look to see which is the best connection. Why is this important? Because one of the challenges that we see in v6 adoption is that there are a lot of places where while you may have local v6 connectivity, somewhere along the way there's a tunnel or other mechanisms that are in place that aren't working very well. They're either very slow or they fail completely. And so using the mechanisms that we've put into the system now, we can ensure that the user actually gets the right experience regardless of the fact that infrastructure might be broken.

There's also new APIs for additional socket capabilities if you're writing to that level of the system to take advantage of some V6 specific capabilities. And frankly, we're feeling pretty comfortable about being completely ready for V6 day tomorrow. Certainly I encourage you to try out both Lion and iOS 5 for that. Another thing that we've been working on is something we call Captive Network Support. Now this is something we actually added a couple of releases ago to iOS.

A captive network is something very similar to what you see when you go to somewhere like Starbucks where you connect to the Wi-Fi, you open your web browser, and it comes up with a sheet that tells you to click OK to accept the terms or maybe put in information in case it's a paid Wi-Fi hotspot or something like that. These were designed for the experience of a laptop where a business user would go somewhere like a hotel or somewhere like a hotel and they would be able to access the information or somewhere of that nature.

They'd open it up and the first thing that they would do would be to go to their web browser. The reality is with these mobile devices, the web browser is most likely not the first connection point to the network. And the challenge with these walled garden captive network environments is that for the user, if they didn't go to the web browser, it would just sit there and wait for them until they did. So we added the capability into the system to detect when you're on a captive network and automatically make the necessary decisions in terms of either automatically connecting or bringing up a web sheet so that the user can interact as necessary with the hotspot environment.

We support a number of different protocols, Whisper as well as EAP Sim and others, depending on the environment that we're in. And the OS again is involved in detecting these particular environments and will remember captive networks that you've been to before and reconnect automatically the next time you go there. Support for this is now on Lion and brings parity between Lion and iOS. We also added support back in iOS 4 for SSL VPN.

There's basically a significant amount of OS level plumbing support to support this that we put in and we now have a number of clients that are available on iOS, Cisco, Juniper and F5 in particular. Each of them provides their own unique vendor specific feature set. Other clients are available via the App Store. This plumbing is now available on Lion as well.

The area where I think that's most interesting and certainly applies to everyone here is in the tool space. We've added a number of tools for you to take advantage of to make your network experience and development better. One of the first ones is NetTop. I'm sure all of you are familiar with using Top at the command line.

You bring it up and you can get a reasonably good idea of what processes are running on your system, potentially how memory is being used, how Mach ports and other things like that, resources are being consumed. We've ended up creating a tool for NetTop to be able to do that kind of analysis as well for your network experience.

So you bring this up, it'll show you all the connections that are currently active, it'll show you a sense of what kind of traffic activity is going on, when the new connections are being established, so that you can see in real time what's going on during different kinds of operations. It can be very, very helpful to you to run NetTop and then run your application and see what's actually going on and that the things that you're expecting to get opened up and connected to are actually occurring.

Another very important tool is the Network Link Conditioner. The Link Conditioner is a tool you run online which helps simulate real-world customer environments for networking. And what it does is it puts in place basically in line to the networking stack either delays, dropouts, other things to help simulate when the user is out in the real world.

Typically, we all have great connections when we're working and developing our software. Certainly at Apple, we have an awesome network. The challenge is that's really not the network our end users are dealing with. Most likely, they're in a situation, even like here, where there's a lot of people competing for a limited resource, where there may be bad connectivity or no connectivity. And that can be very difficult to deal with when you're writing your software because you're writing in this perfect environment.

The Network Link Conditioner allows you to select through pre-built profiles things like DSL, Edge, 3G, and that the apps that then run during that will behave as though you were on that kind of network, either with delays and latency or, again, packet drops or other things so that you can make sure that your application does the right thing.

If you're writing an iOS application, you can also use this particular tool in the simulator. It's a great opportunity to turn on the Network Link Conditioner and simulate an Edge or cell phone environment, run your app in the simulator, and see what's actually going to go on when you have situations like packet drop and others to make sure that your app deals with those error conditions appropriately. Lastly, we have a tool that we've added for iOS, which allows you to perform a remote packet capture.

Basically, this allows you to run your app on your iOS device hooked up to a Lion machine and be able to grab the packets that your iOS device is seeing and then analyze them with things like Wireshark and others to be able to, again, kind of deal with potential errors or other challenges that you might be seeing. Again, a very, very helpful tool for being able to get a better sense of what your application is actually dealing with. You can then capture all these packets, analyze them later, or analyze them again in real time with some of the tools that are available.

I encourage you to go to a session tomorrow which is the Cross Networking in Depth. This is tomorrow morning where we'll be demoing these tools and giving a lot more information about how to take advantage of them as well as a number of the other features that I've been talking about, additional support for V6, et cetera, that is part of both Lion and iOS.

Brett Halle I encourage you to go to a session tomorrow which is the Cross Networking in Depth. This is tomorrow morning where we'll be demoing these tools and giving a lot more information about how to take advantage of them as well as a number of the other features that I've been talking about, additional support for V6, et cetera, that is part of both Lion and iOS.

And when you couple that with the fact that there's, again, hundreds of thousands of apps out there and the fact that the great news is, is that a significant portion of them are now network enabled, that we have to deal with kind of the change in the way we think about networking and realize that mobility is no longer the exception to the way networking is done, but it's the norm. It's the reality that we have to deal with every day.

Again, just to kind of put it back in context, networking used to be very static. The original design of our networking stacks that we all know and love were built on machines that were big, that didn't get moved, where system administrators configured everything, where you had complete control of your networking environment. And also, you probably may remember that in that particular time, there wasn't DHCP.

So when you added a device to your network, you had to find the guy who knew what the available IP addresses were and what all the magic numbers were that you had to put in your configuration files. At best, it would take you quite a few minutes to be able to put together a network configuration, but most likely, if you didn't know what the information was, you had no hope. Again, everything used to be static. Certainly wasn't mobile. You're not about to put a VAX in your pocket.

The reality is of today though that the network is no longer static. Nothing is static anymore. The configuration changes can assume to be changed at any time. Signal strength, cell availability, Wi-Fi ability, whether you're in a public or private Wi-Fi hotspot, or whether you're connected to VPN. These are all part of what we deal with now and what really poses the interesting challenges that we have to deal with.

Brett Halle The goal for us, both us Apple and us as the community that provides applications and services to our collective customers, is that we need to preserve this illusion of magic for networking. I'm sure you all are familiar with this particular quote, but this is the challenge that is before us. Our job is to make all that complexity of networking seem like magic to the user.

So let's talk a little bit about some key principles that you should think about and put into play as you're working on your next great app or you're making the next version for iOS 5 or Lion. First thing to consider, and particularly given some of the things we talked about yesterday with services for iCloud, is that you really want to write to the highest level APIs that you can.

You get an enormous amount of benefit by doing so, by effectively future-proofing your application. You allow the framework and those level of systems to deal with the complexities of the network itself. So one of the benefits you get, for example, today is that you shouldn't have to deal with whether or not you're on an IPv4 network or an IPv6 network.

If you write to the right level of the system, CF network or above, and you don't make any assumptions, which you shouldn't be doing, you'll get this automatically, and as the Internet continues to make this transition, you'll get it for free. Don't depend on... Transport level details. The reality is that you don't know if the user is going to be connected to a Wi-Fi or 3G or on a laptop whether they're on a wired connection or not. Don't ever assume anything about those particular interfaces.

The reality is they may change or you may be fooled into what actually is going on. I'll give you an example. We happen to have shuttle buses that are provided for us as Apple employees for getting around the Bay Area. One of the benefits is there happens to be Wi-Fi on the bus that we can use and it's all great. From a device perspective, I'm connecting to a local Wi-Fi that's really fast.

What I don't realize from a device perspective is right behind it is a 3G connection and all those people on the bus are sharing it. So if I made an assumption that I'm on Wi-Fi and I have a great connection and what's happening is somewhere downstream I've actually got something that bottlenecks the connection, you're going to be completely fooled. Don't assume the transport means anything.

The other benefit of writing to the highest level API here is that you automatically get the benefits of the framework and the infrastructure improvements that we do. We did an awful lot in iOS 5 and in Lion. Believe me, we've got more on the plate that we are trying to deal with because of the way that this space is growing. And we want you to be able to take advantage of it.

And writing to the highest level you can, you'll get a lot for free. We do acknowledge, however, that one size does not fit all. That you're going to have applications where you have to deal with low-level APIs and low-level connections. Be aware, though, that you're going to have to deal with some of the challenges and complexities that come with it.

One thing to consider is don't assume that the network is free. These days the user could be connected anywhere. So they're 3G, they may be roaming, they may be in an environment where they're being charged by either bandwidth or by time. The Wi-Fi certainly could be fee-based if they're in a hotspot environment. They could be roaming. So any number of these situations can occur. Don't assume that it's free and therefore don't abuse the connection.

Take advantage of the fact that assuming that this costs money and that you should really try and narrow your usage model as much as you can, but still give a great experience. But also be aware that power isn't free here either. That when you use and make a network connection, particularly an iOS device, you're firing up potentially a radio that's consuming battery time. The network is also a limited resource.

I'm sure people in the big hall yesterday or today where you're in a large room, we're all trying to share one wireless network in here. And the reality is it's a very limited resource. If everybody just assumes they own it all, they're going to be in for a nasty surprise and probably a pretty bad experience. So think about the fact that from the user that they're dealing in situations like this as well.

Consider the ways you can compress your information. How you can take, instead of small packet, lots and lots. Lots of little small packets going out. How you can cluster your information in transmissions so that they're much more efficient. You should also consider caching things intelligently. If you can, possibly don't reload, download the same information every time you connect to the server or you connect to a service.

And really consider performance as a key part of the experience that you have for your applications. Particularly, understand the trade-off between bandwidth and latency. Depending on your... Depending on your application, frankly, I think in most cases, latency is actually the most important thing that you'll want to deal with. Latency is about responsiveness. It's how quick can I get the information there and back and be able to react to it.

Bandwidth certainly is important, particularly when, for example, you're streaming media, other things. Certainly, bandwidth is a great thing to be able to make sure that you can get the best experience there. But that is not what most of us tend to deal with. And so make sure that when you're writing... When you're writing an application, you're considering the impacts of latency in your design model. And then beware of what we call buffer bloat.

What we're seeing in terms of the experience on the internet as things grow is that cascading buffers, basically it's really cheap to add a few K, a few megabyte of buffers at various levels of the infrastructure. Each of them add, frankly, add latency and other delay into the experience of the network.

And certainly there's not a lot you can do about that. And if you're interested, by the way, in learning more about this, I encourage you to go to bufferbloat.net and read up on it. But there are things that you can do in your application to not have the same experience.

Buffers are great, but they are not the answer to your performance problems. Most of the time you can over-buffer your applications and then end up creating increased latency and, again, reduce the experience, the interactive experience that you're having. One of the things that we've added to iOS 5 and Lion is mechanisms to optimally allocate buffers as far as your TCP connections for the best performance.

We encourage you, again, if you're writing the higher level APIs, you'll get a lot of this benefit. But as well, when you're designing your network applications, think about the impact of putting lots of buffers between the user experience and your network experience. Deal with network errors. Again, back in the day when everything was very static, things didn't change an awful lot and you could kind of get away with not worrying about this.

It was a rare event. I can walk five feet down a hallway and my network experience will change dramatically. And the reality is that connections that I have are going to go down, packets are going to get dropped, timeouts are going to occur. This is just the reality of networking these days.

So you've got to be able to deal with these cases. Intelligently. Make sure as well, for example, that you're dealing with situations on iOS that you're backgrounding correctly. Because those will potentially create error conditions as well if you don't shut down things that you can. When you come back, or if you do come back, you may find your connections have been shut down for you in order to be able to deal with system resource issues.

From the user's perspective, they don't want to know about all these errors. Except in the rare cases. Where they've explicitly made a request to do something and you can't deliver it. They shouldn't know about all these details. Hide problems in the network whenever possible. Deal with them yourself and automatically.

Right to the highest level APIs, you'll get a lot for free. But if you have code that is written to low level APIs, you need to make sure that you're not making assumptions about address types or sizes because these days you may get either or multiple. If you're dealing yourself with DNS resolution, be prepared for the fact that you're going to get multiple address responses back.

You're going to get potentially multiple V4 and multiple V6 resolutions for a given DNS entry. And make sure that you're applying the right logic for determining them. Again, we encourage you to use the higher level APIs and we have other mechanisms that you can use to even make this experience a little bit better.

But be aware that these are the kinds of things you're going to have to deal with. And if you have open source or libraries that you're dependent on that are network based, don't assume that they're V6 capable. If they're code that you have, you may want to go back and look at them.

Chances are they may be a library you've been using for years. The rest of your app may all be ready, but you may have one little library that you're dependent on that isn't. And this is something that you need to be going to make a particular point of the test.

Lastly, I really encourage you to actually build a v6-only network. You can use a number of solutions today to be able to bridge v6 into v4 backbone networks, but at least so that your current application is dealing in a v6 environment and that the right thing happens and that you're comfortable it's going to work when the user deals with those kinds of situations.

Also, if you are providing a service or you're looking for services, Bonjour is definitely the way to go here. It's a dynamic world again. No one ever remembers an IP address, although I can certainly remember the time where I would have to memorize my v4 addresses. There's no way in the world I can possibly memorize an IPv6 address. They're big, gnarly, and there's just no way in the world you're going to be able to do that. Thank you.

Because Bonjour itself is agnostic to the transport. And then on top of all of that on Mac OS, you might want to be aware that there's this mechanism called the sleep proxy, which allows you to also be a good power citizen as well. If you have a service, for example, you know, if there's file sharing or screen sharing, but if you have a service that you're providing for Bonjour, you can still allow the machine to actually go fully to sleep.

And the sleep proxy mechanism is something that basically takes advantage of an Apple TV or an airport base station to make note of the services that your device will provide and wake it up using wake on LAN or wake on wireless capability as needed when that particular service is requested. Again, not only make sure that the user can find things, but that we don't have to keep these devices running and hot 24 hours a day.

Which leads right into the fact that power is actually as important, if not more important than performance. Maybe great that the user gets this great experience, but if the device only lasts a few minutes, it really doesn't do any good. One of the reasons that we've pushed so hard for the experience for things like the way applications are backgrounded and others is because the user expects that the device is going to last all day long. And we have to make sure that that experience is preserved.

So. The fact that you're dealing with a portable device means that you're dealing with batteries and that when you use the network that you are very possibly either powering up the radio or radios or keeping them hot and they certainly draw an awful lot of power. And that's fine if you're again, the point here is to have a great network experience, but there are things that you can do to help. For example, don't trickle data out over time. Little bits of data, you know, spread over time means that you're. You're effectively keeping the radio hot or active constantly and if possible burst your data together, reduce the amount of times that you need to bring up the radio.

You really have no way of being able to control of one that happens, but you can manage the way you deal with your traffic and connections and such to help let the system do that better. Take advantage of push notifications. Pulling the server every little bit is not always the right answer to do things.

There are ways to do this completely asynchronously and not keep radios and things hot. Take advantage of things like sleep proxy on on your desktop and laptop devices for services that you might be making available. But reachability APIs also play a big role here. There are ways that you can use that to determine both connectivity and stuff to make sure that you know your experience is good and to give hints to the system so that it knows how it's being used as well.

This leads right into. Again, dealing with the fact that change is going to happen. It's a reality of the environment that we're in the number of the interfaces that are available, whether you're cellular network is connected with your wife I connected or whether both are your signal strength and quality.

These things are going to change. Assume that in your design space. One thing that you can do to kind of help yourself here is because you have need to assume that there's going to be a lot of change. Don't leave connections open longer than you need to because it's very problematic.

It's very possible that the connection that you had is going to get dropped because the connection actually changed so long lived connections can be a problem unless you're ready to deal with the implications of a change. And again, use the reachability APIs here. It'll help you and notify you when there are changes that are occurring in the system when you've tried to make a connection to a particular service and that interface is down.

It can let you know that the interface is now available. Our connections are possible. So take advantage of the. So that it's not again in the user's face and that your app just deals automatically with these situations. If you do things using the facilities and services that are in the system, you really as an app developer, even though I've listed a lot of challenges, there's actually a small amount that you really should have to do.

There's a lot of the system will do for you. Take advantage of that. Let it do as much of the work as it can. The key to most of this is not making assumptions. The only assumption. The only assumption that you can make the only constant in life is change.

It's all about networking. Everything that we do, the experience that we provide our users is about giving them this sense of connectedness. It's about being able to provide network services and capabilities as part of your applications and add value to your customers. They expect a connected experience these days, regardless of the kind of app that you have.

So be prepared for dealing with the changes that are part of a highly mobile world. Write your app assuming that absolutely nothing is static when it comes to the network. Assume everything will change. And then test. Take advantage of the network link conditioner while you're writing your code, while you're developing your application to test during the design phase. Test in real world environments. And make sure that you create artificial environments that will test the kind of failures that you know are coming.

And it's all about, again, helping keep that illusion of magic for networking. We all know in this room that networking is hard. It's complicated and it's getting more complicated given all the challenges that exist. But there's a lot that we can do to keep this illusion of simplicity and we have got to do it together.

So with that, I want to point you to an evangelist if you've got more questions, Paul Danbold, and certainly the various forums and services, websites. But more importantly, there's a couple of sessions I really encourage you to go to. Tomorrow there's a Core OS Networking In-Depth where we'll get into some of the tools and new APIs in more detail and give you some demos. And as well, on Thursday there's a session on Bonjour and how to take advantage of network discovery and connectivity. With that, I thank you for coming and hope you have a great rest of the conference.