On Mon, 15 Dec 2003 10:22:24 +0100, "Anthony G. Atkielski" <anthony@xxxxxxxxxxxxx> said: > "If a host has received an ECN-setup SYN packet, then it MAY send > an ECN-setup SYN-ACK packet. If a host has not received an ECN-setup > SYN packet, then it MUST NOT send an ECN-setup SYN-ACK packet." See? You parsed it. Couldn't have been TOO ambiguous. > "There exists at least one faulty TCP implementation in which TCP > receivers set the Reserved field of the TCP header in ACK packets (and > hence the SYN-ACK) simply to reflect the Reserved field of the TCP > header in the received data packet." > > If reserved is not synonymous with must-be-zero, then why is reflection > of the reserved field "faulty"? Because simply parroting back bits that you don't understand is broken. Read the next sentence or two of the RFC you're citing: Because the TCP SYN packet sets the ECN-Echo and CWR flags to indicate ECN-capability, while the SYN-ACK packet sets only the ECN- Echo flag, the sending TCP correctly interprets a receiver's reflection of its own flags in the Reserved field as an indication that the receiver is not ECN-capable. The sending TCP is not mislead by a faulty TCP implementation sending a SYN-ACK packet that simply reflects the Reserved field of the incoming SYN packet. Now consider the breakage if ECN had defined the bits such that seeing both ECN-Echo and CWR on a SYN+ACK was interpreted as "the other end is ECN-aware", when in fact the other end was clueless. That's why echoing back the bits is faulty - if anybody ever allocates the bits for something, you may be agreeing to do something you didn't intend to. It's the packet-level equivalent of mumbling "Yeah sure, whatever." in response to a question.
Attachment:
pgp00376.pgp
Description: PGP signature