From owner-freebsd-transport@freebsd.org Thu Jan 16 19:35:59 2020 Return-Path: Delivered-To: freebsd-transport@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 28C221F2E5C for ; Thu, 16 Jan 2020 19:35:59 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47zDvL68Lzz4TPc for ; Thu, 16 Jan 2020 19:35:58 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mb.fritz.box (unknown [IPv6:2a02:8109:1140:c3d:ed19:1698:95d6:bfa1]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id E9D59721E2830; Thu, 16 Jan 2020 20:35:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: TCP Fast Open From: Michael Tuexen In-Reply-To: <75f12c4d-63fb-40d5-8569-f8780de63521@wizmail.org> Date: Thu, 16 Jan 2020 20:35:53 +0100 Cc: freebsd-transport@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <984788AA-EEE0-4348-9F8C-B07E650B6E09@freebsd.org> References: <5276cc23-d37f-e55e-11c5-030314e9e32c@wizmail.org> <1206B1BE-3B7E-45D0-8C2B-6012A5CB6298@freebsd.org> <2752006b-cd6b-7b8b-d23b-ae2c794dc104@wizmail.org> <46A739DC-CCF5-4EA1-802A-0D8E559AC187@freebsd.org> <70c1649f-b3b8-3c3b-ef80-22e851461e9f@wizmail.org> <75f12c4d-63fb-40d5-8569-f8780de63521@wizmail.org> To: Jeremy Harris X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 47zDvL68Lzz4TPc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.83 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.87)[-0.868,0]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; NEURAL_HAM_LONG(-0.96)[-0.958,0] X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 19:35:59 -0000 > On 6. Dec 2019, at 15:23, Jeremy Harris wrote: >=20 > On 05/12/2019 20:31, Jeremy Harris wrote: >> On 05/12/2019 20:17, Michael Tuexen wrote: >>>> - tried TFO but the server didn't take it up >>> I would expect on =3D 0. >>=20 >> Excellent; that's the most-useful one to know. >=20 > Unfortunately, it seems not to be so; it appears > to be recording the sending of a TFO option > (of _either_ type; so a cookie-Request still > gets it set). This means I can't use it to log > "TFO was actually doing something useful for > this connection". > The TCPOPT_FAST_OPEN bit in TCP_INFO says the same > (either pre-ESTABLISHED or post-). >=20 >=20 > Another problem, this time server-side. I was hoping > to get the initial server output piggybacked on > the SYN,ACK, given the TFO design notes in > https://people.freebsd.org/~pkelsey/TFO_Design_Details.pdf >=20 > - but so far I'm not getting that. Packet capture (on lo0): > SYN -> (TFO=3DC) > 0.000224 <- SYN,ACK (TFO=3DC same value) > 0.000078 SYN,ACK -> > 0.001421 <- server_data >=20 > The 224us response time for the SYN,ACK looks immediate, not > a delack time as I'd expect. A fix is under review: https://reviews.freebsd.org/D23212 Best regards Michael > --=20 > Cheers, > Jeremy > _______________________________________________ > freebsd-transport@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-transport > To unsubscribe, send any mail to = "freebsd-transport-unsubscribe@freebsd.org"