[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?