To: end2end-interest@ISI.EDU cc: Mark Handley , Jitendra Padhye Bcc: From: Sally Floyd Subject: Negotiating ECN-Capability in a TCP connection Date: Mon, 02 Oct 2000 17:06:51 -0700 Sender: floyd@elk.aciri.org This is a follow-up to some earlier email about problems with some faulty network equipment that either blocks SYN TCP packets which have the CWR and ECE TCP bits set to indicate ECN-Capability, or which respond to such SYN packets with a Reset. Recent studies indicate that such bugs may affect a small but significant fraction of popular web sites. The TBIT web page at "http://www.aciri.org/tbit/" has a pointer to some of these studies. This note outlines a procedure that ECN-Capable TCP implementations may wish to use in this case to ensure connectivity. We are not suggesting that TCP implementations should be required to use this procedure. However, if implementators wish to implement a work-around for this problem, then we believe the procedure below is safe and may increase the likelihood of ECN being enabled. --------------------------- [Note: Host A=client, Host B=server] Procedures for sending the SYN packet: * Host A sends the initial SYN with CWR and ECE set, to indicate ECN-capability. * If Host A gets a RST in response to the initial SYN which had CWR and ECE set, then Host A resends a SYN (and any subsequent SYN retransmissions) with CWR and ECE cleared. * If Host A does not get any reply to its initial SYN (which had CWR and ECE set) within the normal SYN retransmission timeout interval, then Host A resends the SYN and any subsequent SYN retransmissions with CWR and ECE cleared. ----------------------------- Procedures for using ECN: * If Host A has received only one SYN-ACK, without ECE set, then Host A MUST assume that Host B is not ECN-capable, and so Host A does not set ECT on any data packets it sends to Host B. * If Host A has sent at least one SYN packet with CWR and ECE set, and received at least one SYN-ACK packet with ECE set and CWR cleared, then Host A SHOULD assume that Host B is ECN-Capable. In this case, Host A MAY set the ECT bit on data packets. (Host A is never required to set the ECT bit on any data packets.) Similarly, if, in this case, Host A receives TCP data packets with ECT and CE bits set in the IP header, then Host A processes these packets as specified for an ECN-capable connection. * If Host A has sent at least one SYN packet with CWR and ECE set, and has never received a SYN-ACK packet with ECE set and CWR cleared, but has received a SYN-ACK packet with ECE cleared, then there is possible ambiguity as to whether Host B has seen a SYN negotiating ECN or not. Thus it is possible in this case that Host B still believes Host A is ECN capable. Thus, Host A still could legitimately receive TCP data packets with ECT and CE bits set in the IP header. If, in this case, Host A receives TCP data packets with ECT and CE bits set in the IP header, then Host A processes these packets as specified for an ECN-capable connection. Host A MUST NOT use the reception of such data packets as an implicit signal that Host B is ECN-capable. Justification: The following is a possible scenario: Host A: Sends SYN with CWR and ECE set. Host B: Sends SYN/ACK with ECE set and CWR cleared, packet is dropped. Host A: Sends SYN with CWR and ECE cleared. Host B: Sends SYN/ACK with ECE cleared, but retains memory that A is ECN-capable. Thus, it is possible that Host A sends at least one SYN packet with CWR and ECE set, and does not receive a SYN-ACK packet with ECE set and CWR cleared, but subsequently receives a legitimate TCP data packet with the ECT and CE bits set in the IP header. --------------------------------- Procedures for setting the CWR TCP bit: * For a TCP host that sets the IP ECT bit in data packets, and therefore might receive ECN-Echo feedback from the far end, the CWR TCP bit is set to inform the far end that the congestion window has been reduced, and that therefore the ECN-Echo feedback no longer has to be sent. Thus, if a host ever sets the ECT bit on a packet in a connection, then that host must correctly set/clear the CWR TCP bit on all subsequent packets in the connection. Summary ------- We note that this procedure does not eliminate incentives for network operators to fix malfunctioning firewalls or web servers that block TCP SYN packets advertising TCP flags negotiating ECN-Capability. Even with the procedure suggested in this note, such network equipment would result in significant delays for ECN-capable TCP hosts. It is just that this procedure would allow connectivity eventually to be established. The procedure in this note will no longer be necessary when there is sufficiently little faulty equipment in the network blocking SYN packets from ECN-Capable hosts. This procedure is consistent with the following ECN semantics: If Host A sends at least one SYN or SYN-ACK packet advertising ECN-Capability, then Host B, at the other end of the connection, can assume that Host A is ECN-Capable, and Host B is free to send data packets with the ECT bit set. (This does not eliminate the requirement that Host B also send at least one SYN or SYN-ACK packet advertising ECN-Capability.) Thus, the role of advertising ECN-Capability is not to tell the other end that the host is going to set the ECT bit in all packets in a connection - this is not the case. The main role of advertising ECN-Capability is to inform the other end that the host is able to correctly process incoming packets with the IP ECT and CE bits set. - Sally, Mark, and Jitu This note is in part the result of off-line discussions with a number of other people. I would note that we haven't yet implemented this procedure that we are proposing... ---------------------- Addition on October 4, 2000: Accepting SYN/ACKs: If Host A uses the modified procedure above, and sends both a SYN with CWR and ECE set, and a retransmitted SYN with both CWR and ECE cleared, then Host A MUST accept either a SYN/ACK with ECE set and CWR cleared, or a SYN/ACK with CWR and ECE cleared. This means that if Host B receives at least one SYN packet with CWR and ECE set, then Host B may, if it chooses, send all subsequent SYN/ACK packets for that connection with ECE set and CWR cleared. However, if there is a broken firewall in the reverse direction that incorrectly blocks SYN/ACK packets with ECE set, this means that the connection might never be successfully established. Thus, for hosts that would like to be robust against such faulty behavior, we recommed the following modified procedure for sending SYN/ACKs: Modified procedure for sending SYN/ACKs at an ECN-Capable host: * In response to a SYN with CWR and ECE set, Host B may send a SYN/ACK with ECE set and CWR cleared. * In response to a SYN with both CWR and ECE cleared, Host B should send a SYN/ACK with both ECE and CWR cleared, even if it has previously received a SYN with CWR and ECE set for that connection. This is to provide robustness against faulty equipment in the network.