[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