From owner-freebsd-net@freebsd.org Wed Sep 2 16:21:06 2015 Return-Path: <owner-freebsd-net@freebsd.org> Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E6239C90A4 for <freebsd-net@mailman.ysv.freebsd.org>; Wed, 2 Sep 2015 16:21:06 +0000 (UTC) (envelope-from rpaulo@me.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6552F949 for <freebsd-net@freebsd.org>; Wed, 2 Sep 2015 16:21:06 +0000 (UTC) (envelope-from rpaulo@me.com) Received: by mailman.ysv.freebsd.org (Postfix) id 620C29C90A3; Wed, 2 Sep 2015 16:21:06 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 619D09C90A2 for <net@mailman.ysv.freebsd.org>; Wed, 2 Sep 2015 16:21:06 +0000 (UTC) (envelope-from rpaulo@me.com) Received: from mr11p00im-asmtp001.me.com (mr11p00im-asmtp001.me.com [17.110.69.252]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DCEE948; Wed, 2 Sep 2015 16:21:06 +0000 (UTC) (envelope-from rpaulo@me.com) Received: from akita.local (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by mr11p00im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NU2005US5F2U730@mr11p00im-asmtp001.me.com>; Wed, 02 Sep 2015 16:21:05 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-09-02_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1412110000 definitions=main-1509020253 Message-id: <1441210862.1183.14.camel@me.com> Subject: Re: TCP Fast Open (RFC7413) for FreeBSD From: Rui Paulo <rpaulo@me.com> To: Patrick Kelsey <pkelsey@freebsd.org>, net@freebsd.org Date: Wed, 02 Sep 2015 09:21:02 -0700 In-reply-to: <AEE23E04-C0B7-40D3-B55C-502A41B0D5BE@freebsd.org> References: <CAD44qMVK82rB_MM_fsFt7LXV+uwCFj3+9BXXj=30teUQs0gzrg@mail.gmail.com> <1441169643.1183.12.camel@me.com> <AEE23E04-C0B7-40D3-B55C-502A41B0D5BE@freebsd.org> Content-type: text/plain; charset=UTF-8 X-Mailer: Evolution 3.16.4 FreeBSD GNOME Team Port MIME-version: 1.0 Content-transfer-encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/> List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 02 Sep 2015 16:21:06 -0000 On Wed, 2015-09-02 at 01:30 -0400, Patrick Kelsey wrote: > > > > > On Sep 2, 2015, at 12:54 AM, Rui Paulo <rpaulo@me.com> wrote: > > > > > On Tue, 2015-09-01 at 21:19 -0400, Patrick Kelsey wrote: > > > Hi, > > > > > > About two weeks from now, I will be starting work on server-side > > > TCP > > > Fast > > > Open (TFO) support for FreeBSD head and stable/10, with the > > > intention > > > of > > > having patches up for review by November. This message is an > > > attempt > > > to > > > uncover any existing work on TFO for FreeBSD, as the existence of > > > such work > > > may change my plans. > > > > > > Copying Sara Dickinson and Tom Jones due to this thread: > > > https://lists.freebsd.org/pipermail/freebsd-net/2015 > > > -January/040910.html. > > > > Have you performed any measurements on the likelihood that stateful > > packet inspectors (firewalls, NATs, etc.) will allow a SYN or a > > SYN/ACK > > to pass with data in it? > > I have not performed any such measurements. This issue is discussed > in section 7.1 of the RFC, which cites such studies and summarizes > the finding as being that 6% of the probed internet paths dropped SYN > packets with data or with unknown TCP options. > > > > > > How would this interact with our syncache? Does it just need to > > store > > the cookie? > > > > The exact interaction with the syncache is still TBD, but I do not > expect to be storing TFO cookies in the syncache as the cookies are > per client-server IP pair and not per-connection. > OK. The only request I have is to be conservative and leave it disabled for a while. The RFC is pretty much experimental for a good reason and we don't want to repeat the T/TCP mistake. -- Rui Paulo