From owner-freebsd-net@freebsd.org Wed Feb 1 06:01:20 2017 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 483B2CCCEE7 for ; Wed, 1 Feb 2017 06:01:20 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 01326153D for ; Wed, 1 Feb 2017 06:01:20 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: by mail-ua0-x22c.google.com with SMTP id y9so290893696uae.2 for ; Tue, 31 Jan 2017 22:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=92nNNgTwfGfYv6LQ3/P73onX074RJpaZzEr/s/x56NM=; b=n7zuWlkAYcCrY80tcWp65hFdUrYXYGTk66xs196Zd0j8uua+dr5Wl4q1NqvgQ67vxp HLVMRWhlfaUFglNPSB4i9sZf2jn34vaTtTTUYlRSOuvNDFtTHo+7CUgNOKzY4UWV9ymT cmHRRMDBEwvhq24J7bM5o+ObB0ZCHi7v2cy6Py8cMJSeCUKRpqsLP7VwR+5wNvzdSTJB zsj0BRa0KbNw3NzoUMOdSL3EaabhgUYFdcS6LqJDs6dGcxTBKW2MNKD0kUeipNB/jXmT DENDvC2Mhyb65Zmd645nXbNrPNbb4pbWNDBSwVOULLdLaFVh+ZFvzmgIb4NnPOePw+er akiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=92nNNgTwfGfYv6LQ3/P73onX074RJpaZzEr/s/x56NM=; b=uYHDJ/nTv/tdnqhnnwjYwRSAhop2FhE4wEB3QnW4JNw5PbpNwdz36LTlPH6XpFtdq5 cqvdiey0HqdSBZHPrFZ45X8Ce5RWvMmTMWfrnLFe3H5tDimfoWQMWA9z6Ep9/00+vXUo lLbURGF1+rRJCmNtAYePyfu/gyUYdFMk1g1sW3KFVuRmylPH00Y3tXr3zCY3bulofNkp zzzw0nY6eW3zj1u6bvjT4SGNPdz6vWVasnaWoNBXQgO2HshbQUzrh3D1LNUs7gsNsIXa /5NyUOozEf8awe9cBD/lMUxW23IukfZfdR/P1Jlk4fbIGhozBmLStYFhjXyrVHcq85yA 6GAA== X-Gm-Message-State: AIkVDXL4I9LJsc92NoOKqG3EkAikEKBP6C8DDSF9lN6NvJoA/KHdANVrLni1BSYn0azAZ9cZrqCpCQ1ReUnTHw== X-Received: by 10.176.18.206 with SMTP id o14mr592526uac.58.1485928878971; Tue, 31 Jan 2017 22:01:18 -0800 (PST) MIME-Version: 1.0 Sender: pkelsey@gmail.com Received: by 10.103.74.18 with HTTP; Tue, 31 Jan 2017 22:01:18 -0800 (PST) In-Reply-To: References: From: Patrick Kelsey Date: Wed, 1 Feb 2017 01:01:18 -0500 X-Google-Sender-Auth: GIZEfI0ciagytZBrfhsM1djzUAM Message-ID: Subject: Re: TCP_FASTOPEN is absent in GENERIC To: Sergey Matveychuk Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 01 Feb 2017 06:01:20 -0000 On Tue, Jan 31, 2017 at 10:53 AM, Sergey Matveychuk wrote: > Hi. > > Is there a strong reason for option TCP_FASTOPEN is absent in GENERIC > kernel? It's off by default anyway (net.inet.tcp.fastopen.enabled=0). > > Latest dns/bind* versions want it very much. > > The kernel option name is actually TCP_RFC7413, and currently the implementation is only the server side of the protocol. I committed the code as being compiled out by default because it is a bit intrusive to the normal TCP connection establishment code (tcp_input() and syncache interaction) and I decided to be conservative until it was more thoroughly exercised. The original sponsor of the work lost interest in it shortly after it was implemented, so the expected wider and more thorough testing, to my knowledge, never happened. It has only recently been tested with VIMAGE enabled, and a couple of issues with that configuration are being worked through ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216613). Other than that, I think there is still an unresolved issue with Linux TFO clients that don't ACK data returned with the SYN|ACK of a TFO connection - this forces a retransmit from the server and it has been reported that the retransmit timeout in this case is excessive. There is no technical obstacle there that I am aware of, it is just that no time has yet been spent investigating the report. Best, Patrick