Frame Blasting Modifiers

Following 📄 Basic Use Cases - Measuring Throughput, we are going to explore some modifications to the frame and frameblasting flows. This will enable us to utilize more of the GUI's features; in particular the time and frame-size modifiers. These features create variations in the throughput which simulate non-uniform traffic flows.

We will look at 3 scenarios: 

• Growing frame size - Frame increases size up to a maximum.
• Random size
• Bursty traffic - Frames sent in bursts  (one-second intervals).   

Each one of the tests will run vs a default frame for comparison purposes. 

You can find this project on our github.

Let's go!

When you open the .bbp file you will see the following displayed:

• 2 ports configured with DHCP
• Port 2 is NAT-enabled

Port 1 and Port 2 are set are configured for DHCP so they should be docked onto trunk interfaces compatible with DHCP.

You will see that Port_2 has been NAT enabled but this is not strictly necessary.

• In this example, trunk 1-3 and 1-4 are such interfaces.

In this part we will look at the different frames and frame blasting flows with their modifications. Frames can be modified in terms of their size (number of bytes) as well as adding a modifier at the level 4 layer. This can mean adding a payload offset. Another feature is changing the UDP source and destination ports at the level 4 layer (see below). 

• Two frames have been created with the default size of 1024 bytes. 
• Going to the layer 4 setting we can see that Frame_1 and Frame_2 have different source and destination ports.

In this step, we will look at the different frame blasting flows and how they transmit the data frames. The settings of the 'Frame Blasting' tab enable the user to adjust the throughput as well as change the uniformity of the throughput. A frame blasting flow will take the frame defined in the previous step and repeatedly 'blast' it from source to destination.

In this example:

• The growing size frame will produce a sawtooth throughput.
• The random size frame modifier will generate random frame sizes between a minimum (60 bytes) and a maximum (1514 bytes).
• The bursty traffic frame uses a time frame modifier to produce bursts of traffic containing 5000 frames with an interburst gap of 1.2 seconds.

The flow is the traffic that will be sent by the ByteBlower server. Here we can define the source and destination of the generated traffic.

• Select the source and destination ports. 
• In this demonstration, we will send the frames from Port 1 → Port 2 which are connected back-to-back.
• A latency distribution has been included.

Up to this point, there has been no real communication with the ByteBlower server. Once we run the test, the server comes into the picture

• Go to the 'Scenario' tab and select the correct scenario from the two that have been created (Max_frame_blasting).
• The flow is the one from the previous section. The test duration has been set at 30 seconds though this can be changed as wishes.

When we click run, the GUI will connect with the ByteBlower server and a scouting frame will be sent to verify the connection. 

Growing Frame Size

• The throughput (blue line) rises to a maximum throughput before resetting. This process will repeat for the duration of the test.
• We can see that the latency increases with the throughput though not at the same rate.

Random Frame Size

• The random frame size used in the frame blasting flow will result in a variation in the throughput.
• This is logical as there can be a large difference in frame size from one to the next.

Bursty Traffic

• The throughput for the bursty traffic appears as a square wave. 
• The size of the square wave is proportional to the frame rate, and the frames per burst (see below)