 |
|
||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
|
|
|
Open Economies - Re: [OpenEconomies] A "must read" forward: Trans-Pacific Tour, part two -- SMART Lett er #81 [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [OpenEconomies] A "must read" forward: Trans-Pacific Tour, part two -- SMART Lett er #81
I am somewhat suspicious of this David Isenberg character---subjectively from the way he seems to be milking getting let go by Bell Labs into a touring speaking career, but also partly from the content of his message. I think the ``stupid networks'' thing is pretty well-understood by everyone who has had technical exposure to the Internet, including telco monopolies. The standard technical objection is about QoS. The telco guys I've heard talk about it do seem to have some mechanical-switching brain-damage, using words like ``fundamentally non-deterministic,'' and I don't much like them, but the QoS issue is relevant. Voice requires QoS because eacho VoIP packet must be delivered soon after it's sent, with small variance in how long it takes to be delivered. Otherwise, the speaker's voice will drop out, or the delay between when you tell a joke and the other guy laughs will be too long. QoS is a challenge especially over the last mile on link types that aren't point-to-point, such as cable Interweb connections with 30Mbit/s shared channels, or wireless devices that have to share an actual over-the-air channel. The trivial hack to get QoS on these broadcast networks is to use short reservation packets to chaotically allocate timeslots for long data packets. 802.11b uses this now to avoid data packet collisions---you want to have only one AP per nonoverlapping channel because the AP grants timeslot reservations to its associated cards, preventing cards from colliding with each other's transmissions. The granter of the reservations could also implement QoS scheduling by granting timeslots to VoIP cards such that they get frequent and predictable access to the band. Unfortunately, this trick doesn't actually work for VoIP because the data packets are too short. A long 1.5kB data packet with the GSM codec would be more than one full second of voice, so the delay of waiting for this packet to fill before transmitting it is annoying to the listener. VoIP must, and does, use small packets, less than 100 data bytes. Besides the lack of QoS scheduling on broadcast networks, there is another issue with broadcast links and VoIP. Because VoIP packets are small, they're mostly headers. Obviously it varies depending on the upper-layer protocols like IPv4 vs. IPv6, 802.11 vs. Ethernet, but the headers and the data of a VoIP packet are probably about the same size. There are tricks around this. Over a slow or heavliy-used point-to-point link, one can use stateful header compression to notice virtual circuits without actually nailing them down telco-style, thus reducing 20 - 60 byte headers to more like 1 - 5 bytes, although depending on what else traverses the link this might be an unnecessary exercise. Over a broadcast link, header compression is impossible, but sometimes that's okay because with a fast link like a Fast Ethernet LAN or a cable interweb channel, one might reasonably shrug and accept the 100% overhead. The ATM approach to addressing overhead, based on my vague understanding and some speculation, is a mix between stateful header compression and maybe also using timeslots to imply addressing. And the philosophy if not the ATM protocol itself is rigid and primitive enough to extend to wireless cel networks. However, over a wireless network, the current ``non-deterministic'' packet-switching tricks I've described above break down. Consequently, VoIP over a wireless network is colossally stupid, because it makes very poor use of the band---poor use becasue there is no obvious trick to reduce collision overhead with short packets, and poor use again because most of what you transmit will be packet headers. There's no easy way around it because per-link-stateful header compression doesn't work on broadcast links. When most of the bits are voice bits, as they are for cellular, wasting half the bandwidth is very expensive in crowded cellular spectrum so we can't just shrug off the overhead. It's more efficient to (1) use ATM-style nailed-route constant-bitrate PVCs as existing cel networks do, solving both the collision problem and the header-compression problem, or (2) expose a Nextel-style push-to-talk interface to the user, where a four-second delay (and thus a larger packet) is tolerable. now, grizzled telco veterans calling a cellular network ``fundamentally deterministic'' is ridiculous---we all know that to perform acceptably to their users, cel networks must tolerate packet loss far exceeding the typical ``non-deterministic'' wired networks that our kind of people build. But you must grant that cel networks solve (1) the broadcast-QoS problem, (2) the Alohanet collision problem, and (3) the small-packet header-tax problem, in ways that no existing VoIP-over-wireless architecture does. In the end, I think his ``stupid network'' argument is, kind of, simply wrong. depending on how you look at it. By the time Internet-ancestry networks can support, say, a cel full of gabby wireless voice users, they will probably be even more complicated than existing telco networks. They may be more flexible than telco networks, but they will not be ``stupid'' by any metric compared to ATM and SS7. The other piece of his ranting seems to be that a single service should be provided in layers by more than one company. From a business perspective, I think this part of the good professor's mystical hand-waving is equally suspect. I like the idea very much, but the only evidence I see suggests that it simply doesn't work. To me, the message of the wireless revolution in Korea and Japan, and of the astonishing failure and low subscribership of the amazingly brilliant Ricochet network in the US, is that _the keitai matters_. Matters most, even. The US had CDPD, DataTAC, Mobitex, and Ricochet long before the 1999 release of DoCoMo's i-mode in Japan. People think Japan had wireless Internet first, yet the US had no fewer than four ``stupid networks'' that could get you wireless IP access. Where were all those people who David supposes would emerge through market magic with wireless laptops plugged into the Innurnet, downloading smart applications to use over the existing stupid IP networks? i-mode, OTOH, was released as an integrated network with all the layers under NTT DoCoMo's control, and it continues to do great, with wanna-be i-modes in Taiwan, France, Germany, and the Netherlands; AT&T and Orange signed up to do i-modes soon, and similar-looking competitors within Japan (KDDI EZweb and Vodafone J-Sky) and outside (Korea). Now US carriers, with underlying networks that perform much more poorly than Ricochet, are making their own telco-controlled i-mode competitors---with ``Get It Now,'' ``PCS vision,'' the GPRS Blackberry, danger.com's ``hiptop.'' Successful wireless networks are all about good integration and cool handsets/terminals. Ricochet had no handset/terminal at all---it was one of these PC Card form-factor services. Everyone's first question about these little gizmos is always, ``how fast is it?'' Who cares? They do not ask, ``is it cheap? are there holes in the coverage? does the battery last all day? can I stay logged in all day, or are there frequent inexplicable service interruptions that `kick you off?' do I get a static non-NAT IP address so I can use 'push' services like AIM or ringing-email, or is it strictly proxied 'pull' Interweb NAT nonsense? does it mysteriously space out from time to time, dropping all packets for about 60-second intervals like CDPD? how well does it work with moving terminals in trains/cars? given proper investment, is the technology capable of continuing to perform like this as more people subscribe?'' all of which are more important than speed. Maybe this complexity explains why success requires a single system-wide integrator. Or maybe the investment cost of building a terminal explains it. Or maybe people just don't like stuff that snaps and plugs together with lots of fragile snapon connections, tangled wires, and software misconfiguration. But, for whatever reason, ``stupid networks'' have been a remarkably consistent loser in wireless data. You get your packets, your terminal, your applications, and some kind of server back-end or proxy, all from the telco monopoly. btw someone told me that Vonage sells VoIP phone service with US area codes, using your existing Internet connection. so it is not just a tied service offered by Yahoo! BB. This is, however, very different, because when Yahoo! BB offers it over their own DSL circuits they have a point-to-point link between your house and their infrastructure over which they can do QoS, while Vonage basically has to cross their fingers. Yet another case of end-to-end stupid-network technology available right now, and no one gives a shit. -- In science one tries to tell people, in such a way as to be understood by everyone, something that no one ever knew before. But in poetry, it's the exact opposite. -- Paul A. M. Dirac, quoted by H. Eves
|
