ECN, TCP, and congestion on the ACK-path: ---------------------------------------- >I have one general question, namely whether >pure acks have the ECN-aware bit set. Becaue they're *not* actually >adaptive themselves. For the initial TCP implementations with ECN, pure acks should not have the ECN-capable bit set. This is because it is not completely obvious what the TCP sender should do in response to congestion on the ack-path. Cut its window in half? Or better, tell the receiver to send fewer acks, and to begin rate-pacing in compensation. For current non-ECN-capable TCP implementations, the drop of a single pure ack packet does not generally result in a decrease in the subsequent arrival rate of ack packets. For current TCP implementations, if a single ack packet is dropped, the TCP sender will refrain from whatever window increase it would have made if that ack packet had arrived, and when a subsequent ack arrives at the sender, the sender will send a burst of back-to-back packets. Thus, for current TCP implementations, the main effect of a dropped ack packet is to prevent an increase in the TCP sender's congestion window, and to increase the burstiness of the sending process. One benefit of ECN for TCP is that it opens the door for explicit congestion control on the ack path. This is likely to be particularly useful for TCP connections over asymmetric paths, where the "return" path is relatively low-bandwidth. But the ECN draft leaves the details for future research.