Multisession TCP

This task generates TCP traffic in the form of a specified number of parallel TCP sessions. The picture below shows point-to-point multisession TCP:

../../_images/nwpf-multisession-tcp.png

By running a Multisession TCP task, you will gain insight into the performance (available bandwidth) of your network. Hundreds of sessions will often be initiated when using peer-to-peer software or when browsing certain websites with many objects.

Paragon Active Assurance uses a standard Cubic TCP implementation. For more information, see the page on TCP implementation in Paragon Active Assurance.

When a Multisession TCP task starts, the Test Agent will start the selected number of TCP sessions. There is usually no risk in running five or ten simultaneous sessions during production hours; however, if the number of simultaneous sessions goes into the hundreds or thousands, you might overload NAT routers or simple firewalls, or even slow down Internet accesses. Such tests should therefore preferably be conducted outside of production hours.

A client Test Agent can be placed behind NAT, since traffic will be initiated by the client towards the server.

This task works only with IPv4.

Prerequisites

To run multisession TCP measurements you need to have two Test Agents installed. If you haven’t already done the installation, consult the installation guides found here.

Then add a Multisession TCP task to your test or monitor and fill in the mandatory parameters below:

Parameters

See the common parameters page for the following:

  • Parameters that are set on the test step level: Duration, Fail threshold, and Wait for ready.

  • SLA thresholds for monitors: SLA Good and SLA Acceptable.

  • Advanced settings common to all test tasks: Delayed start.

General

  • Server: Test Agent interface that is going to act as server.

    If a NAT router or firewall is present, the server must be located on the outer (public) side.

  • Client: Test Agent interface that will participate in the TCP measurement and exchange traffic with the server.

    The client can be placed behind a NAT, since traffic will be initiated by the client towards the server.

  • Port: TCP server port to which client will send traffic.

    Range: 1 … 65535. Default: 5000.

  • Connections: The number of parallel TCP sessions that will be set up.

    Min: 1. Max: 10,000. Default: 10.

  • Direction: One of: Down (from server to client), Up (from client to server), or Bidirectional (in both directions at the same time).

Thresholds for errored seconds (ES)

  • Number of connections (down direction): Threshold for triggering an errored second for the server-to-client direction. An ES is indicated if the number of connections falls below this value.

    Min: 0. Max: 10,000. Default: 10.

  • Rate (down direction): Threshold for triggering an errored second for the server-to-client direction. An ES is indicated if the data rate (goodput) drops below this value.

    Min: 0.

  • Number of connections (up direction): Threshold for triggering an errored second for the client-to-server direction. An ES is indicated if the number of connections falls below this value.

    Min: 0. Max: 10,000. Default: 10.

  • Rate (up direction): Threshold for triggering an errored second for the client-to-server direction. An ES is indicated if the data rate (goodput) drops below this value.

    Min: 0.

Result metrics

  • Rate (Mbit/s): Total data rate (goodput) measured for all TCP sessions combined.

  • Connected: Number of connected TCP sessions.

  • Active: Number of active TCP sessions.

  • Disconnects: Number of TCP session disconnects.

  • ES total (%): Aggregated errored second (ES) percentage, taking into account all types of error.

  • ES rate (%): Errored second percentage for data rate (up and down directions aggregated).

  • ES connected (%): Errored second percentage for number of TCP connections (up and down directions aggregated).

  • SLA: Service level agreement fulfillment: equal to (100 – ES total) %.