Use the Client Network tab to configure the client network characteristics that you want to emulate. For example, you can choose to resolve domain names in Action lists for every simulated user request, and specify various TCP/UDP parameters and port ranges.
The Client Network tab contains the following panes:
| Field | Description | ||
|---|---|---|---|
| Miscellaneous Parameters: | |||
| Enable Round Robin DNS | Select to resolve domain names in the Action lists for every simulated user request. If the Action list contains hostnames (fully qualified domain names) instead of IP addresses, Avalanche queries the DNS server and caches the result for future transactions. Because Avalanche queries the DNS server for every transaction, it generates a great amount of UDP traffic out of the administration interface. You can use this as a quick way to test the performance and scalability of DNS servers. A test stops if the DNS server cannot resolve a particular host in an Action list entry. | ||
| IGMP Version | The version of the Internet Group Management Protocol (IGMP) that controls multicast channels for IPv4. This version will be used in Video On Demand (VoD) Multicast tests. The available versions are 2 and 3. | ||
| Suppress IGMP/MLD Reports |
Select to reduce the number of join report messages sent from the client. The Avalanche IGMP and MLD protocols will send join report messages twice to the multicast gateway initially, but will not actively send join report messages without receiving a query message from the multicast gateway. If a query message is received from the gateway, only one join report message will be sent. If deselected, Avalanche will send join report messages to the multicast gateway continuously, triggered at automatic intervals, without receiving a query message from the multicast gateway. This is useful when some multicast gateways do not send query messages for long periods of time, in which case, the multicast gateway will not receive join report messages for long periods, and will stop the multi-stream transmission. |
||
| Fairness Threshold bytes/sec/connection | This value is the throughput (fairness) threshold per connection that you expect when testing a DUT/SUT (device/system under test) that performs bandwidth management, traffic shaping, or QoS guarantee. You specify the fairness threshold per connection in bytes/second. All data sent and received inside a particular connection is recorded. The rate for every connection is calculated as follows: (bytes sent + bytes received) / connection lifetime. This calculation is based on TCP bandwidth, that is, the TCP data minus any Ethernet, IP, or TCP headers. The result determines if a connection is below or above the specified threshold. For example, if a DUT is configured to prevent a connection from exceeding 2048 bytes/second, you would enter a fairness threshold of 2048. The number of connections that exceeded this throughput threshold would appear in the Fairness tab in the client real-time statistics. | ||
| IP Fragment Reassembly Timer | The maximum time in milliseconds that the IP stack waits for subsequent fragments after receiving the first fragment of an IP datagram. If the entire datagram has not been received by this time, the entire datagram is discarded. | ||
| TCP Parameters: | |||
| IPv4/IPv6 Maximum Segment Size (MSS) bytes |
The maximum TCP segment size (in bytes) that the TCP stack receives (data only, excluding headers). The send segment size is determined by the communicating peer. The default maximum segment size (MSS) is 1460 for IPv4 and 1440 for IPv6. The valid range is 6 to 9176 for IPv4, and 6 to 9156 for IPv6.
|
||
| Override Remote Device MSS |
Select to specify the maximum TCP segment size (in bytes) to be used for sending TCP data. This overrides the MSS value announced by the remote device. (If deselected, the send segment size is determined by the remote device.) The specified value must be between 6 and 9176, and the default value is 1460.
|
||
| Receive Window bytes | The receive window in which you want the TCP stack to send TCP segments. The receive window informs the peer how many bytes of data the stack is currently able to receive. The supplied value is used in all segments sent by the stack. The valid range is 0 to 1073741823. | ||
| Delayed ACKs | Select to cause the TCP stack to implement the Delayed ACK strategy, which attempts to minimize the transmission of zero-payload ACK packets. Acknowledgements will be deferred and should be piggybacked on top of valid data packets. If successfully deferred, these acknowledgements are free, in the sense that they consume no additional bandwidth. | ||
| Delayed ACK Timeout ms | If you select Delayed ACKs, use this timeout value to specify the maximum time the TCP stack waits to defer ACK transmission. If this timer expires, the stack transmits a zero-payload acknowledgement. | ||
| Delayed ACK Bytes | If you select Delayed ACKs, use this value to specify the maximum amount of TCP payload (in bytes) that the stack accepts before ACK transmission. Once this value is met, the stack transmits a zero-payload ACK packet acknowledging the received data. | ||
| Timestamps Option | Select to add a TCP timestamp to each TCP segment and calculate RTT (Round Trip Time) for each TCP segment. If selected, Avalanche sends TCP segments with the Timestamps option (TSopt), checks the TSopt received, calculates RTTs, and generates statistics. If deselected, Avalanche sends TCP segments without the TSopt, and discards the TSopt received.
|
||
| Enable Push Flag | Select to set the TCP PSH (push) flag in all TCP packets. This flag causes buffered data to be pushed to the receiving application. If deselected, the PSH flag is not set in any TCP packet.
|
||
| Enable Congestion Control | Select to invoke the TCP stack's congestion control mechanism, and select one of the following algorithms:
|
||
| Initial Congestion Window | The TCP Initial Congestion Window (ICW) specifies the amount of TCP payload to send initially in the TCP slow-start process. This process is part of the TCP congestion control strategy to avoid causing network congestion. Specify a value between 1 and 64. This value gets multiplied by the MSS value to derive the ICW in bytes.
|
||
| Override Internal Timeout Calculation ms | Select to override the TCP stack calculation of the retransmission timeout value and replace it with the value that you enter (in milliseconds). Avalanche uses this value for the first transmission of a particular data or control packet and doubles it for each subsequent retransmission. | ||
| Retries | The number of times a timed-out packet is retransmitted before aborting further retransmission. If the client does not receive a response after the configured number of retries have been attempted, the error is logged in the results CSV file as a TCP timeout when a SYN or FIN is sent, and no SYN/ACK or FIN/ACK from the server is received. | ||
| Inactivity Timer ms |
The amount of time that passes before Avalanche resets (the stack sends an RST segment) and abandons inactive connections. A value of 0 disables the timer. You must disable this timer before each streaming test.
|
||
| Fin Ack Timer ms |
The amount of time that a SimUser waits after it finishes its actions and before it directly breaks all of its TCP connections (that is, the time to wait to receive the LAST_ACK message for a FIN request). A value of 0 disables the timer.
|
||
| Piggyback Get Requests | Select to enable piggybacking the HTTP GET request ACK packet with the server's SYN/ACK packet (available only for HTTP). The behavior will be as follows:
SYN -> <-SYN/ACK ACK with GET -> If you don't select this option, the default behavior for a TCP handshake from Avalanche is as follows:SYN -> <-SYN/ACK ACK to SYN/ACK -> GET/POST -> |
||
| Piggyback TLS ClientHello | Select to enable piggybacking the TLS ClientHello message ACK packet with the server's SYN/ACK packet. The behavior will be as follows:
SYN -> <-SYN/ACK ACK with ClientHello -> If you don't select this option, the default behavior for a TCP handshake from Avalanche is as follows:SYN -> <-SYN/ACK ACK to SYN/ACK -> ClientHello -> |
||
| Enable TCP Port Randomization | Select to enable source TCP port number assignment in a random order, within the range specified by the System Port Range fields below. If deselected, the TCP port numbers are assigned sequentially. This option applies only if you have more than one URL in your Actions list, and HTTP 1.1 Persistence is not enabled.
|
||
| Enable TCP Port Reuse | Select to enable source TCP port reuse with freed ports taking precedence. That is, when a TCP connection terminates, the freed source port gets reused for the next connection for the IP address. If deselected, the source ports within the entire System Port Range get used first, prior to any freed ports.
|
||
| Connection Termination With FIN | Select to close the TCP connection as soon as it completes all transactions for the connection, using FIN (CloseConnection) to complete the closure. (Generally, the server-side TCP close connection method is used.) | ||
| UDP Parameters: | |||
| Enable IPv4 UDP Checksum | Select to enable the checksum calculation in the UDP header of IPv4 packets sent by the client.
|
||
| System Port Range Fields: | |||
| Lower Bound |
The lower bound for source port number assignment (TCP or UDP). The default value is 1024.
|
||
| Upper Bound | The upper bound for source port number assignment (TCP or UDP). The default is value 65535. | ||
| Zero Fill Settings: | |||
| Zero Fill | Select to fill inconsequential data in TCP packets with zeros to speed up checksum processing, and thus improve performance.
|
||