Re: [tcpm] 793bis ready to go?

Michael Tuexen <michael.tuexen@lurchi.franken.de> Sun, 21 February 2021 18:07 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
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 202013A0DFB for <tcpm@ietfa.amsl.com>; Sun, 21 Feb 2021 10:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.488
X-Spam-Level:
X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 zNOyZApjB1Tq for <tcpm@ietfa.amsl.com>; Sun, 21 Feb 2021 10:07:03 -0800 (PST)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA8A3A0DF3 for <tcpm@ietf.org>; Sun, 21 Feb 2021 10:07:02 -0800 (PST)
Received: from [IPv6:2a02:8109:1140:c3d:bd48:ec3f:ec08:510] (unknown [IPv6:2a02:8109:1140:c3d:bd48:ec3f:ec08:510]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id BDA9E7220F400; Sun, 21 Feb 2021 19:06:58 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <985e67f8-e1b8-36c6-f5a7-cce3f786727e@gmx.at>
Date: Sun, 21 Feb 2021 19:06:58 +0100
Cc: Joseph Touch <touch@strayalpha.com>, tcpm IETF list <tcpm@ietf.org>, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA9C2859-82A0-439C-A003-CA6EB7CC5FE9@lurchi.franken.de>
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> <985e67f8-e1b8-36c6-f5a7-cce3f786727e@gmx.at>
To: "Scheffenegger, Richard" <rs.ietf@gmx.at>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/gAeoNY8cOXm9l72YVo-dRsvCnus>
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:07:06 -0000

> On 21. Feb 2021, at 15:33, Scheffenegger, Richard <rs.ietf@gmx.at> wrote:
> 
> 
> 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.
Hi Richard,

I'm not sure about your statement about compliance of the Linux stack.
My testing show that the following packetdrill scripts succeeds:

 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0.000 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
+0.000 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
+0.000 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
+0.000 > S    0:0(0)             win 64240 <mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7>
+0.050 < S.   0:512(512) ack   1 win 65535 <mss 1460,sackOK,eol,eol>
+0.000 >  .   1:1(0)     ack   1 win 64240
+0.000 recv(3, ..., 1024, 0) = -1 EWOULDBLOCK (Operation would block)
+0.000 close(3) = 0
+0.000 > F.   1:1(0)     ack   1 win 64240
+0.000 < F.   1:1(0)     ack   2 win 65535
+0.000 >  .   2:2(0)     ack   2 win 64239

This means that the data on the SYN-ACK is simply dropped. I don't think
this is the handling described in RFC 793.

MacOS handles the case similar to FreeBSD.

Best regards
Michael 
> 
> 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
>>