Quick notes on real-time and upper-limit curves
-
The following may be taken as an introductory howto use real-time and upper-limit curves. As for the meaning of d for multiple concurrent sessions, Notes 1 and 2 correct my points in a sticky thread (on ACK queue sizing), which were wrong. Please forgive my ignorance.
1. Be very precise on specifying curve parameters. Know your packet rate and packet size. Use m1 and d to specify delay, use m2 to specify bandwidth.
Example 1.1. (Real-time curves.) A VoIP session with packet size = 1.2 kb (kilobit) and packet rate = 100 packets/s requires bandwidth = 100*1.2 = 120 [kb/s].
Using a linear real-time curve with m2 = 120 kb/s, maximum delay = 1.2 / 120 = 0.01 s = 10 ms is guaranteed.
In order to reduce the maximum delay 5 times, use a (concave) real-time curve with m1 = 5*120 = 600 kb/s, d = 10/5 = 2 ms, and m2 same as above. This effectively shifts the linear curve, in the (t(ime), s(ervice)) coordinate plane, to the left by 8 ms, so as the point (t=10 ms, s=1.2 kb) becomes (t=2 ms, s=1.2 kb). Note that d is a curve parameter and also is the maximum delay. Set d exactly as calculated. Setting it lower invalidates maximum delay guarantee. Setting it higher makes m2 ineffective (see 3.)
Example 1.2. (Upper-limit curves.) A P2P download session with packet size = 12 kb and packet rate = 1000 packet/s requires bandwidth = 1000*12 = 12000 kb/s.
Using a linear upper-limit curve with m2 = 12000 kb/s, minimum delay = 12 / 12000 = 0.001 s = 1 ms is guaranteed.
Shift the upper-limit curve to the right by 999 ms, i.e. use a (convex) upper-limit curve with m1 = 0, d = 999 ms and m2 same as above, to specify minimum delay = 1 + 999 = 1000 [ms].
2. Know the number of concurrent sessions. Given the suitable real-time curve for a single session then, for n concurrent sessions, multiply the curve by n.
Example 2.1. For a queue running the type of VoIP as specified in Example 1.1 (i.e. 1.2-kb packets, 100 packets/s per call), in order to achieve the same QoS guarantee (i.e. min. bandwidth 120 kb/s per call and max. delay 2 ms for every call) for 4 concurrent calls, use a real-time curve with m1 = 600*4 = 2400 [kb/s], d remains the same = 2 ms, m2 = 120 * 4 = 480 [kb/s]. It is fine if the actual number of concurrent calls is less than 4 (, which gives you even better guarantee, indeed). If it is more than 4, however, the guarantee is lost.
3. "For the first d milliseconds the queue gets the bandwidth given as m1, afterwards the valuegiven in m2." – True, but not quite, and somewhat misleading.
In fact, if the point representing amount of data transmitted so far under the real-time algorithm get below the real-time curve then the last transmitted packet is considered a new session-initiating packet and everything starts over: the algorithm shifts the curve to that point. So, if m1 and d are set larger than needed then the actual amount of data transmitted in d miliseconds never reaches m1*d, which means that new sessions start over and over again, m1 applies forever, and m2 -- never. In other words, such a curve is equivalent to a linear curve with slope (i.e. bandwidth) = m1, sometime called 'bandwidth over-comitting'.
-
can you tell me how to get the packet rate and packet size? i did a pfctl -vsq
$ pfctl -vsq
queue root_le1 on le1 bandwidth 720Kb priority 0 {qwanRoot}
[ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue qwanRoot on le1 bandwidth 720Kb priority 0 {qwandef, qwanacks, qGamesUp, Http_up}
[ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue qwandef on le1 bandwidth 7.20Kb qlimit 500 hfsc( default realtime 7.20Kb )
[ pkts: 1165495 bytes: 863547699 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/500 ]
queue qwanacks on le1 bandwidth 273.60Kb priority 7 hfsc( realtime 72Kb )
[ pkts: 281417 bytes: 18368398 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue qGamesUp on le1 bandwidth 273.60Kb priority 5 hfsc( realtime 20Kb )
[ pkts: 49416 bytes: 5935378 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue Http_up on le1 bandwidth 144Kb priority 4 hfsc( realtime 8Kb )
[ pkts: 11495 bytes: 7940269 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue root_le0 on le0 bandwidth 6Mb priority 0 {qlanRoot}
[ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue qlanRoot on le0 bandwidth 6Mb priority 0 {qlandef, qlanacks, qGamesDown, http_down}
[ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue qlandef on le0 bandwidth 60Kb qlimit 500 hfsc( default realtime 60Kb )
[ pkts: 1001094 bytes: 366194265 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/500 ]
queue qlanacks on le0 bandwidth 60Kb priority 7 hfsc( realtime 600Kb )
[ pkts: 407090 bytes: 23785904 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue qGamesDown on le0 bandwidth 1.20Mb priority 5 hfsc( realtime 30Kb )
[ pkts: 96985 bytes: 62311033 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue http_down on le0 bandwidth 1.20Mb priority 4 hfsc( realtime 200Kb )
[ pkts: 62172 bytes: 86175228 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]