Potential Solution to Bandwidth Capping

[MrEcks@netjunkies.org]

OK, we all know bandwith cappers are out there and in some cases they are used ligitimately to reduce connection degredation, especially on ADSL connections which require some overhead for TCP retry's etc... But some people are just leeches and are happy to take all they can get without giving in return...

With this in mind I have the following proposal... contribs welcome...

In the DC++ client could there be a feature added to test application upload speed by sending about 5 MB of data packets to the local loopback interface of the host thereby determining the amount of upload bandwidth availiable? If there is no capping in place the test should take no more than a few seconds and the reported bandwidth shoud be off scale, if there is capping in place it can be calculated by the 5mb / time taken and sent to the hubs that the client connects to. This gives ops the ability to refuse entry to leechers or modems or can be used to enforce ratios.

Ratios? Simple... When the users u/l speed is reported to a hub the hub can report it to other users whom that person is d/l from. The hub can have preset ratios (eg D/L speed = 4 x U/L speed) so when capped client A tries to D/L from client B in hub C, Client B gets the users u/l speed and ratio from hub C and caps u/l to client A at the hubs ratio speed! Make sense? (gcc not found? ) If the hubs ratio speed is 4:1 then a user with a 25K upload bandwidth could download from others at a maximum 100K. Geddit? ADSL users could cap at 1K below thier max upload speed and still get fast downlaods without performance degredation! Leechers capping at 1K could get a whopping 4K for thier troubles!

Periodic requests by the hub or other clients for an U/L badwidth retest could be sent at random intervals to ensure capping software is not brought into play after initial test is run and will also allow sins to be forgiven if u/l bandwidth is incresed.

Thoughts anyone?

[TheParanoidOne]

No need to double post. Other thread removed.

[Qbert]

... the following proposal. In the DC++ client could there be a feature added ... When the users u/l speed is reported to a hub

There can't be a solution to this which resides completely on the client, because the client can say whatever it wants to whoever it wants. (And that whatever could be lies.)

If there is no capping in place the test should take no more than a few seconds and the reported bandwidth shoud be off scale

Should be yes, even though I'm not going to agree with the term 'off scale'. But many factors could contribute it into not being as high as you would expect for every given attempt.

...if there is capping in place it can be calculated...

If there is capping on the loopback interface or a larger generic domain, such as all network communcations, then maybe. But most network capping programs can be very specific, being able to distinugish specific ports for specific connections.

...Client B gets the users u/l speed and ratio from hub C and caps u/l to client A...

I think its ironic that this solution to capping involves capping. (But I do not sugguest that that is necessarilly a wrong or bad thing, even if it might be.)

[MrEcks@netjunkies.org]

Qbert Wrote:

There can't be a solution to this which resides completely on the client, because the client can say whatever it wants to whoever it wants. (And that whatever could be lies.)

Well yes, the challenge is to provide some sort of validation in that case, perhaps a validation routine on the hub which can vary parameters of the test in order to detect fakes?. Im not too worried about people capable of redeveloping the client or coding to that degree, anyone with brains enough to redevelop the code to that degree is going to want to crack it anyway!

The vast majority of ppl will simply use capping software which will restrict either via application or interface(and no, I wont provide anyone reading this with an example, find it yourself!) which, as it exists outside of the client itself, should allow the client to produce a reliable analysis of its own upload speed.

"Off Scale" could be defined as any result which returns higher than a preset value. Any loopbak interface should at least be able to retun a value of 10mbps or more.

Network capping is unavoidable but I know a thing or two about network capping and the majority of the capping at the moment is on the client, not the network. I know this because if you do a simple large packet test to the remote ip (or its neigbours on the same segment that respond to such requests) then you notice that you get excellent throughput. Also DC++ uses random ports specifically to combat capping on specific ports(or so I am led to believe, I could, as always, be wrong). [/b]

[Seisled]

Rather than going through the difficulties of trying to detect who's capping, wouldn't it be easier to just introduce a capping mechanism into DC++ with a defined UL/DL ratio and then just run searches for known modified cheater clients? Admittedly, this doesn't detect bandwidth-controlling apps like NetLimiter, but it seems to me that those who are currently cheating will have a much greater incentive to move to an unmodified client if a capping mechanism with a decent ratio is introduced. I know this has been discussed before ad-nauseum, but it just seems like such a straightforward easy solution. DC++k's capping mechanism works very well with a 1:4 UL/DL ratio.

[Twink]

Rather than going through the difficulties of trying to detect who's capping, wouldn't it be easier to just introduce a capping mechanism into DC++ with a defined UL/DL ratio and then just run searches for known modified cheater clients? Admittedly, this doesn't detect bandwidth-controlling apps like NetLimiter, but it seems to me that those who are currently cheating will have a much greater incentive to move to an unmodified client if a capping mechanism with a decent ratio is introduced. I know this has been discussed before ad-nauseum, but it just seems like such a straightforward easy solution. DC++k's capping mechanism works very well with a 1:4 UL/DL ratio.

most modded clients have a similar ratio to dc++k, infact I think bcdc might be a little more harsh having a lower ratio, which in your opinion seems to make them fair. I personally think that these are no way near as bad as NetLimiter and that most modded clients dont deserve to be banned. Client Mods are great in my opinion, not to draw people away from DC++ but to find useful features and test them before they are implemented into DC++ (if they ever are)

[Seisled]

I personally think that these are no way near as bad as NetLimiter and that most modded clients dont deserve to be banned.

I entirely agree with you there. The cheater clients I was referring to in my previous post are clients specifically modified for the purpose of cheating. I would NOT in any way consider DC++k or BCDC & etc... to be cheater clients. Sorry if there was confusion about this.

[Twink]

I personally think that these are no way near as bad as NetLimiter and that most modded clients dont deserve to be banned.

I entirely agree with you there. The cheater clients I was referring to in my previous post are clients specifically modified for the purpose of cheating. I would NOT in any way consider DC++k or BCDC & etc... to be cheater clients. Sorry if there was confusion about this.

Actually my fault, I forgot to make my main point being that I'd think more people would use NetLimiter for limiting then a cheating client. I could easily be wrong there, but I was under the impression that NetLimiter was one of the bigger problems.

[MrEcks@netjunkies.org]

The issue at hand has nothing to do with the method of one's bandwidth capping but rather determining a fair way to distribute bandwidth. It only seems fair that users who provide high badwidth should be given the highest possible downloads whilst those who are stingy with thier bandwidth should not enjoy the same luxury.

As stated nicely by QBert:

There can't be a solution to this which resides completely on the client, because the client can say whatever it wants to whoever it wants. (And that whatever could be lies.)

A well run hub with decent software and capping controls would make the entire dc++ experierience more enjoyable by not only sharing files but also by sharing bandwidth.

[Seisled]

It only seems fair that users who provide high badwidth should be given the highest possible downloads whilst those who are stingy with thier bandwidth should not enjoy the same luxury.

I agree with you up to a point. I think it's perfectly reasonable to limit shameless leechers who use massive bandwidth. The point I might disagree with, however, is when it gets down to essentially punishing (or rewarding) people based upon their connection speed or capability. This could be conceivably hellish for people who still use modems and already have a tough enough time as it is using direct connect. Depending on how severe the limitations are, it could also punish ADSL users in what I feel would be an unduly harsh manner.
Again, I agree with you to the extent that people not sharing any bandwidth and also people who are sharing very limited bandwidth when they are making use of T1/2/3 (or above) capabilities for downloading should be punished. However, I think it would be best to try and avoid the sort of exclusionary bandwidth elitism that could possibly arise from capping people based solely on their bandwidth.
Now, I'm not in any way opposed to a 1/4 ratio (which, as I mentioned before, I believe is fair), but looking at users with less capability and total bandwidth available and making special circumstances to accomodate them also seems reasonable to me.