From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 052CB3B2A3 for ; Sat, 22 Apr 2017 12:38:24 -0400 (EDT) Received: by mail-wm0-x22c.google.com with SMTP id o81so34917958wmb.1 for ; Sat, 22 Apr 2017 09:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=61OVihk8GJMfKwbPc4K5OfKKPJUh+FUG127OPrgVWR4=; b=kK4YmL4+7G8aZbpS4N/Ob8viOBKVmHanq9/4Wngq1aE5m1aF2LcnxpUWo6XIFOfeUH a/5EQdKbRJfrPcjnn5bDULxsUuTmWqnBqIkvFbCruMG3fVrrtmSnoo9EOGgTPUK3xuzH l0Bsi4gJvjlUGENLXS9IKNLDJCFuiZ+DUBrOLuCeA2uCrGRD5etlVOGv/BModyMtdVrP SafWuC2mbBlw5rnd0LerA+3w0xqVrSPSqcJWaDHC4j5FKo/mgnOc7nGM3XfTvyam1r9W ZQnMI8Zs2WjANdQutHf5VBx3+140aK81GJbrO7R35js47OvR09sjwhsOgFbiGwQdmLRU EqJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=61OVihk8GJMfKwbPc4K5OfKKPJUh+FUG127OPrgVWR4=; b=W2c+4APUdn1p4MGmcbjdUpzuYmd24Y9qdJH8RrFyKzg7I8V0pwI0Y/kxJlXzS6/xu2 m39gW0nitHn7ZFR1q3Bsm7BWD6rr/w9CHI+jHv0b4hB/zZ18+0frUzaCqWk15VjDeiIW vvYiT+5BifEWMom4fW9o2s2jE4YJaAP+AL0XhtAUM+b0WHI5c/QtIC6ZkscZaPCwglTG dmW4JFpSlJA2fjjhFK++K+vgb8RTyv0lmrwJPRlIaDefTI+ASEkOKAwClr4dz7xvGxSS 1Cl3ARJc8oe0jNuOkCpAd+Yg/dEfj9aOljJIFozJvHrhwOZEAJrc2H43k2HJDHBF01KL 6X0w== X-Gm-Message-State: AN3rC/7Ze2E767QeWtUyIAkRdu5LV5bU/LUYbof/PEl1h0mq44bxRj2J iEg2SUGO+RZn6IrK X-Received: by 10.28.183.70 with SMTP id h67mr3262870wmf.115.1492879103453; Sat, 22 Apr 2017 09:38:23 -0700 (PDT) Received: from [192.168.0.3] (185.182.7.51.dyn.plus.net. [51.7.182.185]) by smtp.gmail.com with ESMTPSA id c34sm2957378wrc.7.2017.04.22.09.38.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Apr 2017 09:38:22 -0700 (PDT) From: Andy Furniss To: cake@lists.bufferbloat.net References: <05C0B0C7-4337-4115-AC6B-DA81392FCB34@gmail.com> <22E633CF-5EE0-4B0F-89A8-B790E730FB6C@gmx.de> <37ea1abc-8c08-784c-0873-ed6df8d089ca@gmail.com> <8ab8a7e3-3946-a555-ef76-e0acfc16eda8@gmail.com> Message-ID: <199f5c68-bdd9-255b-2ed3-27a855b16d3d@gmail.com> Date: Sat, 22 Apr 2017 17:38:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 SeaMonkey/2.51a2 MIME-Version: 1.0 In-Reply-To: <8ab8a7e3-3946-a555-ef76-e0acfc16eda8@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Cake] Getting Cake to work better with Steam and similar applications 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: Sat, 22 Apr 2017 16:38:25 -0000 Andy Furniss wrote: > Andy Furniss wrote: >> Jonathan Morton wrote: >>>>> So please add “atm overhead 32" to cake on eth0 or “atm >>>>> overhead 40” to cake instances on pppoe (these packets do not >>>>> have the PPPoE header added yet and hence appear 8 bytes to >>>>> small). >>>> >>>> Thanks for your help, will definitely use them. Just wondering >>>> if I use "pppoe-vcmux/bridged-llcsnap" on eth0 or >>>> "pppoe-llcsnap" on pppoe0 would have the same effect? Or are >>>> there some other "under-the-hood" changes when using them? >>> >>> On the pppoe interface, use pppoe-vcmux if your modem is set to >>> use VC-MUX, or pppoe-llcsnap if it’s set to use LLC-SNAP (they >>> might be described using slightly different terms, but should >>> still be recognisable as one or the other). This probably >>> depends on your ISP, and may further vary regionally within the >>> same ISP. >>> >>> I really prefer to use the self-explanatory keywords (which is >>> why I added them in the first place) instead of opaque magic >>> numbers. This is a point on which Sebastian has long disagreed >>> with me. >> >> Either way (or maybe not!), what about the observation that >> attaching cake on pppoe, for me at least, required the use of the >> raw param due to the "auto compensation" mechanism seeing pppoe as >> +8 when the actual packets are just ip len so not +8. > > My case is not atm though, perhaps the atm param cancels out all > other auto overhead compensation? Though that wouldn't really make sense for other use cases like shaping on a real eth for some remote atm link. Checking my not atm pppoe it seems without the raw param I would actually be 14 + 8 bytes wrong. tc qdisc add dev ppp0 handle 1:0 root cake bandwidth 19690kbit raw overhead 34 diffserv4 dual-srchost nat rtt 200ms results in - qdisc cake 1: root refcnt 2 bandwidth 19690Kbit diffserv4 dual-srchost nat rtt 200.0ms noatm overhead 56 via-ethernet Random rambling on dual-srchost vs default triple - if I were to shape ingress, which I don't because my ISP does it again now, I think dual-srchost would be better in practice for home use. This being because the CDNs of youtube or TV streamers - well blippers :-) like the BBC netflix etc. may well mean that users that should be separate get somehow lumped together - basically any assertion that it's rare for different users to be downloading from the same remote server doesn't really apply to streaming services.