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 2E1D53BA8E for ; Thu, 26 Apr 2018 03:43:36 -0400 (EDT) Received: from [172.16.11.125] ([134.76.241.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MSdRI-1emPjM1su4-00RUxE; Thu, 26 Apr 2018 09:43:32 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sebastian Moeller In-Reply-To: <46C6A124-61F3-4503-B310-C55D46597EED@gmail.com> Date: Thu, 26 Apr 2018 09:43:31 +0200 Cc: Kevin Darbyshire-Bryant , "cake@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: <51A5A6AB-4B1C-4795-8136-9EB63E59598B@gmx.de> References: <87vacf3th7.fsf@toke.dk> <46C6A124-61F3-4503-B310-C55D46597EED@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.6.18) X-Provags-ID: V03:K1:mb2QH75QQHT4IWElQQ0+Jgrn7143pw+sVddcxRt5UCjl+GVPt3y oAqcCiW7Hefn7QCZ5irOBP2e653uDJ8YzMGnoBtDijLKuDdI8vmpqrSWwljiTZPi4ip320N kfRrG2IzOM+pnDo1G+czIPnUGHAo4BzheR6WyWdhmmfBl3z+a1s86kCiVZ8riHJGG1df2o3 faU4t38qrm9+BSdv1ud7Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:jBEAVWkYhe8=:nklcFJ2hjVGPSxJ5lP4Qym sudcfTsoR90GZI1Hidx+578XoK1qyWo7xnbZB2tdzNGyUyAst3MdS+7gXEJpPF4tqTspdsIql mAQxaIrJMOWae1wJqhd5tdmUVAHxvWyuE0K7QjVcjEVQTrc8zZg7fmb6/4LwUSmowBIX6bmSq m5Ue9c9BHXsVlSEyBZ07EZfArLBYtypviKSQdLTQUNqQIX1sMJyxt7Ofbha0YptuUFzAU9iW1 JcfWqNhHoF1xlh5kK/bgeZYzTU1kHTH6fFN+VspXD9TxHb3YtNi4BaSkz/AISR6wxRF99WC93 lU5UYBNNzni4hp9yY1EloRWjPTw3eRKWw5mS4fHIQFbopFNKwdbj8WAwN/O7eF+86s0WX6o8g aRGyWSsVeNpaIVQ10MDxaJ2H1/nnnbdhsEAeOc4HhVbFEukk+54FEVdw3KHpyX7oOIKdgXERh QpiEgoerfof+ex2uzwC3kZnSd1mqRIMT0p718E5ivwigNAPH+gx93CCquRAMmxecZYcX4PAfR tiSKssD8x8lY83AizhZVw/6eUcTONxGdisnWgTGEoGk/O4DnfY1aQBN5SpVN8Itpf3wiNo7q7 JEjwjU94DfIphIPGTykZKKWbrQnX8j58Z5+es56sLmvvkDChBUOERfRQLvFqj62LBQP2vy7eX klApSgg2upBBOOmT+OS7pNR7gLroLgwAinynzgf3LqjaL3x8kM1BVzUHJ4Ze48XquMze4ICy8 G5DOUFhURuDSLTIbXF/MgzSiKA30MewZ2HQTlCVFfGpDNq36pSzhC/mAJjE/UxMOV6UjUafPc plFEXEOYsBTEciLJyJXNC3YITvzBGV/QgbroDY1xEqk3xSAZ8c= Subject: Re: [Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed 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: Thu, 26 Apr 2018 07:43:37 -0000 > On Apr 26, 2018, at 09:26, Jonathan Morton = wrote: >=20 >> Genuine question: I have a superpacket circa 64K, this is a lump of = data in a tcp flow. I have another small VOIP packet, it=E2=80=99s = latency sensitive. If I split the super packet into individual 1.5K = packets as they would be on the wire, I can insert my VOIP packet at = suitable place in time such that jitter targets are not exceeded. If I = don=E2=80=99t split the super packet, surely I have to wait till the end = of the superpacket=E2=80=99s queue (for want of a better word) and = possibly exceed my latency target. That looks to me like =E2=80=98GSO/TSO= =E2=80=99 is potentially bad for interflow latencies. >=20 >> What don=E2=80=99t I understand here? >=20 > You have it exactly right. For some reason, Eric is failing to = consider the general case of flow-isolating queues at low link rates, = and only considering high-rate FIFOs. >=20 > More to the point, at 64Kbps a maximal GSO packet can take 8 seconds = to clear, while an MTU packet takes less than a quarter second! I venture a guess that it is not so much the concept but rather = the terminology that irritates Eric? If at all Superpackets lighten the = kernel's load and will in all likelihood make in-kernel processing = faster which if at all decreases latency. The effect on flow fairness = that we are concerned about might simply not register under "latency" = for the kernel developers; I am sure they see the issue and this is = really about which words to use to describe this... Also I point at the = fact that Eric did not object to the feature per se, but rather the = unconditionality and the rationale. Now, I also have no better description than saying that each packet = delivered will cause HOL blocking for all other packets and the larger = the current packet the longer the other packets need to wait so = inter-flow latencies seem pretty much affected by GSO. I really liked = you initial idea to make the threshold when to segment a superpacket = based on the duration that packet would hogg the wire/shaper, as that = gives an intuitive feel for the worst case inter-flow latency induced. = Especially this would allow on many links intermediate sized = superpackets to survive fine while turning 64K "oil-tankers" into a = fleet of speedboats ;). This temporal threshold would also automatically = solve the higher bandwdth cases elegantly. What was the reason to rip = that out again? E.g.: if we allow for 1 ms serialization delay 64000*8 / (1 * 1000 * 1000 * 1000) =3D 0.000512 X =3D (64000*8)/0.001 =3D 512000000 / 10^6 =3D 512 Mbps We will still be able to send unsegmented maximal sized superpackets in = <=3D 1ms with speeds >=3D 512 mbps (denoting that the 1 Gbps threshold = aims for ~ 0.5 ms serialization delay) Best Regards Sebastian >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake