From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 D84C93CB35 for ; Wed, 21 Aug 2019 09:20:36 -0400 (EDT) Received: by mail-io1-xd2c.google.com with SMTP id i22so4475581ioh.2 for ; Wed, 21 Aug 2019 06:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=q7RckvtLxvEZ/GUnjWXfq2jULlz9nERz/FSMhCWN8As=; b=Bnj73Zo1cObUTCPWB2dqpjnJxMjfiZnnTiJxM4uTCaYE39NXn6k/0PZwSQ/LqTYCfM M1bx6orZMZdGCOtNknK/Bk8XXD4wKZEx7r/t82NPIWEZIFYG5Rc6uAlih6J3bCZEE8Vo iQCoHN3lponh0J66v34oiCijtlHwDaPUmoSEnNmPSgFOa6Igl7uHGn4275K6ITLkcVB6 VpMebJlvDP30IN/ciAlenOy1wmrKyCFjgg0FWnpeUzJcrJA2+I8fpIn4jx3JbimSfqBT QtkH9P+t6ogbuhjqGT8RBnKOqApHp7Eo9vMfyrml3fpIHsmgBtb0AMBzIWt1KKUMBBe9 L6NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=q7RckvtLxvEZ/GUnjWXfq2jULlz9nERz/FSMhCWN8As=; b=D43Ei8rA5zjqCigWH7/Pvf8ZEYl9nltZHlGPL2XBHEed/D1neDDLR20Aq5NfCJibY8 vUW2PkmGe6e33n58m+lmUTK1BpzHGPs5kZzCJWeH1jVYlRqujXpwcEDFbeVS7AlyEHBX +M/VcffZZI2E+gUuHXODxhgrW86V/ti6jAAvCHNECntZx7X5vV9IQ7ErI7tLCSbyzHux rOWSslJM5Lz3xw+iOllSdA9jrm9uczRvl3qqUSywRPBX910DvnGeikvr50xWic3fi5JC M8cPFz4gMMjla8RZbr3aABJAbuy2XRbkwsfeJVMHEcDeAuts+oXjesVXXT1GbnFF5BsN CUuQ== X-Gm-Message-State: APjAAAW4A7GNdSIgYt9+xdn4z8cpcYQM1RvDKVQU10GTngJoidRb15ae rUI2ff4kjbS2xJzJBvOazG5/AV/YUDJh07zFcK8= X-Google-Smtp-Source: APXvYqzfxOW3jqWdVt2zvawy1i4U0p/nZ1WiRpNy0Wc9Uahd9D8KPDPSPdMp22LTe0pAdsruHgCxWtrA+2meG85J6Rg= X-Received: by 2002:a5e:9818:: with SMTP id s24mr7526567ioj.0.1566393636239; Wed, 21 Aug 2019 06:20:36 -0700 (PDT) MIME-Version: 1.0 References: <384866b4-4c91-cf2c-c267-ee4036e5fbf7@newmedia-net.de> In-Reply-To: From: Dave Taht Date: Wed, 21 Aug 2019 06:20:24 -0700 Message-ID: To: Sebastian Gottschall Cc: Sebastian Moeller , "cake@lists.bufferbloat.net >> Cake List" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] cake in dd-wrt 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: Wed, 21 Aug 2019 13:20:36 -0000 On Wed, Aug 21, 2019 at 12:51 AM Sebastian Gottschall wrote: > > >> i have seen this already. out plan here is that the user specifies the= internet connection type like vdsl2, cable, whatever in case of cake which= then will be used > >> as argument > > Good goal, that also is theoretically well supported by cake with= its multitude of encapsulation/overhead realated keywords. Unfortunately r= eality is not as nice and tidy as this collection of keywords implies, Ther= e are 8 keywords for ATM/AAL5 based encapsulations (ADSL, ADSL2, ADSL2+, ..= .), 2 for VDSL2, 1 for DOCSIS, 1 for ethernet, for a total of 12 that all c= an be combined with one or more VLAN-tag keywords, for a total of 24 to 36 = combinations. (And these are not even exhaustive, as e.g. the use of ds-lit= e can increase the per-packet overhead for IPv4 packets by another 20 bytes= ). > > Ideally one would just empirically measure the effective overhead= and use the "overhead NN mpu NN" keywords instead, but that has issues as = measuring overhead empirically is simply hard... The best bet would be to l= everage BEREC to require ISPs to explicitly inform their customers of the e= ffective gross-rates and applicable overheads for each link, but I am not h= olding my breath. Over at https://openwrt.org/docs/guide-user/network/traff= ic-shaping/sqm we tried to give simplified instructions for setting the ove= rheads for different access technologies, but these are not guaranteed to f= it everybody (not even most users, as we have no numbers about the relative= distributions of the different encapsulation options). > > > > Best Regards > > "another" Sebastian > > as i said. i just started. lets see if i can find a better solution or a > clever way of auto detecting/measuring the overhead +1. One of my favorite feynman sayings is "disregard" and we need new thinking here. I note that I maintain anywhere between 6-16 flent (netperf and irtt) servers around the world, and they are mostly underused.... Sometimes I've thought that a "right" approach would be to send a 10 sec full udp burst, each packet pre-timestamped internally, at, say, 100Mbit... and then measure "smoothness" at the receiver and ifconfig interface (accounting for any other traffic along the way). > > Sebastian > > > > > > > --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740