<div dir="ltr">Hi all,<div>We had another query we would like to resolve. We wanted to verify the working of ack filter in ns-3, </div><div>so we decided to replicate the Fig 6 graph in the CAKE paper(<a href="https://ieeexplore.ieee.org/document/8475045">https://ieeexplore.ieee.org/document/8475045</a>). </div><div>While trying to build the topology we realized that we do not know the number of packets or bytes sent from </div><div>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). </div><div><br></div><div>Could we get a bit more details about how the experiment was conducted?</div><div><br></div><div>Also is this the best way to verify the correctness of our implementation?</div><div><br></div><div>Thanks,</div><div>Avakash Bhat</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 8, 2020 at 9:11 PM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">acks at the time you have reached a point of dropping them<br>
significantly have filled the pipe, also.<br>
<br>
What I saw here was that the first flow to really get going, and<br>
really get dropped, dominated over the others,<br>
because I thought it was consistently ending up in the priority queue.<br>
<br>
<a href="http://blog.cerowrt.org/post/ack_filtering/" rel="noreferrer" target="_blank">http://blog.cerowrt.org/post/ack_filtering/</a><br>
<br>
Look, all I'm proposing is this idea be tried and tested. Cynically...<br>
since there's a new model coming out as<br>
the result of this work, it immediately turns into something a good<br>
paper can hing on.<br>
<br>
On Fri, May 8, 2020 at 8:20 AM Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>> wrote:<br>
><br>
> >> The ACK filter runs on enqueue, so if a queue has only ACKs in it, it<br>
> >> will never accumulate anything in the first place...<br>
> ><br>
> > but the side effect is that on dequeue, it flips it into the fast<br>
> > queue drr rotation, not the slow, so it can't accumulate<br>
> > as many acks before delivering the one it has left.<br>
> ><br>
> > Or so I thought, way back when....<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
>  - Jonathan Morton<br>
<br>
<br>
<br>
-- <br>
Make Music, Not War<br>
<br>
Dave Täht<br>
CTO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: 1-831-435-0729<br>
</blockquote></div>