From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id ECC863B2A0 for ; Mon, 26 Sep 2016 10:30:56 -0400 (EDT) Received: by mail-lf0-x230.google.com with SMTP id l131so144452749lfl.2 for ; Mon, 26 Sep 2016 07:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BybC0+h7e0arbRkOHXuAmA9DFxIun8zPskZNpwkcTgY=; b=YRVJwmJmKkPRTidSUcAxbdlpCH8cSRTOmoOLneKaOn+iLm7rp5JnC8ynEkObDBqGCI bRS0dQEzIVbBJCQ3zAB8WpWoz6QTeN3c1rVR0UXpG5jHbtXIeMLiew96NRMVvMXq+vTI fXFW/SJi1OLaDADPz7PkJviasB4kheEhNvZy6yFqUShseCY2kg8gRB+3KgW+rSRYfgBA SmJaTL8X28yG1eJdDVzYFkezwTrJnRfecBeUGBHbw6GRYEYipBTRFCGpl4iaI7hw57Jg qfoBLdT+Xa4M0piiScfK2fZf04H4I5DOWJzcNXAZD03A6k+33zX+1zuKtCKI04iqwDn6 qwtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BybC0+h7e0arbRkOHXuAmA9DFxIun8zPskZNpwkcTgY=; b=OMCChvqFv/dhenhptV0pqEIn4bieGCk6V1xAhPS+0dq/V/dnkek6ZikgKzqAXmb3C9 s8ov7DreeQnk3PoxStM89xUKwWzRMNgcy+MIzt+fNDTC8wUEcY3T2l9+UAIDL6JXwzTe kkT7Z1//zltA+YUe0lacheDvF4D/JrBjthqtJ7dk88/4T6CMZaUNCMFedlm8DWMx8V0R jMhqJ+WUqUtzphrxqWHhGqqWUmpL18Yi5BFXe6DPsU0WSlhEkky2ugTvwRUK4IdCbMZr PlT/wvqU6fmFDcJ/ryi2HcFvhJEAnSKyrOZWW0T9uTz1dU6fd0hKNTIADeFmYc75x1/y akew== X-Gm-Message-State: AA6/9Rlhfqv379PuAKdoPldQ9vuRf2MDJqEb9CWj3Srz87x0rixGWNo5sXBQ0egWvVxhsA== X-Received: by 10.46.69.137 with SMTP id s131mr3607192lja.72.1474900255162; Mon, 26 Sep 2016 07:30:55 -0700 (PDT) Received: from [192.168.100.13] (37-33-90-35.bb.dnainternet.fi. [37.33.90.35]) by smtp.gmail.com with ESMTPSA id l65sm3812654lfl.30.2016.09.26.07.30.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Sep 2016 07:30:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <3DE6B4CF-ABFF-4B7E-855F-CEEBF80C8EB2@gmx.de> Date: Mon, 26 Sep 2016 17:30:52 +0300 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: moeller0 X-Mailer: Apple Mail (2.3124) 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 14:30:57 -0000 > 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? 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. That assumes we have qdiscs attached to the egress and ingress sides of = a WAN-facing interface, as normally desired. 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=99= s 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. 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. 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. Also long overdue are the more subtle overhead compensation factor for = PTM, and the two extra keywords for DOCSIS=E2=80=99 asymmetric overhead. - Jonathan Morton