Candela Technologies Logo
Network Testing and Emulation Solutions

Emulate video streaming traffic with the l3_video_em.pl Script

Goal: Emulate video stream traffic patterns using Layer-3 connections.

Using the l3_video_em.pl and the l3_vid_group.pl, we assemble two test groups of connections, a group of Generic connections, and a group of Layer3 connections, that emulate the bursty buffer filling pattern of traffic that video streaming tends to resemble. Requires LANforge 5.4.2.
 

  1. Begin with stations

    1. Using a CT523c, we can create 16 stations, and for this script setup you probably do not want to create more than that. These scripts poll LANforge every 200ms and that loads the server quickly. If you are using a CT521a or CT522b, then consider starting with five or six stations.
      There needs to be a continuously named series of stations.
      screenshot

      For more information see Creating Stations

    2. In this example we will use eth1 as our upstream port. We will be referring to that using the EID format: 1.1.2

      For more information see LANforge Entity IDs

  2. Create Connections Using l3_vid_group.pl

    1. The script l3_vid_group.pl has help examples. You can do four tasks with the script. screenshot
      1. Create groups of video emulators
      2. Start groups
      3. Stop groups
      4. Destroy groups
    2. We will create a group of 16 connections on our stations. Use the command:
      ./l3_vid_group.pl --action create --endp_type tcp --first_sta sta000
        --num_cx 16 --test_grp sixteen --upstream 1.1.eth1
      screenshot
    3. You will see two test group created. The group named _L3_sixteen contains the Layer-3 tcp connections. The group named sixteen contains Generic connections that control the Layer-3 connections. screenshot
    4. The Generic tab will have 16 connections. screenshot
    5. The Layer-3 tab will have 16 connections. screenshot
    6. When we inspect one of the Generic connections, we can see the command it uses.
      /home/lanforge/scripts/l3_video_em.pl --mgr localhost --mgr_port 4001
        --cx_name _sixteen-0000 --max_tx 1000000000 --buf_size 3145728 --stream yt-sdr-360p30 
        --tx_style bufferfill --quiet yes
      You can paste this command into a shell prompt on your LANforge and use it. We discuss the options in the following section. screenshot
    7. You can highlight the command in the window and copy it with Ctrl-C screenshot
    8. You can paste the command into the shell with Ctrl-Shift-V screenshot
    9. When we inspect the Layer-3 connection, we see these aspects:
      • It is a TCP connection. This is optional, you can create UDP connections; the Android YouTube app uses TLS over UDP (QUIC protocol) connections.
      • Both endpoints are set at 0 bps transmit. The Generic script will control the throttle on the B-side of the connection.
      • The PDU size is auto. This doesn't have much bearing on TCP, but might have bearing on UDP connections.
      • The Report Timer is set to three seconds. This value is too long to graph with much detail in the Dynamic Report, but you can shorten it to 500ms if you desire to see more resolution in the Dynamic Report graph. This Report Timer value directly impacts processor load, so use it judiciously.
      • Auto-Helper is a new feature intended to reduce CPU load, it has little impact at the moment.
      • Multi-con is not desired for this style of connection.
      screenshot

  3. Exploring l3_video_em.pl

    1. The options for l3_video_em.pl are available with --help. The most important options for tuning video streaming emulation are:
      • tx_style: bufferfill is default and models present video playback
      • max_tx: this is the starting TX rate. The l3_vid_group script defaults this to 1Gbps, which is unrealistic for common WiFi connections. The script will regularly poll the station side for a TX-RATE value of the station to determine a more realistic upper bound for maximum rate. The more stations that share the same channel, the less realistic this rate becomes. We want to know this to some degree so that we can determine a realistic pause between buffer fills at a given bit rate.
      • buf_size: observation of packet captures indicate that a video plugin on a browser buffers three to four megabytes of video. Between this number and our max_tx rate, we can calculate when to transmit to fill the video buffer before it empties.
      • stream_res: This is a list with broadly agreed upon estimates of video bitrates. When people mention frame-rate, that is just part of the bitrate calculation; audio quality, color depth, and resolution are all part of the bitrate value.
      screenshot
    2. A table of stream resolutions are available when you use the --list option. By default, the l3_vid_group.pl script uses the yt-sdr-1080p30 stream size. That name can be decoded like so:
      yt: YouTube (but any popular stream, really)
      sdr: Standard Dynamic Range color, hdr: High Dynamic Range color
      1080: frame height
      p: progressive, i: interlaced
      30: 30 frames per second; smaller bitrates might be 29.9, 25, or 24 screenshot

    3. Running the command

    4. When we run the l3_video_em.pl command that we copied and pasted into our terminal above, we'll see regular output ever several seconds. Lets discuss whats going on: screenshot
      1. Filling yt-sdr-1080p30 3072KB buffer: tells us our video bitrate, and our buffer size (3MB)
      2. est 0.0503 sec: estimate of how long at 1Gbps filling the buffer will take
      3. empties in 3.0016 sec: playback rate before buffer is fully played.
      4. Random start delay: 3.304sec...: the script is waiting this long before starting. This is so that we avoid a load spike, false detections of constant transmit, and more realistic transmit pattern.
      5. Likely overfill detected This warning appears when you transmit longer than your buffer fill takes. Estimates are inaccurate at the start.
      6. drain_wait_seconds is the computed time between stopping and restarting the next transmission. This is our empty time minus our transmit time.
      7. Actual fill: describes how long transmitting a full buffer took.
      8. dev: the difference between estimated fill time and actual fill time.
      9. Setting max_tx to 360000000: indicates we have detected our RX-Rate for our station was detected, and estimates could be better in range. Estimates are only for an isolated station.

  4. Starting and Stopping Connections

    1. You can use the LANforge GUI Test Groups tab or the l3_vid_group.pl script to start and stop connections.
    2. First, make sure you stations are associated. The scripts will not admin-up your stations.

    3. Using the LANforge GUI

      1. Highlight the Test Group holding the Generic connections. In our example that is the group named sixteen
      2. Press the Start button.
      3. The Generic scripts will control the Layer-3 scripts in the _L3_sixteen group.
      4. Stopping the test group will also stop the Layer-3 connections.

    4. Using the l3_vid_group.pl script

      1. Starting the groups uses the --action start argument:
        ./l3_vid_group.pl --test_grp sixteen --action start
      2. Stopping the groups uses the --action stop argument:
        ./l3_vid_group.pl --test_grp sixteen --action stop

  5. Observing Performance

    screenshot
    1. You can observe the performance of the Layer-3 connections using the Dynamic Reports window.
    2. First, use the Rpt Timer combo box to apply a 500ms report timer to the connection. Press Go to apply
    3. Next, right click the connection and select Dynamic Report (or press D)
    4. Observe the bursts of transmission. screenshot
      1. Use the Adjust button to adjust your time window:
      2. Select 30 for max-time-ago
      3. Select 0 for min-time-ago
      4. Click Apply
Candela  Technologies, 2417 Main Street, Suite 201, Ferndale, WA 98248, USA
www.candelatech.com | sales@candelatech.com | +1.360.380.1618
Facebook | LinkedIn | Blog