[tcpm] History of ECN's use of TCP header bits vs. TCP option
Bob Briscoe <ietf@bobbriscoe.net> Mon, 25 November 2019 12:55 UTC
Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1B812013A for <tcpm@ietfa.amsl.com>; Mon, 25 Nov 2019 04:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A_aQg5_97zg for <tcpm@ietfa.amsl.com>; Mon, 25 Nov 2019 04:55:55 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B4912009C for <tcpm@ietf.org>; Mon, 25 Nov 2019 04:55:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: Subject:From:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=iou7+nmiveZ5FVGTWYnQcVw/ip7XYMXqbznVIOmC11I=; b=1upBZnSnhZRBk3ZfcRWnn8W+bi 0WETHNlDBg8VczSOkpEP3kJkTP8qzFWF/NyFfh7RqoKx0JeJRMOpt3i94l/SHtU3SF7WtHHvDtoLS iHQfuo0HXOlqxnlyNOf4pbtqtywwNJSnO+Fnn82tuYtHBYNZ+apDF+NMvnGlly+a43hravhsPtJtq VyTBVZvMC1p/uyU3aMSQRq9WvxNQvO6ftnqSmHZVOjAhneWztfyFHbdefCScfiLxSNfz3OpRtDcHw I+R5UH60zPexg7Ws88aZxUwlwKmN6XBnrXR42FsVc7tsSsDJKdFWvNKGTZR8UEtuntuGFu8rAoKnH 1oftnCHw==;
Received: from [31.185.128.31] (port=47204 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <ietf@bobbriscoe.net>) id 1iZDuC-00024Q-AP; Mon, 25 Nov 2019 12:55:52 +0000
To: tcpm IETF list <tcpm@ietf.org>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <28cdf725-546f-6d0f-516e-1c8f19a00749@bobbriscoe.net>
Date: Mon, 25 Nov 2019 12:55:51 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------CC9C83B569F8CFCB643623C6"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/bd8nFFaVn8CeyuYzYCgcfi51o9I>
Subject: [tcpm] History of ECN's use of TCP header bits vs. TCP option
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2019 12:55:58 -0000
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/
- [tcpm] History of ECN's use of TCP header bits vs… Bob Briscoe
- Re: [tcpm] History of ECN's use of TCP header bit… Jonathan Morton
- Re: [tcpm] History of ECN's use of TCP header bit… Bob Briscoe