Test Description

1. Network layout
2. Router configurations
   No QoS features are inabled in any router on the data path.
3. Parameters:
   packet size of the best-effort microflow to which measurement is applied (the flow is generated by the SmartBits).
4. Stream profiles: two BE streams are run in parallel:
   • one UDP stream at 2 Mbps (217 pack/sec, 1000 bytes of payload per packet) is used to congest the output interface of the first hop router.
   • a second UDP constant bit rate stream generates packets at 300 Kbps. The test is repeated with different packet sizes.
5. Test conditions:
   • tx-ring-limit: 5 particles (constant)
   • PVC: bandwidth 2 Mbps
   • EF traffic (for comparison of results in figure 2):
     • EF queue-limit = 10 pack (constant)
     • queueing algorithm for EF traffic: PQ, policing rate: 1.2 M
     • policing rate at ingress interfaces equal to input EF rate, exceed action: drop, burst tolerance: 8000 bytes

Results in short:

• one-way delay is always higher than 800 msec and increases with the frame size. Contribution to one-way delay must derive from queuing delay in a congested output queue.
• packet loss percentage decreases with the BE frame size.
• both one-way delay and ipdv standard deviation increase with the BE frame size.

Comments:

• Figure 1 plots the average one-way delay for different best-effort frame sizes. One-way delay is always more than 800 msec. In this test no policy was attached to the congested output interface. However, the tx-ring-limit parameter was set to 5 particles. Given the huge one-way delay values, we need to assume that an additional output queue (apart from the tx ring) is deployed by the router. The high one-way delay can only be justified by the presence of a long output queue which is permanently congested. This needs more investigation.
  BE one-way delay is compared to the one-way delay experienced by a similar EF stream (300 Kbps, CBR, variable packet size) run in parallel with the same BE background traffic. (Note: the overall EF rate in the case of the EF graph is 1200 Kbps, the EF class is fed by 4 microflows. So, in the case of EF, one-way delay is affected by both congestion and EF aggregation. Results for a single EF stream - to remove aggregation - have to be plotted instead for exact comparison.)
• Figure 2 shows the packet loss percentage experienced by the 300 kbps best-effort stream. Loss decreases with the frame size: Since the rate is constant, an increase in packet size implies a decrease in the packet rate. This could be due to the memory allocation sheme deployed in the output queue: If memory is allocated in packets, then the smaller is the packet size, the higher is memory fragmentation in the queue, so tail drop is more probable.
• Figure 3 and figure 4 compare the one-way delay frequency distribution for two different BE packet sizes: 256 bytes and 1024 bytes respctively. Both curves have the shape of a normal distribution, but they have a different standard deviation, which is higher for larger packets, as the following table shows:

  frame size (bytes)	average one-way delay	std. deviation
  
  64			 788240			54818
  128			 903599			55671
  256			1043009			62495
  512			1129839			65416
  1024			1225863			69807
  1280			1249459			71252
  1518			1264128			72379
  

  Why?
• Like for one-way delay also the ipdv frequency distribution is characterizes by higher standard deviation when the BE packet size increases, as figure Figure 5 and figure 6 show, respectively for BE packet size equal to 256 bytes and 1024 bytes. Why?