From owner-freebsd-net@freebsd.org Thu Nov 5 09:58:51 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 94525A26DEC for ; Thu, 5 Nov 2015 09:58:51 +0000 (UTC) (envelope-from katoon@sfc.wide.ad.jp) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F0031B36; Thu, 5 Nov 2015 09:58:51 +0000 (UTC) (envelope-from katoon@sfc.wide.ad.jp) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1D79B278216; Thu, 5 Nov 2015 18:58:48 +0900 (JST) Received: by ioc74 with SMTP id 74so18582183ioc.2; Thu, 05 Nov 2015 01:58:46 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.30.10 with SMTP id e10mr9996613ioe.43.1446717526446; Thu, 05 Nov 2015 01:58:46 -0800 (PST) Received: by 10.79.79.73 with HTTP; Thu, 5 Nov 2015 01:58:46 -0800 (PST) In-Reply-To: References: <201509050053.t850rh9P071595@gw.catspoiler.org> Date: Thu, 5 Nov 2015 18:58:46 +0900 Message-ID: Subject: Re: default ECN settings From: Midori Kato To: "K. Macy" Cc: Don Lewis , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Thu, 05 Nov 2015 09:58:51 -0000 Hi Macy and Don, I am Midori. Too late to catch up this topic but this topic is interesting to me. Linux separates inbound and outbound ecn operation while RFC 3168 says that making hosts fail during the negotiation without ecn configuration. I think FreeBSD is probably able to distinguish inbound and outbound with cc_var flag as well. I like to try to work this. If the sender like to use ECN, behaving as ECN receiver is good for the TCP connection. Regards, -- Midori 2015-09-05 10:05 GMT+09:00 K. Macy : > On Fri, Sep 4, 2015 at 5:53 PM, Don Lewis wrote: > > On 4 Sep, K. Macy wrote: > >> By default ECN is completely disabled on FreeBSD. On Linux the default > >> is to disable it outbound (not request it) but enable it inbound > >> (accept new connections asking for it). Is there a good reason to only > >> set ECN_PERMIT on inbound connections if the system is doing ECN on > >> outbound connections? > > > > Not that I can think of. The risk in enabling ECN for outbound > > connections is that some connection attempts can fail, especially if you > > are attempting to connect to some old and oddball device. That should > > not be a risk for inbound connections since those devices won't be > > requesting ECN. > > Even with 'oddball' devices the stack is configured to retry ECN n > times where n defaults to 1 and then revert to not requesting ECN > support. Thus connections would take longer on 'oddball' devices. The > solution that *I* would choose for that would be to track ECN support > in the host cache. The first connection to a new host would always try > ECN and in the event that that failed all subsequent connection > attempts would not try ECN. To me this seems like the most robust > compromise. However, I don't yet have enough information to say how > much benefit this would confer. > > > Seems like we should be defaulting ECN on for inbound connections, > > though we currently can't control the two directions separately. > > That is a straightforward change. > > > Cheers. > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >