Wednesday, July 03, 2002

• Andy Oram on why Cable Modems are a mixed blessing.
• Andy on QoS
• Lawmeme on the new copyright crimes.

I'm posting these without further comment because that would shift this posting to the "to do" queue vs the "have done" queue.

Tuesday, July 02, 2002

As usual I have calls from "anonymous" so I can't return the call or know why I was called.

Caller-ID (CLID) is a good example of the difference between the current telephony world (and Bluetooth) and the Internet philosophy. CLID seems like a wonderful idea in that it gives us the ability to know who is calling.

The idea has great marketing appeal and is doable within the "Intelligent" or SS7 phone network so it was implemented and, in the US, we pay for the privilege of getting this information as a charge on our monthly phone bill. The telephone companies worked hard to assure that everyone enabled caller-ID as a default though they haven't been fully successful.

CLID should be the start of rapid evolution building upon the idea but, instead, it is a fixed product that doesn't work very well. It doesn't really tell you who is calling, just who is paying for the call or an arbitrary text string associated with the instrument being used to make the call. The bigger problem is that the information isn't even delivered unless every system along the chain does precisely the right thing. I often have two cell phones from the same provider side by side but don't get the CLID information.

In the "Internet" approach, CLID would be protocol for exchange information between the end point systems. Thus as long as we get any connectivity we can pass the information. If we can place a phone call we can pass the information.

But plain CLID is fairly lame. Knowing the number someone is calling from isn't that useful. Last year I got a call from someone who I went to High School with and then College. He happened to live nearby but we haven't stayed in touch so I was surprised by the call. Turns out it was his daughter calling my son. Cute but misleading.

It would be much more useful if I would get a "Calling Card" or "Subject Line" instead of just a number (or billing name). In the days before the telephone it was impolite to impose yourself on people by visiting them. Instead you would leave a calling card. Expecting people to immediately answer their phones is just as rude. The proper etiquette should be to leave a short message on the screen of the phone. Not only would I know who is calling but I could also know whether I actually need to answer it. Often sending a response message would not only be enough but more useful.

The advantage of messaging is that it is a better social vehicle as opposed to imposing the requirement that both parties make the particular conversion their immediate and highest priority. Think of how much worse it would be if we had to give our video attention rather than just aural attention.

Once we've gone this far it should become apparent that the audio stream is just a mode of interaction that should be available but it is just an option. Instead of jumping to answer the phone you'd set up a rendezvous time if you do want to have a real time conversation. But instead of scheduling talk time, you can just as well choose face time (meeting in person).

The important point is not so much in the particular features and possibilities as in recognizing that simply implementing these features within the current phone network won't solve the problem. What is required is that we have the opportunity to create our solutions that we can share with others.

As long as we can achieve connectivity between two end points we can, in fact, create such services. This doesn't mean that we will immediately find the ideal solutions since there is no one perfect solution. And that's all the more reason we can't depend upon an omniscient benefactor to do it for us.

The real impediment is the lack of effective connectivity. As much as I might lament public policies which preserve the fiction that we must have an omniscient benefactor (the phone or cable company) to create services, these policies are in response to the public's expectation that there is something special about the existing services.

Until one "gets" the concept of connectivity, it seems natural to expect that these services can only be provided by large companies with special expertise. (I can't help but think of the tagline from the Superman television show from the 1950's -- abilities far beyond those of mortal men).

To those who believe that there is something inherently difficult about creating these services the idea of connectivity as a building block and these services as minor streams of audio and video seems, well, silly. How does one distinguish a claim that there is a secret formula that allows a car to run 100 miles/km on a gallon/liter of gas from the claim about connectivity? The idea that a telephone call is a simple app and that carrying a television stream is nothing special is strange enough. It is even harder to accept the claim that using a lot of connectivity is not only not "hogging" but actually increasing the supply. Such "common sense" thinking is based upon the concept of sharing a limited pie. Connectivity is not a physical resource, and it does follow Moore's Law. It is simply a result of a marketplace process driven by buyers (AKA users).

For now, however, imagine what CLID could be the next time you're in the shower and the phone rings.

I did see it. I found it charming on first read. On second read, though, I think it's wrong: Perl is Internet English. English is far more syncretistic than Yiddish and far more illustrative of TMTOWTDI. As the author says, Perl was created to Get Things Done, and no one would ever tell someone to learn it because it "needs all the help it can get" -- if it were in that state, it would die. Like English.

Monday, July 01, 2002

I recently (June 21st, 2002) spoke at the IPv6 (Internet Protocol version 6) summit (http://www.ipv6summit.com/ipv6-program.html). I was invited to speak about the issues raised in my essay on the Importance of Encrypted IPv6. In that essay I pointed out we need to assure that every system connected to the Internet has its own (IP) address so that it can be a full peer participant. Encryption is important because the separation of the application layer (TCP) and the transport layer (IP) has been weakened by providers who are second-guessing the traffic on the network.

Despite the urgency there are many who wonder if we'll ever be able to make the transition from IPv4 to IPv6.

The answer is "no" because that is the wrong question. The idea of transitioning the entire Internet to a new protocol represents a failure to understand that the Internet has thrived because it is defined by its users rather than a central authority. IPv6 has been designed as a protocol that tries to meet the needs of the user (application) layer and the transport layer at the same time. While IPv6 does a reasonable job at meeting both requirements the deployment model is seriously flawed because it ignores the dynamics of the Internet as a marketplace driven by the needs of each user.

We see this same confusion in ICANN's failure to provide stable identifiers because it is trying to address a (mis)perceived need for commercial names.

The transition from the ARPANet protocols to IPv4 twenty years ago occurred when the Internet was much smaller and there was a central authority that could force a transition. Many of those involved in that effort are also leading the IPv6 effort. IPv4 (or just "IP") represented the birth of the Internet by shifting the power to define the network to the users at the edges.

The Internet has thrived because supply is driven by demand. New application services are supported by simply providing more transport (or IP) capacity. Rather than wait for new capabilities to be defined, users will create their own solutions. (When I say "users" I don't mean all users create applications. It only takes one motivated, creative individual with some time on their hands to create an application that will be adopted by millions of others. We just don't know which user that will be.)

The standard Email transport protocols only support simple text messages. But users at the edge of the network defined an extension called MIME (Multipurpose Internet Mail Extensions) and started to exchange messages without having to wait for any change in the mail transport protocols. MIME was specified using the Request For Comment (RFC) documents issued by IETF (Internet Engineering Task Force). The IETF serves as a meeting place where advocates can discuss their proposals and it can provide a consensus that encourages others to adopt the protocol. MIME is an application protocol and the IETF doesn't play a required role in creation and deployment of the protocol and cannot enforce its adoption. The process works because the user community recognizes the importance of adopting such protocols and the users themselves directly benefit from the adoption of the protocol. In fact, by avoiding dependencies that require infrastructure upgrades, the IETF avoided creating impediments to its adoption.

Unlike MIME the deployment of IPv6 is being delayed and frustrated by the requirements of the transport layer. Efforts to improve the "Quality of Service" and Virtual Private Networks might sound important but they are focused on apportioning scarceness to favored applications rather than creating capacity. Internet Service Providers are focused on immediate needs and have little motivation to provide IPv6 support prior to demand.

As MIME demonstrated, the solution is severing the dependency upon IPv6 as a way to meet the needs of the transport layer. Instead we need to focus on the requirements at the edge of the network.

Edge Protocol 6

I'm proposing a new protocol called Edge Protocol 6 to give us the benefits of the larger address space and simplicity. It gives us the ability to make immediate use of IPV6 technology at the edges using the Internet as-is.

We must not lose sight of what is really important, namely recovering the simplicity of the Internet by giving each end point a public presence. By implementing security between end points not only do we have a chance of understanding what is happening, we can also choose our own policies. Barriers between systems (including firewalls) seem more focused on fear than on allowing organizations to create value.

There is no requirement that the edge protocols and the transport protocols be the same. It should be consistent and convenient to leverage common formats. Those of us at the edges have already paid a high price in waiting on those of us who are tweaking IPv6 for use within the backbone for the Internet. This continues to be a dysfunctional dependency. We must learn from the success of the Internet itself and treat the relationship between the IPv6 and what I am calling EPv6 as similar to the separation of UDP from IP or IP from Ethernet packet formats.

Though this is really Edge Protocol version v1, I am calling it v6 for marketing reasons and it looks a lot like IPv6. The big difference is in the requirements. We can deploy EPv6 on the existing IPv4 Internet now. Not only does this avoid dependency upon unmotivated service providers, it also allows us to ignore those who are trying to build out an IPv6 network since we shouldn't care whether their efficiencies come from adding capacity or clever protocols. In fact, we should discourage any cleverness in favor of just adding capacity.

Key EPv6 characteristics:

• Supports a larger address space. Addresses can be composed using the existing IPv4 addresses as a prefix so we can use the existing infrastructure.
• Address resolution can use the existing IPv4 DNS Entries (A records) as well as the newer AAAA (IPv6) records. Thus I could say "rmf19.myhouse.frankston.com" where "myhouse.frankston.com" is a V4 address part.
• Connections are assumed to be encrypted in order to discourage favors from those who are fixated on "efficiency" and other meddlers.
• While there are elegant approaches to the problems of NATs (those routers you buy for your home), EPv6 implementations can even fall back to TCP tunnels. The advantage of TCP is that it maintains a connection through NATs but the disadvantage is that it can impose arbitrary delays and overhead. From a marketing standpoint, however, it means we can use EPv6 without changing the NATs and that can create a demand for better solutions. The risk is that the pain won't be great enough to force a change but that isn't all that bad.
• EPv6 is meant to enable new applications. Transitioning existing services is a secondary priority though being able to access EPv6 web sites from older systems is important but can be done at the application level.

The Internet has been seriously weakened by the need to share IP addresses among a set of computers. We're ten years overdue on remedying the situation. The availability of EPv6 is a key part the rebirth of the Internet. The P2P (Peer to Peer, including Instant Messaging and other collaboration tools) community already represents a significant pent up demand that is ready to catalyze around a commonly accepted way to provide a large address space with direct connectivity between systems at the edge of the network. The use of encryption helps assure that the connection is indeed direct.

Transport providers who do want to take advantage of the IPv6 addresses to simplify routing will also benefit by having a demand for their services. The process will start by building on IPv4 but the ability of EPv6 will also make it easier to meet the demand using IPv6. IPv6 without such a demand isn't very interesting.

If you want to learn more about IPv6, you can look at Christian Huitema's site.