3
The congestion control algorithm(s) of TCP seem to distribute the available bandwidth fairly between individual TCP flows.
Is there some way to enable (or more precisely, enforce) fair bandwidth sharing on a per-host instead of a per-flow basis on a router? There should not be an (easy) way for a user to gain a disproportional bandwidth share by using multiple concurrent TCP flows (the way some download managers and most P2P clients do).
I'm currently running a DD-WRT router to share a residential DSL line, and currently it's possible to (inadvertently or maliciously) hog most of the bandwidth by using multiple concurrent connections, which affecty VoIP conversations badly. I've played with the QoS settings a bit, but I'm not sure how to enable fair bandwidth sharing on a per-IP basis (per-service is not an option, as most of the flows are HTTP).
Update: I'm assuming TCP or TCP-like congestion control behavior of all flows, as otherwise there would really be no way of controlling inbound traffic.
Currently, congestion control is per-flow, and a single user with multiple flows will cause each user's flows to throttle back, and they will eventually stabilize at 1/n times the total bandwidth for n flows.
Now isn't it possible to modify the inbound queue and packet dropping algorithm in such a way that there is an inbound "packet counter" per user, and packets are dropped per user instead of randomly? That way, if only some users are actually causing the congestion, only their flows will have to throttle back, instead of everybody's flows.
lxgr
Posted 2012-04-03T23:06:16.113
Reputation: 1 041
1It basically won't work. You're trying to control what packets your ISP puts on the wire to you. Once you get a packet, it's already too late -- it's consumed your bandwidth irrevocably. – David Schwartz – 2012-04-04T00:19:45.783
But I can always drop that packet, thereby forcing TCP to throttle back, right? I'm hoping that the offending flows are TCP or TCP-like regarding their congestion control. – lxgr – 2012-04-04T00:32:55.937
1You can, but it's horribly inefficient because you just forced the data to be sent again. You wind up getting deeper queues on the ISP side, and the feedback gets slower. And, of course, that only works on flows that throttle back. (QoS won't help unless your ISP honors it or it's your local WiFi/LAN that's overloaded.) – David Schwartz – 2012-04-04T00:39:02.357
1But isn't that how TCP itself handles congestion control? Packets are dropped, and the sender throttles back. I just want the packets to be dropped "fairly", i.e. if one user consumes more than his fair share, only (or primarily) his packets will be dropped, and only his flows will have to throttle back. Of course that would imply metering each user's current packet rate, and dropping accordingly. Is that possible? – lxgr – 2012-04-05T16:56:10.363
1Yes, but the packets aren't dropped right after they traverse the expensive link that you care about. They're dropped before they traverse it. The point is to drop a packet to avoid incurring an expense, not to drop a packet despite having already "paid" for it. – David Schwartz – 2012-04-05T20:23:48.077