The news (i.e. PR placement) about Intel's achievements at optical switching using silicon chips reminds me to pen a few words on two competing models of the end-to-end concept.
The basic premise of "end-to-end" is that you should put as little functionality into the network itself as possible, within the constaint of that network remaining useful for a broad array of general-purpose applications. The usual implementation is to packetize the data and pump it through a set of short-range wireless or copper connections into a long-haul fiber network. The fiber network itself is switched between nodes using some converters and silicon. The silicon switches inspect the packet, and sends it onwards down the next piece of glass or copper in vaguely the right direction.
The throughput of this system is limited by the silicon. Every conversion takes time. The amount of switching you can do is bounded by the size and clock speed you can build silicon chips. Indeed, even the economics of it are ultimately limited by the power consumption required to do the light to electricity conversion and back again. (Ever wondered what happens to all the used ones and zeros? No, not the great bit bucket in the sky, but heat. There's a big push to try reversible computing to eliminate some of this thermal cost.) More immediately, the cost varies directly with the number of packets swicthed.
Reading some of George Gilder's futurology recently, there's another approach. What if the whole fixed network were optically switched? What if instead of an IP address, you used a frequency? In principle, we have the multiplexing technology to do this, and the physics allows it. It's a fascinating possibility, although well beyond my expertise to critique it. Of course, the "last hop" is increasingly likely to be wireless. The growth of cellular, WiFi and Bluetooth indicates an ever-greater density of short-range wireless access points back into the fixed network. So some sort of hybrid would still be needed. But the cost would essentially scale with the number of fibers, not the number of packets. And the fibers have a mind-boggling capacity when freed of the silicon swicthing cost.
Just to dangle the possibility in front of you, here's some statistics I put together. What we're showing is that the speed of light is the speed limit that counts, and we want to get as close as possible to it as we can. I did some pings and traceroutes from here in Kansas City to www.open.gov.uk (the British government's citizen portal). I chose this because it's a long way away (to illustrate the point), plus the UK is all pretty much the same distance from here, what with being a small soggy island floating off the coast of Europe. So I don't need to care exactly where the packet landed. For political reasons, the web site is also guaranteed to be hosted in the UK rather than an anonymous warehouse in San Jose. Furthermore, any content delivery network nodes are probably going to be in the UK too, since the UK government is unlikely to be paying good money to speed up the access times of US citizens.
The reverse DNS lookups of all the intermediate routers indicate a straightforward route, from KC to Chicago (on the Level 3 network), then to New York and London courtesy of AT&T. The one-way trip is approximately 60ms. Some consultation with Mapquest and Google tells me that the trip to New York is about 1300 miles, and another 3500 miles across the Atlantic. The speed of light is about 186,000 miles/second. (Apologies for the mixed SI and non-SI units -- bear with me.) So a beam of light takes 4800/186000 second to get to London from here, or about 25ms. So by speed alone, we've lost 60% of our time in the 20 hops to London. But because the throughput of a TCP/IP link is very sensitive to latency, the real throughput loss is much worse. And we haven't even begun to address the costing issue.
So, the billion dollar question is will the dumb pipe be displaced by an even dumber one? Answers on the back of a PhD thesis, please.
Posted by Martin Geddes at 10:32 PMTrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/149