From owner-freebsd-net@freebsd.org Wed Sep 2 16:24:06 2015 Return-Path: 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 369EC9C92D0 for ; Wed, 2 Sep 2015 16:24:06 +0000 (UTC) (envelope-from pkelsey@gmail.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 14397B72 for ; Wed, 2 Sep 2015 16:24:06 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 135189C92CF; Wed, 2 Sep 2015 16:24: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 EEA019C92CE for ; Wed, 2 Sep 2015 16:24:05 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA07EB71 for ; Wed, 2 Sep 2015 16:24:05 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: by qgt47 with SMTP id 47so8769350qgt.2 for ; Wed, 02 Sep 2015 09:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YZkT/7Vo1DUAV6MfGNCptyexfKFC6emjkXCk7446H8g=; b=tJRnzJKth/wAdeR9/mjEZi85EQrm8RCDi9QD4plE7I/88rp7eV3vdMxlXwM6yq/PG6 De4ljnhdhL6gRD5MZb7wrJi5pYTM6un2RukrGr/9AZSWcn/CprlHLZ7nmk9MIkUZO0m6 NRTX3ti5eA9cinLw/+27qX5ZoEuiiXJFk2ge+QUUQ6HLF3NtATU04WVNHegYLG/W/WZn dWzNsk+T5JpCFIIzkZAK9wFTAm6uaWPf7bUiLc4WJXeYD2UlW0eIsODLMqMnNloHFImy 0x2Rp0AUL4KHVjH4NOTj+JDMHOO6+6D93RaDKhZ01sUlOfScIKYoX12PtIddw72alF9t W2ow== X-Received: by 10.140.238.3 with SMTP id j3mr61672699qhc.14.1441211044601; Wed, 02 Sep 2015 09:24:04 -0700 (PDT) Received: from [10.117.73.93] (mobile-166-171-057-239.mycingular.net. [166.171.57.239]) by smtp.gmail.com with ESMTPSA id h78sm13007567qhc.47.2015.09.02.09.24.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Sep 2015 09:24:04 -0700 (PDT) Sender: Patrick Kelsey Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: TCP Fast Open (RFC7413) for FreeBSD From: Patrick Kelsey X-Mailer: iPhone Mail (12F70) In-Reply-To: <1441210862.1183.14.camel@me.com> Date: Wed, 2 Sep 2015 12:24:02 -0400 Cc: "net@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1D272A8E-C411-4FE1-A8C7-6E6FBDE23DC8@freebsd.org> References: <1441169643.1183.12.camel@me.com> <1441210862.1183.14.camel@me.com> To: Rui Paulo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 16:24:06 -0000 > On Sep 2, 2015, at 12:21 PM, Rui Paulo wrote: >=20 >> On Wed, 2015-09-02 at 01:30 -0400, Patrick Kelsey wrote: >>=20 >>=20 >>=20 >>>> On Sep 2, 2015, at 12:54 AM, Rui Paulo wrote: >>>>=20 >>>> On Tue, 2015-09-01 at 21:19 -0400, Patrick Kelsey wrote: >>>> Hi, >>>>=20 >>>> About two weeks from now, I will be starting work on server-side=20 >>>> TCP=20 >>>> Fast >>>> Open (TFO) support for FreeBSD head and stable/10, with the=20 >>>> intention=20 >>>> of >>>> having patches up for review by November. This message is an=20 >>>> attempt=20 >>>> to >>>> uncover any existing work on TFO for FreeBSD, as the existence of=20 >>>> such work >>>> may change my plans. >>>>=20 >>>> Copying Sara Dickinson and Tom Jones due to this thread: >>>> https://lists.freebsd.org/pipermail/freebsd-net/2015 >>>> -January/040910.html. >>>=20 >>> Have you performed any measurements on the likelihood that stateful >>> packet inspectors (firewalls, NATs, etc.) will allow a SYN or a=20 >>> SYN/ACK >>> to pass with data in it? >>=20 >> I have not performed any such measurements. This issue is discussed=20 >> in section 7.1 of the RFC, which cites such studies and summarizes=20 >> the finding as being that 6% of the probed internet paths dropped SYN=20 >> packets with data or with unknown TCP options. >>=20 >>=20 >>>=20 >>> How would this interact with our syncache? Does it just need to=20 >>> store >>> the cookie? >>=20 >> The exact interaction with the syncache is still TBD, but I do not=20 >> expect to be storing TFO cookies in the syncache as the cookies are=20 >> per client-server IP pair and not per-connection. >=20 > 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. >=20 I agree completely. This feature will be guarded with an #ifdef, default di= sabled. -Patrick=