From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id DA6B821F6E0 for ; Sun, 8 Nov 2015 11:24:17 -0800 (PST) Received: from hms-beagle.home.lan ([217.237.68.126]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lwnem-1aWpOO2lDc-016RlI; Sun, 08 Nov 2015 20:19:08 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 8 Nov 2015 20:19:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5638A4F4.2010701@darbyshire-bryant.me.uk> <87si4nntcg.fsf@toke.dk> <0196FDEC-50A7-4ECA-9973-1FD23FF2945A@gmx.de> <877flznq3f.fsf@toke.dk> <848953E5-8571-4B81-B67F-D4A7BA4A1F96@darbyshire-bryant.me.uk> <8737wnnpco.fsf@toke.dk> <563B86D4.6030704@darbyshire-bryant.me.uk> <563F21AE.5040506@darbyshire-bryant.me.uk> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:gqauuIzygIj6GLz288VY8a6IFyOLSAWGO/TzglpP5fumroxWpI8 tr3nJtcPzsde342osfoxZ75Tlx51Kxlk+L0x+DYKxBu1LUhlvomnH7akFsd/AyF1aisyHkH zCAUmiZTUrpZx0vpu+wcMvWuhD5r0EDb9Ns6ITF5LNyGp9+WRPG2JFLgVkb/5ugo6ZOxwHm Tp4AxelqZJSnWPyKu8YRA== X-UI-Out-Filterresults: notjunk:1;V01:K0:T1/KI7Trhqw=:OZDYNTpNrIkFL4OJYszzgN G2iEmgJKxUGOCitG/IlW5u1TTcwO2mM+Cjvg13w6vr4Y3b+iQl9eYvM+n4oLtsz5OkKRDJO2j 2mgwnMTbUVNTfucBwCihHPl2U819TZxovtlyaLjyC7+490Bb3Ra0RtUR3iwH5MOF2QTcpTGTm 1Eg6o7mbpl55MAJtwA23Gd/YgCT5pqhisNFti+uD6N+wm4/i95OR0FlUwZ7BKYGj9YQdR1P0G tChiaiNf3od9yXJEkLnQUoTdDL+3YPJGSP8d/VL7yN8fN0nMZ7LoKlhIr+wtmrrrCyLYkwoLU 7wDhk9AhZ9xthtLzEi0uqs2fTBTMIRXXh1ivoT5YBNwFLt/3uRILSRxqpZH76EyFGStIzWC91 RQKV8IapqLUWSC+dfh9wGXFYgm8EGMoEv5dOWrAqGWpq42jXo2g+TIFWQ8d/jlCNrw8VqwAgM f0KEMmyopo7IdWxzH8FVgzOvPFE2AuDO/PLeGq8LUhpfZ/GKrHohE8XYxmr+f/sQ46y9zHgBE 0F3SlLN5VfrozmbykB59wj905leQOGwaJrZQer7uy73ZZ16HNZH3izEj4v7dDtZljWoXjw/8k E6hYx+6aLERZoX0SuX61WeYJY3loVBJHc9ih3mYNJL+pW5QHEeAeee4v1LIbC1Gxb6cVlsioR AqFxH5/GqS4QQ8ZOmUBBp3mW+Dzh9IhTu5p4J4JZTb/9aobeHqzZSAP1H7C2EEbVIgandzVoE nuKJDRf0bH4IK5qWop+8shKnVS3rbZQFuwtyS62U2r4EaFa4+/7E5zt3zHEPRZOTIjF2cV3gy tUjaaQ+ Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] More on 'target' corner cases - rate/target/interval confusion? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 19:24:40 -0000 Hi Jonathan, On Nov 8, 2015, at 17:36 , Jonathan Morton = wrote: >=20 >> On 8 Nov, 2015, at 12:19, Kevin Darbyshire-Bryant = wrote: >>=20 >> Whilst I was there I also subtly tweaked the diffserv4 video tin >> bandwidth allocation to 11/16ths rather than 3/4. In combination = with >> voice (1/4) it meant that (theoretically) best effort could be >> completely starved, let alone bulk - it doesn't seem to actually = happen >> in real life, but setting video to 11/16th & voice to 4/16th means = that >> there's 1/16th to be fought over between best effort and bulk - and = best >> effort as a result does seem to get a little bit more of a look-in in >> the face of 'more important' competition. >=20 > Actually, the =93threshold=94 mechanism doesn=92t implement the = priority queue at all, but only switches the underlying DRR weights = between =93priority balance=94 and =93bandwidth balance=94. Since it=92s = fundamentally DRR, and the weights of the queues never go to zero, there = is no possibility of starvation. Additionally, the threshold mechanism = itself =93borrows=94 bandwidth from lower tins to serve higher ones - = this is a holdover from an earlier version when there was indeed a = separate hard shaper per tin. >=20 > It *is* possible that the per-tin choices of target and interval might = want tweaking, but it=92s probably best to have some hard data for the = effects of doing that. One possibility is that target should be tuned = for the worst-case (minimum) bandwidth under maximally saturated = conditions, rather than the raw threshold value. Interesting, in sqm-scripts I opted for only adjusting for the = total link bandwidth to keep things simple; I always felt this needs = reconsideration, so setting the target for each Tin seems reasonable. In = sqm-scripts I just added the target increase (target - 5ms) to interval = to avoid target >=3D interval, also I believe that if a full MTU packet = takes Xms on the first hop the expected RTTs will be that amount larger = compared to a normal/faster link. (So far we have looked at each = direction independently, which probably is not fully correct, but at = least for asymmetric links I hope we can just ignore one direction). I always argued that interval should be increased to keep the = target to interval ratio close to the ideal. And I have pushed this idea = on the cake list quite offensively ;) Looking at sch_cake and = discussions with you, Kevin and Toke make me wonder whether, especially = for low bandwidth Tins this is the right thing to do. Increasing interval will reduce the responsiveness of the shaper = as it will wait longer for flows to react (even though most flows = probably will react quickly, it will just take longer to reign in = unresponsive flows), so for really slow links adjusting target and then = multiply by 8 or 20 will lead to a rather sluggish controller? = Increasing target/interval above 10% should simply sacrifice a bit more = responsiveness-under-load for more bandwidth utilization? So both = adaptation methods have the potential to counter-act cakes design goal.=20= What are the options besides: 1) target set to worst case for each Tin, keep interval at set interval = or at target, what ever is larger 2) target set to account for the link=92s MTU transfer time, keep = interval at set interval or at target, what ever is larger 3) target set to worst case for each Tin, interval at set interval or = 8*target, what ever is larger 4) target set to account for the link=92s MTU transfer time, interval at = set interval or 8*target, what ever is larger 5) target set to worst case for each Tin, interval at set interval plus = target 6) target set to account for the link=92s MTU transfer time, interval at = set interval plus target What are the relevant bandwidths to test this at? Best Regards Sebastian >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake