[tcpm] 793bis ready to go?
"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Mon, 08 February 2021 17:00 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 3E4F43A129D for <tcpm@ietfa.amsl.com>; Mon, 8 Feb 2021 09:00:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 UgDnR7oPAsV6 for <tcpm@ietfa.amsl.com>; Mon, 8 Feb 2021 09:00:14 -0800 (PST)
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 C93773A1332 for <tcpm@ietf.org>; Mon, 8 Feb 2021 09:00:13 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id AE42025A15; Mon, 8 Feb 2021 18:00:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1612803611; bh=jMqHNFHx3jkYa83tOTZMHZQEmQyPx0OaSNiGcuMeZ74=; h=From:To:CC:Subject:Date:From; b=OkkwfMA+VAPUWl03j6iIdqB1BhirJMzRs52RQdsvGnHyQMDiqyLT1LqBNRwBxETXW CcLOzW3oB5IAHuj87YQloXMIDodsF3rlt9W3EZYDaO4F46X76N9Cq009IEIW1nJmrc f6sSqbxg3OmpEvKxiAUs1vSZ65wQMhYEu6IHuiXw=
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 aX5P8ySMEPbC; Mon, 8 Feb 2021 18:00:08 +0100 (CET)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 8 Feb 2021 18:00:08 +0100 (CET)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 8 Feb 2021 18:00:07 +0100
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.1979.006; Mon, 8 Feb 2021 18:00:07 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: tcpm IETF list <tcpm@ietf.org>
Thread-Topic: 793bis ready to go?
Thread-Index: Adb+OMcXKdPjASFKQc+5zg7FPT9zRw==
Date: Mon, 08 Feb 2021 17:00:07 +0000
Message-ID: <cd600644350847ef8415d21588d1e912@hs-esslingen.de>
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/cpoR7mNcE7_bf8q3i51Gr4-T_sg>
Subject: [tcpm] 793bis ready to go?
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, 08 Feb 2021 17:00:16 -0000
Dear all, draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According to Wes, all WGLC feedback should be reflected in this version. A link to a complete diff can be found below. During WGLC, there has been quite some discussion on the exact wording on congestion control. The suggested text in version -20 is copied below: 3.7.2. TCP Congestion Control RFC 2914 [7] explains the importance of congestion control for the Internet. RFC 1122 required implementation of Van Jacobson's congestion control algorithms slow start with congestion avoidance together with exponential back-off for successive RTO values for the same segment. RFC 2581 provided IETF Standards Track description of slow start and congestion avoidance, along with fast retransmit and fast recovery. RFC 5681 is the current description of these algorithms and is the current Standards Track specification providing guidelines for TCP congestion control. RFC 6298 describes exponential back-off of RTO values, including keeping the backed-off value until a subsequent segment with new data has been sent and acknowledged. A TCP endpoint MUST implement the basic congestion control algorithms slow start, congestion avoidance, and exponential back-off of RTO to avoid creating congestion collapse conditions (MUST-19). RFC 5681 and RFC 6298 describe the basic algorithms on the IETF Standards Track that are broadly applicable. Multiple other suitable algorithms exist and have been widely used. Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint. An endpoint may implement such alternative algorithms provided that the algorithms are conformant with the TCP specifications from the IETF Standards Track as described in RFC 2914, RFC 5033 [10], and RFC 8961 [15]. Explicit Congestion Notification (ECN) was defined in RFC 3168 and is an IETF Standards Track enhancement that has many benefits [50]. A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- 8). As document shepherd I ask everybody - specifically all TCPM contributors who have commented on congestion control - to carefully review this proposed wording within the next few days. If there are any issues with this suggested resolution of the WGLC, please speak up! If the TCPM working group is fine with version -20, 793bis would be ready to go. Thanks Michael -----Original Message----- From: I-D-Announce <i-d-announce-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org Sent: Thursday, January 21, 2021 7:02 PM To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : Transmission Control Protocol (TCP) Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-20.txt Pages : 110 Date : 2021-01-21 Abstract: This document specifies the Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet protocol stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, and should be considered as a replacement for the portions of that document dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
- [tcpm] 793bis ready to go? Scharf, Michael
- Re: [tcpm] 793bis ready to go? Yuchung Cheng
- Re: [tcpm] 793bis ready to go? Praveen Balasubramanian
- Re: [tcpm] 793bis ready to go? Neal Cardwell
- Re: [tcpm] 793bis ready to go? Michael Tuexen
- Re: [tcpm] 793bis ready to go? Martin Duke
- [tcpm] meaning of "idle" for TCP Keep-Alives (was… Neal Cardwell
- Re: [tcpm] 793bis ready to go? Scharf, Michael
- Re: [tcpm] meaning of "idle" for TCP Keep-Alives … Scharf, Michael
- Re: [tcpm] 793bis ready to go? Jonathan Morton
- Re: [tcpm] meaning of "idle" for TCP Keep-Alives … Scheffenegger, Richard
- Re: [tcpm] 793bis ready to go? Markku Kojo
- Re: [tcpm] 793bis ready to go? Scheffenegger, Richard
- Re: [tcpm] 793bis ready to go? tuexen
- Re: [tcpm] 793bis ready to go? Joseph Touch
- Re: [tcpm] 793bis ready to go? Michael Tuexen
- Re: [tcpm] 793bis ready to go? Scheffenegger, Richard
- Re: [tcpm] 793bis ready to go? Michael Tuexen
- Re: [tcpm] 793bis ready to go? Joseph Touch
- Re: [tcpm] 793bis ready to go? Michael Tuexen
- Re: [tcpm] 793bis ready to go? Joe Touch
- Re: [tcpm] 793bis ready to go? Scheffenegger, Richard
- Re: [tcpm] 793bis ready to go? Wesley Eddy
- Re: [tcpm] 793bis ready to go? Wesley Eddy
- Re: [tcpm] 793bis ready to go? Wesley Eddy
- Re: [tcpm] 793bis ready to go? Wesley Eddy
- Re: [tcpm] 793bis ready to go? Wesley Eddy
- Re: [tcpm] 793bis ready to go? Yuchung Cheng