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.'"

Comments

Re:I was wondering about this

[Adradis]

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.

Tell me...

[WiglyWorm]

How does one abuse an "unlimited" internet plan?

Based on my personal experience, possibly

[istartedi]

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.