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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D9FAF3B29E for ; Wed, 6 Sep 2017 03:23:02 -0400 (EDT) Received: from [192.168.250.101] ([134.76.241.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ln8gj-1dH1032dGn-00hQuM; Wed, 06 Sep 2017 09:22:58 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: <915b0913-0ac5-c6b6-3771-752a9e41dff2@gmail.com> Date: Wed, 6 Sep 2017 09:22:57 +0200 Cc: Jonathan Morton , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: References: <915b0913-0ac5-c6b6-3771-752a9e41dff2@gmail.com> To: Dennis Fedtke X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:K6DnDWwiYn2dlNqV0Ke1OgC90RJpecfeuZOGglMyTHLh4K8m7aC hVNPHZr8hxEdMjEP4bAQ0K4BnlqsKq5KEHGSvBgmORh0AXJQAw9aWGzWlhCZ6DUf/OvH4Q4 j17lzuzqWs90LkMuIc1SiZVNErkVYShTJHeICY9JtJKXVw26CfjayBmbANZXjYiGH519STs 13rNgBpPzlu5pdbCLdvBg== X-UI-Out-Filterresults: notjunk:1;V01:K0:GbhbWJN8C/0=:8IRrGEyCzrjjUaJTlRlOtY caol9i2Yx3RZoo4nEXMsK6nPkS0Bkjc74cgRmKsCBb85kGDGdVRYyUxB4vGDELUPsBBwXrcOZ AeXpkuqhvDPGw7eWRnTwc4JA2CYI6sQ1sNFIMGuhN+tB9hzmRF/oQBitTAPSKsDkhzv1L5wRh bG4Cy9MXI0vttcZjt24R3wB/GEgBItfcBCl0nFYfqB86C9DDllFiLv4ZaH7DH/R4xv9dtOYUE 4XWq79eYxXx67ZgXcS7imDe3SiTh2rTJH9Y37xo16wfccK2hyPXXdI1ZTNW0gLwwQGdCzCiUa 6EDTDMHLcQ4FZSvsiUIIjobkYPJVHlUAesDXWG7++NdqP3/TVPtZNEzrmUdf7TfA03gmdQjEE lSXacaiMn7DUZ/FoQvXK6Qx5lEIAO2tfTyqhRYr6ARML+SKkfYZCHf3HNoNoipVYYsiP0BTZP wMr275dWpn5WKJahrbKRj4jDI38a9pXU0qq+Xkd6Ld0hT5dtEhqI4Q9uvln5lHMrKiaj/nVz5 Yyo9O9IyZ4Boi2rDJCU7dtMaCJVB/n6LWueF5CJbOfOX5qqqLO0BF+gGnXgskzyEAt2RyH9FH 2p8uuhv6x0EqvRbuN+JBfZXBSA/Ta+hyEyvc5x6PHB0Jp54kFyCLfDqdvPIDWhyCJD4ncZ2nt PRitb9lp/QiPUZDD4wLRjRrFMOpQZOKzrS8WFU3ZTD9RPZ0WvN+0/W4r20aJUNvSV1D1aT+5R J5ybxOLxK9wjw71x8hlMJY6vgx9jbN5yZUKIktFYpLzyVLhdTRmJ5Xt09VuKeHFUC1gmz6t2d imI4wqFsJLu8RuPEEvdvE+wo/qGkxke8raYruGMRFi8FAVVdTo= Subject: Re: [Cake] overhead and mpu 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, 06 Sep 2017 07:23:04 -0000 Hi Dennis, > On Sep 5, 2017, at 22:19, Dennis Fedtke = wrote: >=20 > Hi! >=20 > Thank you for all answers. > But for me this still makes no sense. > Assuming we have an ethnernet connection running over a docsis line. > docsis is able to transmit full 1500byte ethernet packets. > Lets say it is an 50 Mbit/s Line. (I dont know now how exactly docsis = works) > So to reach the 50Mbit/s ethernet speed the docsis link rate needs to = be higher 50,6 Mbit/s (50*1518/1500 ??) Exactly, but that is completely hidden from the end-user as = DOCSIS per standard offers speedlimits assuming 18 Bytes Ethernet = overhead. Now, unlike DSL-ISPs that often sell close to the physical = maximal capacity of a link, docsis being a shared medium with segment = bandwidth >> single link bandwidth DOCSIS-ISPs get away with this (even = though it raises fairness questions under congesting conditions). And as = recommended by CISCO (and other CMTS manufacturers?) DOCSIS-ISPs tend to = over provision the links so that in the typical case the measurable = TCP/IPv4/HTTP goodput is equal or larger than the contracted bandwidth. = That has the issue that it misleads typical customers into thinking that = the ISP actually guarantees goodput. Why do I say mislead? Well if you = look at the gross bandwidth (and let's restrict ourselves to the = ethernet overhead, diving into the DOCSIS details will only complicate = matters) and the resulting goodput for different goodputs, or better = let's look at the required gross bandwidth for 100Mbps for 1500byte = packets and 64byte packets: 100 * ((1500+18)/(1500-20-20)) =3D 103.97 100 * ((46+18)/(46-20-20)) =3D 1066.67 And the resulting percentual bandwidth cost of the per packet overhead = (at equal goodput): 100-100*((1500+18)/(1500-20-20)) =3D -3.97 % 100-100*((46+18)/(46-20-20)) =3D -966.67 % You quickly realize that there is a factor of 10 between those. Now = without congestion a DOCSIS ISP might still grant that, but under = congestion conditions it seems clearly suboptimal to split the gross = bandwidth based on goodput fairness instead of on gross-bandwidth share = basis... For a DOCSIS system the numbers still work, since the segment = gross bandwidth seems sufficiently hight to allow for 64 byte packets, = but for XDSL links where the gross bandwidth << 10 * the contracted = bandwidth it is obvious that guaranteeing goodput is a foo's errand. > But when running a speedtest it will still not show the full speed. = because of other overhead from underlying protocols (tcp/ip for example) Yes, there is a number of protocols that might or might not be = taken into account, like VLAN tags(s), PPPoE, TCP, IPv4/IPv6, = TCP-options, IPv6 extension headers, the HTTP header typical for browser = based speedtests. Unfortunately not all of those actually are visible = for the endpoints of a speedtest; you really need to get the effective = overhead for the bottleneck link. > So the ISP will set the sync rate even higher to compensate for that. Maybe, maybe not, some ISPs do overprovisioning some do not. = Personally, while I like more for the same price, I am a bit concened if = an ISP seems incapable to correctly inform about the to be expected = bandwidth... >=20 > But does this matter for the end user? As the 1500/64 numbers above hopefully show, it does since the = per packet overhead still is data that needs to be transported and will = "eat" into the available gross bandwidth pool. > In case of docsis does it make sense to account for 18 overhead? Empirically it does seem so. But please note that under = speedtest conditions (or under any condition where the packet size on = the loaded link direction stays constant) not accounting for the = per-packet overhead can be compensated by setting the shaper bandwidth = slightly lower ad so the effect of missing overhead can easily go = unnoticed, it will however cause trouble once a new traffic pattern uses = more smaller packets... > The user will enter 50mbit and it will work. If the isp has provided a = sligher higher syncrate. As I hope I made clear above this will only work for fixed = conditions in which the distribution of packet sizes on the link does = not change. >=20 > and the mpu setting. i don't know how cake handles this in detail. > How the overhead gets added. > lets i enter mpu 46. > And cake we set 18 as overhead. > Will this result in mpu 46 or 64? This will result in MPU 46 (as that is what you requested), so = an ICMP echo request packet with size 18+20+8 =3D 46 will be accounted = as 46 bytes and not like the 64 it really takes up on the link. As = shown, cake will first add the overhead and only compare the = packet_len+overhead to mpu and do max(mpu, (paket_len+overhead)). > Can someone debug the code maybe please? :> > I have the feeling with mpu 46 my pages lot a bit snappier. but could = be placebo. Under most conditions this difference will not matter at all, = since typically packets+overhead are larger than 64 byte, so how did you = measure to come to that feeling? Best Regards Sebastian >=20 > Thank you. >=20 >=20 >=20 >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake