The article is a little light on technical facts. The previous Bittorrent protocol used TCPs congestion control. Any reason to believe that their UDP+µTP replacement will outperform it?
A magic number like 100 ms seems like a bad idea. Also, it's not clear to me what happens when minimum path latency is > 100 ms. Based on my superficial understanding, the uTP rate would go to (nearly) zero.
It's very unlikely. I've seen a bit of the research in this area and all this stuff has been tried before with marginal success. Van Jacobson did a pretty good job.
I like the way they are spinning this. The new protocol, over UDP, is more difficult for ISPs to throttle without harming everything else on UDP (VoIP, games, streaming video, etc) that people regularly use (AFAIK.)
That being said, they really did create the new protocol to have more elegant throttling. Morris: "It’s not QoS, but rather a congestion management mechanism implemented at the end-user’s layer 7 [Application]. This will stop uTP from eating up traffic bandwidth reserved for latency sensitive apps like VoIP and gaming. What’s more, the congestion management mechanism isn’t something we implemented as an afterthought – it’s the whole point of uTP." from http://torrentfreak.com/utorrent-2-0-to-elimininate-the-need...
Looking forward to it, even though Comcast doesn't seem throttle my BitTorrent traffic at my location (North Bay area.)
Is that really feasible for ISPs? I know you can traffic shape anything, but would they bother? I remember there was a pretty big ruckus when this was first announced, since many of the uT guys were talking about how it would be much harder to throttle.
Over here, all the major ISPs do DPI to throttle torrents and about 6 months back the only way to not be throttled was to go with a smaller DSL ISP that leased lines from Bell. Then, one day, Bell turned around and started doing DPI on wholesale client lines and throttling their torrent traffic too. Some people raised a stink about it and it got to the CRTC for a decision and, in typical CRTC fashion, they issued a non-decision that essentially said DPI should only be used when necessary. Nothing changed. It's now impossible* to get an internet line that doesn't throttle torrents in most of Canada.
* Not impossible to run torrents without being throttled though, you just have to set Azureus to its "RC5 encryption" settings and Bell won't be able to analyze your packets though this will break any private trackers that don't use https (most do).
Can an ISP fake a network congestion that uTorrent detects and automatically slows itself? That would be the next logical evolutionary step for people hell-bent on stopping filesharing. That's ISPs, RIAA, etc...
ISP's don't have any vested interest in stopping filesharing. In fact I'm sure many of them would love to have it since its a great reason to use their service.
The ideal customer is someone who pays for a fast connection, and then uses it to check their email once a week.
Lower bandwidth usage leads to more profit for the ISP, since they can get away with overselling their infrastructure. Thus, ISPs do have a vested interest - especially considering that many of them oversell their infrastructure. And if this leads to more people using torrents (because they won't be noticing as many issues, and this will lead to usage getting closer and closer to network capacity), it will cut into profits, and potentially require investments in new infrastructure.
Yep, it shouldn't be too difficult to delay uTP traffic and convince it to slow itself down. It's unlikely that ISPs would do that since getting caught would cause another neutrality smackdown from the FCC.
Edit: found the draft RFC: http://www.bittorrent.org/beps/bep_0029.html. Looks like the congestion control is window- and latency-based.
| "The window size in the socket structure specifies the number of bytes we may have in flight (not acked) in total, on the connection."
| "Each socket aims to never see more than 100 ms delay on the send link. If it does, it will throttle back."