Slashdot Mirror
Is Streaming Video the Real Throttling Target?
snydeq writes "Responding to legal pressure over its throttling of P2P traffic and other dubious practices, Comcast says it will now punish the most abusive users rather than particular applications. Yet its pilot tests in Pennsylvania and Virgina, which would 'delay traffic for the heaviest users of Internet data without targeting specific software applications,' raise greater concerns over net neutrality, ones that belie a potential preemptive strike against the cable company's chief future competition: streaming video. 'Despite the industry's constant invocation of the P2P bogeyman, at present, the largest bandwidth hog is actually streaming video,' writes Mehan Jayasuriya at Public Knowledge. 'Clearly, the emergence of online video is something that cable video providers find very threatening and by capping off bandwidth usage, they're effectively killing two birds with one stone; discouraging users from using their Internet connections for video while increasing the efficiency of the network. Is this anti-competitive? It sure seems like it.'"
Last I checked, Verizon wasn't doing this to their customers. Guess they're becoming the better communications company on multiple fronts now, huh?
I'm noticing something similar with Youtube and such. It's downloading streaming video a hell of a lot slower, and I keep having to wait for another chunk to download.
Set the "baseline" price for video-on-demand = to your per-bit price for internet.
If the video is ad-supported, the price goes down.
If it's a blockbuster video, the price goes up.
Either way, the cable company gets the same $carraige_fee for every 1-hour video, whether it's from the end user or a sponsor. If the cable company has to pay a studio something, then that cost is passed on to end users.
So, instead of videos being "free" because the cable co. doesn't have to pay a vendor, they'll be $1 or something unless the vendor steps in and subsidizes them.
Normal-pay videos will go up in price by $1 or whatever per hour, unless the vendor is willing to lower his take.
Now, by "vendor" may mean the non-transport arm of the very company that owns the wires. You'll need some Chinese-walls between the two arms of the company to make this work effectively.
The bottom line is that within a given quality-of-service and time of day, a bit is a bit is a bit, and the "carraige fee" portion of the customer's bill should be the same whether it's from streaming video or video-on-demand.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
How does one abuse an "unlimited" internet plan?
I don't know about the rest of the world, but here in Canada most people have to pay more for their insurance because they use their cars to go to work.
Which is why the analogy is deeply flawed. Owning a car is not like hiring an ISP. You pay the ISP some money and they have to cover all the costs. The contract is short term. Any equipment is often consumable. It is not like owning a car, where you buy the car and can do anything you want with it because you own it. It is yours, you are keeping it, and the dealer could care less.
A more reasonable analogy is leasing a car. In this case you are paying for the use of the car for a specified time period, just like most ISP contracts, and, just like a lease, the ISPs are being forced to impose limits on the heavy users to be fair for everyone. Most lease agreements limit your use to 15000 miles. You can buy more up front, or pay for overages at the end. There are often other restrictions, But again, you are responsible for the car, so even this is not a good comparison.
Likely the best comparison is renting a car. The agency covers all maintenance, you just pay for the gas. In this cae, the agency is very interested in what you do with car, even putting tracking devices that record speed, distance, and location. It seems to me that, due to the fact that there is little physical product involve. the most reasonable case is somewhere between a lease and rental. But the idea is this, as people begin to use bandwidth, either all of us will pay equally to cover the high end users, much like what happens now with the subsidies of big cars, or those that want more will pay for it themselves.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
It seems like YouTube is getting throttled a lot lately. To be fair though, I haven't checked for the deadly RST packet. Shouldn't be too hard. I just need to set Wireshark to filter everything but RST packets. Of course, that won't really let me know that it was Comcast that sent it. I'd say that a RST followed by the next packet in the expected sequence would be a giveaway, since the TCB at YouTube's server wouldn't send the next packet in sequence if it had sent the RST. Of course, if what Comcast is using to do this is stateful and smart, it'll block that next packet too. So. There is no way to tell, barring YouTube actually logging instances of having sent the RST itself, and letting us access that log. Feel free to point out any flaws in this analysis. I just typed it out in 5 minutes.
The bottom line though, is that YouTube is choppy lately.
It'd be nice if Adobe fixed flash so that it would double the buffering time whenever it got stuck. In other words, if it waits 5 seconds to buffer and then gets stuck again, it should wait 10 seconds the next time before trying to resume the stream. If it gets stuck again, it should wait 20 seconds. And so on, until, if necessary, it buffers the entire vid before playing.
Of course Adobe is not the underlying problem; but they could be more robust given the current environment.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
So unless you are one of the lucky bastards with FIOS or have the cash for a T3 you can pretty much kiss the Internet they way you know it goodbye if they all go tiered. That is the problem with monopolies-they know you ain't got nowhere else to go. IMHO it will also kill off most FOSS,since everyone will be afraid to download distros or OO.o for fear of going over their cap. I predict that corps like MSFT will then jump in with ultra cheap crippled "basic editions" of programs like Office that you'll be able to get at the Wally World and thus not waste what little bandwidth you have. After all how many are going to take the chance and try something like a new 4.3Gb Linux distro DVD when they only have 20-35Gb to last them the whole month? But that is my 02c based on personal exp,YMMV (at least my cable co. is spending the cash trying to upgrade their services,unlike what I've seen from the others in my state)
ACs don't waste your time replying, your posts are never seen by me.
I use both Comcast and Cox (home/work), and all streaming video has become very choppy. But when I use an ssh tunnel to a proxy outside either network, it runs just fine. I'm sure there's an innocent explanation...
I saw this response and decided to wireshark Comcast on my 8MB/3MB connection. I was shocked at the results... On a 2GB rsync upload to a webserver, I saw 4 distinct bandwidth steps switching from:
3MBps
2MBps
1.5MBps
1.2MBps
at each transition, a very clear increase in the number of duplicate TCP ACKs appeared. When the transmission started, there were zero duplicate ACKs for 75 seconds. Then about half of the returning packets became duplicates. On and on....
This is absolutely Comcast injecting these and it doesn't seem to matter what protocol you use (P2P, rsync, etc..). I'd suspect any large data transfer will result in the same behavior (Probably in either direction).
It sucks as I pay extra for the extra bandwidth. Fortunately, I don't pay too much extra and the bandwidth is always at least 4 times better uploading than I used to have. It still sucks...
Well I guess I deserve that response for feeding a troll, but when you grow up maybe you'll see the real problem here : that the big telecoms are holding back our nation's technological progress just to satisfy the greed of thier shareholders.
Caveat Utilitor