Test Description

1. Network layout
2. EF and BE data streams:
   • sources and destinations
3. Router configurations
   • CERN
   • GRnet
   • INFN
   • Uni. of Utrecht
4. Variables:
   • traffic aggregation degree (number of EF microflows in the EF class): [1, 20]
   • EF traffic load: [400, 1200] Kbps
   • EF packet size (different between microflows, but constant withing a given microflow)
   • frame size of EF reference stream used for measurement (generated by the SmartBits): [256, 1024] bytes
5. Stream profiles:
   • measured EF stream: constant bit rate equal to 300 Kbps, packet size variable
   • additional EF traffic: overall rate = EF load - 300 Kbps
   • BE stream: constant bit rate equal to 2.0 Mbps (217 packs/sec, 1000 bytes/pack)
6. Test conditions:
   • EF queue-limit = 10 pack (constant)
   • tx-ring-limit: 5 particles (constant)
   • PVC: bandwidth 2 Mbps
   • queueing algorithm for EF traffic: PQ, policing rate: 1.2 M
   • policing rate at ingress interfaces equal to 1200 Kbps rate, exceed action: drop, burst tolerance: 100,000 bytes

Results in short:

• Packet loss within an EF class is a function of the aggregation degree (i.e. the number of EF streams) and not of the EF load.
• For large EF packet sizes packet loss is almost negligible (below 1.2%), could be because of the different probability of being policed by the PQ policer for different packet sizes.
• One-way delay slightly decreases with the EF load, possibily because of packet loss, which increases.
• For a given EF load, ipdv increase with the number of flows.
• Average ipdv tends to increse with the number of streams for each EF load value, however for more than 12 streams ipdv gets constant.

Comments:

• Figure 1 shows that when several EF microflows aggregate, packet loss can be relevant.
  Packet loss is not due to the EF class load, since for a given overall traffic rate packet loss varies according to the number of EF streams within the class.
  For an EF load equal to 600 Kbps (3/10 of the link capacity) packet loss occurs for a number of streams equal or bigger than 16. The higher the number of EF microflows, the lower is the EF load for which packet loss occurs.

  However, as figure 2 shows, the loss pattern is very different with larger EF frame sizes (in this case 1024 bytes). In this case the maximum packet loss percentage is always below 1.2% (note: scales in figure 1 and 2 are different).
  Packets injected in priority queue are subject to policing. Two are the options: either the packet is rejected or transmitted. In the latter case, large packets consume a higher number of tockens, so the probability that additional tockens are left to other microflows is lower. It may be that in this way a smaller number of EF packets get clustered, as a consequence, they have higher conform probability with respects to the policing applied in the following diffserv nodes on the data path.

• Figure 3 shows the impact of the EF load on average one-way delay. For a given number of streams, the higher the rate, the lower one-way delay is. This could be explained by the fact that for higher rates, the percentage of packet loss increses, so the EF load decreases gradually. This require more understanding.
  For a given rate, even if the difference in one-way delay is small - in comparison with the end-to-end delay -, there is no clear dependency between one-way delay and the number of streams.
• Figure 4 shows that for a given EF load, ipdv increase with the number of flows. This because of the burstiness which increases with the EF aggregation degree. With burstiness PQ introduces queuing delay (it tends to build up).
• Average ipdv tends to increse with the number of streams for each EF load value, however for more than 12 streams the derivative of the curve decreases and ipdv gets constant, this independently of the EF packet size (figure 5 and figure 6).

Other graphs: