[newscracker]

> From a networking perspective most Internet providers are generally not very happy with BitTorrent users.

> These users place a heavy load on the network and can reduce the performance experienced by other subscribers. In addition, the huge amount of data transferred outside the ISPs’ own networks is also very costly.

This could be re-stated with "BitTorrent" replaced with "video" and would still have the same meaning. It seems like ISPs are just acting like insurance companies and depend on the average use being low. It's as if they want to give the users less than what the users pay for instead of improving their networks. I get that managing load, utilization (and maximum demand) over time is not easy, but I doubt if the ISPs have a good enough capacity in the first place considering that many users do consume a lot of video content (which requires higher bandwidth and uses more of the capacity).

[drdaeman]

There were issues specific to BitTorrent. In particular, early uTP versions caused a lot of grief, as they had broken congestion control, which led to absurdly high PPS. Also, it hadn't worked well on congested WiFi hotspots. We had to drop UDP traffic having certain signatures, just to keep the network alive. This was a single one-time incident, though, not a general issue.

Either way, P2P traffic, compared to the unicast one, is also a bit harder for hardware to handle, as there are more connections with different peers. Not an excuse or anything - good ISPs are meant to deal with whatever kind of traffic their customers want to generate (unless it's broken/misbehaving or malware-infested systems), just saying that the load is of a slightly different kind.

-----

Actually, some ISPs I've heard about were setting up BitTorrent caches. They had set up `retracker.local` systems that some fairly large public trackers had supported, grabbed stats to see what's hot, and spawned seedboxes (serving internal customers only) for the frequently downloaded content. Legal waiver was this was fully automated, and working exactly like any other caching proxy, blah blah - given it was in Russia, no one cared anyway. This was quite nice optimization, that allowed to cut outside traffic, IIRC, up to 2-3 times while actually improving customers' experience.

[SmellTheGlove]

Insurance companies don't depend on usage being low, they depend on usage being in line with the actuarial/underwriting models. I've spent my career in insurance (P&C and disability), heavily on the data side, and haven't yet seen an underwriting profit in the plans. It's nice when it happens, but investment income on float is the bread and butter.

Why am I telling you this seemingly irrelevant info? Just to conclude that ISPs behave worse than insurance companies :)

EDIT: It'd actually be pretty interesting to see ISP rates regulated the same way ours (insurance) are. I'm talking about regulatory pressure to take rate when operating margins are high, like we get when underwriting profits become regular, and also on the severability of the product rate - regulators don't care if I'm taking a bath on homeowners and making up for it on the auto coverage. It'd be nice for similar on the ISP side with rates somewhat tied to cost, and not subsidizing losses on the cable subscriber side when that end eventually implodes.

[runeks]

I believe the issue is with the distribution of bandwidth between many TCP connections. The problem is that each TCP connection is treated with equal priority, meaning that a web page loading through a single TCP connection competes on equal footing with each of your 100 BitTorrent TCP connections, all running at a relatively low speed per connection. If this activity saturates your Internet connection, and you then try to load a web page, the web page TCP connection attempt will be placed in the back of the large queue that has accumulated in your router, and will take 20 seconds to load.

I also believe the asynchronous configuration, eg. 10/2 mbit rather than 5/5 mbit, of most residential Internet connections exacerbates the problem. One thing would be getting a connection attempt out on a 5/5 mbit connection, but you're constantly sending out huge amounts of ACKs of very small TCP packets already (due to BitTorrent), and your outgoing bandwidth is much smaller than your incoming.

[throwaway7767]

It's really curious, because even when ISPs have QoS setups they can't seem to guarantee fairness. It's always per-connection instead of per-customer-IP.

My ISP for example seems to classify traffic and prioritise based that (HTTP(s) ports get more bandwidth than others up to the first couple of MB, BitTorrent goes in a low-priority group, etc). Yet I can still eat up all the bandwidth I want by just using multiple connections.

I would think it would be even easier to do this on the customer-IP level? Average over some time span, and customers who haven't used their fair allotment of the bandwidth for that time period get priority over others, and the guy with 2000 bittorrent connections has the same claim to the bandwidth as grandma loading her online banking in the browser through one TCP stream.

Are there some issues I'm missing that make this harder than it seems?