Investigating the LTM TCP Profile: ECN & LTR

1. Nagle's Algorithm
2. Max Syn Retransmissions & Idle Timeout
3. Windows & Buffers
4. Timers
5. QoS
6. Slow Start
7. Congestion Control Algorithms
8. Acknowledgements
9. Extended Congestion Notification & Limited Transmit Recovery
10. The Finish Line

Normal TCP communication consists of a client and a server, a 3-way handshake, reliable data exchange, and a four-way close.  With the LTM as an intermediary in the client/server architecture, the session setup/teardown is duplicated, with the LTM playing the role of server to the client and client to the server.  These sessions are completely independent, even though the LTM can duplicate the tcp source port over to the server-side connection in most cases, and depending on your underlying network architecture, can also duplicate the source IP.

Extended Congestion Notification

The extended congestion notification option available in the TCP profile by default is disabled.  ECN is another option in TCP that must be negotiated at start time between peers.   Support is not widely adopted yet and the effective use of this feature relies heavily on the underlying infrastructures handling of the ECN bits as routers must participate in the process.  If you recall from the QoS tech tip, the IP TOS field has 8 bits, the first six for DSCP, and the final two for ECN. 

Routers implementing ECN RED (random early detection) will mark ECN-capable packets and drop  Not-ECT packets (only under congestion and only by the policies configured on the router).  If ECN is enabled, the presence of the ECE (ECN-Echo) bit will trigger the TCP stack to halve its congestion window and reduce the slow start threshold (cwnd and ssthresh, respectively...remember these?) just as if the packet had been dropped.  The benefits of enabling ECN are reducing/avoiding drops where they normally would occur and reducing packet delay due to shorter queues.  Another benefit is that the TCP peers can distinguish between transmission loss and congestion signals.  However, due to the nature of this tightly integrated relationship between routers and tcp peers, unless you control the infrastructure or have agreements in place to its expected behavior, I wouldn't recommend enabling this feature as there are several ways to subvert ECN (you can read up on it in RFC 3168).

Limited Transmit Recovery

Defined in RFC 3042, Limited Transmit Recovery allows the sender to transmit new data after the receipt of the second duplicate acknowledge if the peer's receive window allows for it and outstanding data is less than the congestion window plus two segments.  Remember that with fast retransmit, a retransmit occurs after the third duplicate acknolwedgement or after a timeout.  The congestion window is not updated when LTR triggers a retransmission.  Note also that if utilized with selective acknowledgements, LTR must not transmit unless the ack contains new SACK information.  In the event of a congestion window of three segments and one is lost, fast retransmit would never trigger since three duplicate acks couldn't be received.  This would result in a timeout, which could be a penalty of at least one second.  Utilizing LTR can significantly reduce the number of timeout based retransmissions.  This option is enabled by default in the profile.