6.1.2 The TCP Sender
6.1.2 The TCP Sender
For a TCP connection using ECN, new data packets are transmitted with the ECT codepoint set in the IP header. ECT(0) SHOULD be used when only a single ECT codepoint is needed by the sender on all packets of a TCP connection. If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK packet with the ECN-Echo flag set in the TCP header), then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should be treated just as a congestion loss in non-ECN-capable TCP. That is, the TCP source halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh". The sending TCP SHOULD NOT increase the congestion window in response to the receipt of an ECN-Echo ACK packet.
TCP should not react to congestion indications more than once for every window of data (or, more loosely, for every round-trip time). That is, the TCP sender's congestion window should be reduced only once in response to a series of dropped and/or CE packets from a single window of data. In addition, the TCP source should not decrease ssthresh if it has been decreased within the last round trip time. However, if a retransmitted packet is dropped, the source TCP interprets this as a new instance of congestion.
After the source TCP reduces its congestion window in response to a CE packet, incoming acknowledgements can allow the "clocking out" of outgoing data packets, as allowed by the reduced congestion window. If the congestion window contains only one MSS (maximum segment size), and the sending TCP receives an ECN-Echo ACK packet, the sending TCP should in principle still halve its congestion window. However, the congestion window has a lower limit of one MSS. If the sending TCP were to continue sending with a congestion window of 1 MSS, this would result in transmissions of one packet per round-trip time. It is necessary to reduce the sending rate of the TCP sender even further when an ECN-Echo packet is received when the congestion window is 1. We use the retransmission timer as the mechanism for further reducing the rate in this case. Therefore, when an ECN-Echo packet is received when the congestion window is 1, the sending TCP MUST reset the retransmission timer. The sending TCP can then send a new data packet only when the retransmission timer expires.
When an ECN-capable TCP sender reduces its congestion window for any reason (because of a retransmission timeout, a Fast Retransmit, or in response to an ECN notification), the TCP sender sets the CWR flag in the TCP header of the first new data packet sent after the window reduction. If that packet is dropped in the network, the sending TCP will have to reduce the congestion window again and retransmit the dropped packet.
We ensure that the "Congestion Window Reduced" information is reliably delivered to the TCP receiver. This is because if the new data packet carrying the CWR flag is dropped, the TCP sender will have to reduce its congestion window again and send another new data packet with the CWR flag set. Thus, the CWR bit in the TCP header SHOULD NOT be set on retransmitted packets.
When a TCP data sender is ready to set the CWR bit after reducing the congestion window, it SHOULD set the CWR bit only on the first new data packet that it transmits.
[Floyd94] discusses TCP's response to ECN in more detail. [Floyd98] discusses validation tests from the ns simulator, which illustrate various ECN scenarios. These scenarios include the following: an ECN followed by another ECN, a Fast Retransmit, or a Retransmit Timeout; a Retransmit Timeout or Fast Retransmit followed by an ECN; and a congestion window of one packet followed by an ECN.
TCP follows the existing algorithms in response to incoming ACKs, multiple duplicate acknowledgements, or retransmission timeouts for sending data packets [RFC2581]. When TCP receives an ACK packet with the ECN-Echo bit not set, it follows normal procedures for increasing the congestion window as well [RFC2581].