Based on statistical data found via Google (confirmed by pftop on my own network traffic) I've re-calculated the maximum bandwidth of qWANack and qLANack. (I'm totally unfamiliar with traffic engineering and the likes, so please correct me if I'm wrong.) As shown below, the calculation supports our feeling that 10% is good in case of symmetric link, and shows that my figures in post #1 for asymmetric links were too aggressive.
For the purpose of calculation we assume a simple model, with qWANroot consisting of only qWANack and qWANdef, and qLANroot consisting of only qLANack and qLANdef. Thus outgoing and incomming packets other than ACKs are all queued in qWANdef and qLANdef, respectively.
A, B, X, Y are defined as above. Let C = bandwidth(qWANdef), D = bandwith(qLANdef). Thus A = C+X and B = D+Y. In post #1, calculation was based on the system of equations X/D = Y/C = 1/9, which was too simplified:
+ It characterizes some "imaginary" or "average" traffic, not uploading, downloading, web surf nor any other real-life traffic.
+ It establishes some relation between the amount of data in certain direction and ACKnowledges in the opposite direction, but not yet the relation between the amount of incomming and outgoing data.
Now we fix both the problems by assuming every (type of) traffic be characterized by a *pattern*, which is a 4-dimensional vector (c,d,x,y), where c, d, x, y is the amount of data passing through qWANdef, qLANdef, qWANack, qLANack, respectively, in the same duration (say, 1s), of that particular traffic.
For example, the traffic pattern for Web surfing is (0.11, 1, 0.075, 0.075), saying that in order to receive 1 kb of useful Web data, 0.11 kb must be transmitted, furthermore 0.075 kb of ACKs must be transmitted and other 0.075 kb of ACKs must be received in 1s.
The actual activity of i-th traffic is then obtained simply by multiplying that vector with a non-negative variable. For example, v*(0.11, 1, 0.075, 0.075) shows how much bandwidth are required for each queue in order to surf Web at v kb/s.
The (new) calculation is based on six types of traffic, corresponding to variables v0 through v5:
v0 * (1, 0.40, 0.01, 0.04) is p2p upload activity
v1 * (0.04, 1, 0.04, 0.01) is p2p download activity
v2 * (1, 0.1, 0.015, 0.05) is other bulk upload activity
v3 * (0.1, 1, 0.05, 0.15) is other bulk download activity
v4 * (1, 0.11, 0.075, 0.075) is web server activity
v5 * (0.11, 1, 0.075, 0.075) is web surf activity
and constrained by:
sum(v_i * a_i) <= A
sum(v_i * b_i) <= B
where a_i = c_i + x_i and b_i = d_i + y_i and i running in 0,...,5.
Two further constraints are made, limiting p2p upload and download at 80% of uplink and downlink bandwidth, respectively:
v_0 * c_0 <= A * 0.8
v_1 * d_1 <= B * 0.8
We are now ready to estimate X and Y, the required bandwidth of qWANack and qLANack, in a worst-case fashion:
X = max(sum(v_i * x_i))
Y = max(sum(v_i * y_i))
One can find the max's using any linear programming solver. I used M$ Excel :-).
Recall that K = B/A. If (say) A=128 kb/s and B=1024 kb/s, then K=8.
Ex 1. For K=1, namely A=1, B=1 [mb/s], X/A = Y/B = 11.90% at (v4 = v5 = 0.794, others v_i = 0, here and below, unshown v_i are zeros), both links saturated.
Ex 2. For K=2, namely A=1, B=2 [mb/s], X/A = 17.86% and Y/B = 8.93% at (v4 = 0.629, v5 = 1.752), both links saturated.
Ex 3. For K=4, namely A=1, B=4 [mb/s], X/A = 29.76% and Y/B = 7.44% at (v4 = 0.299 ; v5 = 3.67), both links saturated.
Ex 4. For K=8, namely A=1, B=8 [mb/s], maximums of sum(v_i*x_i) and sum(v_i*y_i) are not reached at the same time:
X/A = 43.58% while sum(v_i*y_i) = 3.94% at (v1 = 4.016 ; v5 = 3.669), both links saturated.
Y/B = 5.07% while sum(v_i*x_i) = 40.54% at (v5 = 5.405), uplink is saturated (at A*100%), while downlink is loaded at B*72.64%.
The traffic patterns (c_i, d_i, x_i, y_i) used here are illustrative. Nevertheless, the examples of calculation suggest that 10% would suffice in the case of symmetric and nearly-symmetric link, and in the case of very asymmetric link, one might consider setting some larger bandwidth for qWANack (although not too large as suggested in my post#1 above).
Game and VoIP clients do not figure here, as they typically use UDP which -- I think -- does not use ACK queues. In a network with game and VoIP continuously backlogged, then ACK queues require -- in percentage -- yet lower bandwidth.
This is a worst-case analysis. But it is possible to estimate the bandwidths more closely to the average case by further constraining with upper limits that shouldn't be much higher than the desired linkshare.