Re: [tcpm] 793bis ready to go?

Joseph Touch <touch@strayalpha.com> Sun, 21 February 2021 18:38 UTC

Return-Path: <touch@strayalpha.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 6F1CA3A0E65 for <tcpm@ietfa.amsl.com>; Sun, 21 Feb 2021 10:38:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.241
X-Spam-Level:
X-Spam-Status: No, score=0.241 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.339, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 AM2d-cElom5y for <tcpm@ietfa.amsl.com>; Sun, 21 Feb 2021 10:38:30 -0800 (PST)
Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499F23A0E63 for <tcpm@ietf.org>; Sun, 21 Feb 2021 10:38:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fv6jDAzA6KPTwOWj6bfp6MLrms+uWw0idfYKGGR79ds=; b=iqbwT++RdIFnTx2hu2bysOvaN WvpuTqLwCbuEapJmnecM4EvZcBJ2p4Ro/E5srtcieIgaG2fBzFyN6KdRwS3cx54ZyQ5w6N+/r8gdK KqfTrNZLTeGNJXgsuWRVUCSA2bTKebfuNXw4tMT+LyHFtnSyPvFa7uVYrDBi1zffq+Whw0RrENELt s8+cdOZMR4NYyQU+FOQv2yHbBpC2rQzBCThGmxHBtp5r6yRSaVyTiB6n/GI7SjZA9u4g7O0zYrQAB cjAYragBpQ0iNxOFPNWbqyjnV4cDT2EdTSTRDe6vh4ufRY/GmIVIpxoK5+gOqxkD+iWUScXSeWerT Cy6grhUyA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:57299 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1lDtca-000Fc4-B7; Sun, 21 Feb 2021 13:38:25 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_5C0AE96A-48E8-4243-8FCD-5CEA7D8FD6EF"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <54BF8FD5-671F-4AFE-B6B5-B92D872400D0@lurchi.franken.de>
Date: Sun, 21 Feb 2021 10:38:19 -0800
Cc: tcpm IETF list <tcpm@ietf.org>, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>
Message-Id: <CB345F9F-A745-4D0C-854A-8393125CB8D1@strayalpha.com>
References: <cd600644350847ef8415d21588d1e912@hs-esslingen.de> <alpine.DEB.2.21.2102160206350.3820@hp8x-60.cs.helsinki.fi> <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at> <51A077AB-F5A5-4E4E-9B7F-C606DF50C407@fh-muenster.de> <4F753030-7F77-4D6C-98B5-3F1FCBDBA076@strayalpha.com> <54BF8FD5-671F-4AFE-B6B5-B92D872400D0@lurchi.franken.de>
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/_ZnaN71EbQb-kJaDbpALDLQsEk8>
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: Sun, 21 Feb 2021 18:38:31 -0000

On Feb 20, 2021, at 1:53 PM, Michael Tuexen <michael.tuexen@lurchi.franken.de> wrote:
> 
> 
> 
>> On 20. Feb 2021, at 22:37, Joseph Touch <touch@strayalpha.com> wrote:
>> 
>> Even if you prefer the FreeBSD variant, the text below doesn’t appear to fix this; it will end up sending the SYN-ACK of the received data *and a second ACK* at the end of the sixth step.
> I think the idea of Richard is that if the text is
> 
>         If SND.UNA > ISS (our SYN has been ACKed), change the
>         connection state to ESTABLISHED, form an ACK segment
>         <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
>         and should send it.
> 
> Then NOT following the should, but only send the ACK at the end of step 6.
> Wouldn't that work?

FWIW, I think the case of combining the bare ACK with the ACK of the received SYN-ACK data is already covered in the sixth step below in the following text:

        This acknowledgment should be piggybacked on a segment being
        transmitted if possible without incurring undue delay.

If this needs to be made more explicit, here’s my suggestion:

OLD:

        If SND.UNA > ISS (our SYN has been ACKed), change the connection
        state to ESTABLISHED, form an ACK segment

          <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

        and send it.  Data or controls which were queued for
        transmission may be included.  If there are other controls or
        text in the segment then continue processing at the sixth step
        below where the URG bit is checked, otherwise return.


NEW:

        If SND.UNA > ISS (our SYN has been ACKed), change the connection
        state to ESTABLISHED, form an ACK segment

          <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

        Data or controls which were queued for
        transmission MAY be included in this segment.  If there are no 
	other controls or text in the segment then send the ACK segment 
	and return. Otherwise, continue processing at the sixth step below 
	where the URG bit is checked, either sending the ACK segment now or 
	piggybacking it with the response from that continued processing
	(as noted therein).

Joe