Feature Request: Linked Upload and Download

[eierfrucht]

My ISP enforces a total bandwidth cap of 80 Mbps on Upload & Download combined, for QoS and ACC to work I had to cap Download at 60 Mbps and Upload at 20 Mpbs.

Are there any plans for adding some flexible support for this kind of ISP bandwidth capping? Many ISPs in Western Europe employ this kind of bandwidth capping and the only current option for Gargoyle is (sadly!) to reserve part of the bandwidth exclusively for uploading, leaving the rest for downloading.


It seems to me that the easiest way to achieve this goal is just to spawn a "shadow class" counting towards Upload but simply mirroring the current total Download rate. The "shadow class" should have the absolute highest priority possible, defying all percentages and caps of all other Upload classes. As long as the total current Download rate is mirrored in Upload QoS, all the real Upload classes will have to make do with whatever is left to them.

By capping this "shadow class" at a certain percentage or an absolute value, we could keep Download from pushing back Upload beyond a desirable threshold. This would involve spawning a second "shadow class" in Download QoS, automatically capped at [(total bandwidth) minus (maximum value of the first shadow class]) and basically "defending" some bandwidth for the various Upload classes.

E.g. if I cap the Download Shadow Class at 50 Mbps and my total link bandwidth is 80 Mbps, any Download traffic is mirrored in Upload as an active, top-priority shadow class of up to 50 Mbps, and any Upload traffic is mirrored in Download as an active, top-priority shadow class of up to 80 - 50 = 30 Mbps. Thus Download traffic will have the privilege of pushing back all existing Upload traffic for as far as 50 Mbps, and any Upload traffic will push all existing Download traffic for as far as 30 Mbps, 30 + 50 resulting in the total Linked Upload & Download Bandwidth cap.

This may sound clumsy but it should work without rewriting the whole QoS because Upload and Download counters are left independent, it's just some numbers from either side which are mirrored as fake traffic in the opposite direction.

[pbix]

Why not just put 80MB/sec as your download limit and something less as your upload limit (say 20MB/sec) and let ACC handle this automatically?

And to your question there are no plans to do anything like your describe nor do I think it would be possible given the way Linux works.

[eierfrucht]

ACC is too slow to react. A sudden upload burst while downloading at maximum speed literally cripples QoS. ACC can only slowly adjust the link speed, it can't handle sudden upload bursts and it takes too long for ACC to throttle down the link even if the upstream traffic is more or less persistent. Imagine something sending upstream traffic at 30 Mbps and the Fair Link Speed is set at 80 Mbps, it takes several minutes to throttle the link down to 50 Mbps. During this time, ping times are a nightmare.

nor do I think it would be possible given the way Linux works.

Does simply faking extra upload / download traffic in qosmon involve any low-level tampering? Emulating download traffic as a fake, high priority upload class and upload traffic as a download class should resolve the issue, wouldn't it?

[pbix]

ACC should be quick at reducing the download bandwidth in response to high pings. The response time should be under 30 seconds I would think. If it is taking minutes something is wrong or it is not enabled or setup correctly. Try selecting RTT mode for your classes. You should post screen shots of the problem while it is happening.

In Linux there is no way to link the upload and download queues. Using ACC is your best an only option and there is no other router firmware out there than can even do what Gargoyle is doing for you.

[eierfrucht]

I used to set my downlink cap at 80 Mbps, which gave me a link limit of 72 Mbps in ACC.

Whenever I started a bunch of torrents, the outgoing traffic started to stiffle the incoming traffic. ACC would react by slowly reducing the downlink limit to 57-60 Mbps (over a period of two or three minutes) but after quitting the torrent client (and thus eliminating all traffic) it would only increase the link limit at a very slow rate, getting back my 72 Mbps usually took from five to seven minutes.

Ping times are about 30-40 ms while ACC is active and MINRTT mode is active. Is this supposed to be normal? I thought minRTT should keep ping times below 10 ms (ACC target host response time is less than 1 ms when there's no heavy traffic)

ACC is really quick to react when ping times hit the hundreds, but once ping is below 40 ms, ACC becomes too sluggish in pushing down the downlink cap. In fact, it never succeeds in setting the link cap low enough to eliminate the ping lag completely.

This is the behaviour I have witnessed with 1.5.X, 1.6.X and the latest 1.7.X builds. My router model is TL-WR1043ND and it never experienced any CPU overload even while downloading torrents @ 80 Mbps with QoS and ACC turned on.

My best guess is that my ISP's hardware does a bad job at squeezing both incoming and outgoing traffic within the 80 Mbps overall limit, so the real downlink limit during massive outgoing traffic fluctuates too wildly for ACC to properly react.

Like, one second it might be 80 Mbps, 40 Mbs the other second, but the average number is 60 Mbs which is consistent with the 20 Mbps of outgoing traffic eating away at the downlink.

This is only a guess, though, all speed tests indicate that the downlink shortage is quite stable and consistent with the amount of outgoing traffic at any given moment.

[pbix]

ACC tries to control your ping times. The target ping time is shown in the status section. Since you did not post any screen shot I cannot say if 40ms is the correct number or not. But I will say that 40ms pings are generally very good and will allow good operation of all applications that I know of.

I cannot from your post see anything that indicates a problem but glad to hear you checked your CPU utilization (but unfortunately again did not post it). Because it is important for proper operation.