According to RFC 2598:
The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate.
This requirement implies that contribution to delay of an EF queue should be less or equal to the time needed by the EF queue to transmit an MTU at a rate equal to the EF guaranteed rate.

In fact, given:

• G: the EF configured rate,
• D_EF: a given amount of EF data,
• tx: transmission time of an EF packet at line rate,
• del: delay of an EF packet due to queueing

If D_EF corresponds to 1 EF packet, then, the formula above translates into:

In our scenario, the "configured EF rate" (G) is 300 Kbps. Given an MTU of 1500 bytes, the resulting bound is 40 msec.

Service-To-Arrival-Ratio (STAR) is defined in RFC 2598 as: "For WRR, we define the service-to-arrival rate ratio as the service rate of the EF queue (or the queue"s minimum share of the output link) times the output link bandwidth divided by the peak arrival rate of EF-marked packets at the queue."

So STAR can be computed according to the formula:

• %_r = parcentage of link rate assigned to EF
• link_r = link rate
• A_r = peak arrival rate

Test Description

1. Parameters:
   • EF packet size
   • service-to-arrival-ratio. STAR values in the range [1, 5].
2. Stream profiles:
   • EF: 300 Kbps, variable packet size
   • BE: 2.0 Mbps, 200 packs/sec, 1000 bytes per packet
   Note: PVC bandwidth is 2 Mbps.
3. Test conditions:
   • tx-ring-limit = 5
   • EF queue-limit = 10 pack
4. Router configuration

Results of this experiment in short:

• in this test scenario EF queue service rate under WFQ is irrelevant to the delay of small EF packets; however it can improve one-way delay of up to 25 msec for larger packets.
• Service rate does not impact ipdv for any EF packet size. However, if arrival rate = service rate, ipdv is irregular.
• ipdv varies periodically over time. Periodicity is due to the highly regular traffic patterns deployed in this scenario (CBR best-effort traffic and CBR EF traffic both with constant packet sizes). The maximum ipdv experienced by an EF packet corresponds to the transmission time of a best-effort packet.
• the period length depends on the decimal part of the ratio between BE packet rate and EF packet rate. If this value is less than 0.5 then the slope of the curve during the period is negative (ipdv decreases), otherwise it's positive.
• For different service rates, the delta between one-way delay curves depends on the STAR value:
  If STAR = 1200 / 300 = 4 , then EF packets have to wait for 3 or 4 BE packets before they can be enqueued, since the BE queue is always full. Figure 2 confirms that, in fact the delta between the min values of curves for service rate = 300 and service rate = 900 is approx. equivalent to the tranmission time of 3 BE packets.
  If STAR = 900 / 600 = 1.5, then one EF packet waits for 1 or 2 BE packets. This is confirmed by figure 2, since the delta between the min values of curves for service rate = 600 and service rate = 900 is approx. the transmission time of one BE packet.
  If STAR < 1, then when an EF packet arrives, it is tranmitted immediately after the tranmission of the current packet, so the EF service rate is such that WFQ applied to the EF queue is equilvalent to priority queuing.

Comments:

• According to Figure 1 service rate has a minor impact on one-way delay for small EF packet sizes. This is according to our expectations, since the smaller the EF packet, the longer is the burst of EF packets (the size * packet rate product is constant) between subsequent best-effort packets. Given the small degree in packet interleaving, during an EF burst EF packets and only them are available for transmission, whatever service rate is deployed.
  However, for packet sizes close to the MTU, an higher service rate can decrease one-way delay of up to 25 msec.
• Figure 2 shows that one-way delay increases periodically. The lenght of the period is independent of the service rate and is approximately 1 sec. Periodicity is due to the highly regular pattern of both EF and BE traffic. Depending on the decimal part of the ratio between BE packet rate and EF packet rate, during the period ipdv increases (if the decimal part is greater than 0.5), otherwise it decreases.
• Figure 3 confirms simulation results from Table 2 in RFC 2598. In fact, apart from the case where the service-to-arrival-ratio is 1 (service rate = 300 Kbps), an increase in service rate does not change ipdv considerably, whatever packet size we consider.
  For service-to-arrival-ratio equal to 1, ipdv is not stable. In particular, it can be greater or smaller than the ipdv measured for other ipdv values, depending on the packet size. In our test oscillations depend on the number of BE packets sitting in the tx ring at a time. If just one BE packet is under tranmission then contribution of the tx ring to delay is the remaining part of that transmission time. If two BE packets are in the transmission queue, then the contribution is the same as in the previous case plus the whole tx time of the second packet.
  Since in this test the tx queue size is 5 particles, given the memory allocation policy in the router, the maximum number of BE packets (1028 by) which can be stored by the tx queue is exctly 2. Simulation results from RFC 2598 show that for two packet sizes (1500,and 160 by) ipdv is higher when the service-to-arrival-rate is close to 1.
• Figure 4 shows that the maximum ipdv experienced by and EF packet corresponds to the transmission time of 1 best-effort packet of 1000 by at 2 Mbps (around 4 msec). ipdv are periodic for any service rate deployed in the test.
  Peaks are larger for small service-to-arrival-ratio values.