5.2 Dropped or Corrupted Packets

5.2 Dropped or Corrupted Packets

For the use of ECN proposed in this document (i.e., for transport protocols such as TCP where lost packets are an indication of congestion), end-nodes detect lost packets, and the end-nodes' congestion response to a lost packet is at least as strong as the congestion response to a received CE packet. To ensure reliable delivery of the congestion indication of the CE codepoint, the ECT codepoint MUST NOT be set in a packet unless the loss of that packet in the network would be detected by the end-nodes and interpreted as an indication of congestion.

Transport protocols such as TCP do not necessarily detect all packet losses, e.g., the loss of a "pure" ACK packet; for example, TCP would not respond to the loss of an earlier ACK packet by reducing the rate of arrival of later ACK packets. Any proposal to extend ECN-capability to such packets must address issues such as the following: an ACK packet that has been marked with the CE codepoint but is later dropped in the network. We consider this area to remain a research topic, and this document therefore specifies that "pure" ACK packets MUST NOT indicate ECN-capability at this time.

Similarly, if a CE packet is later dropped in the network due to corruption (bit errors), end-nodes should still invoke congestion control, just as TCP would today respond to a lost packet. In any proposal for the network to differentiate between packets dropped due to corruption and packets dropped due to congestion or buffer overflow, this issue of corrupted CE packets must be taken into account. In particular, the widespread deployment of ECN alone is not sufficient for end nodes to be able to interpret packet drops as an indication of corruption rather than congestion.