TCP flow configuration

Introduction

TCP flows have multiple options to finetune the behavior. Although the defaults are a good starting point, this article provides more details on the different parameters.

Name

The Name of the TCP flow template. This needs to be unique from the other TCP and FrameBlasting Flow templates.

Duration

The column configures how long or how much data the TCP flow should transmit. There are two options here:

  • Payload based: The flow will transmit the configured payload and close the connection. This amount is the total data size. The overhead at the TCP layer and below is not omitted.
  • Time based: This method is similar to FrameBlasting templates, the flow will transmit for a fixed duration. How long it should send is configurable from in the Scenario View
Rate limit

This applies an optional rate limit to the TCP flow. Similarly, e.g. video streaming or downloads, this rate limit is applied to the amount of data supplied to the TCP flow.

Unscaled Initial Receive Window

The TCP protocol uses this parameter to initialize the Receive Window. The Maximum Receive Window is 65535 bytes. The TCP Window is the amount of outstanding data (unacknowledged by the recipient) that can remain in the network. After sending that amount of data, the sender stops and waits for acknowledgement back from the receiver that it has gotten some of it. As such, this value together with its scaling factor is probably the single most important setting in tuning broadband internet connections.

Window scaling

Enable or disable window scaling here. The TCP window scale option is an option to increase the TCP receive window size above its maximum value of 65535 bytes.

Reeivers window scale value

Here you can choose which window scale value should be used. The following options are possible:

  • 0 (multiply with 1)
  • 1 (multiply with 2)
  • 2 (multiply with 4)
  • 3 (multiply with 8)
  • 4 (multiply with 16)
  • 5 (multiply with 32)
  • 6 (multiply with 64)
  • 7 (multiply with 128)
  • 8 (multiply with 256)
Slow start threshold

This is a low-level parameter of the TCP algorithm. Throughput grows exponentially until this value, afterwards on speeds increments linearly and thus slow. Increasing this parameter results in steeper, faster throughput gains, but often also more instability. Reverse, a low-value results in TCP flow that slowly increases throughput.

HTTP Request Method

Choose which method should be used to get the payload from the server to the client. The following options are possible:

  • AUTO: The GUI will choose the appropriate method (GET or PUT). When the source ByteBlower Port of a TCP Flow is NAT-ed, an HTTP PUT command will be used, otherwise, an HTTP GET command will be used.
  • PUT: The source ByteBlower Port will initiate the data transfer by executing an HTTP PUT command. The data will be ”uploaded” from the source to the destination.
  • GET: The destination ByteBlower Port will initiate the data transfer by executing an HTTP GET command. The data will be ”downloaded” from the source to the destination.
L4S (since v2.22)

Enable support for L4S on both the server and the client port. L4S reduces latency and avoids retransmissions. 

See:  L4S Testing with ByteBlower GUI | Support Portal (excentis.com) for more information on L4S and testing L4S with ByteBlower.

Congestion Algorithm

The algorithm used by the TCP flow to deal with congestion. See 📄 TCP Congestion Avoidance Algorithms

Client and Server ports

The TCP-ports used by the flow template. When left to automatic, the ByteBlower will pick an available port to set up the flow. In general, this is the preferred option.