From: Jonathan Morton <chromatix99@gmail.com>
To: Avakash bhat <avakash261@gmail.com>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
cake@lists.bufferbloat.net,
"Mohit P. Tahiliani" <tahiliani@nitk.edu.in>,
"Vybhav Pai" <vybhavpai1999.vp@gmail.com>,
"Deepak K" <deepakkavoor99@gmail.com>,
"Shrinidhi Varna" <shrinidhivarna.171co145@nitk.edu.in>
Subject: Re: [Cake] Query on ACK
Date: Thu, 7 May 2020 09:59:49 +0300 [thread overview]
Message-ID: <8258F6F9-0754-49C7-BEEE-92AE7A944B1A@gmail.com> (raw)
In-Reply-To: <CAC8NkTCYBokx0NedyuOKjhZqUMHXAc5tZtObTpdyjkvE4U_zUw@mail.gmail.com>
> On 7 May, 2020, at 9:44 am, 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?
No, if you are doing this on enqueue, then you are comparing the new ack with an ack immediately preceding it in the same queue, which will also be at the tail. And if you are doing it on dequeue then both packets were enqueued some time ago, and both are already due for delivery very soon.
In general, the second packet is delivered sooner, in place of the first one that was removed. This means it reduces feedback latency to the (forward path) sender.
- Jonathan Morton
next prev parent reply other threads:[~2020-05-07 6:59 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 [this message]
2020-05-07 7:07 ` Sebastian Moeller
2020-05-08 6:36 ` Avakash bhat
2020-05-08 6:50 ` Dave Taht
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=8258F6F9-0754-49C7-BEEE-92AE7A944B1A@gmail.com \
--to=chromatix99@gmail.com \
--cc=avakash261@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=deepakkavoor99@gmail.com \
--cc=shrinidhivarna.171co145@nitk.edu.in \
--cc=tahiliani@nitk.edu.in \
--cc=toke@redhat.com \
--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