From owner-svn-src-all@freebsd.org Mon Dec 28 04:06:26 2015 Return-Path: Delivered-To: svn-src-all@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 C91F5A52826 for ; Mon, 28 Dec 2015 04:06:26 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (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 8273217F6 for ; Mon, 28 Dec 2015 04:06:26 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f41.google.com with SMTP id y184so192437609lfc.1 for ; Sun, 27 Dec 2015 20:06:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=IVRgJsuxwARE5nwvIahxEhYUS9OVkWyoLPNMPwHT/Eo=; b=cFQ/oDCVD3w6ZdSJhPIf76RAYr1bSjmz/dsQqr6kN95YkuxZvx0Iv2xbghAeD6xeaY QUa6XWjWLvHyp6sLF7U18LnD0VOt+PWyq9OfpIrjUx9k5er/p4oVWVJHpfYNz1TqCfMy gNCu87HWDUS1piMlXuUOKJ/kCW3xdSTiOXiQ6XUXdZUNaC00XOfRUK/cNIsEJ+VUx2lg jUW2cgUQhBSJGAKWy7VnAJCiV4vMKuPMN8IB4ckK+ereat7u3uIAM8SHDAXcgMGKqwIx tDtEtAZ/pIl3TiQqOWkBXriUsBA4pucQYpcoyG5I4p46kWNgby2AbX3XqiNQ01u/49Ua MGaw== X-Gm-Message-State: ALoCoQmwEn91nLG13ueq5m31w+5Sm0RbxjK/URfEj6+f2sYjA2xywDR7QQsQK2uQVONLplR07UtnrsAHAlCdA3sM2YzwxcFGUg== X-Received: by 10.25.165.133 with SMTP id o127mr9385380lfe.105.1451275584489; Sun, 27 Dec 2015 20:06:24 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id p138sm6847431lfb.22.2015.12.27.20.06.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Dec 2015 20:06:23 -0800 (PST) Subject: Re: svn commit: r292823 - in stable/10/sys: conf netinet To: Patrick Kelsey References: <201512280243.tBS2hD7X008202@repo.freebsd.org> <5680A574.9050002@freebsd.org> <5680ABD5.7030206@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org From: Andrey Chernov X-Enigmail-Draft-Status: N1110 Message-ID: <5680B53F.9040903@freebsd.org> Date: Mon, 28 Dec 2015 07:06:23 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 04:06:27 -0000 On 28.12.2015 6:45, Patrick Kelsey wrote: >> On Dec 27, 2015, at 10:26 PM, Andrey Chernov wrote: >> >>> On 28.12.2015 6:15, Patrick Kelsey wrote: >>> This is explained in the top comment in sys/netinet/tcp_fastopen.c, but >>> I will repeat it here and elaborate a little. It is disabled by default >>> in the kernel build as a conservative measure until it is exercised more >>> widely, given the modifications it introduces to the TCP state machine >>> code, syncache code, etc. When you do enable it in the kernel build >>> (and after some point in the future when it is enabled by default), >>> there is still a sysctl that governs its availability in the system that >>> must be enabled before it can be used. >>> >>> -Patrick >> >> Thanx, if I understand it correctly, is not ready for real use yet but >> just for experiments. See my other comment about TCP_RFC7413_MAX_KEYS >> > > It is a serious implementation that is believed to be complete, however I do not see much evidence that TFO is currently widely deployed and used*, and I consider the changes I made to the rest of the TCP stack, which is widely deployed and used, to be intrusive enough to warrant being conservative in putting these changes into the default kernel build at this point. > > *For example, the current Linux TFO client appears to be surprisingly > weak in that it does not ACK data in a TFO SYN|ACK, forcing a > retransmit of fast TFO server responses, which kind of defeats the > purpose. RFC7413 sounds very promising. Should we wait until Linux fix its bug you mention or just go further having TFO at least for FreeBSD machines on some internal net? If the second case is preferred by others, IMHO it will be better to control it via sysctl compiled in by default, controlled by rc.conf on the upper level. I don't see too much code added to make sufficient size bloat. -- http://ache.vniz.net/