[tcpm] History of ECN's use of TCP header bits vs. TCP option

[Bob Briscoe <[e-mail]>]

tcpm-ers,

In Appendix B.1 of the AccECN draft 
<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#appendix-B.1> 
it says:

    It is not recorded why ECN originally used this [header flags]
    approach instead of the more orthodox use of a TCP option.

Having dug into the history, I propose we change this to:

ECN originally used header flags rather than a TCP option because it was 
considered more efficient to use a header flag for 1 bit of feedback per 
ACK, and this bit could be overloaded to indicate support for ECN during 
the handshake. During the development of ECN, 1 bit crept up to 2, in 
order to deliver the feedback reliably and to work round some broken 
hosts that reflected the reserved flags during the handshake.

==History==
While checking through RFC3168, in the acknowledgements I noticed it 
says "we would like to thank Kenjiro Cho for the proposal for the TCP 
mechanism for negotiating ECN-Capability," so I asked Kenjiro what the 
history was. Here's the outcome, following some further digging via the 
archival section <https://www.icir.org/floyd/ecn.html#archival> of Sally 
Floyd's ECN page.

==Exec summary==
A TCP header flag was uncontroversial for 1-bit TCP feedback of 
Congestion Experienced at the IP layer, but a TCP option was not ruled 
out. Initially, the authors imaged a TCP option to negotiate the ECN 
capability. But when Kenjiro implemented it, he suggested overloading 
the feedback flag for each peer to communicate their ECN-capability 
during the TCP handshake as well. This made the whole thing simpler 
without having to assign any additional options or bits so it was 
quickly adopted. 1 bit crept up to 2 when reliable delivery of feedback 
needed to be solved. Then the second bit was overloaded during the 
handshake as well, to work round a bug in certain TCP implementations 
that reflected unrecognized header bits.

==More detail==
In the -00 ECN draft <https://tools.ietf.org/html/draft-kksjf-ecn-00> 
(Nov'97), the authors proposed a TCP header flag called ECN-Notify for 1 
bit of ECN feedback per ACK.

On 19-Nov-1997, in this email to Curtis Villamizar about the ECN I-D 
<https://www.icir.org/floyd/email/sf.97nov19A.txt>, Sally and K. K. 
Ramakrishnan explained that they had not ruled our the alternative of a 
TCP Option:

(The main decision to be made
is whether to allocate an ECN-Notify bit in the TCP header (as recommended
in our draft) instead of using an ECN option to carry the ECN notification
from the receiver to the sender.  Not too earth-shattering...)


At the time, the authors were imagining a host would declare that it was 
ECN-capable, either using the ECN-capable bit at the IP layer, or using 
a TCP option. On 23-Jan-1998, Kenjiro explained to Sally how his 
experimental implementation overloaded the ECN-Notify flag at the TCP 
layer for initialization as well as feedback. The authors quickly 
adopted this, because it made the whole thing simpler without having to 
assign any additional options or bits. And the two functions of the bit 
didn't conflict, because it was realized that there wasn't a need to 
echo ECN on the SYN-ACK because, while the client didn't know whether 
the server was ECN-capable, it was safer not to make the SYN ECN-capable.

On 29 Jan-1998, a few days after Kenjiro had suggested this, Sally 
posted this txt file recording that decision 
<https://www.icir.org/floyd/ECN-TCP.txt>. By then, Sally had also 
introduced stickiness of the ECE flag (acknowledging Kevin Fall for the 
idea) and added a new CWR flag to acknowledge it. This was how ECN stood 
in Jul'98 when draft-kksjf-ecn-01 was published.

Then, by the -02 version of the ECN draft in Sep'98, the broken hosts 
that reflect the TCP flags had been discovered, and, building further 
onto Kenjiro's solution, both the ECE and the CWR flags were used on SYN 
and SYN-ACK to indicate ECN-capability, but in different combinations to 
distinguish the SYN-ACK from a broken reflection of the SYN.



Bob



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/