Re: [tcpm] 793bis ready to go?

"Scheffenegger, Richard" <rs.ietf@gmx.at> Sun, 21 February 2021 14:33 UTC

Return-Path: <rs.ietf@gmx.at>
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 BA55B3A0A02; Sun, 21 Feb 2021 06:33:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 (1024-bit key) header.d=gmx.net
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 PFPeJVM7rADP; Sun, 21 Feb 2021 06:33:50 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 E8C273A0A0B; Sun, 21 Feb 2021 06:33:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613918009; bh=8arydKN4Abz82AXJ3ylPiL7prsGqgPk1zKJRucHtTgU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=V08lX5ReyZgA8S3QyuKz6U093z/492FMJrw57lIHh9HRTFi5qAUlYWJ0/Yv8jCqYA Ri7OL6PqBBRbcwCD2tXnrcKgQL0+lBDr1lQ15zt0Kx9NbhTTnJjhddzufwYvSm9KYZ xTs8aKNDl7xF8jb44WW/yf29bqm/0mwqVHbXCUgc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.199] ([77.119.130.38]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N8XPt-1lrl3g0i5B-014Trv; Sun, 21 Feb 2021 15:33:29 +0100
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>, Joseph Touch <touch@strayalpha.com>
Cc: tcpm IETF list <tcpm@ietf.org>, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>
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>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <985e67f8-e1b8-36c6-f5a7-cce3f786727e@gmx.at>
Date: Sun, 21 Feb 2021 15:33:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <54BF8FD5-671F-4AFE-B6B5-B92D872400D0@lurchi.franken.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:SwCLcYd1p2cuDEUs1meMkE+ymJyyhs9SXRRZIIdAWb8BgPAleUw KEeff+Nh8SuIw5qUL4+f0VO2xgBMRZf507SAsqBpyFMoQWvDds2ASpRLt/ArX7qZkLKWua1 NR28Cq0JVEXleh/yXnwpG7wTSc+GQEuVXv7Sl2fAcP0y+l4d9k/WC+6oUTIdqRuuYfyaK9N aFonUwbCJl8tzXkcwdLFg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:XFdx9HvVzgo=:aRONfOH7rc2oXW5rnHW2Dn swVr9gfO7sR6fLdFrgUz8JIq1LDv+O+kK9vWGsiS3HbUZFdYygpc47Gjn+X/gxdnOBN4NXwGA dQZBNDs8S8g5sm2eI6Z3+scjNeTcdAbx5Zs+MBaZjlBapOGQEfHLo9qPcZWSTpLtRb43Sc2kq +twFTsqc2E6dQ4+j/753CMIkYJ+T4TGepXL7+0Acn7AGMbeTs3Mf/N7yv8PBtFeeEatfdgRKO SWqU6zeXQCzVf+H8QcxC0cKYVVWLdkmyhxToUTKF11v27pBE+BnCfHJQI3no42UFPJaRe3pd/ tOANs/OquXpRGnzCFBKFWQTVBIQrWovnXKKRxAglwPUO5eDUU611eKNvH/Dmh731vrb33Ej/r 0vqu6R9+4S1XBUc2teoVDRAdyXz10UGupOYAewofZZ1KnrI90u/X9YgxdjevSc6Qqtv4cPdp1 WpAnhg2SU4KKhn/mnEi/uAwjkdEkzAlU0SGDuW9kU+fLEfu8Dlgufj8I3EwVROyzuP7zExton 2BRoEMKgTgOkJXNoFSUDVm6GnulmqtTV6g4XZCePDTIVLeNbiCb+5VT96Jfwrk0P+7m1EJrZJ CS3Ov1hVSndOg2DJbBG976f+4aWBI/cKP9MNr2hNhpY/4h5GO+Iw0uBp0AGp+BWHcDAFAdJku khLydVDP7R9jaFaWt+thxTduXST/ASvPJb8zU2gjNsuyjGUkWKBnESAjllSgzhHxWjcL14yCl pnwHCFpjhkMUpFBqdYGNkFtzWdecGA9jYkocRcoJlh/FgW2z1dapvIUqAXoP05DH49tHvNXjK 3ISvsfpxQdNL/9kU2sBPhkapMzROj8qAcqgUAYIdVEraxNSiyTgMAuwAYMmsosAZRXIt/RTTN Afu9RSz7XTs/b59At/8w==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/K8zIjXoQg2MLsvKdj1M6waqcD28>
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 14:33:53 -0000

Well, making the transmission of the ACK-only-the-SYN optional when data
is present, which needs to be ACK'd anyway..

That way, current FBSD and Linux behaviour both would comply with
793bis, while I agree with Michael T. that the behavior of FBSD is more
efficient.

Richard

Am 20.02.2021 um 22:53 schrieb Michael Tuexen:
>
>
>> 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?
>
> Best regards
> Michael
>>
>> Joe
>>
>>> On Feb 20, 2021, at 12:56 PM, tuexen@fh-muenster.de wrote:
>>>
>>>> On 18. Feb 2021, at 14:59, Scheffenegger, Richard <rs.ietf@gmx.at> wrote:
>>>>
>>>> One more nit, around dealing with data-in-SYN,ACK
>>>>
>>>> 793bis (page 71) has this text, which unfortunately doesn have any
>>>> RFC2119 language.
>>>>
>>>> But in short, it seems to require the transmission of a pure ACK just
>>>> for the SYN bit, and a 2nd ACK right afterwards (step 6) to acknowledge
>>>> the data.
>>>>
>>>> The FBSD implementation was found to skip over the ACK-only-the-SYN
>>>> intermediate step (which must be acceptable, as that ACK may get lost in
>>>> the network), sending out only the cummulative ACK for SYN and data,
>>>> after having transitioned into ESTABLISHED.
>>> Hi,
>>>
>>> I really prefer the FreeBSD behaviour. A TCP stack should not need to send
>>> two segments at the same time when handling the event of a single segment reception.
>>>
>>> Best regards
>>> Michael, as an individual
>>>>
>>>> But strictly speaking, this behavior is a deviation from 793 / 793bis.
>>>>
>>>> Perhaps a "and should send it" would do, to allow this behavior,
>>>> conserving one pure ACK...
>>>>
>>>> Best regards,
>>>> Richard
>>>>
>>>>
>>>>
>>>> If the state is SYN-SENT then
>>>>
>>>>        first check the ACK bit
>>>>
>>>>           If the ACK bit is set
>>>> :
>>>> :
>>>> fourth check the SYN bit
>>>>
>>>>           This step should be reached only if the ACK is ok, or there
>>>>           is no ACK, and it the segment did not contain a RST.
>>>>
>>>>           If the SYN bit is on and the security/compartment is
>>>>>>>        acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to
>>>>           SEG.SEQ.  SND.UNA should be advanced to equal SEG.ACK (if
>>>>           there is an ACK), and any segments on the retransmission
>>>>           queue that are thereby acknowledged should be removed.
>>>>
>>>>           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 that 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.
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>