Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Avakash bhat <avakash261@gmail.com>
Cc: Sebastian Moeller <moeller0@gmx.de>,
	Vybhav Pai <vybhavpai1999.vp@gmail.com>,
	 Shrinidhi Varna <shrinidhivarna.171co145@nitk.edu.in>,
	 Cake List <cake@lists.bufferbloat.net>,
	"Mohit P. Tahiliani" <tahiliani@nitk.edu.in>,
	 Deepak K <deepakkavoor99@gmail.com>
Subject: Re: [Cake] Query on ACK
Date: Thu, 7 May 2020 23:50:38 -0700	[thread overview]
Message-ID: <CAA93jw6xZRcUerJ8JuxjtjW2_C+wyAUKRtqDojPj6hLdg1w0Dg@mail.gmail.com> (raw)
In-Reply-To: <CAC8NkTBRWrhAQneAf6ZacTzWLYyM5TqX6jmD4-fafAD=7iPgfQ@mail.gmail.com>

On Thu, May 7, 2020 at 11:36 PM Avakash bhat <avakash261@gmail.com> 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 <moeller0@gmx.de> 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 packet's in a reverse ACK flow will be ACK with identical 5-tupel....
>>
>> On 7 May 2020 08:44:59 CEST, Avakash bhat <avakash261@gmail.com> 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 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?
>>>
>>> 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



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

  reply	other threads:[~2020-05-08  6:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 18:43 Avakash bhat
2020-05-06 19:01 ` Jonathan Morton
2020-05-06 19:13   ` Toke Høiland-Jørgensen
2020-05-07  6:44     ` Avakash bhat
2020-05-07  6:59       ` Jonathan Morton
2020-05-07  7:07       ` Sebastian Moeller
2020-05-08  6:36         ` Avakash bhat
2020-05-08  6:50           ` Dave Taht [this message]
2020-05-08  7:41             ` Sebastian Moeller
2020-05-08 15:08             ` Toke Høiland-Jørgensen
2020-05-08 15:11               ` Dave Taht
2020-05-08 15:20                 ` Jonathan Morton
2020-05-08 15:40                   ` Dave Taht
2020-05-25  5:17                     ` Avakash bhat
2020-05-25  9:42                       ` Jonathan Morton
2020-05-25 11:58                         ` Toke Høiland-Jørgensen
2020-06-14 12:43                           ` Avakash bhat
2020-06-14 14:43                             ` Jonathan Morton
2020-06-16  5:22                               ` Avakash bhat
2020-06-16  5:31                                 ` Dave Taht
2020-06-16  5:32                                   ` Dave Taht
2020-05-08 17:43             ` [Cake] Curious regarding Cake sensitivity to hardware queue depth David P. Reed
2020-05-08  8:23         ` [Cake] Query on ACK Sebastian Moeller
2020-05-06 19:08 ` Toke Høiland-Jørgensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw6xZRcUerJ8JuxjtjW2_C+wyAUKRtqDojPj6hLdg1w0Dg@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=avakash261@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=deepakkavoor99@gmail.com \
    --cc=moeller0@gmx.de \
    --cc=shrinidhivarna.171co145@nitk.edu.in \
    --cc=tahiliani@nitk.edu.in \
    --cc=vybhavpai1999.vp@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox