Re: [tcpm] Draft schepherd write-up for 793bis

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Thu, 10 June 2021 16:23 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54DC3A45AB; Thu, 10 Jun 2021 09:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoLC0pGGX-J3; Thu, 10 Jun 2021 09:23:50 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBA93A45A9; Thu, 10 Jun 2021 09:23:49 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 4D24025A20; Thu, 10 Jun 2021 18:23:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1623342227; bh=rPY7DRBIKbjhHVuXb7BXk+mgLPYxuJOkwRS06Z9qvS4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ppKEp3LQOy9dSFmLgWo5H8+dBEH03clbRAH9qMGYcbZpfgGlOuB5Xs0tPDZ7TPLCd kApHuhJyT92DhZNWl7tckgvFnH+dO0ImNS9xwTmJBDh50XWh2v4XyCJ2S4zWEPr3HS MT2Z2gAzTKlD+G9094335iZoL+VIij97lU9JX4ZM=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19KLAG2ZSjCP; Thu, 10 Jun 2021 18:23:45 +0200 (CEST)
Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (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 18:23:45 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) 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 18:23:45 +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 18:23:45 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: tom petch <ietfa@btconnect.com>, "tcpm@ietf.org" <tcpm@ietf.org>
CC: tcpm-chairs <tcpm-chairs@ietf.org>
Thread-Topic: Draft schepherd write-up for 793bis
Thread-Index: Addd1jp8v9JHxVLlQJqEoECOEi9ZnQAPNXYwAABWk3A=
Date: Thu, 10 Jun 2021 16:23:45 +0000
Message-ID: <430978e6927f4dfe95b9269c3bcd3a21@hs-esslingen.de>
References: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de> <DB7PR07MB5546812311768D0E851DA163A2359@DB7PR07MB5546.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB5546812311768D0E851DA163A2359@DB7PR07MB5546.eurprd07.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.248]
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/hsGjTjPFqg2faIFK3wq7ekP59Y8>
Subject: Re: [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 16:23:56 -0000

The write-up uses the official "essay" template https://www.ietf.org/chairs/document-writeups/ .

I personally prefer that template over the "Q&A" one, and have used the "essay" one in the past many times already.

Michael


> -----Original Message-----
> From: tom petch <ietfa@btconnect.com>
> Sent: Thursday, June 10, 2021 6:14 PM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; tcpm@ietf.org
> Cc: tcpm-chairs <tcpm-chairs@ietf.org>
> Subject: Re: Draft schepherd write-up for 793bis
> 
> From: tcpm <tcpm-bounces@ietf.org> on behalf of Scharf, Michael
> <Michael.Scharf@hs-esslingen.de>
> Sent: 10 June 2021 10:02
> 
> 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.
> 
> <tp>
> Michael
> 
> Lots of good stuff but it does not appear to follow the template, a layout
> which I find  useful when wanting to check on an aspect thereof, such as
> validation by sundry tools, as it saves me having to work my way through it.
> 
> Tom Petch
> p.s. Reviewing 793bis has been on mytodo list for an embarrassing number of
> years:-(
> 
> Thanks
> 
> Michael
> 
> 
> ***
> 
> 1. Summary
> 
> The document shepherd is Michael Scharf <michael.scharf@hs-
> esslingen.de>.
> 
> The responsible Area Director is Martin Duke <martin.h.duke@gmail.com>.
> 
> 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 conge
>  stion 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!
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm