From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 D0C983B25E for ; Thu, 9 Jun 2016 19:27:59 -0400 (EDT) Received: by mail-lf0-x236.google.com with SMTP id j5so35752545lfb.3 for ; Thu, 09 Jun 2016 16:27:59 -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=ATcenbIsIUE/ZbdERcjtMCcPwuv6NzIu7qkEIL4vskM=; b=MqpQuY/+5Ga/qPSfP2zKYi59xsJIs86ljg7dXyI1p/sszKyzGHMeoJFNYADWX4YXq/ y/NQ0b78FK5HOUKUI2ixX7N9lzLvaQMTqfLKs6QIM6RLbGzMCFCB7aDrgXLhbOHZ3B4D 64W644dZ08zpRukcQLctYcd4aZ2takgHJoqpfbgjmRelen3I95xgBVEtJkSQPjscoxrJ nvvr9mZJt0p1sTVDvlgBxAs+tD33upAlZt9x54fxrhRcuNuD/f3o3RViTzxcFIqMf4pl iHHX0SVbnjzDwmUMht/JnykGBxx9VHXz6OBX1PtSTNyiB7A/hAk3nExaaR1pUaUdeUNe 6ZYQ== 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=ATcenbIsIUE/ZbdERcjtMCcPwuv6NzIu7qkEIL4vskM=; b=FBkr2QNEAf3Fc8nFGpVX1zTbs+dwYFfa1743n5YYohJR0eI26FhtmGP4CdKq3ELU+Q iNjIqiz/E4Bab4SUZKpGWk0KgVwRM6PFxxta7xb/Se3eRzCoRuoh576VK4tv1mLydaUS o4iVwK0cLrrvnYEmvhf8ZXFfcDU+iVeS2RyrXZeYUzzXAGxqmqaB/Ad/QFtzSUrRKSVI pOVAEd2lA0hUijF+kV6sLPwguApYcca+ak0jN4JMJLG7q2/ZRPhmUY6TqXdFH9RZWBIX xlHiQZQm7aka2gQIPE10q18RWirRwXzQavpE7roEUp4VWqDYYrk5eI0wmsxMqlPXKh6R n6Og== X-Gm-Message-State: ALyK8tLKWrp78WqfbTt/OJDvnhrI+l1ZrKUW0hSHn+BvquXenr8+TXSQ2w2ZgTYcnXa39Q== X-Received: by 10.25.86.6 with SMTP id k6mr5764516lfb.97.1465514878559; Thu, 09 Jun 2016 16:27:58 -0700 (PDT) Received: from bass.home.chromatix.fi (87-93-1-125.bb.dnainternet.fi. [87.93.1.125]) by smtp.gmail.com with ESMTPSA id g28sm926014ljg.24.2016.06.09.16.27.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 16:27:57 -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: <65184CD2-7205-4D93-9AD3-20F68C461E0E@gmx.de> Date: Fri, 10 Jun 2016 02:27:54 +0300 Cc: Kevin Darbyshire-Bryant , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <74C47155-52F4-4F20-9C55-BFC0AD817555@gmail.com> References: <7409a52d-8c81-25f0-e070-c7638fdf9d83@gmail.com> <5759E14D.1050806@darbyshire-bryant.me.uk> <65184CD2-7205-4D93-9AD3-20F68C461E0E@gmx.de> To: moeller0 X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] New to cake. Some questions 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: Thu, 09 Jun 2016 23:28:00 -0000 > why are the vdsl options suffixed with _ptm, but the atm options are = not? Because the =E2=80=9Cvcmux=E2=80=9D and =E2=80=9Cllc=E2=80=9D suffixes = are sufficient to imply ATM cell framing. > is the currently selected set of keywords minimal and complete? I did some careful research back when I added that feature, including = taking some suggestions from you, and according to that: yes, it is = correct and complete, and every keyword is related to a real protocol. = Though some are not widely used in practice, they *are* widely supported = in ubiquitous consumer-grade equipment. I haven=E2=80=99t seen any evidence to the contrary; if you have any, = please show it, if not, PLEASE SHUT UP about it. That, by the way, is *me* being blunt to the point of rudeness. > why name something conservative that will for all peop;e not using an = ATM link cost between 9 to 40% of goodput? The use-case for the =E2=80=9Cconservative=E2=80=9D keyword is = essentially: =E2=80=9CI know what the raw bitrate of the link is, but I = have no sodding clue what overhead it has=E2=80=9D. The goal is to = prevent the dumb buffers elsewhere from filling up and undoing our good = work. Yes, it will overcompensate, leading to reduced throughput. That=E2=80=99= s recognised and accepted as far as I=E2=80=99m concerned; the worst = corner cases are with very small packets, which frankly matter less. If = you don=E2=80=99t want overcompensation, figure out what the real = overhead is and set that. - Jonathan Morton