UTorrent 2.0 To Elimininate The Need For ISP Throttling | Hacker News Reader

UTorrent 2.0 To Elimininate The Need For ISP Throttling

torrentfreak.com

32 pointsrms17 comments

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?

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

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.

The point of uTP is not to outperform TCP but to underperform it, using the network's idle bandwidth but not competing with regular TCP.

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.

uTP spec: http://www.bittorrent.org/beps/bep_0029.html

Previous uTP discussion: http://news.ycombinator.com/item?id=877510

A more general proposal for controlling Internet congestion: http://tools.ietf.org/html/draft-moncaster-congestion-exposu...

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.)

Who's spinning it that way? I didn't see that in the article. Also, DPI or traffic analysis can easily distinguish different UDP-based protocols.

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.

ISPs can detect BitTorrent traffic today and I don't see why uTP would be any harder to detect than the classic BitTorrent protocol.

Obviously you don't live in Canada.

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

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.

ISPs can, but they can already traffic shape, so that isn't really a weakness. Malicious clients can't because the throttling is done per-socket.

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.

If this works out as planned and ISPs trust it enough to ease up on the throttling, seems like everybody will win.

They won't. All this does is remove a convenient excuse they have to throttle the bandwidth.

Reply on news.ycombinator.com