From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DBAD03B2A0 for ; Mon, 26 Sep 2016 11:23:55 -0400 (EDT) Received: from [172.17.3.48] ([134.76.241.253]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M1nbu-1awIRX0JUw-00tkIK; Mon, 26 Sep 2016 17:23:53 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Mon, 26 Sep 2016 17:23:52 +0200 Cc: Kevin Darbyshire-Bryant , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <3a99770e-6350-471f-72b6-b209d7d77d75@darbyshire-bryant.me.uk> <76bde2de-b6da-60d1-6daa-b5346cc7c185@darbyshire-bryant.me.uk> <3DE6B4CF-ABFF-4B7E-855F-CEEBF80C8EB2@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:NsZMxrGyWi/F+MAzCf0fAEl93fSaMMmZ3ScVe6vY3RjXh+O/PRt GNkvCv+zP6oayKdaCehs8phQz0B9tydXo49V+pdohvR07DydWjOLzX51z8VPRFcPBUb+NTm aCpo0h7HF1GKeoaLizkftRcFYTBwNolUklUnP1oYLwOY1Rekr93//jZOh29deaPdTD/wtBw Sk0/PwwGXopGH+n211baA== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZFVDf3PNODI=:eDXi34aMPSh3CfDno5JW3G 8k/aQGyhhxUNXvz69X4bfmR7sLl0bwm8yN3OjRwINE6kP4Zd1ESOBBnLPqnYc5xKeUDrUjikH RN53EaqAWUHM3KYAi1wU1uZp1k5E8h9Z+0m2VXrRFaxIXlnhX9XWs4j3rJqf1cdMW9qaPJyzp yiLU8t264NXhUIckJB19nC7lXk9czmonet6jJRbKqFJ/pwPaVkf0r00KKVQRqvYcsaDmtwbfE uOR9I9+muykOsyGXADQO9NvsWZgNBCdDHENWKTjTjxjki6fEhn2ogAj7P1gEsVmCgy6Q8vedM NM5Spy69hu8e+c3NdVxFPLCdX/G1jARKkWww5TOHngM5PlN9xyzuIrFU+zD/WpXipydCWzJGt 9ypIGdS7DhmwX+7yl5ZavjMb7RIgsMZDTqZ71kju6H4FN49BZGSTmCc8l004eQanrQWt6h4Sh kX7eTw/cxvlH1FjnYaXf4KgnWBILG1kLkDzk2tw6233L/OLKyq1H5jAgfM3qdWq/MiTGm3aWY ejBJiBiGDmqfUZ9jElEPc+VhDt0F4FPHyUs6PMSfyw6aCzDDnDQ/SR/Vb+W8tIk/fBtvoUbpe Zs2aI7SvBIJ0JNgnmNYWVEPFSV0pfRxxaaaWYpN6Wt5o/XQxATx+vJM5TCbCwFxQSv5oXCoHm zpsm1UCyxgrEBrFStDjrQbwwuNdOUA+GB4LMM29PvkUGU06+Zcwp748CfXgo1OP6QnNR212ci Duj0OUKXL952wvCUVz5m6rCiI2HIW3kyNu4TQ/bP7Q2nSDFIab4CqGCFZMPA3sIPRiYGauh1+ u5GVaby Subject: Re: [Cake] de-natting & host fairness X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 15:23:56 -0000 Hi Jonathan, > On Sep 26, 2016, at 16:30 , Jonathan Morton = wrote: >=20 >=20 >> On 26 Sep, 2016, at 16:28, moeller0 wrote: >>=20 >> Does that mean an initial packet(s) for a flow will be = =E2=80=9Cmisclassified=E2=80=9D (not really since there should be no = record yet to snatch the translated IP from) do all those initially = non-classified packets end up in the same bin? >=20 > The initial packet will normally be outgoing, so it=E2=80=99ll go = through conntrack before reaching the qdisc. If it=E2=80=99s incoming, = then it=E2=80=99ll be =E2=80=9Crelated to=E2=80=9D an existing = connection or else won=E2=80=99t be natted - though I=E2=80=99m not sure = whether =E2=80=9Crelated=E2=80=9D connections pre-emptively get = conntrack entries before traffic has been seen. If not, that initial = packet will be associated with the NAT box by the qdisc, rather than the = internal host, while subsequent packets will correctly be associated = with the internal host. Okay, so the worst case is =E2=80=9Cregression=E2=80=9D to = simple flow fairness and only for initial packets. What about port = redirects, will these be already included into the conntrack and what = about UDP (I believe bit-torrent uses UDP so I believe this to be = relevant). >=20 > That assumes we have qdiscs attached to the egress and ingress sides = of a WAN-facing interface, as normally desired. >=20 > The code looks sane at first glance, so I=E2=80=99ll give it a try at = my end. With any luck, I=E2=80=99ll be able to improve = triple-isolate=E2=80=99s performance enough to make that the default, = too. I should probably use a different data structure than a ring = buffer, so that there is less in the way of linear searching for an = unblocked flow. >=20 > The current default is =E2=80=9Cflows=E2=80=9D, which doesn=E2=80=99t = need NAT information to unambiguously distinguish flows from each other. = However, =E2=80=9Chosts=E2=80=9D mode does need it when running in a = NAT environment, otherwise internal hosts will erroneously be lumped = together with the NAT box. Triple-isolate is effectively a combination = of =E2=80=9Chosts=E2=80=9D and =E2=80=9Cflows=E2=80=9D - that is = probably the easiest way to understand it. But the dual-[src\dst]host options are similar to triple-isolate = in that regard except they also need directionality information which is = hard to divine, so I fully agree that riple is the best candidate for a = default. Assuming that it actually works=E2=80=A6 >=20 > I think it is reasonable to turn on conntrack lookups by default = whenever host information is relevant. This is potentially true for all = modes except =E2=80=9Cflowblind=E2=80=9D and =E2=80=9Cflows=E2=80=9D. >=20 > Also long overdue are the more subtle overhead compensation factor for = PTM, and the two extra keywords for DOCSIS=E2=80=99 asymmetric overhead. Teacher, teacher, ask me: the term you are looking for is = =E2=80=9Cproper documentation=E2=80=9D.=20 About PTM what are you thinking about, the 64/64 encapsulation = =E2=80=9Ctax=E2=80=9D?=20 About DOCSIS, while we have Greg White going on record for cable labs, = would it not be wiser to survey more cable ISPs to check first whether = everybody actually follows those recommendations before creating = keywords? One thing I have learned about overhead compensation is, it = never is as simple and nice as in real life as RFCs make you hope. I = would love to be wrong on DOCSIS, but I believe the hypothesis should be = someone set it up different. So in essence pan for a number of keywords = for DOCSIS and name them in a way that allows future additions that do = not sound awkward. Best Regards Sebastian >=20 > - Jonathan Morton >=20