Re: [tcpm] 793bis ready to go?
tuexen@fh-muenster.de Sat, 20 February 2021 20:56 UTC
Return-Path: <tuexen@fh-muenster.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 D9AC73A0CD3 for <tcpm@ietfa.amsl.com>; Sat, 20 Feb 2021 12:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.834
X-Spam-Level:
X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_SOFTFAIL=0.665, 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 MfJ2-wTDzXvM for <tcpm@ietfa.amsl.com>; Sat, 20 Feb 2021 12:56:06 -0800 (PST)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B353A0CCC for <tcpm@ietf.org>; Sat, 20 Feb 2021 12:56:06 -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: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 6E1E372246348; Sat, 20 Feb 2021 21:56:01 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: tuexen@fh-muenster.de
In-Reply-To: <07c02ad6-979f-4049-3075-cae0064b7def@gmx.at>
Date: Sat, 20 Feb 2021 21:56:00 +0100
Cc: Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>, Michael Scharf <Michael.Scharf@hs-esslingen.de>, Wesley Eddy <wes@mti-systems.com>, tcpm IETF list <tcpm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <51A077AB-F5A5-4E4E-9B7F-C606DF50C407@fh-muenster.de>
References: <cd600644350847ef8415d21588d1e912@hs-esslingen.de> <alpine.DEB.2.21.2102160206350.3820@hp8x-60.cs.helsinki.fi> <07c02ad6-979f-4049-3075-cae0064b7def@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/bWzFKF_zIKWWPyObOPFFyPSkgYA>
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: Sat, 20 Feb 2021 20:56:11 -0000
> 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] 793bis ready to go? Scharf, Michael
- Re: [tcpm] 793bis ready to go? Yuchung Cheng
- Re: [tcpm] 793bis ready to go? Praveen Balasubramanian
- Re: [tcpm] 793bis ready to go? Neal Cardwell
- Re: [tcpm] 793bis ready to go? Michael Tuexen
- Re: [tcpm] 793bis ready to go? Martin Duke
- [tcpm] meaning of "idle" for TCP Keep-Alives (was… Neal Cardwell
- Re: [tcpm] 793bis ready to go? Scharf, Michael
- Re: [tcpm] meaning of "idle" for TCP Keep-Alives … Scharf, Michael
- Re: [tcpm] 793bis ready to go? Jonathan Morton
- Re: [tcpm] meaning of "idle" for TCP Keep-Alives … Scheffenegger, Richard
- Re: [tcpm] 793bis ready to go? Markku Kojo
- Re: [tcpm] 793bis ready to go? Scheffenegger, Richard
- Re: [tcpm] 793bis ready to go? tuexen
- Re: [tcpm] 793bis ready to go? Joseph Touch
- Re: [tcpm] 793bis ready to go? Michael Tuexen
- Re: [tcpm] 793bis ready to go? Scheffenegger, Richard
- Re: [tcpm] 793bis ready to go? Michael Tuexen
- Re: [tcpm] 793bis ready to go? Joseph Touch
- Re: [tcpm] 793bis ready to go? Michael Tuexen
- Re: [tcpm] 793bis ready to go? Joe Touch
- Re: [tcpm] 793bis ready to go? Scheffenegger, Richard
- Re: [tcpm] 793bis ready to go? Wesley Eddy
- Re: [tcpm] 793bis ready to go? Wesley Eddy
- Re: [tcpm] 793bis ready to go? Wesley Eddy
- Re: [tcpm] 793bis ready to go? Wesley Eddy
- Re: [tcpm] 793bis ready to go? Wesley Eddy
- Re: [tcpm] 793bis ready to go? Yuchung Cheng