From nobody Mon Jul 12 11:57:46 2021 Return-Path: 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 4929D3A0C46 for ; Mon, 12 Jul 2021 11:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 Ouush44AU7Lb for ; Mon, 12 Jul 2021 11:57:40 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 170CD3A0F35 for ; Mon, 12 Jul 2021 11:57:39 -0700 (PDT) Received: by mail-qk1-x732.google.com 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; d=mti-systems-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 [192.168.1.114] (069-135-001-122.biz.spectrum.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id j65sm7106572qkd.17.2021.07.12.11.57.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 11:57:37 -0700 (PDT) To: tcpm@ietf.org References: <162611569026.7615.3785325543750944369@ietfa.amsl.com> From: Wesley Eddy Message-ID: <9f310fe4-1e50-4a94-5ac2-c3eeac4feba6@mti-systems.com> 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: <162611569026.7615.3785325543750944369@ietfa.amsl.com> 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-BeenThere: tcpm@ietf.org 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 is a multi-part message in MIME format. --------------1086F537CECF4DF43C7F397B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 Changed: 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. to: 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, internet-drafts@ietf.org 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: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-24 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-24 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------1086F537CECF4DF43C7F397B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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

Changed:

         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.

to:

      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, internet-drafts@ietf.org 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:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-24

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-24


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--------------1086F537CECF4DF43C7F397B--