Test Description

1. Parameters:
   • EF packet size
   • sheduling alogrithm applied to the EF queue (Weighted Fair Queuing and Priority Queuing)
2. Stream profiles:
   • EF: 300 Kbps, packet size variable
   • BE: 2.0 Mbps, 200 packs/sec, 1000 bytes per packet
3. Test conditions:
   • EF queue-limit = 10 pack (constant)
   • tx-ring-limit: 5 particles
   • PVC: bandwidth 2 Mbps
   • queueing algorithm for EF traffic: WFQ or PQ
   • service rate of EF queue: 400 Kbps (constant)
4. Scheduler configuration:
   • WFQ: bandwidth is set to 400 Kbps, i.e. the EF service rate is slightly over-estimated. 400 Kbps was chosen for the sake of homogeneity with the PQ configuration.
   • PQ: no bandwidth needs to be assigned to the PQ queue, paramter 400 kbps is the policing rate applied to the EF queue. The EF stram deployed in the test is such that no packet drop occurred during the tests.
5. Router configuration

Results in short:

• the contribution to queuing delay with PQ is always smaller than with WFQ. The gain depends on (figure 1):
  1. the average EF packet size,
  2. the EF queue service rate under WFQ (for higly over-estimated service rates the two schedulers are equivalent).
• in our test scenario the maximum gain with PQ is for MTU-size packets and it's equal to 24.18 msec.
• for large packet sizes the difference in one-way delay with WFQ and one-way delay with PQ is a multiple of the BE packet transmission time.

Comments:

• Figure 1 shows that with Priority Queuing one-way delay is alwyas less than with WFQ, since with PQ queuing time is always less than with WFQ (the maximum queuing time is the transmission at line rate of a best-effort MTU packet).
  WFQ converges to PQ when the service-to-arrival ratio increases and/or when the packet size decreases. The larger the ratio or the smaller is the EF packet size, the longer is the burst of EF packet which can be transmitted before any other WFQ queue is serviced. However, with WFQ at some time we can still have that one EF packet has to wait for a BE packet to be transmitted, since with WFQ we don't have starvation.
  Also with small packet sizes up to 512 bytes PQ and WFQ are almost equivalent for two reasons. First since the EF rate is constant, when small EF packets are deployed the inter-arrival time between subsequent EF packets decreases and more EF packets can arrive into the EF queue during the transmission time of a single BE packet. Second, given the formula deployed by WFQ to calculate the next candidate packet: FT = ST + pack_size * W where FT is the finish time of the packet, ST is the time when the EF packet arrives and W the weight of the queue a given packet belongs to. If packet size pack_size is very small, then the effect of the weight assigned to a queue vanishes.
  For MTU-size packets, with PQ the gain in one-way delay is up to 24.18 msec.
• The influence of the EF packet size on the gain with PQ is illustrated in figure 2, figure 3 and figure 4, which compare one-way delay over time with WFQ and with PQ for different EF packet sizes: 128 by, 1024 by and 1518 by respectively.
  In each case the shape of the two curves is the same. Delay variation depends on the instantaneous number of BE packets in the tx ring when the EF packet is sent by the scheduler and on the time needed to complete the bE transmission in progress when the EF packet arrives in the EF queue. These two delay contributions can slightly vary depending on the sceduler in use.
  However, the most significant contribution to delay derives from the time an EF packet has to wait in the EF queue because of the scheduling decisions. For EF packet size equal to 64 bytes, the queuing delay is almost the same. For EF packet size equal to 1024 it's approximately equal to the transmission time of 4 BE packets, and this delta rises to 5 for EF packets of 1518 bytes.
• Figure 5 plots the average ipdv for different packet sizes. For small packet sizes (e.g. 128 bytes and 256 bytes) ipdv is higher. As figure 2 shows, this is due to the fact that for subsequent packet sizes at times the maximum one-way delay is the same in the two cases (WFQ and EF), while with PQ the minimum can be much lower than with WFQ.
  For MTU-size packets (Figure 7) the maximum ipdv is equivalent to the transmission time of a BE packet both with WFQ and with PQ. However, while with EF traffic peaks in idvp are less frequent, with WFQ the probability of experiencing the maximum ipdv is higher because EF packets may be required to wait in the EF queue until several BE packets are dequeued.