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-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 082283B2A4 for ; Fri, 8 May 2020 03:41:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588923707; bh=9pEs1xSMTyk6oSYPtBAxY0w5RfY5mI57UcvuIrWs3hM=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=KXhfcMtBuRjXzoE6FKDvHWLibR+2tDX7If5TCkhSoyTZ1k4+KOM7+H8aPxQkswVRn t39lDcNbNHcY09AHAez2p10b5jwtQVZFs4eIz945tY9DA9tRijVb+8sPfwYZP6oBZ1 qn5fenpkQrR2q8nslbshap1nLozeHnua/MMXfVlw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.16] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MeU4y-1iwnTb0jv2-00aWos; Fri, 08 May 2020 09:41:47 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 8 May 2020 09:41:45 +0200 Cc: Avakash bhat , Vybhav Pai , Shrinidhi Varna , Cake List , "Mohit P. Tahiliani" , Deepak K Content-Transfer-Encoding: quoted-printable Message-Id: <63D392A7-ACE8-4A8A-A68E-51F22F09DD72@gmx.de> References: <87wo5okhbo.fsf@toke.dk> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3445.104.14) X-Provags-ID: V03:K1:k34OoVgWlrXCp8iDivAyMVFLOnDTCF94m7SW2Wq2/x87vmcmYAU xX4VX7E8n0y/oHkbhKBx/yzs2W/cjgsXvLnQxGROnY4iihuH85qd6e3yIj5kW8E1qvzzM+N 6q+NarNsXfPq3Z505MCCeBwI63KtOo1HLS1tIVWJEDkgSiwhoXyy0Vp+QjCWXtkqE+jIJTZ PpXRcJJTY3Rb/FOczXYXw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:aLkBKMv86Hg=:5WYMMst18bKOmv9cX8Hx6N 7o0usB0hiVjcfVZ/PFuRGGH7W1qmDY4z4yLtYQEahdq860vtzTs01De+0L7QNnqaZLcs6SoDE T9AleIUZYNOWQpXcwrZcD2+YOQ0asRtOm3P5b9F+rVDMaS3N4r1WYQonr7pM3/yiUVMmuB27/ 1f/ykjV1JYDDd6JePucF+TnCexIbgc4crUzsnZCbOlsrT4FiEbN1n+jDKYOsFDLjGPKd7GAQ4 DgJUJIxR9hZQ1t5Wxc0YEPG+Au6MaAPDUUw3znF4eX2e5utGjY0nk0n2X5laks3iqNETgwfVk QkuQKmQ6oV3fBCBdIPRmWHFuwzfFRGqpXxXv6kO7cUaZsuncw42cTCbTxgoaR/VtKqGAspAvh HI33mMcGhYjkY/WEwZM5hQMHTzSrOlcJjCxV73SKWbRTqN5Dzq7srSj4C8z3QSLlfhz/7/p+B qNSKg1x2f/2WnLnwQ68La9NaNHV/6jRZf/Nzip5yFDSuw6lQXkGHXLVc6t5bABrHysfbRM5vR WQlXfhjAOin4q2ph4GeyFgZ/IqOnxXalx51l1e7z8KY1/VBCCAuqviS4kS7hdbJImZ5UHX2ku jI3f2BimzPoJKWvpCL+CSzQjHyNWEThsrUCUbnh9VZWAXW5xWmABAWhPpUs4GoMXIpb6kekQJ D8wMs4GOKKhJPhDQ1Letozk88qRYMzPKGkAnVlfpt0u0BbxBiL8pjwcbuyxtNwz8wQKQWMgS7 +m6d7j8vkqVlhB8rl3W1hTbG0OC74kXYiusiI5LyFYJNd5O5fKnP1Abkch+kq36mI8RTax8dS tuFVL7FSraWnQqy8qI9hjj/Dw4V/8z0ER+/aVIprciSBm4BgDUHUNHvQh1gdeGladBRy0OWd8 wzBxBe61W+P+MeQ6mBIFIng3/pXd2Q6Mo3aZ5yeoPdxa3bSimaf8SvuGQrkioaLwQbr0DKH7a CNOs+2+8LpadyotFMXEFBRELRu1GOrSY5h1AaBfhZHuqmJ98+iwlJMRFrj3tVzOBp38ClGOVD 1o1F6t5iVlvpp3lJ82KUKy/Frs0hxOeLI5McvyebeSZrchXc4BCjqOEwXjF3N9vEG9sG1JmHm qXOGuqNwDtxFom2xUTaR20w/us1J9SOGtSJ4XwC7MI9Ywye6B5Aty9LtT/j3xXb7Sx3KrZPs0 1NttdXxVSiG5IpR48gg6dFf09OMxnS+Hv7F/l1NbIyoVHDegudL2DKh2wCo8NXLuNuPVCc+nn K2AvAKeA3BpfsmrPw Subject: Re: [Cake] Query on ACK 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: Fri, 08 May 2020 07:41:50 -0000 Hi Dave, > On May 8, 2020, at 08:50, Dave Taht wrote: >=20 > On Thu, May 7, 2020 at 11:36 PM Avakash bhat = wrote: >>=20 >> Ok thanks so much for the clarifications. >> That cleared it up quite a bit. >=20 > I note that there was something really subtle that could have been > done to improve cake's ack handling, and for all I know > it actually happened in the final codebase. >=20 > so, please, go forth and duplicate the existing implementation, and > ignore me, cause looking at this hairy code gives me a > headache. >=20 > anyway, to try and describe what I thought I saw an interaction with > the scheduler back in the day. >=20 > The ack-filter runs, deleting all but one packet from the ack queue, > and delivers that. > the scheduler runs, serves a bunch of other flows, then returns to the > ack queue, which has accumulated a couple more packets, > the ack-filter runs, deleting all but one packet from the ack queue, > and delivers that, but doesn't exhaust its qauntum > but now that flow is in the "fast" queue, and we service just a few > other flows, and return to it, delete a couple, service one... and > stay stuck in the fast queue. Why would that be a problem? In that case ACKs did not bunch up = (otherwise there would be backlog in the queue and it would forfeit its = sparseness boost) and hence delivering the only ACK in a timely fashion = should preserve the ACK clock, especially for non ABC-ACKs = (https://tools.ietf.org/html/rfc3465) that relay on ACK count? Sure, if = the single ACK had already matured a bit and immediately after sending = it a fresher ACK would have been enqueued that looks suboptimal, but = that race seems to exist no matter what? Now if the goal is to weed out = ACKs to conserve bandwidth, sure not filtering ACKs is sub-optimal, but = for the clocking? Side-note, whoever invented the term "ACK-clocking" seemingly had a very = fuzzy concept of what a clock is and what precision a clock can be = expected to deliver ;) Best Regards Sebastian P.S.: As so often, I might simple be confused about the actual = subtlety... >=20 > better, I thought, was once the ack filter exceeded the quantum of > packets for that flow in that drr round, even if it only delivered one > packet, > that it should always return it to the bulk queue, because tons more > packets would arrive in the interval between servicing > all the rest of the flows, thus more of which could be safely removed, > while maintaining a steadier clock for tcp. >=20 > I've already seen cake remove over 25% of all ack packets with no harm > to the other flows. So for all I know (and I'd have to > look) it's already doing it this way. >=20 >>=20 >> Thanks, >> Avakash Bhat >>=20 >> On Thu, May 7, 2020 at 12:37 PM Sebastian Moeller = wrote: >>>=20 >>> I think that you will remove all redundant Backs in one go = considerably advancing the new ACK in the queue. And more importantly, = in most relevant modes cake will apply one queue per flow = stochastically, so almost all packet's in a reverse ACK flow will be ACK = with identical 5-tupel.... >>>=20 >>> On 7 May 2020 08:44:59 CEST, Avakash bhat = wrote: >>>>=20 >>>>=20 >>>> Thanks for the quick response. I also had a followup question. >>>>=20 >>>> If the ack filter adds the new ack to the tail of the queue after = removing an ack from the queue, won't it be starving the ack? >>>> The replaced ack was much ahead in the queue than the ack we = replaced at the tail right? >>>>=20 >>>> Thanks, >>>> Avakash Bhat >>>=20 >>>=20 >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >>=20 >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >=20 >=20 >=20 > --=20 > Make Music, Not War >=20 > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729