Surfing the Luminiferous Ether

Ryan McIntyre wrote about watching TV from a taxi on the way to the airport. (Parenthetically, I’ll note that Dulles is possibly my least favorite airport. I grew up in Chicago, so O’Hare was the formative airport of my youth. Let’s face it, I have really low standards for airports. Dulles is just bad.)

I’ve always been intrigued by the idea of a Slingbox, though I haven’t felt the need to run out and buy one. My TV is captured with a MythTV system, so I have full access to the recordings I make with it. I can either get a full-resolution video stream right away, or transcode videos down to a reasonable size for transport (a process which looks more attractive after my recent upgrade). The choice that I make tends to depend on how much video I need; when I was traveling throughout Asia in 2005, I tended to wait for the 300 MB/hour video so I could carry a huge amount with me on the plane. If I just want something to occupy my train ride between home and the office, I’ll take the uncompressed version.

The dependence of the Slingbox on a network connection has kept it from being useful to me, since my travels involve lots of airplane time, where there is no wireless WAN coverage, or international destinations, where the data roaming charges are far too high to spend the money on video transfer. With this sort of a usage, though, I can understand why it might be cool to have one. Transcoding takes a bunch of CPU time before the compressed video is prepared. Generally, when I want to pick up the transcoded video, I’m traveling internationally, so it’s not particularly onerous to wait the couple of hours it takes to prepare. However, if I were to travel to places that have smaller time-zone shifts, I might want the video faster than I could get it transcoded down to a small size.

I’m not ready to race out and buy one. My international travels keep me firmly entrenched in the GSM world, where the mobile data rates are a bit lower than the systems that are widely deployed in the U.S., and in any case, the charge for a high-speed mobile data link would result in a monster roaming charge.

I wonder how much longer this type of application will be possible. Though they are easier to add users to, and far easier to be in motion while connected to, wireless networks can be harder to expand in terms of capacity. The temptation with any shared last-hop type network is to sell as many subscriptions as possible, and to figure out the minimum required service level by managing the subscriber churn rate. I doubt that very few people will drop the service over a data rate that “only” reaches 400 kbps and is useful for everything but streaming video.

Another note: this type of story is why I have spent much of my career as what I affectionately describe as a “network plumber.” If you build the pipes, people always figure out how to use them.

On February 12, I went to check up on the status of the OpenMoko project. With my likely disappointment on the iPhone, I’ve been looking for a replacement for my aging four-year-old Nokia 6600. Based on my set of ideal features for an 802.11 phone, I’ve been looking seriously at the Nokia E series, but they are quite expensive. The recent announcement of the “i” models in the E series lineup (E61i, etc) has shifted my allegiance slightly. I’ve been working with an E series, but it has limited battery life and a flaky SIP stack. My thoughts increasingly turn towards OpenMoko, since it would embrace SIP and open telephony in a way that is still alien to the telcos and their big suppliers. Unfortunately, the project has been delayed a short while. There are good reasons for this, namely that the team is dedicated to having a completely open system from hardware specs up through the toolchain before finally getting to the phone software itself. All commendable, but it doesn’t make it sting any less.

One of the curses of OSS is that you must live your life in full view of the world with a transparency that is a bit jarring for those accustomed to hiding delays and flaws in commercial software. (I’ve come to the conclusion that big government IT projects are no worse than their corporate counterparts, just much easier to see. A similar analogy would seem to hold for open source projects.) I’d like to than Sean Moss-Pultz for his honesty. I still want the phone just as badly as I did before the delay was announced. Touching the phone last week at the Emerging Telephony conference only made my desire worse.

I’m writing this from the Red Carpet Club at the San Francisco airport, waiting for my first hop flight on a trip to Abu Dhabi. I’ve been invited to speak at the Education Without Borders conference on networking and access to technology. Here’s the abstract for my talk, which was inspired by Stewart Brand’s book How Buildings Learn:

Pervasive communication networks greatly increase our ability to share information, but this can sometimes come at a great cost. In physical architecture, the imperceptible slow change of the site and structure dominate the more fast-moving familiar processes that are easily visible to the users of building. The same is true in communication networks, where the social environment of a network’s users and its basic technology steer its future development path. Network engineering is mainly a technical discipline that attempts to optimize for the technology of today while remaining open to tomorrow’s developments. Defining what is optimal and should be maximized, however, is a social question that drives those engineering decisions.

We are in the midst of one of the most fundamental changes in the physical architecture of the Internet, with potential profound changes in its social effect. Most of the technology that underlies traditional Internet access is based on “fixed” networks built from expensive and inflexible cables. The physical architecture constrains network services to areas where the infrastructure is easy to build, keeping access concentrated in densely populated areas. Newer wireless technologies free network builders from technological dependence on cables, and from the financial constraints of needing to pay for costly infrastructure. These technologies enable the network to reach into remote locations that would have previously been considered “off-limits” to traditional technologies.

The resulting flexibility from wireless technologies is shifting the focus of innovation and use away from traditional markets for new technology towards emerging markets that benefit more from its advantages. Instead of importing designs and their implicit social models from existing networks, network builders need to ensure that these new technologies are used within the correct social context and are made broadly available.

The conference is doing a/v recording. I’ll definitely post my slides, and with luck, the audio and video.

One of the most annoying facets of the current market in the U.S. for mobile telephones is that the carriers control the market in a self-serving way. They build closed systems to extract as high an economic rent as possible. You want to be a bookmark on the default WAP screen? That’ll cost you. Phones are sold at a huge discount to get you hooked on the service, and then “locked” to that carrier so they can’t be used elsewhere. I’m assuming that the iPhone will be no different, especially since Apple has shown a willingness to trade away freedom on previous consumer electronics products.

In theory, the lock is supposed to be temporary until the carrier has recouped their subsidy. In practice, I find that most carriers use it as a way to keep you hostage. When I was a Cingular subscriber five years ago, I was told that I had bought the GSM phone to use with the “Cingular service,” and it was Cingular policy never to unlock phones. I’m sure that the then-current world roaming rate of $4.99/minute had nothing to do with the policy.

(Fortunately, it was a Nokia phone, so the unlock procedure is well understood and there are many unlocking tools available.)

The “control your customers and force feed them” model cuts against my entire experience, which is based on open systems and architectures. Innovation in entire handset business is constrained by the fact that the cell phone companies buy and promote the phones, not the manufacturers. Anything that does VoIP is a big threat to per-minute pricing, and therefore won’t be bought or actively promoted by the carrier.

With the carriers strangling new services and innovation in an attempt to ensure they are stillborn, there is one obvious way around it. If consumers were to purchase phones that were compatible with the carrier network, there is very little that a carrier can do about it. I had hoped that Apple would sell the iPhone directly to customers (in addition, perhaps, to the carrier channel). Apple is the one company that can build a product that people would head to the stores for, and perhaps shine a little bit of the light of open systems on to the mobile telephony world.

I’m not surprised Apple didn’t take on the telcos. They can still demonstrate their famous focus on usability by showing off the integrated voice mail system they developed with Cingular’s voice mail vendor. Using the carrier sales channel is going to move a lot more phones in the short-term, even though there is a much more diffuse long-term benefit of breaking the innovation choke-hold.

For the record, this is a bit of a wish on my part. I would love to have an iPhone, but Cingular’s mobile data plans ($79.99/month for unlimited) can’t touch the price of my T-Mobile plan ($30/month, for unlimited hot spot and EDGE). I can’t afford the service to move over to Cingular, but if the phone were made available in a non-locked model, I would be in the store on the first day with cash in hand. Fortunately for me, there is a true open mobile phone platform still to come.

This is an idea that’s been percolating for a while, but Dameon’s recent rant about how VoIP hardware is boring has triggered two responses.

One is that I have started explaining what I do with VoIP to the rest of the world as, “I have become my own telco.” If I want a service, I can define and implement it myself, without needing to wait for a big market to develop and catch the eye of the telco. (I did this recently to make Asterisk handle incoming telephone calls in a time-aware fashion for my international travels.)

But, more on point, I’m also excited by the proliferation of wireless LAN phones. The dual-mode phone is a way of communicating traditionally (with the cell side of the device) as well as with services that I can define myself (with the 802.11 side). Unfortunately, most of the phones on the market are hardly interesting. Here’s my “hit list” of features that you have to implement to make me pay attention:

1. WPA(2). This shouldn’t even be hard at this point. We’ve worked out all of the kinks from these protocols, and there are multiple open-source implementations. There is no excuse for bringing any wireless LAN device to market that doesn’t support good security in 2007.
2. WMM. Last year at Interop, I was able to demonstrate that WMM can give you voice quality, even with significant background traffic. There are plenty of reference designs from hardware vendors that do WMM. Selecting only WMM phones drops you to just eight Wi-Fi Certified devices.
3. PMK caching. This is an under-appreciated feature that was part of the 802.11i amendment. It’s a way of saving master keys to cut down on roaming times. Combined with the “opportunistic” version that establishes master keys on APs before it’s needed, you can get some impressive handoff times between APs, and you’re hard pressed to hear a difference.
4. U-APSD. This is an acronym for Unscheduled Automatic Power Save Delivery. Anybody who’s used an early 802.11 phone has undoubtedly noticed that the battery life is, to put it nicely, awful. U-APSD works keep the 802.11 radio powered down when it’s not used, so that almost all of the 802.11 radio (and power) usage is devoted to transmitting voice. Anecdotally, it can extend battery life by 50-100%, but there are so few implementations I can’t speak from a wealth of data.

Naturally, even after you get to the end of this list, there’s a lot more that can be done, but it’s relatively small potatoes compared to the big four. There are some further quality of service parameters that can be used to help an 802.11 phone in a big network select the right AP to go to, and there are some features that help further smooth out handoffs. To be honest, there are so few phones that can get to #2 on the list that I’m not worried about writing up #5 through #10.

Three and a half years ago, I used a simple model to calculate the maximum throughput of 802.11 networks. Recently, a reader wrote to me and asked me how the use of the short preamble would affect the throughput numbers. The answer is that using the short preamble increases throughput by more than 20%.

The re-calculations aren’t particularly complicated. The short preamble is only 96 microseconds instead of 192. The initial slow component of the preamble is shorter, and the second and final component is transmitted at a faster data rate. This affects the model by making any frame transmitted with 802.11b data rates take 96 fewer microseconds in the air.

In the 802.11b model, that savings exists on four frames (the initial data frame with the TCP payload, the 802.11 ACK, the second data frame with the TCP ACK, and the final 802.11 ACK). Therefore, the simple TCP+ACK transaction the model is based on is 384 microseconds shorter.

In the 802.11g with CTS-to-self protection, the short preamble saves on just two frames. In CTS-to-self protection, the frames transmitted at 802.11b data rates are the two CTS frames used to lock up access to the medium. Therefore, the TCP+ACK transaction unit in the model is 192 microseconds shorter.

Finally, in the 802.11g with RTS-CTS protection, there are once again four frames with a preamble saving. Both of the two 802.11 data frames carrying a TCP payload are protected by an RTS and a CTS frame, so the TCP+ACK transaction unit is once again 384 microseconds shorter.

Throw it into a spreadsheet, and you get the following table, where the short preamble rows are new.

It’s also important to note that the equipment on the market rarely uses the full RTS-CTS protection. It is an option on most equipment, but it is rarely used.

I am sitting in the 802.11 working group meeting in London right now, and we have just voted overwhelmingly to send the draft out for another letter ballot vote. The vote was important enough that the chair required a rising vote, though a look around the room made it obvious that it passed; final count was 100-0 with five abstentions. This is a big milestone for the process because the nine-month slog to resolve the 12,000 initial comments is complete. It’ll be interesting to see how many comments the new draft gets.

This afternoon, I received the latest TiVo newsletter. My TiVo and I have been drifting apart for years, in large part because TiVo seems to be falling behind. Today’s newsletter bragged about how the current TiVo software update now has WPA:

MORE SECURITY: Choose either WEP or WPA security for your wireless networks (WPA requires the TiVo Wireless Network Adapter) [Networking nerds cheer.]

Actually, we don’t cheer you. We wonder what took you so long.

A serious network engineer would never use WEP, because it is unsafe at any key length, and we’ve known that for more than six years. WPA was announced on October 31, 2002. (I remember that date because I was speaking on wireless security the day after the announcement, and the audience asked about it.) WPA-certified products have been available since 2003.

In 2003, my home wireless LAN was running WPA. When I discovered that my TiVo could only support WEP, I grudgingly pulled an Ethernet cable into the living room because I didn’t feel the need to downgrade my network security to WEP.

In September 2004, I was invited to be part of a security panel at the Wi-Fi Security Seminar in Washington, D.C. Before the panel took the stage, I vividly remember talking with David Cohen of Broadcom, who was leading the marketing efforts for the Wi-Fi Alliance on WPA2. In our discussion, David pointed out that many consumer electronics devices were supporting WPA, and that there was no reason why anybody needed to use WEP. When I pointed out to him that TiVos only supported WEP and that they had no apparent plan to support WPA, he was shocked. I never imagined that the situation would remain unchanged for the next two years.

To add insult to injury, the upgrade doesn’t help the TiVo customers who are already using 802.11. TiVo WPA support doesn’t work with just any wireless adapter like the one that most users already have stuck into the USB port. Oh no, it requires the use of the TiVo-branded wireless adapter! The TiVo adapter lists for $60, which is a pretty high price premium over a “standard” USB-to-802.11 network adapter. With careful shopping, you can get a regular Linksys/D-Link/Netgear adapter for $20 or less.