He, he… TUUS, for the values you indicated in your post, there definitely shouldn’t be any problem for the user to browse even by leaving the settings on default.
What I mean is that in the earlier days (3-4 years ago), when the average “high speed” Internet connection was 1-4Mb/s, well the difference between the “left” 20% of upload bandwidth between a 512Kb line and a 2-4MB line wasn’t that much as they all had around 128-512kb/s upload speed.
But nowadays, there are way faster connections out there, and the simple 20% formula is starting to be quite inaccurate.
Sure, it will still keep you on the safe side, but let’s face it, even for my 25/3.5Mb/s connection which is not “top of the class” these days, 20% of the upload bandwidth will mean 700kb/s upload bandwidth available for the rest of applications, which is enough for 20 simultaneous browsers to send their requests and still run another BitTorrent client along with them.
My point is that the higher you go on download/upload speed plans the higher the available bandwidth provided by the 20% will be, in a logarithmic-like, not in a linear fashion.
So while this will address part of the issue for the users which have slower connections these days it won’t have any noticeable impact for those with faster ones.
Nonetheless, even on fast connections you can find yourself “stalled” at times by BitTorrent and thus we come back to the second most important reason why you can encounter serious slowdowns while using a BitTorrent client, which is the clogging of the NAT table in your home router. BitComet (and most of the other BitTorrent clients) sends and receives A LOT of packets on UDP and quite often to lots of **different **IPs.
And apparently that number increases with the speed of your connection (i.e the speed at which your tasks run). On my older 4Mb connection the highest numbers of simultaneous “connections” I could usually see in my firewall was around 800+, whereas with my new connections I’ve witnessed it go to as high as 2000+.
And that wouldn’t be a problem at all, if the traffic would happen among a handful of IPs, but very often this happens with lots of different IPs which leads to your NAT table filling up pretty quickly.
When that happens from one model to the next, routers handle it differently. The worst ones crash or freeze, the better ones just drop new connection attempts until an entry in the table times out and is being freed. So, in the best of cases you will experience the same thing as if your whole bandwidth was being used by BT protocol.
As you may remember I’ve been nagging the team a while ago, to implement a feature which will monitor the number of IPs which BC tries to contact on UDP, within a defined amount of time, by constructing and maintaining a table similar to the one used by the router, where UDP sockets would be entered when first used and then timed out (if not used anymore). That was meant to give the user the means to limit the number of different outgoing UDP sockets per minute and keep in line the number of entries which BC creates in the NAT table.
The team went instead with the choice of limiting the raw number of UDP packets per second (it obviously was the easier choice). Unfortunately there is no way to tell how many new UDP sockets BitComet will open in each different minute, therefore it’s kind of hard to decide upon a right value to use here.
There are 2 different situations:
A. When BC “talks” with lots of different IPs (on UDP) in a very short time, limiting the number of raw UDP datagrams to something lower (let’s say 10/s) will help address the issue of flooding the NAT table of the router with entries;
B. When BC may “talk” with roughly the same IPs (on UDP) for let’s say 5-10 minutes, the limit you set on the raw no. of UDP packets may actually hinder the communication between your client and those peers, needlessly, as BC doesn’t create anymore entries in the NAT table anyway but still can only send a limited no. of UDP packets towards the same IP.
As you can see the current solution, while offering some degree of control over the problem it makes BC shoot itself in the leg quite often, since the pattern of communicating on UDP is quite dynamic.
That’s why is hard to come up with a “right” value to use here, for any connection line/ISP speed plan of your choice.
Therefore, my final point is that if the extension you propose would include both a speed throttling mechanism, as you mentioned, and a mechanism to keep the NAT table occupied to less than 100% at all times, only then it will address the slowdown issues that many users may encounter quite often.
Of course, nobody jumps to speak about how much work it may take to create something like this. 
