Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-24.txt

Wesley Eddy <> Mon, 12 July 2021 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4929D3A0C46 for <>; Mon, 12 Jul 2021 11:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ouush44AU7Lb for <>; Mon, 12 Jul 2021 11:57:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 170CD3A0F35 for <>; Mon, 12 Jul 2021 11:57:39 -0700 (PDT)
Received: by with SMTP id j184so19035204qkd.6 for <>; Mon, 12 Jul 2021 11:57:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=s6aRhi+5KrevTLtmGM2pzMM6Z9c7NkDf7yiohriDz58=; b=1ZFdDbnTgUkHSEeznHWuOc8zjWzYzIEoamSP+9ZEf1l7oBYTyTXTlGrpwQTUWCa4yT RKbDw1pNAnFoYsIeiZAXq2x/EYbLPJXHceNc9LsQTI3SYAwssulZtsw1ZKxJv74eLoYs KaxyvpgoxqBVoWub7R2FJXiZ2Q1N3Um1PiM8mYYQcm5Q5lhU3sQXnBfKhsahdEfzXGpk 0kVpfX9RUxlfg8Y5yuPa9wrf7yhKTsGIP/me+ogXcgYcHYFDWLh1iICqhp/9NcOQvsCC dIQJPuuzckh1yddHVhb88N+0D3czgzHTrnxWM3LJHQJpM2jjkkBvHxG+IUZJ+nsWZCTj sdTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=s6aRhi+5KrevTLtmGM2pzMM6Z9c7NkDf7yiohriDz58=; b=AqHEyaxL0adsyywq73WE0Kn3QbRPnsBA7zmkt5Zr40EfhZdgpNpRZmJ+wio0svWfw1 rmQQYwe6rOIXSZbGwyF80K6IfJC1tjsMr1ErsJUiN/1qR2uWw8xsJUIPu4QfddhoSAe9 UEQzv7wTdiqRYyD7+MvC/Ou79qdg+9uf5vZ92ruROTCeb2KDgAODr0i4U6IomKqVQlJ9 uVQQFrXWqLk85pwsD4FgoQEOPQGaIbHeCNpDx3Zoc6lJsxUEOOFj/oFqx6/G3FKQ1WPC 8r1ydEyEE3uVW4N7ErYpWmbiWjjaNhVnky1scQNDYFFuRp0P1ANBKTpdDIcaRo7p7xWm GwoA==
X-Gm-Message-State: AOAM532OqLJAErA5Wz0s/LEeLnnSULgZhJCcCztkKE1brxxPy7B6IO1x jWafkJSKN1LMGAUWx2MQyiQeYlSbCtEnZOCP
X-Google-Smtp-Source: ABdhPJzb/vS6MnqYmh5Kc5julAurf8mMan4hCTQpjqYBTqkXUtp3LiWJDsLMrvo80DNQSgPOoo24Eg==
X-Received: by 2002:a05:620a:22d6:: with SMTP id o22mr168707qki.444.1626116257908; Mon, 12 Jul 2021 11:57:37 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j65sm7106572qkd.17.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 11:57:37 -0700 (PDT)
References: <>
From: Wesley Eddy <>
Message-ID: <>
Date: Mon, 12 Jul 2021 14:57:35 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------1086F537CECF4DF43C7F397B"
Content-Language: en-US
Archived-At: <>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-24.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Jul 2021 18:57:45 -0000

This revision has changes resulting from Martin's AD review and 
subsequent comments from Yuchung and Joe.

A few things to specifically check over since I wasn't sure if the 
thread totally converged on them, and they should be confirmed:

(1) urgent pointer "receding"

I think the key to understand is that the only time an application can 
set this is when data is written, so it should not "recede" since you 
can't write backwards.   There was already a paragraph saying:

    To send an urgent indication the user must also send at least one
    data octet.

I'm not sure if this completely satisfies Martin's comment, but for now, 
I added this sentence:

   Note that because changes in the urgent pointer correspond
    to data being written by a sending application, the urgent pointer
    can not "recede" in the sequence space, but a TCP receiver should be
    robust to invalid urgent pointer values.

(2) PUSH check in SWS timer expiration

I think Martin is right, and if the intention is that if the SWS timer 
expires, it's okay to send, even if PUSH isn't set.  This:

    or if data is PUSHed and the override timeout occurs.

was changed to:

    or if the override timeout occurs.

(3) unnecessary Step 4 for LISTEN state when SEGMENT ARRIVES


          fourth other text or control

             Any other control or text-bearing segment (not containing
             SYN) must have an ACK and thus would be discarded by the ACK
             processing.  An incoming RST segment could not be valid,
             since it could not have been sent in response to anything
             sent by this incarnation of the connection.  So, if this
             unlikely condition is reached, the correct behavior is to
             drop the segment and return.


       fourth other data or control

          This should not be reached.  Drop the segment and return.  Any
          other control or data-bearing segment (not containing SYN) must
          have an ACK and thus would have been discarded by the ACK
          processing in the second step, unless it was first discarded by
          RST checking in the first step.

Although maybe if we agree that it's totally pointless to have, then 
this "fourth" step can just be removed entirely.

On 7/12/2021 2:48 PM, wrote:
> 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-24.txt
> 	Pages           : 108
> 	Date            : 2021-07-12
> 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:
> There is also an htmlized version available at:
> A diff from the previous version is available at:
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> tcpm mailing list