Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Shefali Gupta <shefaligups11@gmail.com>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Testing Scenarios for Validation of Ack_Filter implementation in ns-3
Date: Mon, 29 Apr 2019 03:17:50 +0300	[thread overview]
Message-ID: <CCD603A1-7DBC-473E-9FE6-F0D901404D22@gmail.com> (raw)
In-Reply-To: <CAFp5xQ5BBNZF-eTiZo+uZYc+M1zWZYpA2rtaXUeo-ifgRmVM2Q@mail.gmail.com>

> On 22 Apr, 2019, at 2:45 pm, Shefali Gupta <shefaligups11@gmail.com> wrote:
> 
> It would really help if you could suggest the testing scenarios so that I can validate Ack_Filter implementation in ns-3.

It may help to understand the design intentions of the ack-filter:

1: Reduce the bandwidth consumed by pure acks, and possibly also the latency of the ack stream.

2: Avoid losing any relevant information from the ack stream.  This particularly includes not erasing any "tail" acks and not interfering with any SYN, FIN or RST packets.

To test the latter, you really need a correctness analysis, but it should be sufficient to observe no reduction in performance across a wide range of scenarios, including those involving application-limited workloads (with a lot of tail acks), many short flow starts, continuous transfers with various amounts of packet loss in the forward direction, and cases where ack-filter activity is intense.

That last scenario will involve a demonstration of point 1, which is best achieved by setting up an asymmetric link, then running one flow over the "wide" direction but many flows over the "narrow" direction.  A 10:1 bandwidth ratio with a 1:50 flow setup should do the trick.  The ack filter should greatly improve the throughput of the single, fast flow, and also free up a little bandwidth on the slow side for the many flows.

As an aside, in the current Cake version we treat the former NS bit the same way as the ECE and CWR bits in the ack filter, so you may want to ensure this tweak is also made in your version.  This is to improve its behaviour on SCE traffic.  The change should have no effect on non-SCE traffic.

 - Jonathan Morton


      reply	other threads:[~2019-04-29  0:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-22 11:45 Shefali Gupta
2019-04-29  0:17 ` Jonathan Morton [this message]

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=CCD603A1-7DBC-473E-9FE6-F0D901404D22@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=shefaligups11@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