From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 97A6B3B2BD for ; Sun, 19 Jun 2016 14:37:40 -0400 (EDT) Received: from [192.168.42.15] ([80.187.112.115]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lz3rc-1bRg6E0ybA-014BcI; Sun, 19 Jun 2016 20:37:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Sun, 19 Jun 2016 20:37:40 +0200 Cc: "cerowrt-devel@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: <01C6A933-D65F-4CCC-84C2-86B2CFB62601@gmx.de> References: To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:bqKA9S7lS5vdbWzrSuHx33n1ng+cucCXCKEfOrvL7o3rasAjjL3 TAvonygwOezeRnb2StiEkxA4Y0kUzJjgVRCbZZApsB6woXK6jJFauH6dCuZdOSMsZEfWnnr 6+TjdU3WLc3k4nX4KsQrj9P66irnYIc5NP0Efs+Vm0O1AwgQf7CNPc1S+yB/TNql04wJI2s 2QC/8H3UtChVzg+E1qVJA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Ad4+v3aye54=:i/b7LOE1dozkgAmYripVo3 cA06kAC3A55aWSa+C4Z+KpS6PkGz2gUERcadYZ5T16eQb9ouWOefAPgnaMFTk5anzp0SFw5x5 VUZTEikU/jlEZjuC1oGj4mkl3nW7GVhn6p2pOmSc04RtLvUAk/M93mun0kfq3r2zPiMifRqZV UGmx6bihuZbbZKD5t4IYVyf5s7Fk1/u2tw9xIhyJsyj31PFaf2ql8Vqhia5WGRPo4r0oWkLf9 45Etpo71BL0Xh2hls+r2c2omBn6+FrMCouxEmcGMobFDdJjhDR4ZY3cXXSm2/u9ABy/ypo37f pVJ20NHujAh4gp2c1gT0BgCNEDZJ4NiErJqzL0an1d3ogcXRxOHHQ+rcFY44G6m+zFimFgnI1 jonfN5E05rNcrraxMZMSTrL4MSVABuSxQhhJGFbm8oiSREvwcKMprdYw3bsErgsw0JyX6N/3R GB15vnXYfM8QT1Cg7Ga0hhmo0LJN5cql91PgL8Lg0lMZLGIZWTs7rVgVU9QJ5E/N2erOxU4Bi q/LFRKCM/kwuY1yX/rWsUIaOJvpITFUZmNj7Q+eMBqlq5ezF8zuixDPFERbvZQwQ3uVi2ah8P OXzn7I9OycsVEGuwGxp1bHLs1JztnLr6gBNGvVxtjWvO484HwG9gW+TO2C80JljkhoemZxZc5 5KcImRoY16ZgMWRMg6DLyw56Ief6t9EIWotBqhiIdkDUzKLMUknxDymxsJoZcsM9BtX9yqAT1 cYKiAoVnBIXKmcc1AGfjcc/Ic2fwW70lxBSb1IcBsJGg+RS2D4QunN9STbdW10lkkWM3Ybf2Z ccmtlIgj5n50lZO97Bp2K/GbLvYNg== Subject: Re: [Cerowrt-devel] qos calculator & paper for htb rate selection X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 18:37:40 -0000 Hi Dave, > On Jun 19, 2016, at 02:53 , Dave Taht wrote: >=20 > I do keep hoping that one day we'll just be able to plug values into > an equation and come up with the right =E2=80=9Cthing". Well, define =E2=80=9Cright=E2=80=9D and =E2=80=9Cthing=E2=80=9D = first ;) >=20 > Anyway, this paper had some pretty graphs and some severe flaws - like > only using long flows, not emulating longer RTTs, nor experimenting > with speeds greater than 40mbit. Some of the results, I think, hold, > but I'd have to think about it. I was attracted to reading it because > it attempted to take our "85%" rule for sqm-scripts on downloads and > attach some science to it=E2=80=A6 Oh, I have a theory about that. As far as I can see when the = =E2=80=9Cfolk=E2=80=9D recipes evolved a lot of folks were using ADSL = links, and the 48/53 encoding of ATM cells eats up 100-100*48/53 =3D = 9.43 % of the available bandwidth right there. Add to this the typical = ADSL overheads of say 32 bytes past the 1500 MTU limit you end up = incurring another 100-100*1500/1532 =3D 2.09% of overhead for a total of = around 11.4% (well actually it is 100-100*1500/1536 =3D 2.34 % due to = the fact that in AAL5 each packet gets an integer number of ATM cells). = So any shaper set to more than 100*1500/(32*53) =3D 88.44% of link = bandwidth should not have been very effective; combined with the = observations that a) people prefer round numbers and b) that especially = downstream shaping/policing works better with more than the minimum = required shaping anyway 15% seems like a reasonable recommendation.=20 I would guess that this probably developed by pure observation = without being backed by =E2=80=9Cmath". Now people on other link = technologies than ADSL might have sacrificed a bit more bandwidth than = absolutely necessary*, but since that would still lead to a working = configuration, I assume no one cared deeply enough? Tl;dr: The 85% has some backing in real link technologies used, that the = paper completely glosses over=E2=80=A6=20 Now I might be somewhat =E2=80=9Cobsessed=E2=80=9D with trying = to understand how per-packet-overhead and encapsulations affect = on-the-wire bandwidth for different traffic patterns on different link = technologies, but a bit more research in the reality home-users face, = might have improved the applicability of the proposed solutions=E2=80=A6 = AND they also do not consider the case typical for bit-torrent = situations where a stampeding herd of shortish ingress flows cause = sufficient back-pressure to actually flood the real bottleneck links = under-managed buffers=E2=80=A6 The weird thing is they mention that = their solution should work for DSL links, while I am certain it can not, = given that at the upper end of ADSL links, like 16Mbs for AnnexJ the = recommended shaper percentage of 87.5748 % is really to close to the = effectively available link bandwidth of around 88.4% that their solution = will not offer much safety margins=E2=80=A6 and at an adsl bandwidth of = 22 Mbps (as far as I know the theoretical maximum for ADSL) the = recommended 89.7557% will not work at all. Now the authors could assume = that users do link layer accounting first and only apply their shaper = rate to the =E2=80=9Creal=E2=80=9D user visible bandwidth, but then = 88.4*0.897557 =3D 79.3440388 is damn close to the 80% recommendation = they just tried to debunk=E2=80=A6 As so often, I have to admit I am confused=E2=80=A6 Best Regards M. *) I just started looking into what happens on DOCSIS links, and all I = can say right now is that DSL starts to look logical ;) >=20 > http://sci-hub.bz/10.1109/TNET.2014.2366496 >=20 > --=20 > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel