Re: [Cake] Query on ACK

[Avakash bhat <avakash261@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

Hi all,
We had another query we would like to resolve. We wanted to verify the
working of ack filter in ns-3,
so we decided to replicate the Fig 6 graph in the CAKE paper(
https://ieeexplore.ieee.org/document/8475045).
While trying to build the topology we realized that we do not know the
number of packets or bytes sent from
the source to the destination for each of the TCP connections ( We are
assuming it is a point to point connection with 4 TCP flows).

Could we get a bit more details about how the experiment was conducted?

Also is this the best way to verify the correctness of our implementation?

Thanks,
Avakash Bhat

On Fri, May 8, 2020 at 9:11 PM Dave Taht <dave.taht@gmail.com> wrote:

> acks at the time you have reached a point of dropping them
> significantly have filled the pipe, also.
>
> What I saw here was that the first flow to really get going, and
> really get dropped, dominated over the others,
> because I thought it was consistently ending up in the priority queue.
>
> http://blog.cerowrt.org/post/ack_filtering/
>
> Look, all I'm proposing is this idea be tried and tested. Cynically...
> since there's a new model coming out as
> the result of this work, it immediately turns into something a good
> paper can hing on.
>
> On Fri, May 8, 2020 at 8:20 AM Jonathan Morton <chromatix99@gmail.com>
> wrote:
> >
> > >> The ACK filter runs on enqueue, so if a queue has only ACKs in it, it
> > >> will never accumulate anything in the first place...
> > >
> > > but the side effect is that on dequeue, it flips it into the fast
> > > queue drr rotation, not the slow, so it can't accumulate
> > > as many acks before delivering the one it has left.
> > >
> > > Or so I thought, way back when....
> >
> > The ack filter converts a stream of acks that might be treated as a bulk
> flow into a sparse flow, which is delivered promptly.  This is a good
> thing; an ack should not be held back solely to see whether another one
> will arrive.
> >
> > I think of it as an optimisation to reduce delay of the information in
> the ack stream, not solely as a way to reduce the bandwidth consumed by the
> ack stream; the latter is a happy side effect.
> >
> >  - Jonathan Morton
>
>
>
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
>

[-- Attachment #2: Type: text/html, Size: 3218 bytes --]