From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 8C5183B2A4 for ; Fri, 8 May 2020 02:50:50 -0400 (EDT) Received: by mail-io1-xd33.google.com with SMTP id w4so800194ioc.6 for ; Thu, 07 May 2020 23:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4XnFBnGr43qCOC8ft3QrLvLWdYAi3rJtyU/hWGZozf4=; b=QJKoQJIbYj8JEGo4LkCWWWS+Pz3BNvSA8XXRgV/5d3VhCjlC5yVyyUbzoMeYMDfjWy Pf09yoT3fg/uJesTBYgUVf0Er/hKpQFPwGL7UUJa8jKCNWWSdNadxM5r0zMQDhzpQ/YH bDQEtMzUS1Bcx0nf4K3zwpXlzNbselHw3GIQ1DRXx92CV9JVXT1vkXTx6i7fUYfNc30O D82i4YzR2CqvAoETc0XMVU+YQsXgKgA3WRSBzBl77m2k29ts4YPRLufFPEuz6/3MWPl0 wB1meWpWEjrZkRqnAfrKKuyI/RR6U4NB1f/DCxDmDzBAPHLXIPKt8av9brMLCRhZoBV4 s0sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4XnFBnGr43qCOC8ft3QrLvLWdYAi3rJtyU/hWGZozf4=; b=bv4xWwdjzkD3espFeucH3KZUc3mTZ2B74c3Y4TFhdgE64j3N7lDo8HOHzXHlMVfSa6 c7mnUfUjycJ6uvapwWvwk3YXdBJxrijFuRa595C949ZvyG+ndGqWPJFuTx2LgOJZNk7L wRuugxBXX8wSQGH8PaNsbUqr/o3DbXWUFhRYHFhJofJvHSH/y5A9Usxt7qV6i45ANWBM PMwKZ/yJeW+u13Pz5Ct+AA5G+4NUQcDD+1zZ6ALjr4G7GKCGPW4Vm3TaJHJxdGzGE2fc B4jbsm7OBCGcTUvYdqjRrHfHQRrTGuxqbWbiEOGQHsAKhZoMCHCoMalQT60XA+z48QQS VuhQ== X-Gm-Message-State: AGi0Pubm+QZ4+JWS2MNKCIH4Zfu0+waqaQMihD77nLkhV6aO/Jf0VSDU y3GE+0aXfy7PrIitEdoIZLFWndwrr1M6XRfqh5M= X-Google-Smtp-Source: APiQypLGW4UgW5KfqFvdBINAacbDOjYk9WXm5D9nmja+mI/yu8Kk+ct425sU1z5ebnD5y4PS1oIZszSh7clCWOUtREk= X-Received: by 2002:a6b:510d:: with SMTP id f13mr1216505iob.25.1588920650019; Thu, 07 May 2020 23:50:50 -0700 (PDT) MIME-Version: 1.0 References: <87wo5okhbo.fsf@toke.dk> In-Reply-To: From: Dave Taht Date: Thu, 7 May 2020 23:50:38 -0700 Message-ID: To: Avakash bhat Cc: Sebastian Moeller , Vybhav Pai , Shrinidhi Varna , Cake List , "Mohit P. Tahiliani" , Deepak K Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 06:50:50 -0000 On Thu, May 7, 2020 at 11:36 PM Avakash bhat wrote: > > Ok thanks so much for the clarifications. > That cleared it up quite a bit. 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. so, please, go forth and duplicate the existing implementation, and ignore me, cause looking at this hairy code gives me a headache. anyway, to try and describe what I thought I saw an interaction with the scheduler back in the day. 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. 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. 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. > > Thanks, > Avakash Bhat > > On Thu, May 7, 2020 at 12:37 PM Sebastian Moeller wrote= : >> >> 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 pack= et's in a reverse ACK flow will be ACK with identical 5-tupel.... >> >> On 7 May 2020 08:44:59 CEST, Avakash bhat wrote: >>> >>> >>> Thanks for the quick response. I also had a followup question. >>> >>> If the ack filter adds the new ack to the tail of the queue after remov= ing 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 a= t the tail right? >>> >>> Thanks, >>> Avakash Bhat >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729