Yes, the buggers hop onto their three ships, land in the caribbean, start enslaving the locals and don't even bother with their paperwork. Hate it when that happens..
You sir, just earned a tinfoil hat. While I have no particular love for Bluecoat (they're competitors in another field), you're assuming things based on what you think to be the case. Claiming that others are misinformed simply because it doesn't fit your mental image is rather silly.
There's only so and so much time in a workday. Spending it on going over phone-home in detail and sending across sensitive information in the first place? Not so useful.
(We also do phone home. Aggregates only, nothing sensitive. It usually makes very little sense to go fucking with your customers or risking their sensitive data, so there's no reason to send anything else.)
If you use different compression algorithms, sure, it'd yield a different result. But if you rip a CD with default settings in whatever music manager - say iTunes, for posterity - you'd end up with the same file hash as the next guy that did the same thing with the same software. Digital data, et al.
This is actually not the case with dedicated solutions for this sort of thing (yes, they exist. No, they're not cheap), commonly used for annual general meetings by large corporate entities. A normal wireless network will hold up rather nicely as long as a) the AP's cope with the # of connected clients and b) whatever service you're pushing data to isn't too chatty.
It depends entirely on how many polls you need to perform in what time span. The way we do it (non-profit NGO) is by a simple web form - there's a number of terminals available for people who doesn't bring their own laptop/phone, and those who do bring their own, can use it. Performing a poll with 100 people takes ~2 minutes - but it'd depend on the number of people with their own equipment and the number of terminals at hand, naturally.
Avoid doing it by hand, if at all possible. Counting sucks and people are way, way more focused if they can get the outcome almost right away rather than after n minutes.
Think bigger. The US has a net export of culture (if I may call it that for the sake of the argument) - Disney is one rather marked example, but say Hollywood in general and ignore all other sources of culture for the time being. There's still a metric fuckwad of products out there in the world with Mickey and Donald images on them. Some are even produced by outfits in places where you actually pay royalties. Disney series - even old ones from the 80's - are broadcast in quite a few countries, also generating royalties. There's still an interest in the older Disney characters (yes, the more recent shows obviously wouldn't be free-for-all even if the characters went free-for-all, but nothing would stop other firms from making their own shows with the same characters)
This translates into a steady stream of revenue coming into the country from the rest of the world. Mickey & Donald. Batman. Superman. Hell, even Popeye. Money translates, sooner or later, into jobs. Either directly in the corporate entity that owns the IP, or by the spending of said money. All this is somewhat tangible. The benefits of not extending copyright aren't.
You (I'm not a resident of the US myself) need to provide some good, solid arguments backed up by good, solid numbers in order to see any sort of change here. That's the tricky part.
If you extend copyright: Some number of jobs (thousands, tens of thousands?) saved. IP exports generating US revenue. No real downside other than "What, you extended it again?" and no clear loser.
No wonder they extend it. They have no real case against doing so.
I'm sure it's not in your opinion, but you're sadly oversimplifying or ignoring every use case and ignoring the drivers behind QoS in general. If you want something simplistic and turnkey, there's certainly products out there. Netequalizer springs to mind.
But hey, let's throw in a few simple examples:
HTTP downloads vs. Flash video streamed over HTTP. One is decidedly interactive (even if buffering certainly helps), the other one is decidedly non-interactive (even if faster = neater, naturally).
SIP telephony vs. SIP videoconferencing. Agnosticism per your definition would make the algorithm punish the SIP videocon.
Or, let's take an even simpler example: P2P. Rather than a few very hungry connections, you get a large number of connections pushing less data per connection.
One can always argue that service providers should provide enougb bandwidth so that they won't even have to prioritize data the first place. Nice in theory, hard (or simply uneconomic) in practice. Take a cable provider - with a limited upstream bandwidth per channel, you need some sort of fairness. Simple per-plug fairness works to some extent, but you don't really want to punish the puny amount of upstream data your average HTTP request would generate just because the same user is P2P'ing like there's no tomorrow. Makes for a bad user experience.
When we get to wireless, it gets even messier with the limited and shared upstream and downstream.
I could go on for a whie, but I believe the point has been made. It's not a case of "You simply XYZ" at all.
Yeah, the web went downhill back when they started embedding images in the pages. Who, I mean, who would want to see GRAPHICS in the middle of your CLEAN, SEMANTIC INFORMATION? It doesn't WORK and it's an OUTRAGE!
While I hate to copy it, the server being pummeled and reporting errors for 9/10 requests doesn't lead to ad revenue either, so here goes:
About a year ago, we bought an Intel-based Xserve with a pair of 80 GB SATA drives to act as our primary Web server. When the boot drive went flaky on us in October 2008, we were able to recover from the backup on the second drive and off-site backups, if a little shakily (see "TidBITS Outage Causes Editors Outrage", 2008-10-07). But although we were able to bring the machine back online, we didn't trust the drive that had failed. Since the Xserve has three drive bays, the obvious solution was to purchase another drive. Sounds simple, doesn't it? Not so much.
You cannot buy a bare hard drive and insert it into an Xserve, as you can with a Mac Pro (and having just added a drive to my new Mac Pro, I can say that Apple did a stunningly nice job in making it easy to add drives, especially in comparison to the awful approach they used in the Power Mac G5). Instead, Xserves require Apple Drive Modules, which are custom carriers containing drives.
For users accustomed to buying inexpensive hard drives, Apple's pricing on the Apple Drive Modules comes as a bit of a shock. An 80 GB SATA ADM costs $200 from Apple, and a 1 TB SATA ADM costs $450. In comparison, a bare 80 GB SATA drive can be purchased for a measly $35, and a 1 TB drive is only about $100. That would seem to point toward buying a new SATA drive and swapping it into the bad drive's ADM. However, when I started down that path, a number of problems arose, such that I bailed on a quick solution and simply purchased a new 80 GB SATA ADM to replace the bad one.
First, I wasn't sure whether my Xserve had SATA drives, as I thought, because System Profiler on the Xserve shows nothing on the SATA bus, instead including all drives on the SAS bus. (SAS stands for Serial Attached SCSI, and is a high-performance data transfer technology that supports fast SCSI drives and is downward compatible with SATA drives.) After some discussion with knowledgeable folks on the MacEnterprise list and careful reading of the drive details in the SAS section of System Profiler, it became clear that both SAS and SATA drives are shown in the SAS section, with SATA drives having "ATA" as the Manufacturer, and showing "Yes" in the SATA Device line.
Second, once I knew that I had SATA drives in my ADMs, I started investigating if there were any gotchas involved in replacing the drives. There turned out to be surprisingly little hard information about this, with some people having replaced an ADM's drive with no trouble and others experiencing performance or reliability issues. I did find a few discussions about how replacing drives isn't recommended, but giving no solid sources.
Confused, I contacted Apple to discuss why ADMs are so expensive in comparison to bare drives, exactly what an ADM does, what Apple recommends users do with failing ADMs, and whether or not replacing a drive in one is a good idea. That conversation revealed a great deal of interesting information about the ADM and shed some light on what people with flaky ADM drives should do.
Drive Selection -- The most important fact to know about ADMs is that Apple doesn't use just any drives. We've all benefited from the amazingly low cost of storage. But whenever manufacturers compete on price, they cut corners every way they can to reduce costs. Although drive reliability is generally good, everyone who buys bare drives regularly has a drive vendor they refuse to patronize due to bad experiences in the past. (As is often the case, these people all hate different vendors, depending on which one was having a bad run at any given time.)
Since the Xserve is designed to be in constant use - 24 hours a day, 7 days a week, for years at a time - Apple doesn't use the least expensive drives available, since those drives are designed for more normal duty cycles in desktop computers - 8 to 10 hours per day, with variable use during that time. Instead, Apple wor
The users I support are going to have *huge* problems with the new taskbar. First, they have a problem with grouping tasks into one icon. They never did get the hang of that, so we ended up just unchecking that feature.
Second, the default is to have no text under the icon. They are going to have a hard time figuring out what is already running. They'll end up double clicking everything.
Third, the taskbar no longer appends each new application to the end of the running tasks. That will throw people off.
You do realize that they pretty much replicared the dock from OSX and that people - even fairly computer illiterate such - manage to use that one, right? It sounds more like a familiary issue than anything else.
Call me an elitist, but I don't care much about the hundreds of millions of consumer grade appliances sitting on a home user network somewhere. If you use them for something important and they can't even swallow a decent SSL cert for the web frontend - well sorry, but you bought the wrong device. It's definitely not worth diluting PKI over that. I'll be the first one to agree that PKI is not perfect, but it'll be closer to worthless every time JoeUser learns just to click warnings away.
Are there similar organizations with reasonable security though? CAcert certainly hasn't and including them in Mozilla would be particularly bad due to this. Other free alternatives would be nice, but lacking that, $15 for a year for a cert isn't beyond the reach or any non-profit.
In a way true, but you'd be stuck with one of two scenarios really: Quick and expensive (nice last-mile solution) or Not-so-quick and inexpensive (cheap last-mile solution). Or quick-and-exposed-to-competition-hopefully-meaning-inexpensive (municipality owned access network w. nice last-mile solution), but they seem to get sued left and right for some reason, which is a pity.
I'd hand out a complimentary tinfoil hat if I had one.
IPv6 is on the radar and requested as a must-have, but normally only on a roadmap level ("Will your product support this some time in the future?"). In some parts of the world (there's more to it than the US), any device incapable of IPv6 won't get onto the network in the first place.
If you stop to think about the practical implications for a while, it's very unlikely that encryption will be that much more widespread than it is today (it's a processing power issue as well, not just one of protocol ease of implementation) while the whole NAT issue will be zapped. This means that DPI gear all of a sudden can pick out a whole lot more, since traffic that'd normally be aggregated by a NAT - won't be. Insta-higher-resolution.
Yes, there's DPI devices for traffic shaping (or throttling or management or whatever term you prefer), and there's DPI devices for ad insertion but those really wouldn't be the same devices, probably not even made by the same vendor. Plugging my own blog, here's a shortentry about this.
As for the article, I think - but I could well be called biased - that the unnamed sources may be overreacting a bit. Could you do the things described with a decent traffic shaping DPI enabled box? Sure. Do ISP's do this? With the exception of some high profile cases we're all aware about, not that I noticed. As it happens, I wrote about this as well fairly recently (the text is quite long, if you want only the relevant bits on DPI uses, scroll down to 'DPI uses' near the bottom)
(In all honesty, I could well see the point of very restricted and extremely cheap access though. The net is a resource you pretty much need access to in order to function well in society nowadays. If that's all you need it for, it might make a lot more sense to get a $10/mo line restricted to only web and mail than a $30-or-more/mo line unrestricted. I sure as heck wouldn't get a restricted one myself, but then again, I'm not really the target audience of that idea)
As for an american rollout, quite a few ISP's run the gear in the US already. Again, with a few (very notable) exceptions, you don't really notice it. Which is kind of the point of a good implementation, in my book.
Affecting the quality? Obviously not, but I won't stop you for being silly to try to make a point.
I'm seeing a release blurb which looks more like an abbreviated commercial press release - including the mandatory "we're the market leader" claim - for a pretty uninteresting update. While this sort of stuff weasels its way into slashdot every now and then, the whacked out of reality claims definitely raises the bullshit-o-meter alarm.
Allow me to demonstrate using the "Almost every modern uses somewhere" template:
"Almost every modern streaming video server uses Windows Media Technologies somewhere" "Almost every modern web server uses PHP somewhere" "Almost every modern web design firm uses Dreamweaver somewhere"
Do these claims affect the quality of whatever technology they're trying to push? No. Are the statements obviously overreaching? Yes. Does the fact that the recommendation (assuming they're attached to one in the first place) both push a product/tech and try to convince me that "it Must be Good since So Many Others use it (especially if they're 'modern')" make me less inclined to buy into the pitch? Oh yes.
"Almost every modern C++ codebase uses Boost somewhere"? While I think it looks like a pretty useful set of libraries, I must admit that statements like this makes me less inclined to even look at it.
OFF is an interesting concept. At the same time, it feels like their legal reasoning is braindead and their underlying transport is.. shall we say less efficient than it could be. Would be extremely surprised to see it gain traction in any meaningful manner.
I think you're seeing the effect of something else than your ISP killing connections here - there really is no use case what so ever for an ISP to block WoW, and there really isn't any (normal) congestion alleviation algorithm that kills connections. Drop packets? Yes. But that's not the same thing as sending RSTs..
WoW is a pretty light game on resources as well. 1000 simultaneous connections incur a negligible impact on any ISP large enough to have 1000 simultaneous WoW users (say a userbase of 100k total, ballpark numbers)
Oh, it's a tool - could definitely be used for good - or evil (and as a bonus, one mans good is another mans evil). Could you block P2P outright? Pretty much, yes. Would it make sense? Not really, for several reasons (See the collective public happiness about Comcast and BitTorrent blocking for one)
Could you rather use it to allow a decent amount of P2P (keep in mind that you could shape/limit, it rather than outright block it) while keeping the net snappy for the non-filesharers as well? Sure, definitely possible.
It boils down to tools. If you *only* can block stuff, that's a blunt instrument. If you can shape as well, I'd be hard pressed to think of a scenario where blocking would be preferable to an ISP, worms and Windows Messenger Service (Not MSN, rather the popup crud in windows) excluded.
Say you got a pipe of 1Gbps and limit P2P and bulk transfers to 700 Mbps of that, you still allow a lot while keeping interactive stuff.. well, interactive.
Actually, the whole idea of DPI is *not* to detect things based on port. There's definitely legitimate uses for encrypted traffic - heck, even encrypted P2P, but it'd be a bit premature to say that you can't separate protocols from each other even if they're encrypted.
It's a bit beside the point though. A sane approach to DPI is just to give some traffic a lower priority than other traffic. If the pipe goes full, you don't want to RED drop some WoW traffic (unhappy user) over some BT traffic (decidedly non-interactive). You might also want to keep web browsing at a better priority than bulk HTTP transfers and P2P, whatnot.
Slashdot Mirror
Yes, the buggers hop onto their three ships, land in the caribbean, start enslaving the locals and don't even bother with their paperwork. Hate it when that happens..
You sir, just earned a tinfoil hat. While I have no particular love for Bluecoat (they're competitors in another field), you're assuming things based on what you think to be the case. Claiming that others are misinformed simply because it doesn't fit your mental image is rather silly.
There's only so and so much time in a workday. Spending it on going over phone-home in detail and sending across sensitive information in the first place? Not so useful.
(We also do phone home. Aggregates only, nothing sensitive. It usually makes very little sense to go fucking with your customers or risking their sensitive data, so there's no reason to send anything else.)
Actually, no.
If you use different compression algorithms, sure, it'd yield a different result. But if you rip a CD with default settings in whatever music manager - say iTunes, for posterity - you'd end up with the same file hash as the next guy that did the same thing with the same software. Digital data, et al.
This is actually not the case with dedicated solutions for this sort of thing (yes, they exist. No, they're not cheap), commonly used for annual general meetings by large corporate entities. A normal wireless network will hold up rather nicely as long as a) the AP's cope with the # of connected clients and b) whatever service you're pushing data to isn't too chatty.
It depends entirely on how many polls you need to perform in what time span. The way we do it (non-profit NGO) is by a simple web form - there's a number of terminals available for people who doesn't bring their own laptop/phone, and those who do bring their own, can use it. Performing a poll with 100 people takes ~2 minutes - but it'd depend on the number of people with their own equipment and the number of terminals at hand, naturally.
Avoid doing it by hand, if at all possible. Counting sucks and people are way, way more focused if they can get the outcome almost right away rather than after n minutes.
Damn, good sir. You beat me to posting that very sentiment. Utterly pointless book review.
Think bigger. The US has a net export of culture (if I may call it that for the sake of the argument) - Disney is one rather marked example, but say Hollywood in general and ignore all other sources of culture for the time being. There's still a metric fuckwad of products out there in the world with Mickey and Donald images on them. Some are even produced by outfits in places where you actually pay royalties. Disney series - even old ones from the 80's - are broadcast in quite a few countries, also generating royalties. There's still an interest in the older Disney characters (yes, the more recent shows obviously wouldn't be free-for-all even if the characters went free-for-all, but nothing would stop other firms from making their own shows with the same characters)
This translates into a steady stream of revenue coming into the country from the rest of the world. Mickey & Donald. Batman. Superman. Hell, even Popeye. Money translates, sooner or later, into jobs. Either directly in the corporate entity that owns the IP, or by the spending of said money. All this is somewhat tangible. The benefits of not extending copyright aren't.
You (I'm not a resident of the US myself) need to provide some good, solid arguments backed up by good, solid numbers in order to see any sort of change here. That's the tricky part.
If you extend copyright: Some number of jobs (thousands, tens of thousands?) saved. IP exports generating US revenue. No real downside other than "What, you extended it again?" and no clear loser.
No wonder they extend it. They have no real case against doing so.
I'm sure it's not in your opinion, but you're sadly oversimplifying or ignoring every use case and ignoring the drivers behind QoS in general. If you want something simplistic and turnkey, there's certainly products out there. Netequalizer springs to mind.
But hey, let's throw in a few simple examples:
HTTP downloads vs. Flash video streamed over HTTP. One is decidedly interactive (even if buffering certainly helps), the other one is decidedly non-interactive (even if faster = neater, naturally).
SIP telephony vs. SIP videoconferencing. Agnosticism per your definition would make the algorithm punish the SIP videocon.
Or, let's take an even simpler example: P2P. Rather than a few very hungry connections, you get a large number of connections pushing less data per connection.
One can always argue that service providers should provide enougb bandwidth so that they won't even have to prioritize data the first place. Nice in theory, hard (or simply uneconomic) in practice. Take a cable provider - with a limited upstream bandwidth per channel, you need some sort of fairness. Simple per-plug fairness works to some extent, but you don't really want to punish the puny amount of upstream data your average HTTP request would generate just because the same user is P2P'ing like there's no tomorrow. Makes for a bad user experience.
When we get to wireless, it gets even messier with the limited and shared upstream and downstream.
I could go on for a whie, but I believe the point has been made. It's not a case of "You simply XYZ" at all.
Yeah, the web went downhill back when they started embedding images in the pages. Who, I mean, who would want to see GRAPHICS in the middle of your CLEAN, SEMANTIC INFORMATION? It doesn't WORK and it's an OUTRAGE!
While I hate to copy it, the server being pummeled and reporting errors for 9/10 requests doesn't lead to ad revenue either, so here goes:
About a year ago, we bought an Intel-based Xserve with a pair of 80 GB SATA drives to act as our primary Web server. When the boot drive went flaky on us in October 2008, we were able to recover from the backup on the second drive and off-site backups, if a little shakily (see "TidBITS Outage Causes Editors Outrage", 2008-10-07). But although we were able to bring the machine back online, we didn't trust the drive that had failed. Since the Xserve has three drive bays, the obvious solution was to purchase another drive. Sounds simple, doesn't it? Not so much.
You cannot buy a bare hard drive and insert it into an Xserve, as you can with a Mac Pro (and having just added a drive to my new Mac Pro, I can say that Apple did a stunningly nice job in making it easy to add drives, especially in comparison to the awful approach they used in the Power Mac G5). Instead, Xserves require Apple Drive Modules, which are custom carriers containing drives.
For users accustomed to buying inexpensive hard drives, Apple's pricing on the Apple Drive Modules comes as a bit of a shock. An 80 GB SATA ADM costs $200 from Apple, and a 1 TB SATA ADM costs $450. In comparison, a bare 80 GB SATA drive can be purchased for a measly $35, and a 1 TB drive is only about $100. That would seem to point toward buying a new SATA drive and swapping it into the bad drive's ADM. However, when I started down that path, a number of problems arose, such that I bailed on a quick solution and simply purchased a new 80 GB SATA ADM to replace the bad one.
First, I wasn't sure whether my Xserve had SATA drives, as I thought, because System Profiler on the Xserve shows nothing on the SATA bus, instead including all drives on the SAS bus. (SAS stands for Serial Attached SCSI, and is a high-performance data transfer technology that supports fast SCSI drives and is downward compatible with SATA drives.) After some discussion with knowledgeable folks on the MacEnterprise list and careful reading of the drive details in the SAS section of System Profiler, it became clear that both SAS and SATA drives are shown in the SAS section, with SATA drives having "ATA" as the Manufacturer, and showing "Yes" in the SATA Device line.
Second, once I knew that I had SATA drives in my ADMs, I started investigating if there were any gotchas involved in replacing the drives. There turned out to be surprisingly little hard information about this, with some people having replaced an ADM's drive with no trouble and others experiencing performance or reliability issues. I did find a few discussions about how replacing drives isn't recommended, but giving no solid sources.
Confused, I contacted Apple to discuss why ADMs are so expensive in comparison to bare drives, exactly what an ADM does, what Apple recommends users do with failing ADMs, and whether or not replacing a drive in one is a good idea. That conversation revealed a great deal of interesting information about the ADM and shed some light on what people with flaky ADM drives should do.
Drive Selection -- The most important fact to know about ADMs is that Apple doesn't use just any drives. We've all benefited from the amazingly low cost of storage. But whenever manufacturers compete on price, they cut corners every way they can to reduce costs. Although drive reliability is generally good, everyone who buys bare drives regularly has a drive vendor they refuse to patronize due to bad experiences in the past. (As is often the case, these people all hate different vendors, depending on which one was having a bad run at any given time.)
Since the Xserve is designed to be in constant use - 24 hours a day, 7 days a week, for years at a time - Apple doesn't use the least expensive drives available, since those drives are designed for more normal duty cycles in desktop computers - 8 to 10 hours per day, with variable use during that time. Instead, Apple wor
The users I support are going to have *huge* problems with the new taskbar. First, they have a problem with grouping tasks into one icon. They never did get the hang of that, so we ended up just unchecking that feature.
Second, the default is to have no text under the icon. They are going to have a hard time figuring out what is already running. They'll end up double clicking everything.
Third, the taskbar no longer appends each new application to the end of the running tasks. That will throw people off.
You do realize that they pretty much replicared the dock from OSX and that people - even fairly computer illiterate such - manage to use that one, right? It sounds more like a familiary issue than anything else.
OpenNet, by a very quick look on google, seem to be their network name for the non-classified bits and pieces. Supposedly Microsoft + Cisco stuff.
Feel free to disagree, but please provide a URL reference to the OpenNet email server software vendor if doing so.. ;-)
Call me an elitist, but I don't care much about the hundreds of millions of consumer grade appliances sitting on a home user network somewhere. If you use them for something important and they can't even swallow a decent SSL cert for the web frontend - well sorry, but you bought the wrong device. It's definitely not worth diluting PKI over that. I'll be the first one to agree that PKI is not perfect, but it'll be closer to worthless every time JoeUser learns just to click warnings away.
The FF3 warnings are a good thing.
Are there similar organizations with reasonable security though? CAcert certainly hasn't and including them in Mozilla would be particularly bad due to this. Other free alternatives would be nice, but lacking that, $15 for a year for a cert isn't beyond the reach or any non-profit.
Whitespace.
In a way true, but you'd be stuck with one of two scenarios really: Quick and expensive (nice last-mile solution) or Not-so-quick and inexpensive (cheap last-mile solution). Or quick-and-exposed-to-competition-hopefully-meaning-inexpensive (municipality owned access network w. nice last-mile solution), but they seem to get sued left and right for some reason, which is a pity.
I'd hand out a complimentary tinfoil hat if I had one.
IPv6 is on the radar and requested as a must-have, but normally only on a roadmap level ("Will your product support this some time in the future?"). In some parts of the world (there's more to it than the US), any device incapable of IPv6 won't get onto the network in the first place.
If you stop to think about the practical implications for a while, it's very unlikely that encryption will be that much more widespread than it is today (it's a processing power issue as well, not just one of protocol ease of implementation) while the whole NAT issue will be zapped. This means that DPI gear all of a sudden can pick out a whole lot more, since traffic that'd normally be aggregated by a NAT - won't be. Insta-higher-resolution.
There's no conspiracy here. Really.
Yes, there's DPI devices for traffic shaping (or throttling or management or whatever term you prefer), and there's DPI devices for ad insertion but those really wouldn't be the same devices, probably not even made by the same vendor. Plugging my own blog, here's a shortentry about this.
As for the article, I think - but I could well be called biased - that the unnamed sources may be overreacting a bit. Could you do the things described with a decent traffic shaping DPI enabled box? Sure. Do ISP's do this? With the exception of some high profile cases we're all aware about, not that I noticed. As it happens, I wrote about this as well fairly recently (the text is quite long, if you want only the relevant bits on DPI uses, scroll down to 'DPI uses' near the bottom)
(In all honesty, I could well see the point of very restricted and extremely cheap access though. The net is a resource you pretty much need access to in order to function well in society nowadays. If that's all you need it for, it might make a lot more sense to get a $10/mo line restricted to only web and mail than a $30-or-more/mo line unrestricted. I sure as heck wouldn't get a restricted one myself, but then again, I'm not really the target audience of that idea)
As for an american rollout, quite a few ISP's run the gear in the US already. Again, with a few (very notable) exceptions, you don't really notice it. Which is kind of the point of a good implementation, in my book.
Affecting the quality? Obviously not, but I won't stop you for being silly to try to make a point.
I'm seeing a release blurb which looks more like an abbreviated commercial press release - including the mandatory "we're the market leader" claim - for a pretty uninteresting update. While this sort of stuff weasels its way into slashdot every now and then, the whacked out of reality claims definitely raises the bullshit-o-meter alarm.
Allow me to demonstrate using the "Almost every modern uses somewhere" template:
"Almost every modern streaming video server uses Windows Media Technologies somewhere"
"Almost every modern web server uses PHP somewhere"
"Almost every modern web design firm uses Dreamweaver somewhere"
Do these claims affect the quality of whatever technology they're trying to push? No. Are the statements obviously overreaching? Yes. Does the fact that the recommendation (assuming they're attached to one in the first place) both push a product/tech and try to convince me that "it Must be Good since So Many Others use it (especially if they're 'modern')" make me less inclined to buy into the pitch? Oh yes.
YMMV, of course.
"Almost every modern C++ codebase uses Boost somewhere"? While I think it looks like a pretty useful set of libraries, I must admit that statements like this makes me less inclined to even look at it.
OFF is an interesting concept. At the same time, it feels like their legal reasoning is braindead and their underlying transport is.. shall we say less efficient than it could be. Would be extremely surprised to see it gain traction in any meaningful manner.
I think you're seeing the effect of something else than your ISP killing connections here - there really is no use case what so ever for an ISP to block WoW, and there really isn't any (normal) congestion alleviation algorithm that kills connections. Drop packets? Yes. But that's not the same thing as sending RSTs..
WoW is a pretty light game on resources as well. 1000 simultaneous connections incur a negligible impact on any ISP large enough to have 1000 simultaneous WoW users (say a userbase of 100k total, ballpark numbers)
Oh, it's a tool - could definitely be used for good - or evil (and as a bonus, one mans good is another mans evil). Could you block P2P outright? Pretty much, yes. Would it make sense? Not really, for several reasons (See the collective public happiness about Comcast and BitTorrent blocking for one)
Could you rather use it to allow a decent amount of P2P (keep in mind that you could shape/limit, it rather than outright block it) while keeping the net snappy for the non-filesharers as well? Sure, definitely possible.
It boils down to tools. If you *only* can block stuff, that's a blunt instrument. If you can shape as well, I'd be hard pressed to think of a scenario where blocking would be preferable to an ISP, worms and Windows Messenger Service (Not MSN, rather the popup crud in windows) excluded.
Say you got a pipe of 1Gbps and limit P2P and bulk transfers to 700 Mbps of that, you still allow a lot while keeping interactive stuff.. well, interactive.
Actually, the whole idea of DPI is *not* to detect things based on port. There's definitely legitimate uses for encrypted traffic - heck, even encrypted P2P, but it'd be a bit premature to say that you can't separate protocols from each other even if they're encrypted.
It's a bit beside the point though. A sane approach to DPI is just to give some traffic a lower priority than other traffic. If the pipe goes full, you don't want to RED drop some WoW traffic (unhappy user) over some BT traffic (decidedly non-interactive). You might also want to keep web browsing at a better priority than bulk HTTP transfers and P2P, whatnot.