4 UDP streams - each generates throughput with defined packet size and bit rate - from E1 to E2.

Send UDP packets (bit blasting) at defined rate to validate the capacity between endpoints on all 4 different streams. This will allow to validate class of services mix with bit blasting on each one, and run over-subscription scenarios.

Per stream :

• Generated Bitrate
• Packet Size
• DSCP setting

If generated bitrate is 0 on one stream then this stream will be ignored

Per stream:

• Average Throughput (Mbps) from->to
• Loss (%)
• Total bytes lost

Per stream

This test will generate UDP packets from E1 to E2 based on requested throughput. Test sample Filesize will be computed according to the requested bit rate so that there should be approximately one timing record per second. Optimized packet size is udp size used to optimize the stack therefore pushing packet size bigger than MTU to get full MTU packets on the line. While it provides better results for throughput it can be sensitive to packet fragmentation on the network therefore providing lot of packet losses in some network conditions.

The result in throughput is displayed at layer 4 level (with ethernet, IP and UDP headers). UDP packet generation is similar to bit blasting therefore will not autoadjust to available bandwidth. Some higher than capacity traffic generation can result into network equipments traffic congestion and therefore cause some service drops.

If the configured bitrate is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out (unable to collect result). Small packet sizes are not able to generate as much throughput as large ones: at high traffic, it is possible that endpoints generate packet losses as they would be unable to generate the expected traffic rate.

In case of use of UDP packet size optimized or 1460 packet size, be careful in case of low MTU or network fragmentation: this can cause packets to be fragmented therefore unexpected or higher than expected packet loss rates. It is recommended to use a lower UDP packet size (1300 for example) to validate there is no impact on test result.

If there is unexpected loss this could be because of some bursty UDP traffic generation: make sure you have endpoints supporting the send low jitter option and enable in preferences/test engine in Hawkeye preferences.

If results cannot be collected (some pairs failures complete error):

• Check that your E2 endpoint can open 10115 port toward E1 for management (this is needed for stream pairs).
• Check that port for traffic is opened (no firewall).
• Check that synchronization port between pairs is opened (management UDP 10115). Check that port in use is in range (see "preferences/Test Controller/Destination Port Conf Option" and "preferences/Test Controller/First Destination Port" so that correct destination port for test traffic is used.

Test consists of up to 4 class of services validation. One is real time (UDP) and others are data oriented (mostly transporting TCP traffic).

Send UDP packets (bit blasting) at defined rate to validate the capacity between endpoints on all 4 different streams. The TCP classes of services are tested with TCP stream mixes (3 mixed streams) trying to achieve as much traffic as possible. The class of services should "auto adjust" themselves to the defined compared capacity they should allow transport. For voice class of service, the expected throughput should be defined.

Global: filesize (in bytes)- will define which filesize shall be used for TCP traffic generation.

Filesize is going to determine how precise and efficient traffic generation on TCP classes of service will be.

Each class of service is sent 3 streams.

So if classes of services are expected to adjust to :

• 1M : 40000 bytes
• 5M: 200000 bytes
• 10M: 400000 bytes

For Voice stream: defined bitrate

Per stream :

Destination port: leave to blank for auto, otherwise put a specific port used by the network architecture to define class of service

DSCP setting: define stream class of service

If generated bitrate is 0 on voice stream then this stream will be ignored

Voicestream:

• Average Throughput (Mbps) from->to
• Loss (%)
• Total bytes lost
• Delay
• Jitter
• Max loss Burst

For TCP streams:

• Throughput

Per stream

This test will generate TCP packets for class of services and RTP packets for voice.

The TCP packets are generated on each class of service so that they should all take most of the class of service.

In case class of service reservation is higher on some COS than others the repartition should not be even but reflect what is configured.

Each TCP class of service is filled with 3 concurrent streams.

The (optional) voice test will provide throughput but also voice related parameters for jitter/loss/delay while the data network is under stress.

See advanced Information.

For voice:

If the configured is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out (unable to collect result). Small packet sizes are not able to generate as much throughput as large ones: at high traffic, it is possible that endpoints generate packet losses as they would be unable to generate the expected traffic rate.

For TCP: the filesize needs to be adjusted to the expected minimum COS throughput. Setting a filesize too high might result into test impossible to finish because file transfer is too long.

If results cannot be collected (some pairs did not complete error):

• Check that your E2 endpoint can open 10115 port toward E1 for management (this is needed for stream pairs).
• Check that port for traffic is opened (no firewall).
• Check that synchronization port between pairs is opened (management UDP 10115). Check that port in use is in range (see "preferences/Test Controller/Destination Port Conf Option" and "preferences/Test Controller/First Destination Port" so that correct destination port for test traffic is used.