From owner-freebsd-net@freebsd.org Fri Nov 6 00:52:57 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 67A1EA25EA2 for ; Fri, 6 Nov 2015 00:52:57 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 469F21E3E; Fri, 6 Nov 2015 00:52:56 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 0935C10B5BD; Thu, 5 Nov 2015 16:52:56 -0800 (PST) Date: Thu, 5 Nov 2015 16:52:56 -0800 From: hiren panchasara To: Midori Kato Cc: "K. Macy" , "freebsd-net@freebsd.org" , Don Lewis Subject: Re: default ECN settings Message-ID: <20151106005256.GE69928@strugglingcoder.info> References: <201509050053.t850rh9P071595@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w/VI3ydZO+RcZ3Ux" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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: Fri, 06 Nov 2015 00:52:57 -0000 --w/VI3ydZO+RcZ3Ux Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 11/05/15 at 06:58P, Midori Kato wrote: > Hi Macy and Don, >=20 > 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 th= at > making hosts fail during the negotiation without ecn configuration. >=20 > 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. >=20 > Regards, > -- Midori >=20 >=20 > 2015-09-05 10:05 GMT+09:00 K. Macy : >=20 > > 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 defau= lt > > >> is to disable it outbound (not request it) but enable it inbound > > >> (accept new connections asking for it). Is there a good reason to on= ly > > >> 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. ECN is a good thing to have and I think that we should support it if an incoming connection requests it. I also like this approach suggested by Kip for implementation. > > > > > 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. Just to clarify, with/after this change, the default behavior would be: enabled on inbound and disabled on outbound. And we should also have a way to disable ecn completely on both directions. Cheers, Hiren --w/VI3ydZO+RcZ3Ux Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWO/nkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lVPIH/jSQSWqjVUAWbXYy2V6Q9IFN vYjMwvaRGSfu5tAc3qGXEgXuU4+eM0CdMsmIVXH5SC+7vwpR74IOpPq5ao/cot9J 0j3WRRUkVo3Aqo4Ag9bNW5VzoUSZ6Bgoa9UfAPH8wZlKTfyWc1JHyQXncInZhHHz rewyiyKoIxmSr4q8pLnRSMwQkrRfUmdMZtCVoUJuXBG87DmBzLeIMkJs86C/EAfg bveBLWKxt+5xt1Ub/uJPf5o6gi8aJfhodNmXzYtcS9DJZbB4JN1yV2mBOsddB8Fw TRDRjqF21WrW01bWtz9PliZq5SddNlHgTfKTadsa9eTV4qmTqIZDS9+hWjvqQs0= =VCtp -----END PGP SIGNATURE----- --w/VI3ydZO+RcZ3Ux--