Re: [tcpm] 793bis ready to go?

[Martin Duke <[e-mail]>]

I agree that the congestion control text skillfully threads the needle
between Standards Track and reality. Well done!

On Fri, Feb 12, 2021 at 7:19 AM Michael Tuexen <
[e-mail]> wrote:

> > On 11. Feb 2021, at 06:22, Neal Cardwell <ncardwell=
> [e-mail]> 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 <[e-mail]> 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
> > <[e-mail]> 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 <[e-mail]> On Behalf Of
> [e-mail]
> > > Sent: Thursday, January 21, 2021 7:02 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > 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
> > > [e-mail]
> > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/tcpm
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>