Multisession TCP

The picture shows point-to-point TCP traffic generation from one server Test Agent to one client Test Agent, using a selected number of parallel TCP sessions.

The Client Test Agent can be placed behind NAT, since traffic will be initiated from the client to the server.

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

Netrounds uses a standard TCP implementation.

When you start a Multisession TCP test, the server Test Agent will start the selected number of TCP streams. 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 devices or simpler firewalls, or even slow down Internet accesses. Such tests should therefore preferably be conducted outside of production hours.

Prerequisites

To run multisession TCP measurements you need to have two Netrounds Test Agents installed. If you haven't already done the installation, consult our quick start guides for various types of Test Agents in the section Netrounds Test Agents.

Then create a new Multisession TCP test or monitoring sequence and fill in the mandatory parameters below: 

Parameters

Tests only 

  • Duration (seconds): The duration of this test step in seconds. Min: 30 s. Max: 604800 s. Default: 60 s.
  • Fail threshold (seconds): The maximum number of errored seconds (ES) that may occur without triggering a fail for this test step. Default: 0.
  • Wait for ready: Time to wait before starting the test. The purpose of inserting a wait is to allow all Test Agents time to come online and acquire good time sync. Min: 1 min. Max: 24 hours. Default: "Don't wait", i.e. zero wait time.

General

  • Server: A Test Agent that is going to act as the server side. If NAT or a firewall is present, the server must be located on the outer (public) side.
  • Client: A Test Agent that will participate in the TCP measurement and exchange traffic with the server Test Agent. The client can be placed behind NAT, since traffic will be initiated from the client to the server.
  • Port: TCP server port to which the client will send traffic. Range: 1 ... 65535. Default: 5000.
  • Connections: The number of parallel TCP sessions that will be set up.
  • Direction: One of: Up (from client to server), Down (from server to client), 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.
  • Rate (down direction): Threshold for triggering an errored second for the server-to-client direction. An ES is indicated if the data rate drops below this value.
  • 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.
  • Rate (up direction): Threshold for triggering an errored second for the client-to-server direction. An ES is indicated if the data rate drops below this value.

Advanced

  • Delayed start (s): (Tests only) Time by which to delay the start of the test within a test step. Default: 0 s.

SLA thresholds (monitorings only)

  • SLA Good: Threshold for good fulfillment of service level agreement. Default: 99.95%.
  • SLA Acceptable: Threshold for acceptable fulfillment of service level agreement. Default: 99.5%.

Result metrics

  • Bandwidth, connected streams, active streams, SLA, ES total, ES rate, ES connected
Have more questions? Submit a request

Comments

Powered by Zendesk