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'.