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