Sunday, August 3, 2008

MetoWi Failing

It may be too early to tell but it looks like metro WiFi is in the process of failing.

Here in Silicon Valley, many of the existing and planned deployments have been dropped. A report in the local weekly paper details the damage. The San Francisco deployment was dropped after Earthlink decided to get out of the Metro WiFi business. The city of Milpitas was also dropped by Earthlink after the network was already deployed, though the city government is now contemplating taking over the network which is still in place. MetroFi also dropped their deployed service in Cupertino and Sunnyvale. About the only services still going are the nonprofit WiFi101 network in East Palo Alto and the Google network in Mountain View. I’ve heard some people in Mountain View use Google’s network as their only broadband link, though they need a repeater, since coverage indoors is spotty. There is also a prototype deployment planned for San Carlos by Silicon Valley Metro Connect. They’re planning on using the prototype to assess the feasibility of doing a Valley-wide deployment. Good luck!

I remember in the early 2000’s when 3G was running into deployment setbacks due to the cost of licenses. Some people were confidently projecting that WiFi would easily overtake 3G and be the next generation because WiFi hardware is cheap and the spectrum is free. What happened? Well, one problem is the technology itself. WiFi was really not designed for covering large geographical areas. As hotspots in airports and hotels, it works great. But for covering a city, the number of access points you need is too large. Even if each access point is cheap, if you need a lot of them, the cost can run up quickly. In addition, the frequency and power levels don’t allow reliable building penetration. So a city-wide deployment on light poles (which is what most of the metro deployments are) will really only reach people outside. This is great for utility workers and maybe people sitting at cafĂ© tables in the park, but it doesn’t work so well for people at home or work inside a building.

Another, more complex problem is the business model. Most of the cities involved in metro WiFi didn’t want to take any risk. Their idea was that they would provide the light poles and the service provider would take care of the deployment and run the system. Getting good coverage for a wireless network, especially with short range access points like WiFi, requires flexibly deploying a lot of access points and plenty of work doing site surveys and tuning to make sure there are no dead zones. Restricting access points to the top of light poles really limits coverage too. In some cases, the service providers even ended up renting light poles from the cities. Considering how hard it is to make money being a small Internet service provider, it isn’t surprising that most metro WiFi deployments are failing. It’s notable that the ones which are succeeding in Silicon Valley are essentially nonprofits: Google’s which is provided for free and WiFi101 which is a nonprofit. And Palo Alto, which never seriously considered metro WiFi, just cut a deal with a consortium of companies to turn over its city-built fiber ring in return for having the companies expand the network and run fiber-to-the-home. That’s something I could get excited about: 100 Mb to fiber to the home, like they have in Tokyo. Now if only they manage to keep the price the same: about $25 a month.

Large scale commercial mesh networks are now 0 for 2. The first attempt was Metricom’s Ricochet network, which was first deployed in 1994 in Cupertino. Same basic technology idea: mesh repeaters on light poles, free spectrum (900 Mhz). Throughput started with 56 kbps and went up to 128 kbps, which was really something for the time, considering that you were lucky to get 9.6 kbps with analog cellular CDPD. The latency was kind of high, but back then their 51,000 customers mainly used the network for reading email. No YouTube videos in 1998! Slightly different business model: Metricom actually paid cities to use their light poles. At its height, Metricom had a network covering many US metropolitan areas. But unfortunately they couldn’t make any money on it and Metricom went bankrupt in 2001. I remember seeing the mesh nodes hanging from the light poles in the Valley for years after, some are probably still out there.

Anyway, maybe there’s a business model that will manage to squeeze some money out of a large scale mesh network deployment. But for now, it looks like the only way to succeed with a metro mesh deployment is to not expect to make it a business.

Sunday, June 22, 2008

Privacy

I've been away from blogging for far too long, mainly because I've had too many other things going on. Anyway, this week I thought I'd get back with a short, not very extensively researched post on privacy.

The House and Senate this week finally came to agreement on a replacement for the Foreign Intelligence Surveillance Act of 1978. This law was passed as a reaction to the excesses of Watergate, the CIA, and the FBI in the 60's and early 70's, when there was widespread spying on domestic political groups opposed to the Vietnam war and on the political opponents of Richard Nixon. The law requires the government to go to a special court and obtain a warrant to tap into the telephone number of a particular party. Despite the contention of the current Bush administration that the involvement of the special court is onerous, the court has, in practice, never refused the government's request for a wiretap. Whether that is because the government has in the past prepared cases with sufficient evidence to be convincing or that the court is simply a rubber stamp is, of course, impossible to tell, but most knowledgable people I've heard talk about it seem to think it is the former. The prospect of having to go before a judge and present a convincing case that may in principle be rejected has tended to spur the government lawyers responsible for preparing the cases to quality work.

The problem with the 1978 law is that is was written based on circuit-switched voice technology. Today, with the Internet, there are many other ways for the black hats to communicate, and the white hats need tools - or at least a clear legal framework - to allow them to do their job. Another change is that much traffic from foreign countries transits the US on the Internet, unlike the situation with the old circuit-switched network. While foreign countries may not like the idea that their traffic is being monitored by the US spooks, it certainly gives our intelligence guys an excellent opportunity to check on possible terrorist messages originating from, say, someone in the Philippines and headed for someone in Spain. And then inform the Spanish and Phillippino authorities who can take action.

Changing the law to reflect the radical change in communications technology in the last 30 years isn't such a bad idea. While I haven't read the text of the law, I certainly hope they maintain the distinction between domestic and foreign intelligence gathering that was in the 1978 law. The CIA is not legally allowed to gather intelligence on American citizens, only the FBI can do that, since the FBI tends to have more of a sensitivity to constitutional issues. For example, I've heard the FBI refused to sign on to the Bush administration's post-911 warantless wiretapping program. How the government is going to arrange for traffic to get sorted is another matter. I also believe that the new law requires court review of any wiretapping request, but I don't know what the details of that are. Certainly, it can't be on a per phone number basis. Keeping court review is critical to limiting excesses.

One of the most disturbing parts of the law is the apparent amnesty given to telcos that bought into the Bush administration's warrantless wiretapping program. Now, I work for a telco myself so I guess I should be more willing to give them the benefit of the doubt. But it seems to me that what the Bush administration was asking them to do was breaking the law, and they should have been willing to stand up and say no (in fact I think one telco, Qwest I believe, refused to participate). The Bush administration would then have had to go to the court and get a warrant, in other words, follow the law. It's very interesting to see how elected officials from a particular ideological direction readily condemn amnesty for illegal immigrants, but when it comes to something like this, where their Big Business political donors are threatened, they are ready to extend amnesty. This is hypocrisy of the worst sort, and I expect other elected officials signed on to it simply for purposes of reaching consensus. In other words, a compromise.

I think it would be far better if the cases against the telcos were allowed to go to trial. It would serve as a cautionary tale for the future, when another administration with fantasies of unbridled executive power comes to them and wants something illegal. In the spirit of Watergate, nobody in the US should be held above the law. Unfortunately, it looks as if the amnesty will make it into the law since President Bush has agreed to sign the bill.

Tuesday, May 27, 2008

Still Busy

Well, I'm still busy with my work for the Sustainability Task Force. My working group has a presentation to the Steering Committee next week, at which time I hope that the amount of work will taper off and I'll be able to start blogging again. Sorry for the extended hiatus.

Saturday, May 10, 2008

Taking a Break This Week

I'm taking a break from blogging this week. I'm the Working Group Chair for the Baseline and Measurement Working Group in the local Sustainability Task Force and I need to do some writing for them. It's a bit like being an IETF Working Group Chair without having to fly anywhere, and with somewhat less email. I'll try to get back blogging next week.

Sunday, May 4, 2008

“Hey! What about me?”

In the old Chinese folk tale, Journey to the West, the protagonist, the Monkey King, accompanies a monk named Xuanzang to India to collect Buddhist sutras (the story serves as the basis for the new Jackie Chan film, The Forbidden Kingdom). One of the Monkey King’s companions is Pigsy, a half-pig, half-human fellow who is always getting his companions into trouble. While the Monkey King is brave and selfless, Pigsy is always looking for some angle on events that will get him the biggest reward. When he loses out, he’s liable to complain long and loud about getting the short end of the stick. In the end, the Monkey King and the other companions all achieve enlightenment (a standard happy ending in Buddhist stories) except for Pigsy. He gets a job cleaning altars at the temple and all the food he can eat.

The Internet is kind of like that. On the one hand, you have the IETF leadership who try to keep the best interests of the entire Internet community in mind when making decisions. Sometimes, but very rarely, this even requires them to make decisions that may be not be entirely in the interest of the people who provide their day jobs. On the other hand, some working group chairs and many working group members are looking out for the best angle for their company (and sometimes themselves if they have some notion of making a career in IETF). Often, the interests of the groups represented by these people clash, though of course nobody in IETF officially represents anything except themselves. Dave Clark, John Wroclawski, Karen Sollins, and Bob Braden in their 2002 SIGCOMM paper call these clashes “tussles”, and they are a defining aspect of today’s Internet that wasn’t there 15 or 20 years ago. Of course, one would expect these kinds of clashes, given the economic, political, and social currents that swirl around the Internet, since no human endeavor is ever free from the clash of competing interests. The surprise should rather be that anyone would expect the Internet to be different.

Network architectures done in a vacuum without reference to economic, social, and political consequences end up like the Internet experiment: with unintended economic, social, and political consequences. Therefore, I feel it makes some amount of sense to examine these issues as part of any attempt to forge a CleanSlate Internet. It’s impossible to predict exactly what the impact of a CleanSlate Internet will be. But some issues, in particular the appeal of the architecture to various interest groups in today’s Internet, will control whether or not a CleanSlate Internet is ever deployed. These issues had better be well understood, or the CleanSlate Internet will never happen. Since it seems like virtualization is shaping up to be the foundational architectural principle of the CleanSlate Internet, it therefore seems appropriate to examine what’s in virtualization that would satisfy the tusslees in today’s Internet.

About the clearest beneficiary of virtualization are the network equipment vendors. A new, greenfields communications network with virtualized switches and controllers provides them with a new market. Benefits for vendors of end user software and hardware such as PCs and OSes, are a bit harder to see. They will certainly have to invest in putting any virtualized networking software and interface cards into their platforms. Similarly with service providers, they will have to invest in deploying these new virtualized networks. So there had better be some pretty serious benefits to convince these groups to make large investments in new products. The justification for virtualization has until now been primarily the ability of virtualization to foster research. But that isn’t likely to appeal to vendors of end user devices and software, and service providers. If you dig somewhat deeper, however, research really means innovation. What virtualization does is open up the innovation bottleneck at the IP layer. It opens the bottleneck up in a way that has the potential to re-inject real value beyond simple packet routing into the service provider’s network, and to provide vendors of end user software and hardware with tons of possible new products.

In a virtualized network, a service provider can offer an array of slices that provide services different from IP service at a flat rate tiered by bandwidth. The isolation properties of slices mean that a service provider can provide contractually guaranteed properties on a slice and charge for it. A service provider can even provide a slice that doesn’t spit IP out of the wall plug. For example, suppose a bunch of enterprise customers decided they wanted to set up a slice that talked .NET (or Java, or Python, or…). An innovative startup could provide a .NET slice over various service providers’ networks. The end devices would use the .NET service discovery mechanisms, communicate among each other using .NET, and wouldn’t even need an IP stack. What happened in the network – if IP was used or not – would be irrelevant (though in all likelihood, IP probably would be used at least initially). Since users these days are by and large only interested in the services, not what protocol goes into the wall, vendors of devices and software would have the opportunity to provide new products that meet this new market.

It’s hard to say exactly what virtualization will do, but it is clear that the potential for innovation in the network should be vastly larger in a virtualized network than it is in today’s IP monoculture. And the innovation will reach beyond academics doing research. Equipment vendors, service providers, vendors of end user devices and software, and – last but not least - users should all benefit from an enhanced service offering.

Sunday, April 27, 2008

The Middlebox Daemon

Last week there was a hot discussion on the end-to-end mailing list about the future of the end-to-end principle. As usual when this discussion erupts on an IETF-related list, some folks came out and complained about middleboxes. Middleboxes are devices that sit in the network between two end nodes performing some function on the traffic. Firewalls are a good example. The consensus seemed to be that, if only those pesky middelboxes would disappear, things would be a lot easier for the end-to-end principle. Other than NATs, there’s no topic that can get the microphones smoking at an IETF Plenary like middleboxes.

These discussions tend to ignore the point that middleboxes arose for a reason. The reasons differ depending on the middlebox. Some reasons are good in the sense that the middleboxes support important functions involving network or user utility that are difficult or impossible to achieve in any other way. Mostly these types of middleboxes have to do with security. A good example is firewalls. While it is still necessary to have firewalls on end nodes (especially for nodes with wireless interfaces), firewalls as middleboxes protect networks not individual nodes. They allow the network operator to exclude certain traffic, for example during a DDoS attack, that threatens network operations. Another example is anti-virus scanners. Because most customers on end nodes these days are not technically savvy, they often don’t see the need to keep up to date with the latest security patches. Having an anti-virus scanner in the network helps keep these customers from becoming infected. Spam filters are another example. An example of a nonsecurity related function is transcoders. In the area I mostly work, mobile computing, obtaining Web content that works well on small wireless devices is really hard. Having a middlebox that transcodes content for small wireless devices can help.

There are other middleboxes that are put into the network for dubious reasons, usually having to do with some particular industry’s perceived-at-the-time business needs. On the service provider side, the ongoing Next Generation Network (NGN) architecture effort in ITU has specified a middlebox called a session border controller. The session border controller is an example of a dubious middlebox. It is basically a SIP proxy that sits between two operators’ networks through which all SIP signaling traffic for VoIP must flow. From a technical standpoint, the SIP proxies in the operator’s network that originates the VoIP call and the operator’s network that terminates the VoIP call could signal end-to-end without having to go through any other proxy in the intervening operators’ networks. But the session border controller was put in to the NGN architecture to preserve the metered voice telephony business model of circuit switched telephony into the all-IP world, in which everybody on the path gets a cut of the call revenue. Now as I understand it, the charging structure for international calls is regulated by treaty terms, which are of course somewhat difficult to change. That said, I don’t see service providers clamoring to change the treaties. Rather than change their business models to more naturally match the VoIP technology, they find it easier to specify a middlebox in the architecture.

Another example on the equipment vendor side comes from the 3GPP R99 architecture for wireless GSM/UMTS networks. There are several middleboxes in this architecture which seem as if they were put in specifically to preserve equipment vendor’s market share, since it is difficult to see any technical reason why they need to be there. The SGSN is an example. The SGSN really is just a router, but because 3GPP specified a specialized tunneling protocol, GTP, for the IP access network the SGSN was inserted. It performs specialized functions for GTP in the GPRS network. The indication that the SGSN is unnecessary can be seen in the new 3GPP architecture, the All IP Network (AIPN), nearing completion. The AIPN has no SGSN in it. Maybe I'm misssing something but I can't see any reason why this should not have been obvious when the R99 architecture was developed.

When I was on the IETF in 2003, we gave a lot of attention to middleboxes. The IAB published RFC 3724, “The Rise of the Middle and the Future of End-to-End”, which I edited along with Rob Austein, about middleboxes and their role in the Internet architecture. Our conclusion was that the end-to-end principle applied to the connection between a middlebox and an end node, and that the end node should have some way to detect and signal to middleboxes. IETF started a working group to work on a protocol that could serve such a function, NSIS. The working group has made some good progress, but widespread adoption of the protocol seems unlikely since the installed base of middleboxes and end nodes is so huge that it would be almost impossible to change. Like all changes in the Internet, the scale makes introducing any new functionality below the application level almost impossible.

Hopefully, in the CleanSlate Internet, we can fix this problem. End nodes and middleboxes need a well-defined control plane architecture, with an interface between the two architectural entities that specifies the functions necessary to detect and negotiate with a middlebox. Open protocols can then be specified on the control plane interface so that anybody can build and operate a middlebox that works together with end nodes. The Internet has no such well-defined interface. The CleanSlate Internet needs to acknowledge that middleboxes serve important and useful functions in many cases, and that they must be provided for in the architecture from the start.

Sunday, April 20, 2008

The End-to-End Principle and the Value of Networks

If there is one thing everybody interested in network architecture agrees on, it is that the end-to-end principle is the fundament on which the Internet architecture is based. Perhaps the best statement of the end-to-end principle is in a review paper by Saltzer, Reed, and Clark written many years after the original Internet architecture was formulated:


The function in question can completely and correctly be implemented only with the knowledge and help of theapplication standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)

Put briefly, the end-to-end principle states that services and functions should not be implemented in the network; rather, they should be implemented only in the end nodes. The flip side of this is what should be implemented in the network: packet routing. The parenthesized point about performance has over the years been mostly dropped, as the performance of the basic underlying network link technologies has steadily increased to the point where acceleration of end node functions within the network isn’t necessary.

To appreciate how revolutionary the end-to-end principle was at the time it was introduced, we need to go back to the days when the Internet was new and the number of nodes could be counted on one hand. Back then, the global communication system de jure was the circuit-switched telephone network. The circuit-switched telephone network was anything but end-to-end. Functions such as call waiting were built into the switches that routed the calls. End nodes were capable of only two functions – dialing telephone numbers and receiving voice-based telephone calls. Though touch tone phones were available in 1969 when the Internet was first switched on, most people had mechanical rotary dial phones. There really aren’t many functions other than making and receiving voice-based telephone calls that are possible on a rotary dial phone.

Bob Kahn, Dave Clark, David Reed, Vint Cerf, Jon Postel and the other pioneers of the Internet saw much greater possibilities in the combination of computers and networking. While it might be stretching it to say that they foresaw the Web and all the other applications that today are available on the Internet, email and file transfer were available in the late 1970’s, and these certainly looked much different than voice-based telephone calls. In particular, the application-layer protocols for performing these functions (SMTP for email and FTP for file transfer) were implemented in the end nodes performing the functions, and not in the packet routers in the network. The applications using the protocols interfaced with the protocols on both ends at the end nodes.

One factor that has been largely overlooked in discussions of the end-to-end principle is its impact on the economics of the Internet. Despite what many people in the Internet community believe, a system architecture is not strictly driven by technical considerations. People pay for the deployment of a global communication system because it serves some useful function. System architectures must therefore have an economic impact, and the choices made during the development of a system architecture drive business models. Business models in turn determine the cost of system deployments. They also drive how profitable or not actually operating the system is. In particular, the system architecture determines the value proposition offered by a network to various players in the global communication ecosystem.

If you search the literature about the value of networks, you’ll find that there is some debate about exactly how to model it. Metcalfe’s Law which was formulated by Bob Metcalfe, the inventor of the Ethernet, states that the value of networks scale as the square of the number of possible connections. By some accounts, Metcalfe was talking about local area networks, but later misapplication of Metcalfe’s law to the Internet by George Gilder resulted in the hype surrounding the Internet boom in the late 1990’s. More recently, work by Briscoe, Odlyzko, and Tilly suggests that the value of a network scales more O( n ln(n) ) rather than O( n**2 ). The reason is easy to see. In a local area network, each new connection – to a printer, to a file server, or to a work colleague’s machine – is valuable so the quadratic scaling law of Metcalfe’s Law makes sense. But with the Internet, do you really derive value from being able to connect with a Nigerian scammer posing as a prince with $10 million to give away?

The point is everybody agrees that the value of networks lies in the connectivity. The problem is the end-to-end principle lays no value on connectivity. The only value in networks according to the end-to-end principle is in their ability to route packets to the end nodes, where the real value – the functions – lies. One can see this in the tariffs for Internet service. ISPs charge for bandwidth, not connectivity. My service provider has a tiered DSL plan, with the lowest tier offering 768 kbps downlink for $19.95 and the highest tier offering 6 Mbps for $35. For that, I can connect to as many other nodes as I want (and if I get infected by the Storm worm, as we saw last week, I surely will). These tariffs reflect the value that users place on the network. The old circuit-switched telephony world charged for both bandwidth and connectivity. You paid a certain amount per call (the connectivity) and then a certain amount per minute depending on distance (sort of like bandwidth). By today’s standards, the tariffs for telephone calls in the 1970’s were outrageous and nobody wants to go back to them, but the problem is that today, customers expect and get the connectivity for free.

The impact of the end-to-end principle has been to drain the value out of networks and into the end nodes. Networks now have become cost centers, expensive to maintain because the equipment must be upgraded every 3 years to meet the inexorable demand for more bandwidth and hard to monetize because users are simply unwilling to pay for more than bandwidth (and for a flat rate at that). End nodes are where most people view the real profit as, in fact, the further up the stack, the more profit. Whereas the most profitable and hottest area in the 1990’s was the OS and PC, today it is in Internet services. This situation has led to all kinds of distortions, from attempts by ISPs to lock users into their services where they see the opportunity for providing value (the “walled garden”), to ISPs injecting ads, to the network neutrality debate. While the end-to-end principle has made the proliferation of services available on the Internet possible, the downside is that it has caused the provision of actual Internet service to be a marginal proposition. Users see the network as a pipe for bits, and little else.