Re: [tcpm] 793bis ready to go?

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Fri, 12 February 2021 15:19 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.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 913443A1667 for <tcpm@ietfa.amsl.com>; Fri, 12 Feb 2021 07:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 yEccU-Gy0C6H for <tcpm@ietfa.amsl.com>; Fri, 12 Feb 2021 07:19:34 -0800 (PST)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3383A1657 for <tcpm@ietf.org>; Fri, 12 Feb 2021 07:19:33 -0800 (PST)
Received: from [IPv6:2a02:8109:1140:c3d:d16c:2458:32da:4617] (unknown [IPv6:2a02:8109:1140:c3d:d16c:2458:32da:4617]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 58E2B721BE030; Fri, 12 Feb 2021 16:19:29 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <CADVnQym-W-KmR8ZN3sxSqyTBptU_tOm=u844b6-5xLRbmYtdiw@mail.gmail.com>
Date: Fri, 12 Feb 2021 16:19:26 +0100
Cc: Yuchung Cheng <ycheng@google.com>, tcpm IETF list <tcpm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de>
References: <cd600644350847ef8415d21588d1e912@hs-esslingen.de> <CAK6E8=fs_EaMpAEmpV=7_ZwmtugN=1rnuxRjfY4zPxEiyp8NgA@mail.gmail.com> <CADVnQym-W-KmR8ZN3sxSqyTBptU_tOm=u844b6-5xLRbmYtdiw@mail.gmail.com>
To: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/kOKkQHHTY1tjiLJ0I6IZH9kmbzk>
Subject: Re: [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: Fri, 12 Feb 2021 15:19:38 -0000

> On 11. Feb 2021, at 06:22, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org> wrote:
> 
> The wording in the Congestion Control section looks great to me.
> 
> > Minor:  https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4
> 
> I agree with Yuchung that it would be nice to clarify what is meant by "idle" connections (in the pre-existing text), with respect to keep-alives. It seems at least the historical behavior for two of the major implementations out there interpret this in different ways, and this has caused some confusion in the developer community about what semantics to expect from TCP keep-alives. I guess the rfc793bis-20 draft does have some nice new text (that does not seem to be in RFC793 or RFC1122) that seems to shed some light on this:
> 
>    Keep-alive packets MUST only be sent when no sent data is
>    outstanding, and no data or acknowledgement packets have been
>    received for the connection within an interval (MUST-26).
> 
> 
> That sentence helps quite a bit. It seems to correspond to the last 20 years of Linux TCP keep-alive behavior, but not the BSD behavior (at least BSD TCP as documented in Stevens volume 2; I have not checked more recent BSD kernels).
Can elaborate what Linux behaviour you are referring to an what BSD behaviour you are referring to?

Best regards
Michael
> 
> And, yes, thank you, Wes for all your years of effort on this!
> 
> neal
> 
> 
> 
> On Wed, Feb 10, 2021 at 7:14 PM Yuchung Cheng <ycheng@google.com> wrote:
> I think it's ready. Kudos to Wes for the N-years-long effort to put
> this together!
> 
> Minor:  https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4
> 
> The less clear part is the wording of "idle connections". Idleness can
> be interpreted in several ways: no recent rx, tx, or both {on the wire
> | on socket interface}. It'd be good to define more clearly. AFAIK
> implementations have different definitions already leading to
> different KA behaviors.
> 
> 
> 
> 
> On Mon, Feb 8, 2021 at 9:00 AM Scharf, Michael
> <Michael.Scharf@hs-esslingen.de> wrote:
> >
> > 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 mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm