Skype seems to be a pretty decent system, and it uses good codecs, but unfortunately it's a closed proprietary system, so you won't be able to hook up your own PBX to it unless they come out with a PBX feature, or unless you want to relay it through a conventional phone line. They are adding "Skype In", which will let people make incoming calls from POTS lines, so at least the service is becoming more useful.
There aren't a lot of places where a 2-hour car commute is viable with public transit, because that's usually a 3-hour train ride or worse. There are exceptions - if traffic's bad enough, the train can be faster, or a bus might get to use a carpool lane. And usually it's not a combination of home and work locations and schedules that you can find someone to carpool with. A 1-hour commute's a lot different - that's more likely to offer alternatives.
I used to commute to San Francisco by Caltrain. It was about 45 minutes to drive, or 1:15 to take the train, but the train was a *lot* less hassle, and I could work on my laptop on the train, usually for more than half an hour. One reason the train was easier was parking - the train station parking lots had space, while parking near my office in the city was not only expensive, but often time-consuming, because I drive a van, and most San Franciso parking garages either don't allow vans or charge $20-40 extra for them, and open lots tended to become construction sites (for condos during the dot-com boom, and highway construction during the crash.)
If you're somewhere that has a Pacifica radio station, try listening to that. (And if you can't, they webcast - try kpfa.org.) It's listener-sponsored non-commercial radio, so the content is much different and usually better than most commercial stations. Most of their stations carry a mixture of local music, leftist-oriented news, and random silliness. Don't let the "leftist" bit bother you - they'll carry a lot of news that other stations don't, it's often much more in-depth than anything except the best of NPR, and it's much easier to recognize the occasional biased leftist whining than guess what stories CBS and PBS are leaving out or reporting from a government press-release.
Also, Canadian Broadcasting is good if you can get it. You'll recognize a few programs as "oh, *that's* what PBS was ripping off when they did this program...".
Back when I was doing an occasional 1.5-hour-each-way commute from NJ to Long Island, I found it was just about right to listen to a bit of traffic radio plus tapes of the Grateful Dead Hour. These days I usually work from home, with an occasional 1-hour commute into San Francisco by train, but since I don't have to drive I can use my laptop.
I guess there are people running uncompressed VOIP wide-area, but G.729a is really quite reasonable. It gets a higher MOS score than the cell phone codecs, plus you usually have a decent microphone and no road noise in the background which make a big difference.
A number of ISPs are starting to offer QoS on their own networks. Typically there's a higher price to use the service, and at least within the US, it doesn't really affect backbone usage much, but it gives the packet a higher priority for delivery at the destination. So on the fat OC48 backbone (2.5 Gbps), it doesn't change anything, but on the 1.5 Mbps access line at the destination, you want to deliver any high priority packets right away and it's ok to make lower-priority traffic to wait for them, at least for a little while.
If your ISP offers this, it can be very useful for some applications - VOIP and video-conferencing obviously benefit from it, while FTP, email, and streaming video don't need to be high-priority, because it's ok if they arrive 100ms later. Applications in between are typically database applications (some SAP and Oracle things don't like long delays, and perform much better if they get a higher priority than ftp.) It would be really nice if you could designate some applications as lower-than-normal priority, such as File Sharing - other applications get priority, but you'd like BitTorrent to be able to use up any leftovers - but the standard IP protocol markings aren't really good for that, so usually somebody needs to specially configure a router to make that happen, and that often costs money.
Cringely reveals the horrifying fact that at most ISPs, *all* packets are *already* tagged for QoS, and they're just not using the QoS features yet. Well *duh*, they're already tagged because the TOS byte is part of the standard IPv4 packet header. So it's not just *most* ISPs, it's everybody running IPv4 or IPv6.
They're normally tagged with all-0, which is Vanilla priority, because that's what everybody's Windows and Linux and Mac and Cisco and Linksys and Netgear box puts on the packets unless you tell your box to mark it differently (which some boxes know how to do and some don't.) Some ISPs will let you mark the packets with other priorities and ignore them; other ISPs will mark the packets back to 0 if they don't support QoS features, or drop them, or they'll remark/drop them if you're not paying extra for higher-grade service, or if you've marked them with a format that's not the one their equipment users.
Unfortunately, the standard IP priority markings provide a number of options for specifying that a packet should be treated as a higher priority the default, but don't really provide a way to say that it should be treated as a lower priority (except by increasing the probability of discarding the packet.) There are applications like file sharing and ftp which don't mind extra delay, and will soak up any available bandwidth, so marking them lower-priority would be a good thing - leave them in the queue if there's more important work to do, but don't just drop them. Since about 30-35% of the packets on the internet today are BitTorrent, this could make a real difference to some people.
DSL is designed so that handling the wire to your house is one job, handling the DSLAMs and regional ATM distribution is another, and connecting your PVC to the Internet or other applications like email servers is a third separate job. They can all be provided by the same company, e.g. telco ISP service, or they can all be provided by different companies, e.g. telco does the wires, Covad does the DSLAMs, and Joe's Garage ISP handles the Internet upstream. Different providers keep juggling their rates and policies, but basically it's pretty easy to become a DSL ISP in most of the populated parts of the US. I use an ISP that has extremely open policies (though come to think of it, I don't know if they support QoS or not - probably not at the price I'm paying.)
Cable modems work differently - the right architecture handles routing from fairly close to the customer, and the easiest way to "open up" the business is strictly non-technical a wholesale billing arrangement and discounted prices, with the newbie ISP buying service at a couple of peering points, but pretty much the whole infrastructure run by the cable TV company or a partner of theirs. There are technical kluges like PPPoE that provide a bit more control, but they're ugly hacks.
VOIP uses trivial amounts of bandwidth. I assume that's 60GB per month? So that's 2GB per day. Compressed voice uses 8kbps, so 1KB/sec; when you turn it into VOIP it's about 3KB/sec. 86400 seconds/day means you can leave your phone on for 24 hours a day using about 250MB/day - a mere eighth of your bandwidth.
While there are ISPs that are far worse about it - Telstra, for instance, or some of the US cable companies who think that they need to catch up with Telstra's unwillingness to let people actually use data for anything - a 2GB/day cap is still annoying. Basically, it means that you can't do file-sharing without being very selective in what you leave running for how long - so you can download that latest Knoppix release and share out a couple of copies, but you can't leave your entire set of Linux and *BSD distros open all month.
The current 911 and E911 systems in the US (for you non-US folks, that's Emergency calling or 999 or whatever) are designed with heavy dependence on a bunch of technical assumptions that weren't always valid for the traditional telco infrastructure and are less valid now. They didn't really like PBXs, and in some sense VOIP is like PBXs for everybody, and they certainly don't like mobile phones, though the control-freak FBI types have managed to bully the wireless companies into building location-tracking capabilities without making them actually useable to the owner of the phone. For instance, you can stick your Vonage or AT&T CallVantage phone in your suitcase and take it on a business trip with you - but if you call 911, you really want the fire engine to show up at your hotel or the Starbucks you're in, not back at your house when you're not there.
Cringely's speculations about providers tinkering with QoS are bogus - I've heard other clueless people ranting about how awful it is that some ISPs might start offering higher quality service for more money (the bastards!) At most, his arguments are really that some ISPs might fail to provide higher-quality service for people who don't pay extra for it, and that this might not be good enough quality in spite of the fact that many people like it today. And if that's the case, and their basic service isn't good enough, then either you're going to get a different ISP, or you're going to pay more for better service, or you're going to keep your old-fashioned phone, and of course, if you can afford broadband and VOIP service, you can also afford a cellphone (at least a pre-paid 7-11 phone for emergencies), which will even work when bad weather makes your cable modem go down.
Furthermore, Cringely focuses on QoS in the backbone, but the real impact isn't there, where the network's fat enough, but at the skinny edges. The ISPs have no control over your outbound traffic - what if you're trying to call 911 and somebody is downloading that music video file you're sharing? That has a much bigger impact on VOIP performance than anything a backbone provider is going to do. Or what happens if that music you're downloading starts getting better performance because the server is less busy - QoS could help that direction a bit, but if your ISP uses one standard for QoS markings and the 911 Center's ISP uses a different standard (there are lots), then the QoS isn't going to work the way they expected anyway.
Cringely doesn't understand it either, so don't feel bad. I've heard similar rants from people who are appalled that ISPs might start offering higher-quality service for more money (the bastards!)
Most ISPs don't support prioritization right now, at least for low-end services - they're starting to add it for business services, but it's much easier to make it work on a T1 line than on a DSL line where different people are providing different parts of the infrastructure and so nobody has enough control to make a good Service Level Agreement - and without a good SLA, it's hard to get customers to pay extra. Also, most ISPs that do support QoS only support it within their own networks - figuring out how to interconnect with other ISPs is difficult, as is figuring out who to charge how much for it. (For instance, what if one ISP uses two priority levels, one uses four, one uses a different four, one uses five, some use TOS markings while others use DSCP, etc.)
Interconnections between ISPs turn out to be a big problem for the sort of ham-handed regulation you're suggesting. A single ISP is going to deploy one set of policies across their network for how to mark a high-priority packet, so if one of their customers wants to talk VOIP to another, it'll work - but if I've got DSL from one ISP, and you've got a cable modem from another, and our ISPs aren't using compatible QoS settings or ToS markings, we may not be able to send high-priority packets to each other, or maybe I can send high-priority packets on my half of the network, but your ISP doesn't recognize my ISP's markings so it resets everything to vanilla, etc. This means that a nationwide or global ISP has some advantages over a local or regional ISP.
Some telco monopolies or ex-monpolies in the third world are trying to ban VOIP services that compete with their overpriced traditional voice service, and encryption can be useful for evading them. Costa Rica's trying that one, for instance. A few countries are paranoid about their subjects being able to have unrestricted conversations - China, for instance - but they might just block obviously encrypted calls as well.
But as you say, Cringely's not talking about them - he's talking about telcos failing to give high priority to competitor's VOIP packets, and encryption doesn't help that at all.
Encryption doesn't have to add to the delay - IPSEC certainly does, and some SSL-based approaches might, but if you're using encryption built into the voice protocol, the delays are trivial, because encryption calculations are much faster than voice compression if done well, and much much faster if done sloppily (e.g. RC4.)
The backbone's fat - most of the Tier 1 providers are running lots of OC48 or OC192 on fiber, or at least OC3 in small cities, and in general it's not filled up, because when you own the fiber, it's cheaper to fire up more bandwidth than it is to get fancy equipment to do all the prioritization equipment and engineering. And most of the bandwidth is already data - there are more bits of data than raw voice today, and running compressed VOIP would make it much smaller.
The bottlenecks are the skinny edges - mostly individual user's lines, but to some extent DSL feeder networks if the providers aren't careful about how much to oversubscribe, or concentrator networks to small cities not near the backbones.
Not everybody's in DSL range, but almost all of the DSL services have a wide choice of ISPs who provide upstream connectivity and set service policies, even if the wire is managed by the phone company and the DSLAM is managed by a phone company or CLEC like Covad. While there's some regulatory stuff that drives this, it's largely because DSL technology is fundamentally ATM PVCs underneath, so it's easy to deliver them to multiple service providers.
Cable modem doesn't have the same built-in competitiveness, because the right technology is routed IP service all the way down to the head end. When the dial ISPs started to be threatened by cable modems and raised a big "open the technology" PR campaign, the cable companies did the stupid monopolistic thing and claimed that they'd invested all this money and should be allowed to make a profit and lobbied lots of politicians; the right choice would have been for them to explain that their technology really *was* open (because it was! It was IP routing), and come up with an attractive reseller price and a wholesale billing option. But no, they treated it like it was Pay-Per-View, which they knew something about.
If your employer can't reach you on your VOIP phone, they'll call your cell phone, or if you can't reach them on VOIP, you'll call them. If you've got DSL, VOIP should be about as reliable as POTS (the two biggest problems with VOIP are physical problems with the access line, which doesn't care much whether it's taking down POTS or DSL, and power failures, which mean your computer wasn't going to work so you were going to be stuck driving to the office anyway.) Cable modems are a bit different, because the repair infrastructure cost models for cable TV are built around the concept that it's just television, and if your TV stops working on a dark and stormy night, you can read a book or watch videos or play with your kids until they get around to fixing it.
The real issue is whether your employer will pay for your cell phone if they're using too many of your minutes. With pagers, it was pretty obvious that it was the employer's expense, because almost nobody really *wanted* a pager, and the monthly cost was usually fixed. On the other hand, these days, you're going to have a cellphone anyway.
(Explanation to non-US readers: when the US telco monopoly got split up in the 1980s, the regional Bell companies and smaller telcos were the part that got to run local telephone service, and long distance calls were run by competitive long distance carriers, who are now mostly either going bankrupt or being bought by the Bells or making money in other ways like mobile phones.
The Bells aren't going to lose too much money to residential VOIP, because most of the people who are using it are using DSL, so they're getting to rent the old telco copper wire and sometimes to provide ISP service on top of it. They'll lose some business, because some of the VOIP users get their broadband from cable modems instead, but they're getting to charge more for what they keep.
The long distance companies are in some trouble from residential VOIP, because they don't get to rent fully-depreciated wire to consumers at high prices. But they were in trouble anyway, because cheap fiber made the costs of transmission go down, and Moore's Law made the cost of switching equipment go down, and VOIP and similar technologies deployed as telco infrastructure by newer competitors means that the prices of voice minutes have been diving rapidly for 2-3 decades, and you could pack a lot more margin in a 40 cent call than a 4 cent call or a 1 cent call, and residential VOIP is just kicking them while they're down.
The real disruption is the effects on business telephony. Most VOIP applications these days are internal, with IP PBXs replacing old-fashioned PBXs, and VOIP calling between different offices of a single enterprise, but there's not a lot of VOIP calling between companies yet - H.323 wasn't really designed for that problem, and SIP hasn't fully emerged yet. If it weren't for the need to preserve connectivity to POTS, especially to cellphones, and the security problems associated with networking different companies' VOIP systems together, we'd be just about to hit the tipping point where huge chunks of the business voice market disappear in a puff of greasy orange smoke.
The highest-value business calling service in the US has been toll-free call centers, and it's an odd market. It really provides two different services - letting customers avoid paying for calls (which mattered a lot more at 25 cents/minute than at 1c/min or 0 c/min), but less obviously, it provides extremely flexible mechanisms for managing traffic load between call center agents, who cost more per minute than the phone calls (even a $6/hour telemarketer grunt is 10 cents/minute.) That part's harder to replace with other telephone technology - but the Web replaced a lot of former toll-free calling by making it possible for companies to get their information out to the public without having to have operators send people snail-mail, and online travel reservations are taking away more of that business. Travel reservations were already having trouble, because the 9/11/2001 tragedy cut way down on travel for a couple of years, so that meant a lot fewer calls to reservation agents.
SIP and the older H.323 use standards-based codecs that provide telephone-like frequency ranges ( 3-4kHz mono) and get a bit noisy with packet loss and jitter. Skype mostly uses proprietary codecs (from GlobalIP Sound) which are designed to tolerate more packet loss and jitter, and I think they also support some codecs that handle higher frequency ranges (because they're no longer constrained by 1930s carbon microphones and 1960s 64-kbps channel sizes), so they're able to sound better. As somebody who supports open standards, and as a crypto geek who *really* doesn't trust non-open crypto standards, I find this frustrating (:-), but in practice, far too many of the SIP vendors don't bother turning on their standards' optional crypto features at all, and with H.323 it was even less common.
Your points about increasing bandwidth are right on, but there are a couple of technical nitpicks - bandwidth is important, but jitter from competing data packets can be a bigger issue. Naive encapsulation techniques mean that an 8kbps codec typically expands to 25-30kbps of IP traffic (because you're taking a lots of very small Voice data samples and wrapping them in RTP, UDP, and IP headers, so it's mostly overhead.) However, one big annoyance is that conventional data usually wants to ship 1500-byte packets, and sometimes your VOIP packet gets stuck waiting for a data packet to finish transmitting. (Prioritization reduces how many of them you have to wait for, but they do get their turn occasionally.) At 128kbps, this is about 100ms; at 384kbps it's only ~33ms, which is less annoying. In theory, you could fix this by reducing your MTU size to something smaller like 576 - it's less efficient for data transfer, and too many applications don't know how to do PMTU discovery properly so they fail. In practice, most upstream data is smaller packets anyway (e.g. small http requests that get big response packets on your faster downstream connections, but only occasional outbound email/ftp/http-POST), so you get a lot of Extra Slack that you don't deserve.
However, file-sharing applications like BitTorrent blast out lots of big outbound packets, causing jitter on the way out, and can also fill up your inbound connection, which most other applications can't (or at least, not for very long, because the far end is a server sending traffic to a lot of people or else it's a home user or at most a T1 so it's no faster than your DSL/cable downstream.) So you probably still need to turn it off when you're trying to talk on the phone, just like you used to have to turn off the radio when you wanted to talk on the phone.
Yes, there are some ISPs that want to kill every application that generates upstream traffic, so that any consumer in their right mind would buy services from somebody else. And there are third-world telecom monopolies or ex-monopolies that use their position to strangle new competition. (In the US, the worst offenders are mostly cable TV companies, but even in the bad old days of Excite@Home banning anything server-like, they understood that the main reason people bought their service was to file-share pirated music. And in the Pacific Rim, unfortunately Australia's telecom industry has a third-world attitude toward data users.)
But fundamentally, the things Cringely's complaining about aren't accurate, because he doesn't understand the technology or the resulting economics. Yes, telcos are dealing with the threat of VOIP, and it's making their heads explode, and VOIP is much *much* harder to integrate with an old-fashioned telephone infrastructure than to run as a pure-VOIP business. (The technology's difficult, making it scale is difficult, different parts are centralized or decentralized, all the assumptions about who hands money to whom are different, the regulatory infrastructure doesn't match well at all, etc.) And the telcos are making sure that their data networks will support any VOIP services they develop with as close as they can get to traditional telco voice quality, and they're not sure how to deal with the fact that cellphones have convinced the public to accept lower-quality calls and newer codecs with much higher frequencies can support speakerphones much better.
Some big ISPs happen to be owned by telcos, or by telco-wannabees like the cable TV companies. Most of them are working on adding CoS capabilities to their backbones, but that's the least critical part of the network because most of them own their own fiber plants, and it's cheaper for them to burn more wavelengths on their fibers than to add fancy engineering capabilities to their routers or to hire fancy engineers to run them. It's the friendly mom&pop ISPs (that Cringely's not worried about) who are most likely to have backbone congestion issues that need CoS support to prioritize VOIP over best-effort data applications, because they're running at a different scale and don't generally own their own fiber networks.
The places that CoS matters most are the skinny parts of the network - the ingress from the customer's premises to the ISP's POP, and the egress from the ISP's POP to the customer's premises. The ingress direction is really a customer hardware and management problem, making sure that VOIP packets get on the wire before data packets, but service providers (including Vonage) typically handle that by forcing the customer's data through the same box that converts traditional-phone signals to VOIP, and software-based providers like Skype handle that inside the user's PC. This doesn't require the ISP to do anything, though it's sometimes cheaper to build those capabilities into the DSL/cable modem.
The egress direction can benefit from CoS marking, or from other fair-queuing systems that share bandwidth between remote sites or protocol types, or even from dumber systems that prioritize UDP over TCP. In a symmetric environment, like most business T1 connections, this is the most critical part of the system, because data applications can drown out voice unless there's some QoS approach. But most consumer connections are asymmetric, with much faster downstream connections than upstream, so there's less of a problem. Also, in most home applications, if downstream bandwidth is the bottleneck, it's usually because of some application like downloading music that can be turned off or slowed down during phone calls, which isn't a practical approach in most multi-person offices.
Cringely's arguments are especially bogus because the impact of backbone QoS / CoS features on network performance is much smaller than the impact of slow upstream connections in ADSL and Cable Modems. A 12
Disclaimer: I work for a large telecommunications company that does IP and voice. These are my opinions, not theirs.
In most ISP networks today, the big causes of latency are distance, packet insertion time in the skinny parts of the network (1500 byte packets take ~100ms at 128kbps, so you don't want to wait behind them, and that's also the biggest cause of jitter), and queuing in the skinny parts of the network again, that's the customer's upstream and sometimes downstream connections.
If you've got a business with a T1 line, shared by lots of users then using QoS to manage queuing priorities is important, but your MTU size isn't a big worry because 1500 bytes takes ~8ms at 1.5 Mbps, which is good, because there are too many boxes to set everybody's MTU small, and too many applications that can't do PMTU discovery correctly to just set it small in the router. QoS helps by letting VOIP cut ahead of big data packets in the egress queue, so you only get hit with one set of 10ms jitter instead of multiples of that, but even if an ISP's router only does some variant on fair queuing, that's usually good enough.
If you've got an ADSL line or cable modem with only 128kbps upstream, then QoS in the network isn't your big problem - it's keeping packet sizes small enough that they don't cause too much jitter. (It's still an issue at 384kbps upstream, but not as bad.) If you're a typical couch-potato consumer, you luck out, because you probably don't transmit very many big packets (e.g. HTTP requests are 100-150 bytes, and the 1500-byte responses are on your fast downstream network.) If you're running a file sharing application, which does transmit non-trivial numbers of upstream fat packets, so you may need to pause BitTorrent while you're talking, but as a home user you can do that. In theory, most DSL is really running ATM, so if you separated the voice and data onto two different PVCs, instead of combining it on one PVC, you could interleave cells and avoid the MTU jitter, but in practice, not only are most DSL carriers not able to manage multiple PVCs, but most DSL routers (or low-end Cisco boxes) aren't bright enough to interleave streams, as opposed to sending all 32 cells from a 1500-byte packet in one burst.
QoS can help home users with outbound queuing, but the ISP doesn't need to actually pay attention to it - the big bottleneck is usually getting to their POP.
Bram Cohen is adding some QoS marking to BitTorrent, though I don't know which marking scheme he's using (alas, I don't read python yet.) Typical home firewall/routers don't usually know what to do with QoS unless they've got built-in VOIP cards, but at least applications running on the same PC as BitTorrent can benefit from it.
Businesses also like to bitch about keeping latency under 150ms, because that's what "Beating Up ISPs So You Can Run VOIP For Dummies" says, which is no problem within the US middle-48 states or within Europe, where big ISPs typically get 30-50ms max, but India and Singapore are far enough away from New York City that you won't get that unless you change the speed of light in fiber or dig a tunnel through the earth's core. And most big ISPs typically have backbone jitter less than 10ms, compared to customer-driven MTU-size jitter of at least 17ms (for 1500 byte packets from one T1 to another T1), so a lot of the bitching about jitter SLAs is misdirected energy as well. It gets worse as businesses start planning for VOIP support for home workers on DSL, but fortunately cheap VOIP hardware is getting better.
Sure, a few ISPs may try to play games, but that's not the game they'll play - some third-world monopoly or recently-ex-monopoly telcos will block VOIP entirely, and some cable modem companies will do stupid things because they're incapable of not doing any stupid thing they can think of, but it's really few.
Here's how it works technically:
Upstream bandwidth from customer to the ISP is often limited due to asymmetric technologies, and it's up to the customer's hardware to put the time-critical packets on the wire first and keep their upstream MTU sizes small enough (e.g. 1500 byte packets take too long at 128kbps.)
Some ISPs have DSL concentrator networks that are oversubscribed upstream, but not many - the technology's symmetric, and consumer bandwidth is mostly downstream. VOIP takes up very low bandwidth - typically about 30kbps (8kbps G.729a plus RTP/UDP/IP headers). If you're not getting enough upstream bandwidth, you may need to buy a bigger pipe.
Once you're past the feeder networks onto open backbone, there's plenty of room, at least on any telco-sized ISP (mom&pop ISPs may have congestion problems, but they're not the ones Cringely is accusing of being Evil.) Most of the Tier 1 providers use a lot of OC48s, especially telcos who own their own fiber plants - it's cheaper to waste bandwidth than to use lots of mux equipment to limit it, at least in the network core.
Downstream feeder networks can be congested, but they're not usually that bad, and again, VOIP uses very little bandwidth.
The big problem is dumping the traffic onto the recipient's egress line. If the recipient is trying to run BitTorrent and VOIP at the same time, without any QoS markings, their quality will suffer - but most people have fatter pipes downstream than upstream, and they'll just have to pause BitTorrent/ftp/etc. while talking unless their CPE is smart enough to throttle outbound requests.
QoS markings can help prioritize that egress traffic, so the VOIP packets get to exit before data packets do. As ISPs add QoS to their available services, they'll obviously include it with any of their VOIP offers, and they might or might not charge extra for it as a separate offer.
Basically, if you're satisfied with VOIP quality now, it's not going to get worse as new technology gets deployed, except technology that encourages you to consume more bandwidth at home without buying a bigger pipe, and it might get better.
Spectrum Regulators have two reasons for justifying their existence - (1) protecting monopolies of the politically well-connected, and (2) preventing new equipment from interfering with existing equipment. Since this article isn't intended to be flamebait, I'll leave the first along (:-) The EU's response to the wireless part of the late 90s technology boom was to auction off their spectrum to the EU cellphone carriers, who spent $100 Billion trying to outbid each other for the opportunity to become 3G-powered Mozillionaires (just about when the boom was ending, helping fuel mass telecom company bankruptcy problems.) So that spectrum is very valuable to its owners, at least as a sunk cost, and anything that interferes with it is a problem, and it's the regulators' job to protect the spectrum they've sold.
Of course, UWB technology is designed to pretty much not interfere with anything else, and it's far better at it than WiFi, which has already annoyed the regulatory environment by being wildly successful in large part *because* its development isn't limited by regulators. So 99% of the "interference" is "people might buy UWB instead of 3G", but that's expressed in technical terms of "they might garble a few bits on our services which are fairly robust, have built-in ECC, and run TCP protocols which detect and correct for errors", so the 3G owners ask for unreasonably low power levels for UWB and the regulators go along with them. In reality, the equipment will probably have user-adjustable signal levels, they'll get type-approved with the Eurocrat settings, and users will immediately crank them up to US power levels, which still won't bother anybody.
Yeah, SEOs are 90% slime and 10% standard advice about making the information on your page accessible (e.g. telling you to use the META keywords and not just have all your navigation information in dancing flash attachments.)
Google is a robot that tries to guess what pages are most interesting to humans.
SEOs try to take pages that are not very interesting to humans and make them look interesting to robots.
This is annoying to humans, because the pages aren't very interesting to humans.
Occasionally lying to robots can be fun - the "Weapons of Mass Destruction" Googlebomb, etc.
But mostly it's just annoying, and it's made some kinds of searches totally useless. I've recently been trying to find out about drug interactions, and not only do you get tons of legitimate pages that are describing the "side effects" of "drug1" and also list "drug2" in their index of things they'll tell you about (or sell, which is fine), but there are lots of pages which are full of robo-generated sentences with drug names, common medical phrases, and phrases having nothing at all to do with medicine, with medical phrases in the URL pathnames as well, designed to attract search engines to their pages. I'd expect this if I were searching for widely spammed drugs starting with V, but it's annoying to have to put up with it when I'm looking for variants on penicillins.
To the extent that anything in Afghanistan has ever been regular, the Taliban (about half the prisoners captured over there) were regulars. Their party was the ruling government, a government that only a few months before received a $43M payment from the US for doing such a fine job of suppressing opium production. The US invaded them primarily because Osama bin Laden was there, but attacked the Taliban government alleging that they had permitted bin Laden to operate. That doesn't mean that the regular grunts ought to be treated as terrorists because of the actions of their politicians/generals - they ought to be treated as PoWs. The US has argued that since the War on Terror is a perpetual, never-ending war that won't be over until we've stomped out the last vestige of anybody who dislikes the US, that the terroris prisoners don't ever have to be let out (unlike traditional PoWs) - but the Taliban were attacked because the US was attacking their government, and the US has finished defeating them, deplacing them, and replacing them with a democratically elected government, so it's time to let the Taliban PoWs go home. Perhaps a few of their leaders can be kept for show trials, but you don't do that to grunts.
The Nurenberg trials established the principle that you can prosecute grunts for committing war crimes even if they were only obeying orders. But the Taliban grunts weren't committing war crimes; they were simply resisting the American invasion. (What they did to get into power was a separate story; it's not like they were nice people, but the way you deal with war crimes is to hold trials.)
A large part of the motivation for the Geneva conventions is that governments agree to treat each other's PoWs in a civilized fashion in the hopes that their own PoWs will be treated in a civilized fashion, as opposed to throwing them in tiger cages and subjecting them to constant beatings and torture the way the Vietnamese did to US PoWs. Now that the Bush/Cheney Administration has declared that their policy is to disappear PoWs and stick them anonymously into tiger cages, beat them, freeze them, water-board them, and do various things on both sides of most definitions of "torture", and reinforced it by the way they've treated random detainees in Iraq, they've endangered any future US soldiers caught by anybody for the next few decades. It's shameful and Un-American.
Worms are a *terrible* way to implement something like that - the only reason to use them is if you're trying to hide. An ISP who's not trying to hide can run a scanner on their clients, and quarantine them until they get cleaned up. Some ISPs routinely do that with customers whose machines get detected running attacks; it's not a bad idea to do that as part of the setup process for new users.
The client doesn't need to be technically sophisticated - you set them up by routing all their HTTP requests to your new-user server, so they don't even have to remember to go there themselves, tell them to wait while you run a scan, and then have them tell you whether they've got XP/Win2K/Win98/Mac/Linux and download the appropriate checkup program. Furthermore, it's not unreasonable to keep them in a quarantine zone with an easy mechanism to get full internet capability if they can fill out your form correctly - that keeps the naive users in protected mode, and lets the clients who know how to RTFM get unfiltered or semi-filtered access if they want it.
A couple of years ago I got DSL in my lab, and left a couple of machines on it unprotected partly to experiment with and partly to see what would happen to them. One Linux box was running tcpdump continuously to sniff the network. The Win95 box was never bothered - it had anti-virus software, and I used Netscape rather than IE (and of course there was nothing useful on it to exploit because it was a Win95 box:-) The RedHat 6.x box typically lasted a week between crackings - I eventually named the machine "Kenny" because it kept getting brutally and senselessly killed every week. One of the crackers really didn't like it when I got rid of his Staecheldraht installation and reformatted the disk. So I installed a newer RedHat version, in a mode with no servers running, and people mostly left it alone other than basic doorknocking.
This *was* a few years ago, and crackers have gotten more sophisticated, and DSL and cable modem proliferation means there are lots more fast net connections for them to work with. At the time, Win95 was obsolete, RedHat was doing 7.x versions, and Staecheldraht attacks seemed to mostly come from universities (including Washington University, whose wu-ftpd was one of the main holes exploited by crackers, and a machine that looked like it was from MIT but was actually from somebody in Japan with a byte-order problem.)
As long as the original authors, who presumably know a little bit about computer security, build some decent security mechanisms in their tools, then script kiddies don't need to think about it themselves - they can just enter a password when the program tells them to. Also, lots of these tools appear to be written for hire by organized crime, e.g. Russian Mafia, who use them to make money through phishing and DDOS extortion, and they can hire good designers. The question with those products, though, is how much information they report back to their original designers while they're ostensibly only working for the script kiddie who's running them...
There are two reasons a hacker might not want to leave the key unencrypted on his disk - one is that if he gets caught, it's proof that he knew the key, and the other is that if somebody cracks that machine, they can steal his zombie army. Neither problem is a real worry - if you're Evil But Not Stupid, you don't run the zombie controller on your own machine, you crack somebody else's machine and use that to crack somebody else's machine and use *that* to run the zombies from, so it's hard to trace back to you or the cybercafe you rode in on. The theft problem is a threat model issue - since the zombie controller is just another hijacked machine, you may decide not to worry about it getting stolen, or you do a little more cookbook cryptography and handle the asymmetric private key the way PGP does - store it encrypted using a conventional symmetric cypher using a password you can easily remember, so you don't need to store that on your machine, though you might write it on a yellow sticky note.
Slashdot Mirror
Skype seems to be a pretty decent system, and it uses good codecs, but unfortunately it's a closed proprietary system, so you won't be able to hook up your own PBX to it unless they come out with a PBX feature, or unless you want to relay it through a conventional phone line. They are adding "Skype In", which will let people make incoming calls from POTS lines, so at least the service is becoming more useful.
I used to commute to San Francisco by Caltrain. It was about 45 minutes to drive, or 1:15 to take the train, but the train was a *lot* less hassle, and I could work on my laptop on the train, usually for more than half an hour. One reason the train was easier was parking - the train station parking lots had space, while parking near my office in the city was not only expensive, but often time-consuming, because I drive a van, and most San Franciso parking garages either don't allow vans or charge $20-40 extra for them, and open lots tended to become construction sites (for condos during the dot-com boom, and highway construction during the crash.)
Also, Canadian Broadcasting is good if you can get it. You'll recognize a few programs as "oh, *that's* what PBS was ripping off when they did this program...".
Back when I was doing an occasional 1.5-hour-each-way commute from NJ to Long Island, I found it was just about right to listen to a bit of traffic radio plus tapes of the Grateful Dead Hour. These days I usually work from home, with an occasional 1-hour commute into San Francisco by train, but since I don't have to drive I can use my laptop.
I guess there are people running uncompressed VOIP wide-area, but G.729a is really quite reasonable. It gets a higher MOS score than the cell phone codecs, plus you usually have a decent microphone and no road noise in the background which make a big difference.
If your ISP offers this, it can be very useful for some applications - VOIP and video-conferencing obviously benefit from it, while FTP, email, and streaming video don't need to be high-priority, because it's ok if they arrive 100ms later. Applications in between are typically database applications (some SAP and Oracle things don't like long delays, and perform much better if they get a higher priority than ftp.) It would be really nice if you could designate some applications as lower-than-normal priority, such as File Sharing - other applications get priority, but you'd like BitTorrent to be able to use up any leftovers - but the standard IP protocol markings aren't really good for that, so usually somebody needs to specially configure a router to make that happen, and that often costs money.
They're normally tagged with all-0, which is Vanilla priority, because that's what everybody's Windows and Linux and Mac and Cisco and Linksys and Netgear box puts on the packets unless you tell your box to mark it differently (which some boxes know how to do and some don't.) Some ISPs will let you mark the packets with other priorities and ignore them; other ISPs will mark the packets back to 0 if they don't support QoS features, or drop them, or they'll remark/drop them if you're not paying extra for higher-grade service, or if you've marked them with a format that's not the one their equipment users.
Unfortunately, the standard IP priority markings provide a number of options for specifying that a packet should be treated as a higher priority the default, but don't really provide a way to say that it should be treated as a lower priority (except by increasing the probability of discarding the packet.) There are applications like file sharing and ftp which don't mind extra delay, and will soak up any available bandwidth, so marking them lower-priority would be a good thing - leave them in the queue if there's more important work to do, but don't just drop them. Since about 30-35% of the packets on the internet today are BitTorrent, this could make a real difference to some people.
Cable modems work differently - the right architecture handles routing from fairly close to the customer, and the easiest way to "open up" the business is strictly non-technical a wholesale billing arrangement and discounted prices, with the newbie ISP buying service at a couple of peering points, but pretty much the whole infrastructure run by the cable TV company or a partner of theirs. There are technical kluges like PPPoE that provide a bit more control, but they're ugly hacks.
While there are ISPs that are far worse about it - Telstra, for instance, or some of the US cable companies who think that they need to catch up with Telstra's unwillingness to let people actually use data for anything - a 2GB/day cap is still annoying. Basically, it means that you can't do file-sharing without being very selective in what you leave running for how long - so you can download that latest Knoppix release and share out a couple of copies, but you can't leave your entire set of Linux and *BSD distros open all month.
Cringely's speculations about providers tinkering with QoS are bogus - I've heard other clueless people ranting about how awful it is that some ISPs might start offering higher quality service for more money (the bastards!) At most, his arguments are really that some ISPs might fail to provide higher-quality service for people who don't pay extra for it, and that this might not be good enough quality in spite of the fact that many people like it today. And if that's the case, and their basic service isn't good enough, then either you're going to get a different ISP, or you're going to pay more for better service, or you're going to keep your old-fashioned phone, and of course, if you can afford broadband and VOIP service, you can also afford a cellphone (at least a pre-paid 7-11 phone for emergencies), which will even work when bad weather makes your cable modem go down.
Furthermore, Cringely focuses on QoS in the backbone, but the real impact isn't there, where the network's fat enough, but at the skinny edges. The ISPs have no control over your outbound traffic - what if you're trying to call 911 and somebody is downloading that music video file you're sharing? That has a much bigger impact on VOIP performance than anything a backbone provider is going to do. Or what happens if that music you're downloading starts getting better performance because the server is less busy - QoS could help that direction a bit, but if your ISP uses one standard for QoS markings and the 911 Center's ISP uses a different standard (there are lots), then the QoS isn't going to work the way they expected anyway.
Most ISPs don't support prioritization right now, at least for low-end services - they're starting to add it for business services, but it's much easier to make it work on a T1 line than on a DSL line where different people are providing different parts of the infrastructure and so nobody has enough control to make a good Service Level Agreement - and without a good SLA, it's hard to get customers to pay extra. Also, most ISPs that do support QoS only support it within their own networks - figuring out how to interconnect with other ISPs is difficult, as is figuring out who to charge how much for it. (For instance, what if one ISP uses two priority levels, one uses four, one uses a different four, one uses five, some use TOS markings while others use DSCP, etc.)
Interconnections between ISPs turn out to be a big problem for the sort of ham-handed regulation you're suggesting. A single ISP is going to deploy one set of policies across their network for how to mark a high-priority packet, so if one of their customers wants to talk VOIP to another, it'll work - but if I've got DSL from one ISP, and you've got a cable modem from another, and our ISPs aren't using compatible QoS settings or ToS markings, we may not be able to send high-priority packets to each other, or maybe I can send high-priority packets on my half of the network, but your ISP doesn't recognize my ISP's markings so it resets everything to vanilla, etc. This means that a nationwide or global ISP has some advantages over a local or regional ISP.
But as you say, Cringely's not talking about them - he's talking about telcos failing to give high priority to competitor's VOIP packets, and encryption doesn't help that at all.
Encryption doesn't have to add to the delay - IPSEC certainly does, and some SSL-based approaches might, but if you're using encryption built into the voice protocol, the delays are trivial, because encryption calculations are much faster than voice compression if done well, and much much faster if done sloppily (e.g. RC4.)
The bottlenecks are the skinny edges - mostly individual user's lines, but to some extent DSL feeder networks if the providers aren't careful about how much to oversubscribe, or concentrator networks to small cities not near the backbones.
Cable modem doesn't have the same built-in competitiveness, because the right technology is routed IP service all the way down to the head end. When the dial ISPs started to be threatened by cable modems and raised a big "open the technology" PR campaign, the cable companies did the stupid monopolistic thing and claimed that they'd invested all this money and should be allowed to make a profit and lobbied lots of politicians; the right choice would have been for them to explain that their technology really *was* open (because it was! It was IP routing), and come up with an attractive reseller price and a wholesale billing option. But no, they treated it like it was Pay-Per-View, which they knew something about.
The real issue is whether your employer will pay for your cell phone if they're using too many of your minutes. With pagers, it was pretty obvious that it was the employer's expense, because almost nobody really *wanted* a pager, and the monthly cost was usually fixed. On the other hand, these days, you're going to have a cellphone anyway.
The Bells aren't going to lose too much money to residential VOIP, because most of the people who are using it are using DSL, so they're getting to rent the old telco copper wire and sometimes to provide ISP service on top of it. They'll lose some business, because some of the VOIP users get their broadband from cable modems instead, but they're getting to charge more for what they keep.
The long distance companies are in some trouble from residential VOIP, because they don't get to rent fully-depreciated wire to consumers at high prices. But they were in trouble anyway, because cheap fiber made the costs of transmission go down, and Moore's Law made the cost of switching equipment go down, and VOIP and similar technologies deployed as telco infrastructure by newer competitors means that the prices of voice minutes have been diving rapidly for 2-3 decades, and you could pack a lot more margin in a 40 cent call than a 4 cent call or a 1 cent call, and residential VOIP is just kicking them while they're down.
The real disruption is the effects on business telephony. Most VOIP applications these days are internal, with IP PBXs replacing old-fashioned PBXs, and VOIP calling between different offices of a single enterprise, but there's not a lot of VOIP calling between companies yet - H.323 wasn't really designed for that problem, and SIP hasn't fully emerged yet. If it weren't for the need to preserve connectivity to POTS, especially to cellphones, and the security problems associated with networking different companies' VOIP systems together, we'd be just about to hit the tipping point where huge chunks of the business voice market disappear in a puff of greasy orange smoke.
The highest-value business calling service in the US has been toll-free call centers, and it's an odd market. It really provides two different services - letting customers avoid paying for calls (which mattered a lot more at 25 cents/minute than at 1c/min or 0 c/min), but less obviously, it provides extremely flexible mechanisms for managing traffic load between call center agents, who cost more per minute than the phone calls (even a $6/hour telemarketer grunt is 10 cents/minute.) That part's harder to replace with other telephone technology - but the Web replaced a lot of former toll-free calling by making it possible for companies to get their information out to the public without having to have operators send people snail-mail, and online travel reservations are taking away more of that business. Travel reservations were already having trouble, because the 9/11/2001 tragedy cut way down on travel for a couple of years, so that meant a lot fewer calls to reservation agents.
Your points about increasing bandwidth are right on, but there are a couple of technical nitpicks - bandwidth is important, but jitter from competing data packets can be a bigger issue. Naive encapsulation techniques mean that an 8kbps codec typically expands to 25-30kbps of IP traffic (because you're taking a lots of very small Voice data samples and wrapping them in RTP, UDP, and IP headers, so it's mostly overhead.) However, one big annoyance is that conventional data usually wants to ship 1500-byte packets, and sometimes your VOIP packet gets stuck waiting for a data packet to finish transmitting. (Prioritization reduces how many of them you have to wait for, but they do get their turn occasionally.) At 128kbps, this is about 100ms; at 384kbps it's only ~33ms, which is less annoying. In theory, you could fix this by reducing your MTU size to something smaller like 576 - it's less efficient for data transfer, and too many applications don't know how to do PMTU discovery properly so they fail. In practice, most upstream data is smaller packets anyway (e.g. small http requests that get big response packets on your faster downstream connections, but only occasional outbound email/ftp/http-POST), so you get a lot of Extra Slack that you don't deserve.
However, file-sharing applications like BitTorrent blast out lots of big outbound packets, causing jitter on the way out, and can also fill up your inbound connection, which most other applications can't (or at least, not for very long, because the far end is a server sending traffic to a lot of people or else it's a home user or at most a T1 so it's no faster than your DSL/cable downstream.) So you probably still need to turn it off when you're trying to talk on the phone, just like you used to have to turn off the radio when you wanted to talk on the phone.
But fundamentally, the things Cringely's complaining about aren't accurate, because he doesn't understand the technology or the resulting economics. Yes, telcos are dealing with the threat of VOIP, and it's making their heads explode, and VOIP is much *much* harder to integrate with an old-fashioned telephone infrastructure than to run as a pure-VOIP business. (The technology's difficult, making it scale is difficult, different parts are centralized or decentralized, all the assumptions about who hands money to whom are different, the regulatory infrastructure doesn't match well at all, etc.) And the telcos are making sure that their data networks will support any VOIP services they develop with as close as they can get to traditional telco voice quality, and they're not sure how to deal with the fact that cellphones have convinced the public to accept lower-quality calls and newer codecs with much higher frequencies can support speakerphones much better.
Some big ISPs happen to be owned by telcos, or by telco-wannabees like the cable TV companies. Most of them are working on adding CoS capabilities to their backbones, but that's the least critical part of the network because most of them own their own fiber plants, and it's cheaper for them to burn more wavelengths on their fibers than to add fancy engineering capabilities to their routers or to hire fancy engineers to run them. It's the friendly mom&pop ISPs (that Cringely's not worried about) who are most likely to have backbone congestion issues that need CoS support to prioritize VOIP over best-effort data applications, because they're running at a different scale and don't generally own their own fiber networks.
The places that CoS matters most are the skinny parts of the network - the ingress from the customer's premises to the ISP's POP, and the egress from the ISP's POP to the customer's premises. The ingress direction is really a customer hardware and management problem, making sure that VOIP packets get on the wire before data packets, but service providers (including Vonage) typically handle that by forcing the customer's data through the same box that converts traditional-phone signals to VOIP, and software-based providers like Skype handle that inside the user's PC. This doesn't require the ISP to do anything, though it's sometimes cheaper to build those capabilities into the DSL/cable modem.
The egress direction can benefit from CoS marking, or from other fair-queuing systems that share bandwidth between remote sites or protocol types, or even from dumber systems that prioritize UDP over TCP. In a symmetric environment, like most business T1 connections, this is the most critical part of the system, because data applications can drown out voice unless there's some QoS approach. But most consumer connections are asymmetric, with much faster downstream connections than upstream, so there's less of a problem. Also, in most home applications, if downstream bandwidth is the bottleneck, it's usually because of some application like downloading music that can be turned off or slowed down during phone calls, which isn't a practical approach in most multi-person offices.
Cringely's arguments are especially bogus because the impact of backbone QoS / CoS features on network performance is much smaller than the impact of slow upstream connections in ADSL and Cable Modems. A 12
In most ISP networks today, the big causes of latency are distance, packet insertion time in the skinny parts of the network (1500 byte packets take ~100ms at 128kbps, so you don't want to wait behind them, and that's also the biggest cause of jitter), and queuing in the skinny parts of the network again, that's the customer's upstream and sometimes downstream connections.
If you've got a business with a T1 line, shared by lots of users then using QoS to manage queuing priorities is important, but your MTU size isn't a big worry because 1500 bytes takes ~8ms at 1.5 Mbps, which is good, because there are too many boxes to set everybody's MTU small, and too many applications that can't do PMTU discovery correctly to just set it small in the router. QoS helps by letting VOIP cut ahead of big data packets in the egress queue, so you only get hit with one set of 10ms jitter instead of multiples of that, but even if an ISP's router only does some variant on fair queuing, that's usually good enough.
If you've got an ADSL line or cable modem with only 128kbps upstream, then QoS in the network isn't your big problem - it's keeping packet sizes small enough that they don't cause too much jitter. (It's still an issue at 384kbps upstream, but not as bad.) If you're a typical couch-potato consumer, you luck out, because you probably don't transmit very many big packets (e.g. HTTP requests are 100-150 bytes, and the 1500-byte responses are on your fast downstream network.) If you're running a file sharing application, which does transmit non-trivial numbers of upstream fat packets, so you may need to pause BitTorrent while you're talking, but as a home user you can do that. In theory, most DSL is really running ATM, so if you separated the voice and data onto two different PVCs, instead of combining it on one PVC, you could interleave cells and avoid the MTU jitter, but in practice, not only are most DSL carriers not able to manage multiple PVCs, but most DSL routers (or low-end Cisco boxes) aren't bright enough to interleave streams, as opposed to sending all 32 cells from a 1500-byte packet in one burst.
QoS can help home users with outbound queuing, but the ISP doesn't need to actually pay attention to it - the big bottleneck is usually getting to their POP.
Bram Cohen is adding some QoS marking to BitTorrent, though I don't know which marking scheme he's using (alas, I don't read python yet.) Typical home firewall/routers don't usually know what to do with QoS unless they've got built-in VOIP cards, but at least applications running on the same PC as BitTorrent can benefit from it.
Businesses also like to bitch about keeping latency under 150ms, because that's what "Beating Up ISPs So You Can Run VOIP For Dummies" says, which is no problem within the US middle-48 states or within Europe, where big ISPs typically get 30-50ms max, but India and Singapore are far enough away from New York City that you won't get that unless you change the speed of light in fiber or dig a tunnel through the earth's core. And most big ISPs typically have backbone jitter less than 10ms, compared to customer-driven MTU-size jitter of at least 17ms (for 1500 byte packets from one T1 to another T1), so a lot of the bitching about jitter SLAs is misdirected energy as well. It gets worse as businesses start planning for VOIP support for home workers on DSL, but fortunately cheap VOIP hardware is getting better.
Here's how it works technically:
- Upstream bandwidth from customer to the ISP is often limited due to asymmetric technologies, and it's up to the customer's hardware to put the time-critical packets on the wire first and keep their upstream MTU sizes small enough (e.g. 1500 byte packets take too long at 128kbps.)
- Some ISPs have DSL concentrator networks that are oversubscribed upstream, but not many - the technology's symmetric, and consumer bandwidth is mostly downstream. VOIP takes up very low bandwidth - typically about 30kbps (8kbps G.729a plus RTP/UDP/IP headers). If you're not getting enough upstream bandwidth, you may need to buy a bigger pipe.
- Once you're past the feeder networks onto open backbone, there's plenty of room, at least on any telco-sized ISP (mom&pop ISPs may have congestion problems, but they're not the ones Cringely is accusing of being Evil.) Most of the Tier 1 providers use a lot of OC48s, especially telcos who own their own fiber plants - it's cheaper to waste bandwidth than to use lots of mux equipment to limit it, at least in the network core.
- Downstream feeder networks can be congested, but they're not usually that bad, and again, VOIP uses very little bandwidth.
- The big problem is dumping the traffic onto the recipient's egress line. If the recipient is trying to run BitTorrent and VOIP at the same time, without any QoS markings, their quality will suffer - but most people have fatter pipes downstream than upstream, and they'll just have to pause BitTorrent/ftp/etc. while talking unless their CPE is smart enough to throttle outbound requests.
- QoS markings can help prioritize that egress traffic, so the VOIP packets get to exit before data packets do. As ISPs add QoS to their available services, they'll obviously include it with any of their VOIP offers, and they might or might not charge extra for it as a separate offer.
Basically, if you're satisfied with VOIP quality now, it's not going to get worse as new technology gets deployed, except technology that encourages you to consume more bandwidth at home without buying a bigger pipe, and it might get better.Of course, UWB technology is designed to pretty much not interfere with anything else, and it's far better at it than WiFi, which has already annoyed the regulatory environment by being wildly successful in large part *because* its development isn't limited by regulators. So 99% of the "interference" is "people might buy UWB instead of 3G", but that's expressed in technical terms of "they might garble a few bits on our services which are fairly robust, have built-in ECC, and run TCP protocols which detect and correct for errors", so the 3G owners ask for unreasonably low power levels for UWB and the regulators go along with them. In reality, the equipment will probably have user-adjustable signal levels, they'll get type-approved with the Eurocrat settings, and users will immediately crank them up to US power levels, which still won't bother anybody.
- Google is a robot that tries to guess what pages are most interesting to humans.
- SEOs try to take pages that are not very interesting to humans and make them look interesting to robots.
- This is annoying to humans, because the pages aren't very interesting to humans.
Occasionally lying to robots can be fun - the "Weapons of Mass Destruction" Googlebomb, etc.But mostly it's just annoying, and it's made some kinds of searches totally useless. I've recently been trying to find out about drug interactions, and not only do you get tons of legitimate pages that are describing the "side effects" of "drug1" and also list "drug2" in their index of things they'll tell you about (or sell, which is fine), but there are lots of pages which are full of robo-generated sentences with drug names, common medical phrases, and phrases having nothing at all to do with medicine, with medical phrases in the URL pathnames as well, designed to attract search engines to their pages. I'd expect this if I were searching for widely spammed drugs starting with V, but it's annoying to have to put up with it when I'm looking for variants on penicillins.
The Nurenberg trials established the principle that you can prosecute grunts for committing war crimes even if they were only obeying orders. But the Taliban grunts weren't committing war crimes; they were simply resisting the American invasion. (What they did to get into power was a separate story; it's not like they were nice people, but the way you deal with war crimes is to hold trials.)
A large part of the motivation for the Geneva conventions is that governments agree to treat each other's PoWs in a civilized fashion in the hopes that their own PoWs will be treated in a civilized fashion, as opposed to throwing them in tiger cages and subjecting them to constant beatings and torture the way the Vietnamese did to US PoWs. Now that the Bush/Cheney Administration has declared that their policy is to disappear PoWs and stick them anonymously into tiger cages, beat them, freeze them, water-board them, and do various things on both sides of most definitions of "torture", and reinforced it by the way they've treated random detainees in Iraq, they've endangered any future US soldiers caught by anybody for the next few decades. It's shameful and Un-American.
The client doesn't need to be technically sophisticated - you set them up by routing all their HTTP requests to your new-user server, so they don't even have to remember to go there themselves, tell them to wait while you run a scan, and then have them tell you whether they've got XP/Win2K/Win98/Mac/Linux and download the appropriate checkup program. Furthermore, it's not unreasonable to keep them in a quarantine zone with an easy mechanism to get full internet capability if they can fill out your form correctly - that keeps the naive users in protected mode, and lets the clients who know how to RTFM get unfiltered or semi-filtered access if they want it.
This *was* a few years ago, and crackers have gotten more sophisticated, and DSL and cable modem proliferation means there are lots more fast net connections for them to work with. At the time, Win95 was obsolete, RedHat was doing 7.x versions, and Staecheldraht attacks seemed to mostly come from universities (including Washington University, whose wu-ftpd was one of the main holes exploited by crackers, and a machine that looked like it was from MIT but was actually from somebody in Japan with a byte-order problem.)
There are two reasons a hacker might not want to leave the key unencrypted on his disk - one is that if he gets caught, it's proof that he knew the key, and the other is that if somebody cracks that machine, they can steal his zombie army. Neither problem is a real worry - if you're Evil But Not Stupid, you don't run the zombie controller on your own machine, you crack somebody else's machine and use that to crack somebody else's machine and use *that* to run the zombies from, so it's hard to trace back to you or the cybercafe you rode in on. The theft problem is a threat model issue - since the zombie controller is just another hijacked machine, you may decide not to worry about it getting stolen, or you do a little more cookbook cryptography and handle the asymmetric private key the way PGP does - store it encrypted using a conventional symmetric cypher using a password you can easily remember, so you don't need to store that on your machine, though you might write it on a yellow sticky note.