Way back in 1982, £400 was a lot of money. We could have had a good holiday with it. We might have bought a VCR (and my mother’s Sony fetish would have made it a Betamax, no doubt). Or perhaps we should just have had a ravingly good time of restaurants, theatre and days out. My mother had just gone back to work as a shop assistant after a decade of raising us wee monsters. That money hadn’t just fallen like manna from the money tree.
My dad is still flabbergasted as to what my mother insisted we got. I’m thankful, because it changed my life. We bought a computer.
And not just any computer. The then state-of-the-art in home computing was the BBC Micro. (Apple II owners, please don’t write letters.) An 8-bit 6502 processor, 32Kb of memory, and an unreliable tape drive for storage. It taught me a lot. After all, the whole purpose of the BBC putting their name to a computer was to encourage computer literacy. (Our grandkids will be surprised to discover there was any other kind of literacy…)
I learned many important lessons from owning this computer, but two stand out. The first is that when you’ve got limited resources (memory, CPU speed, storage), you subordinate everything else to that limitation. Write in assembler, pack every bit with data, don’t be too ambitious with your program’s functionality. The second was that you have to assume the worst. No memory protection, faulty media, and overheating hardware. Save your work — in a new file — every 15 minutes. Swap tapes regularly. Reboot often.
In essence, it taught me the importance of non-functional requirements. Performance, scalability, security, availability, compatibility, upgradeability, resilience and cost. As an Oracle consultant years later, I would see the occasional client trying to build systems at the cutting edge of technology. All too frequently, they would have fixed their business and functional requirements first, and then told the technologists to go off and implement it — cheaply, reliably and quickly. But if the non-functional requirements are sufficiently challenging, you have to realize that they are the fixed constraint. You tailor your functionality to what will fit in your server and progammer budget. If you want a million concurrent users of your interactive TV system, you don’t start your project with a fixed list of must-have shopping and banking applications. You instead rent a server farm and see how many transactions you database and apps server can support. Then you fill that capacity with the most valuable transactions.
The end-to-end principle of networking is a functional principle. It states that the network should assume the least possible amount about the functions of the applications that run over it. The stupider the network, the better. Just deliver every lump of data as fast as you can, make the end points agree on how to resolve resource contention.
Just like my Oracle clients hell-bent on deploying every business feature regardless of whether the technology could take the load, the same happened in networking. This was observed and codified by some smart people at Sun over a decade ago as the Eight Fallacies of Networking.
We’ll run through these in more detail in a minute. But I’m hoping you’re seeing a pattern here. These are all non-functional aspects of networking. In effect, they demarcate the edge of the applicability of the end-to-end principle. Although an abstract dumb pipe is exactly what an applications wants to be presented with, in reality it is going to face all the issues listed above.
If you’re a retail network operator, that’s good news. So good, you should be rejoicing. There is a way out of the financially barren lands of the dumb pipe. Be functionally dumb. But be non-functionally very, very smart.
So let’s take the fallacies in turn (plus one of our own…) and see how they can be converted into money-making opportunities.
The network is reliable.
Cables get cut, coverage ebbs and flows, sysadmins make mistakes. No news there. This causes a problem for two parties. One, the person who wants to initiate a communication over a non-existent link. Two, the person who wishes to contact someone who is disconnected. Their issues aren’t identical.
For the receiver, you need a local data store and the ability to sync. Easy.
Negroponte forecast a long time ago the dominance of the store-and-forward paradigm over real-time connectivity. Push technology is one way of solving the sender’s problem. Sync is it’s cousin. Store-and-forward serves the sender and receiver.
Look at the mess today that carriers make of operating their user data stores. Silos of email, pictures, profile data, address books. No standard discovery mechanism, no standard object interface. Given an IP address (or phone number!), how can I discover your store-and-forward services? I probably can’t even trace back the right mail server, let alone any user-level credentials or permissions. Where’s the API for me to ask for authorisation to access your picture store? The value chain is riddled with holes. Nobody makes much money because the innovation is all locked away in the benighted product development departments of the telcos.
You might easily argue that the whole point of end-to-end is that the carrier is cut out of the store-and-forward game. Just send my goddam bits! But the carrier is uniquely well positioned to aggregate the storing and forwarding over multiple service providers. Today, every normal user on the Internet ultimately bought a pipe from someone upstream. Users pay for access. They don’t peer at the connectivity level.
The idea of end-to-end is that the carrier isn’t obliged to be part of your application. That isn’t the same as saying they cannot contribute. So carriers need to get their act together here. Unless you actively want someone else to manage the intermittent connectivity issue instead.
The money opportunity? Enabling third party value-added services, and charging for access to the APIs. Reducing churn by holding more stateful data on behalf of the customer. Building services on data that third parties bring to the game and federate.
The carrier also has a unique advantage in managing the presence status of intermittently connected users. If you suddenly go out of wireless coverage, by definition you’re not in a good position to update anything that isn’t local. In particular, you can’t update your presence status to say ‘out of coverage’. The ability to know someone isn’t answering because they’re not there is uniquely endowed to the carrier. Charge for it.
Have you every tried to sign up to a carrier’s developer program (yes, they do exist!)? Spotted the APIs that let you peer into the network status? See which nodes are down? No? Well, that’s because this data is regarded as super top secret. What if someone actually discovered we have less that 100% uptime? The marketing illusion of perfection would be busted!
Unfortunately, this also excludes all third parties from doing anything intelligent about partial network availability. Your ops status is a lost commercial opportunity as long as you keep it to yourself.
Latency is zero.
Where does latency come from? I can think of four sources:
- Delays within the end points.
- Delays in transmission, caused by contention for network access.
- Delays in transmission, caused by electronic processing of the signal at intermediary nodes.
- Distance of transmission, capped by the speed of light.
The middle two are clearly under carrier control. Quality of service (QoS) is the traditional way of dealing with this. But QoS is normally done in a really stupid way. The carrier selects the applications needs priority (e.g. voice traffic). This is the last thing you want. On September 11th, the de-facto priority given to voice was a disaster. Nobody could call anyone else. Indeed, the more urgent your need to communicate, the less chance there was of the service being available. If the network capacity had been given over to IM, everyone would have been in touch. (Except on crappy faux-packet networks that insist on setting up a circuit before anyone can do anything and therefore get dreadful real throughput on chatty data apps … informed readers will know who I’m thinking of.) So the priority should be set by the users. The carrier’s job is to arbitrate between users, not applications. And static allocation of bandwidth to users (e.g. with MPLS) isn’t good enough.
When you’re selling data, don’t sell bandwidth, sell priority (aka low latency). Make the economic model reflect the underlying physics. Don’t fight it.
Bandwidth is infinite.
Ever got half way through that FTP download before your connection crapped out? Started copying a thousand files off the network drive at work and had to give up before you went home? I dread to think how much of my life has been wasted watching a little bar futilely count from 0 to somewhat less than 100%.
What if you could ask your network provider how quickly you can get the file delivered? What if your application could intelligently select an alternative course of action of the time frame is too long? What if the network was smart about all non-functional aspects? The Internet may be non-deterministic, but that doesn’t mean you can’t make money managing that unpredictable variance.
This is just like the QoS issue above. I can’t request — and pay for — more bandwidth on a dynamic basis. More dollars down the drain, and pipes left unfilled. (For more information, you might want to read Andrew Odlyzko’s paper Data Networks are Lightly Utilized, and will Stay that Way [PDF]).
Another example of this today is edge servers that resize images for mobile consumption. The weakest link in the network is the wireless one, and you place the processing on the wired side of that link.
The network is secure.
Bob Frankston has eloquently argued about the futility of encrypted WiFi connections. Why encrypt just one hop and then send cleartext the rest of the way? You must be nuts if you think that counts as security. Over to you Bob…
Today we have to run through a gauntlet of firewalls, NATs (network address translators), blocked ports and other impediments. Even if you get through you have to trust the transport because encryption is not the norm. The focus on the wireless links is typical — focusing on those links out of context just adds complexity which actually reduces the effective security.
Bob’s solution?
Very briefly, the key is to use self-generated end point identifiers that double as cryptographic keys and treat the Internet as routing service rather than a layer.
The opportunity? Be the manager of those crypto keys. (Bob will have a fit if he reads this.) If Bill Gates ever manages to produce his sender-verified email system, make sure it’s you (and not Microsoft) managing the keys.
The money? It’s all in what you assert about the keys you issue, and the liability you accept. Don’t believe me? Just look up Verisign’s price list, and see how much extra a high-liability crypto key will cost you. If you can link a crypto key back to a name and address, you’ve got value you can sell. Bob’s detested telco pipe operator still has the edge over other key issuers.
Topology doesn’t change.
Things shift about in the real world. People relocate offices and move house. Laptops are carried everywhere. Telecom is about shifting a virtual thing (a message with a delivery label on it) to a physical place. You want to move the place around, but don’t want to change the label. The name-to-address resolution problem gets solved at various layers of the architecture with mesh systems, mobile IP, DNS, LDAP and application-specific naming systems.
Are telcos doing a good jobs? No they aren’t. Example: dynamic DNS is never even offered as an extra, even if it’s money for old rope. Are these functions naturally aligned with nework operation? Yes they are. As devices become more mobile they need to authenticate to the network to assert that they have paid. (Anyone who thinks free access is more than a temporary niche is welcome to pay my telecom bills for me.) Be that 802.1x, log-in splash screens or proprietary cellular systems, just plugging in isn’t good enough. The act of authenticating to the network is a natural point to update a directory to say “this thing is in this place”.
Prediction: there will be massive price discrimination based on whether you are issued a publicly routable static IP address compared to a dynamic or private one. The knowledge of who is where is the most closely guarded asset of a mobile wireless system. Connectivity is nothing without routability.
The issue of dyamically varying network topology is brought home with attempts to let VoIP phones roam between WiFi access points, or between WiFi and cellular. The old school way of doing this is to do hand-offs between the nodes using a smart network. The little gap in time as you switch access points is the killer to a voice call.
But why do it at the IP layer or below? Why not just use a smart radio that can connect to more than one access point at once? A smart voice application that can accept multiple session control and media streams for a single conversation? The irony is that the smart network doing hand-offs produces an inferior solution to smart end points negotiating which physical connection to use.
So where’s the money opportunity for managing topology change if a smart network is a stupid idea? As usual, the network operator has a god’s eye view of the world. The edges of the network are in principle capable of updating a directory somewhere with location changes. But the network operator is also able to just see what MAC addresses turn up where and make directory adjustments accordingly. This can be done with minimal latency (no wireless networks to traverse) and few negotiation protocols (as the carrier, you’re talking to yourself).
Convenience can be added to any simple commodity to extract a premium. How much did you pay for a can of sugar water the last time you visited a vending machine?
So what to do? Stop embedding the topology change functionality inside applications like voice, and let anyone access the raw topology data, for a fee.
There is one administrator.
I was amazed to recently discover the horrible costs of (failing to) keep the contact names and addresses of business customers up to date. Sometimes there’s a business opportunity lurking without any associated high technology. Basic execution of business processes to keep track of who is responsible for what in the network topology is a source of advantage. It’s one thing to deliver a packet successfully. It’s another to know who to contact when there’s a problem with the packet. Accessing the hooks back to the physical world should command a premium price. You’re the coordination point of the network admins at the edge.
Transport cost is zero.
For this one, we’ll take our old airline analogy. Where’s the telecom equivalent of the standby ticket? Why doesn’t the cable operator want to fill 100% of the pipe capacity, keeping everyone’s TiVo stuffed with new goodies constantly? The marginal cost of sending a bit is the energy in the photon to send it. For broadcast TV, this turns out to be a big electicity bill. For a fiber, there’s still a significant cost of keeping it lit. It might not be the electricity bill, but the support bill from your equipment vendor. Marginal costs are small, but not zero.
Telcos are doing an abysmal job of what should be their core functionality. It’s a sunk-capital and capacity-driven business. The product is perfecly perishable. Every moment the pipe isn’t used is an opportunity lost forever. Yet we fail to fill the pipes. Arguably the telcos aren’t doing a good enough job of price discrimination. It’s all static — you sign up for a plan, and that’s it. What we need is dynamic network pricing. In particular, we need to enable those sub-prime applications that need to shift a lot of off-peak bits to create value.
The network is homogeneous.
This really means “the end points are homogeneous”. (When Sun folks talk about The Network, stupid pipes are such a given that they aren’t even given a thought.) Java is one example of a way of masking the differences of operating system, hardware and application services.
How to make money here as Mr Pipe Operator? Trickier, since we’re really talking about application-layer compatibility. The testing of which applications work on which devices is one that carriers tend to delegate to specialists like Handango. At best, you’re probably just a brand asserting the goodness of someone else’s work here.
Bonus offer, this week only.
I promised a bonus fallacy, so here it is. I’d like to turn the eight fallacies into nine. The extra is as follows:
The network end points have unlimited processing power.
Alhough it doesn’t say it, this is inspired by the finite battery life of mobile devices. Every CPU cycle dissipates energy from the battery into heat. There is a massive cost asymmetry between the edge and the center in every Joule. This isn’t likely to change soon. Current mobile data networks are the equivalent of 80286 PCs. Fixed wireless broadband is like a 80386. The average user still has a long way to go to get to the overkill of a 3GHz Pentium 4. We’ll be able to soak up all the battery technology that can be thrown at us for the next few years.
The money opportunity? Anything with high CPU cycle costs at the edge. As David Berlind puts in in comparing Bluetooth to IPv6:
SO, WHAT ARE WE supposed to do? Should we forgo the conveniences that a bleeding edge technology like Bluetooth can deliver to us today in order to avoid getting trapped in a cul-de-sac tomorrow?
The financial risk is that we’ll have to spend more money to get out of that cul-de-sac later. Or do we pay the premiums (money, battery-life, size, etc.) for a wireless technology that fits better into the layered model now (like 802.11/WiFi)? Plenty of people won’t even consider swallowing that bitter pill.
Sometimes activities like polling a database can have a high computational cost to business benefit ratio. Wake up the device, negotiate a network connection, authenticate to database, perform query, find no result, disconnect, go back to sleep, repeat. An example might be tracking your buddies, and sending a notification when they are in range. In principle, the smart end points could all talk to each other exchanging GPS coordinates and doing a lot of smart geometry. In reality, you need a geospatial product like those from Wavemarket in the middle to do this for you.
To wrap up, there are multiple layers of the communication stack. Jefsey Morfin has interestingly described them thus:
- telecoms: infrastructure - bandwidth and hardware
- datacoms: structure - protocols and software
- intercoms(?): metastructure - interrelations and brainware (the “use
together”)
Functional separation of these is good and necessary. But the non-functional side isn’t like that. You’re only as good as the weakest link. You therefore can get bleed between the layers as they coordinate their way around that weakness. And therein lies your escape route from the paradox of the best network.
Posted by Martin Geddes at 05:26 PMTrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/264.
Listed below are links to weblogs that reference When it's dumb to be stupid:
»
There is stupid, and there is Stupid from James Seng's Blog
Telepocalypse has an interesting article about when it's dumb to be stupid.
This was observed and codified by some smart[Read more] Tracked on June 27, 2004 11:02 PM
»
There is stupid, and there is Stupid from James Seng's Blog
Telepocalypse has an interesting article about when it's dumb to be stupid.
This was observed and codified by some smart[Read more] Tracked on June 27, 2004 11:03 PM
Brilliant essay. Really fascinating thoughts on where the value-added lies for transport providers. This looks like the beginning of a really important dialog on technology and business in communication networks.
Charlie
Posted by: at June 29, 2004 10:07 AM