[tcpm] Draft schepherd write-up for 793bis

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Thu, 10 June 2021 09:02 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 05C963A3ADF; Thu, 10 Jun 2021 02:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Yl3uuDZ21cpw; Thu, 10 Jun 2021 02:02:43 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB443A3ADA; Thu, 10 Jun 2021 02:02:42 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by mail.hs-esslingen.de (Postfix) with ESMTP id 8162F25A16; Thu, 10 Jun 2021 11:02:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1623315760; bh=h8dHOCNn+q9zsMM6sWzJv1xivnscWuh8x7V09tm9zYg=; h=From:To:CC:Subject:Date:From; b=DwaJMfM/GxH2muGv8e2PMiV/PSz5BFIP5E3qaw+GCA2Ex3I+5ch4vBohAHP+OcBMg LGud/oWRq7voANV6ukV30HqzP+KqYJ8xpAjSXLW8Qdz0t3mD0zEH9EEJq8mwaT6Ixa kodKW10klkdC8SaoytoNkCijgUlZyFjJWSAvWLcE=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([]) by localhost (hs-esslingen.de []) (amavisd-new, port 10024) with ESMTP id 4k6ZQO5f2LmQ; Thu, 10 Jun 2021 11:02:39 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 10 Jun 2021 11:02:39 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ( by rznt8202.rznt.rzdir.fht-esslingen.de ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 10 Jun 2021 11:02:38 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.014; Thu, 10 Jun 2021 11:02:38 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "tcpm@ietf.org" <tcpm@ietf.org>
CC: tcpm-chairs <tcpm-chairs@ietf.org>
Thread-Topic: Draft schepherd write-up for 793bis
Thread-Index: Addd1jp8v9JHxVLlQJqEoECOEi9ZnQ==
Date: Thu, 10 Jun 2021 09:02:38 +0000
Message-ID: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/LrXZvl8u_d6GaR0QJVVzQ8-Cfa0>
Subject: [tcpm] Draft schepherd write-up for 793bis
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: Thu, 10 Jun 2021 09:02:48 -0000

Dear all,

As document shepherd, I have started to work on my write-up for 793bis. Given that 793bis may one of the most important deliverables of TCPM, I'd like to ensure that the write-up correctly describes the TCPM consensus. Therefore, I share the text before actually hitting the button.

If the write-up listed below is not accurate or misses important details, please let me know ASAP (on-list of off-list).

I plan to forward 793bis to our AD tomorrow.




1. Summary

The document shepherd is Michael Scharf <michael.scharf@hs-esslingen.de>de>.

The responsible Area Director is Martin Duke <martin.h.duke@gmail.com>om>.

This document specifies the Transmission Control Protocol (TCP) as "bis" document to RFC 793. It obsoletes RFC 793 as well as a several other RFCs that specified additions to RFC 793. It also updates RFC 1122, and it should be considered as a replacement for the portions of that document dealing with TCP requirements.

The purpose of this document is to bring together all the IETF Standards Track changes that have been made to the base TCP functional specification and unify them into an update of RFC 793. The document focuses on the common basis all TCP implementations must support to interoperate. With one exception, protocol modifications compared to RFC 793 are limited to standards-track RFCs or verified erratas, i.e., changes of TCP standards that already have IETF consensus.

RFC 793 and RFC 1122 are ubiquitously implemented Internet Standards. The same applies to 793bis. The TCPM working group requests publication of 793bis on Standards Track. If approved, the document should replace RFC 793 as "STD 7".

2. Review and Consensus

The TCPM working group has worked on this document for more than 6 years, and many TCPM contributors have reviewed the specification during that time. In particular, many TCP implementers have provided detailed comments based on operational experience. The document was relatively stable in the latest versions. During and after WGLC, several comprehensive reviews flagged some open issues that all got resolved.

793bis improves the specification of TCP but it does not modify the TCP protocol. TCP is a complex protocol and even minor wording details in the protocol specification can matter. Given the restriction to TCP changes that already have IETF consensus, there has never been any major controversy about the main content.

Nonetheless, several questions were non-trivial and triggered longer discussions in TCPM. These issues can roughly be subdivided in three categories:

1/ Being published in 1981, RFC 793 defines several protocol mechanisms that have become outdated and may not be implemented at all in a modern TCP/IP stack. However, in some cases the corresponding specification in RFC 793 never got updated or obsoleted and is still formally valid. Appendix A.1 summarizes some of these issues. The TCPM consensus for those cases is to document the issues in 793bis, but not to change the TCP standards. The required changes to the TCP standards should be handled by dedicated, narrow-focused RFCs that would have to reach IETF consensus first. This de-risk strategy ensures that each TCP protocol change can be properly and comprehensively reviewed.

2/ There are some known issues in the standards-track specification of TCP that exist but only matter in corner cases. An example is documented in Appendix A.2. In Internet usage of TCP, these conditions are rarely occurring. Common operating systems include different alternative mitigations, and the standard has not been updated yet to codify one of them. Also, there is no known best approach. Given the lack of practical relevance, the TCPM consensus is to describe these known problems, but not to change the TCP standards in 793bis. Again, these problems could be solved by future, dedicated, narrow-focused RFC that would have to reach IETF consensus first. 

3/ There are known deviations between mandatory-to-implement requirements in the TCP standard and some widely deployed implementations. An example are some details in Section 3.8.3, such as the numerical value in MUST-23. Those cases typically do not affect interoperability with other implementations. The TCPM working group has discussed whether to change the standard in such cases (e.g., downgrade MUST-23 to a SHOULD), but finally refrained from going down that road in 793bis, given the huge installed base with a very large variety of TCP implementations. Similar like in the previous cases, 793bis may get updated by narrow-focused RFCs.

There is one important exception to the decision not to include new guidance in 793bis. The exception is Section 3.8.2 "TCP Congestion Control". TCP congestion control was developed after publication of RFC 793 and the state-of-the-art has evolved a lot as compared to RFC 1122. While there are numerous RFCs that specify TCP congestion control, there is no clear normative guidance on the required minimum in all TCP implementations that would be appropriate for 793bis. However, 793bis cannot just stay silent on congestion control. Given the lack of other applicable wording in existing standards, Section 3.8.2 includes new text and is therefore different to the rest of the document. Section 3.8.2 was comprehensively reviewed by the TCPM working group and in particular by TCP implementers. The section is short and straightforward, and the wording was chosen very carefully to reflect existing TCP standards and operational experience in the Internet. Also, given ongoing research, TCP congestion control will most likely further evolve in future. Section 3.8.2 enables such a further evolution while defining important base requirements.

Running code exists - in billions of TCP/IP stacks. Given the very limited scope of modifications in the 793bis document, all TCP implementations that are already compliant to the TCP standards before publication of 793bis should be compliant to 793bis as well.

The shepherd believes that the 793bis document has unanimous support from the entire TCPM working group.

3. Intellectual Property

The editor has stated that his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. The editor is not aware of any IPR relevant for the base TCP protocol. Since 793bis does not change the TCP protocol, relevant IPR would have to be disclosed already for the existing RFCs included in 793bis.

There is a Cisco IPR disclosure from year 2004 related to the Internet-Draft that resulted in RFC 5961 (https://datatracker.ietf.org/ipr/421/). RFC 5961 is one source of changes included in 793bis. In all places in 793bis where the recommendations from RFC 5961 are mentioned, 5961 is prominently referenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the changes described in RFC 5961 are optional and not mandatory-to-implement.

It has been suggested that the owner of the IPR disclosed in https://datatracker.ietf.org/ipr/421/ updates the IPR disclosure to make clear whether it applies to 793bis, or not.

The TCPM working group is aware of the IPR disclosure related to RFC 5961, which is known already for a long time. The document shepherd has verified on the TCPM mailing list that the TCPM working group is fine with the proposed text in 793bis related to RFC 5961. In the TCPM working group there are no known concerns regarding this IPR disclosure related to an optional mechanism.

4. Other Points

The intended status listed in the document is "Proposed Standard". As all main TCP implementations are supposed to comply with 793bis, the document may fulfill the requirements of an "Internet Standard" according to RFC 2026 and RFC 7127. 

idnits reports some warnings, such as obsolete references. These are all false positives. The document refers to some obsolete documents to provide historical context.

The IANA Considerations in Section 5 include some editorial clean-up of the TCP entries in the IANA registry. The modifications neither change any allocation nor any policy in the IANA registry. These purely editorial changes have been discussed in the TCPM working group for a long time and there is unanimous consensus in TCPM that this clean-up is useful.

All errata to RFC 793 and related RFCs have been considered in this "bis" document.

When Wes started working on a 793bis document in 2013, the document shepherd, as well as many other TCPM contributors, were pretty convinced that writing a 793bis document is an impossible endeavor. Well, after many years, we are proven wrong. Many thanks to Wes as editor!