Tuning the TCP Profile: Part Three

Since February I've walked you through most of the TCP profile configuration page. This month I'll finish this tour. As I said previously, when I refer to "performance" below, I'm referring to the speed at which your customer gets her data. Performance can also refer to the scalability of your application delivery due to CPU and memory limitations, and when that's what I mean, I'll say so.

Congestion Control

Appropriate Byte Counting increases the congestion window based on the number of bytes received rather than the number of acks received. If there are multiple acks per full-size packet, ABC will grow the congestion window less agressively; if the remote host is using delayed acks, ABC will grow more agressively. In any case, ABC means TCP is using a more genuine estimate of the demonstrated link capcity.

Congestion Metrics Cache deserves a whole article to explain in its intracacies. However, it basically stores historic congestion data from previous connections with that IP address. In general, your connections to converge more quickly on the maximum sustainable data rate, although in paths with low bandwidth-delay products and large queues, that may not be the case. The Congestion Metrics Cache Timeout allows you to define the length of time that old congestion data is likely to be useful (default 600 seconds).

Congestion Control is also an extensive subject. It allows selection of a congestion control algorithm for sending data. Except for the F5-proprietary "Woodside" congestion control, all of these have their designs described either in an IETF document or in a peer-reviewed paper. In general, we'd recommend Woodside -- especially if your path is partly wireless -- and use Highspeed in cases where the path incurs a total delay of only a couple of milliseconds.

Delay Window Control is a means of adding delay awareness to congestion control protocols, so that they back off if the current sending rate appears to be filling queues instead of unlocked unused bandwidth. In all honesty, it's probably better to use a congestion control algorithm that has delay sensitivity built-in, like Illinois or Woodside.

Explicit Congestion Notification allows routers to mark packets, instead of dropping them, during periods of congestion. TCP adjusts its send rate as if the packet were lost, which in theory would allow the internet to largely avoid packet losses. In practice, most routers are not configured to support ECN marking.

The Initial Congestion Window Size controls the amount of data TCP will send at connection start, if there is no congestion metrics cache entry. In practice, large initial cwnd values will simply limit the initial burst to the advertised receive window of the remote host. As internet speeds increase, typical initial cwnds are creeping upwards. It can make a big difference in the number of round trips necessary to deliver small files. However, on a congested path a large initial window may cause multiple packet losses. Slow Start is the normal way that TCP operates. Turning it off means places no restrictions on send rate except the remote host's advertised receive window, effectively setting initial cwnd to infinity. Disabling slow start is not recommended except in private LANs where congestion is not an issue.

Packet Loss Parameters are appropriate in situations where there is a known probability of packet losses not due to congestion effects. When enabled, TCP will retransmit many lost packets without reducing its sending rate.

Rate Pacing spreads out packet transmissions over time instead of sending all at once and overloading the queue, using a rate based on detected packet losses. It reduces queue overflow without having significant downsides. Rate Pace Max Rate places a ceiling on the computed rate. The max rate should not be any more than the maximum bandwidth of your path.

Timestamps are a nearly universally adopted extension to TCP. F5's delay-based congestion control protocols, including Illinois and Woodside, don't use timestamps for round-trip-time estimation, so this setting has no effect on effective data transfer. However, timestamps may still be useful for the remote host, so we strongly recommend supporting this option.

Loss Detection and Recovery

Limited Transmit Recovery and Selective ACKs are extremely common TCP extensions that take appropriate opportunities to be more aggressive, and better determine which packets are missing, respectively. Selective ACKs consume slightly more resources per connection. D-SACK uses the SACK framework to help TCP identify duplicate packets; BIG-IP doesn't really need or use this info, but the remote host might.

I wrote about Early Retransmit and Tail Loss Probe last year.

Maximum Syn Retransmissions and Maximum Segment Retransmissions tell BIG-IP how many times to keep trying on a connection it hasn't heard from. They represent a tradeoff between connection success rate and resources devoted to dead remote hosts. The concisely named Initial Retransmission Timeout Base Multiplier for SYN Retransmission is just the timeout applied to the first SYN or SYN-ACK packet; again, it trades off success against resources.

Selective NACK is an F5-specific option to enhance communication between BIG-IPs. It is not recommended you enable this option unless directed by F5.

Security and MPTCP

IP ToS and Link ToS set bits in IP and link headers sent for this connection to execute various preferential forwarding behaviors.

Hardware SYN Cookie Protection, which you will only see on platforms that support it, uses hardware to handle the computational load of responding to SYN flood attacks.

SYN Cookie White List is useful in cases where packets from the server do not pass through the BIG-IP. Otherwise, just leave it disabled.

MD5 Signature and MD5 Signature Passphrase support RFC 2385, a security mechanism for Border Gateway Protocol (BGP).

Multipath TCP is another rich subject I can't treat fully here. If your clients are so enabled, MPTCP allows connections to survive an IP address change at your client.

**************

That concludes our pass through the TCP profile. If there are any features you'd like to see get the full-article treatment, please say so in the comments.

 

Published Mar 25, 2016
Version 1.0
  • Hi Martin,

     

    this kb article states that "The Woodside algorithm relies on timestamps to determine transmission. If timestamps are not available in your network, avoid using Woodside.". In this article though, you mentioned that Woodside does not rely on timestamps for rtt estimation.

     

    I am not sure what "determine transmission" really means in that sentence but is it really necessary for the server/client to actively set this option in the TCP packet so that Woodside can do its job correctly?

     

  • Hi RicR,

     

    The KB article is incorrect. Timestamps are not necessary to run Woodside. We'll file a ticket to fix the article

     

    Thanks