Re: [tcpm] 793bis ready to go?

Neal Cardwell <ncardwell@google.com> Thu, 11 February 2021 05:23 UTC

Return-Path: <ncardwell@google.com>
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 2E9123A11C1 for <tcpm@ietfa.amsl.com>; Wed, 10 Feb 2021 21:23:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 L8BZr_qwNFak for <tcpm@ietfa.amsl.com>; Wed, 10 Feb 2021 21:23:07 -0800 (PST)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7343A11BF for <tcpm@ietf.org>; Wed, 10 Feb 2021 21:23:07 -0800 (PST)
Received: by mail-vs1-xe31.google.com with SMTP id o186so2406775vso.1 for <tcpm@ietf.org>; Wed, 10 Feb 2021 21:23:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rvDner9/K3P16uPlgn8O9IHCTYcil1ZNu+IzmHzuuZA=; b=uSIkn8HK4Mjcg8q9uQICqUVrqEVdln+6OZJGCRfDuMmpl53pNbCP5ZkeTvpFmG2Q29 20gsm6QxGaIuzeLOD6eILjKM7au42yM9qdb1R/+gBwLXhLE00kh+h+xq4FnGODEP8coW VBGP5hHnThyQyQbdhlJUDG4FTxz3yswcT4FEy6YyqpUwJnabZiBVfzcGuHbQeXuFnzy+ /I6aNIxwE2Wv4R3nAEoH1T0z7Y05EcVzVN1xIeGekWKI0RnXBhX4K059XLoOBt1JiWtS FTT/dgPsbChOCM3vyTwal8SebWeVHsYZiVP5teMkkzVe285oomox+0QUoWbLWl/iMvA3 ak3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rvDner9/K3P16uPlgn8O9IHCTYcil1ZNu+IzmHzuuZA=; b=V4OsGVHvlkQaGntmara3m+7NvVRMNdvOijv2qAjgH8iTcNM+rItSme1clOYte/kpAq YY2E9vtrkEXAJlUCuYw2Ix34/siXGTun7vbE8aEvPl1x207V19Kofhdfkxp11tFbbVXj zw0AF6WCncM7fge95fJ8KXD1YIp4fzebWP9N00UdtSKNfr7zLPx0rl1T7PvihZry/cjW FhAhMMrPPUOslg9ZofvI72V0LeDDtFkziCZ9cAib2ijgIbtFEk1zjV7+qBuekHPg5Lmf 7dGPqAIKHFg0/ZyYcTSFunHi0jiTXdq3t6Xl0uU3kvepow5CuvugwTosI6G0Ojtx1TPj fUMQ==
X-Gm-Message-State: AOAM532nteH1+0qiwHBatewjqLgfMx0r2Xng66p50ZonwPICkvbL0JpB ZhvTFZxSwAFnNNL5wYO7TuPjIHNsWcOkMt1onrhcKQ==
X-Google-Smtp-Source: ABdhPJzgGYxIZZLpFJXDTZty0WKFupWoQHM93Con5mAgVpr2Ct4+EOM0Uo5jyAT845CPGagMhTFyRO4qCOcUUvYDSvo=
X-Received: by 2002:a67:c82:: with SMTP id 124mr4032870vsm.54.1613020984843; Wed, 10 Feb 2021 21:23:04 -0800 (PST)
MIME-Version: 1.0
References: <cd600644350847ef8415d21588d1e912@hs-esslingen.de> <CAK6E8=fs_EaMpAEmpV=7_ZwmtugN=1rnuxRjfY4zPxEiyp8NgA@mail.gmail.com>
In-Reply-To: <CAK6E8=fs_EaMpAEmpV=7_ZwmtugN=1rnuxRjfY4zPxEiyp8NgA@mail.gmail.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Thu, 11 Feb 2021 00:22:48 -0500
Message-ID: <CADVnQym-W-KmR8ZN3sxSqyTBptU_tOm=u844b6-5xLRbmYtdiw@mail.gmail.com>
To: Yuchung Cheng <ycheng@google.com>
Cc: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, tcpm IETF list <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d196ec05bb08b6af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/BXPpxgLQqzwpD5cKGuWLHQ7kj9Q>
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: Thu, 11 Feb 2021 05:23:10 -0000

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).

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
>