The pfSense Store

Author Topic: Quick notes on real-time and upper-limit curves  (Read 2824 times)

0 Members and 1 Guest are viewing this topic.

Offline dusan

  • Full Member
  • ***
  • Posts: 198
    • View Profile
Quick notes on real-time and upper-limit curves
« on: February 12, 2010, 10:18:17 am »
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'.
« Last Edit: February 13, 2010, 10:08:09 am by dusan »

Offline jet

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: Quick notes on real-time and upper-limit curves
« Reply #1 on: March 16, 2010, 04:23:19 am »
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 ]