From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 94DB73B29D for ; Mon, 25 May 2020 01:18:10 -0400 (EDT) Received: by mail-ua1-x935.google.com with SMTP id 36so5723390uaf.9 for ; Sun, 24 May 2020 22:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WqhblJUeYNqkEJvHhc49SOJHnOdQA9KcXFKb5DYt+JA=; b=BSrE2fki0qKdQt52CGRcVknO09xb6E1tLO3TWGSRSXXe9npGVX94yjRskIAiUnN70e wINlAh2rmF9++87Qz80VGZyWkFEeOI0CypEqa79Z2HBgMUqiYO3zbUkt9Fus8auM/RnL bTZu1TS6tqrZloT5cr+mmGUSVmMdhACyojMH+eGoHAqBEytskCudyGTjmSHiqI3xY2ZE lKtQ50UnyyEL78rktda12WgmcZttfrReqN442uRFLfXzTQZok5EqRJZ+NzrTCElFzyWS 1pvLajN1eD/joUObNtZ++ge134DZffF6+P1tQVCWezzvR76NgzC0ztXroJl3gtdjL11x hyyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WqhblJUeYNqkEJvHhc49SOJHnOdQA9KcXFKb5DYt+JA=; b=ejeRoG8MvBWoS6eA7pQs3uep371zVmj518p6QhKtjHBYksLNWSfJGqGYQ9G/bfCMfp kOTEgv9xbINtTBAflB7mNm2N/C7cDOk2Ex0n5c+fcniU4S7SsTvW/253Vpx7gev1xjoZ A0P8e6qxNQ1pb987VRo0mIoKvMN+4diVCOoX5wJk9vwJJvZogzNbvmJx8u6Dnmh+0xSJ XFgRpVAdnpDMLgxm1D/B20BJMhQDjIISDZTnYn5K/VT3uZtZVerTbtWVaBR4lmGICwSB M3BionxM2jI8Dw+NlrG6YLUv6iVKd/IUKcGBAGALlba/xy0g8LcWNx6GRd8jTlLJBGAP X8dA== X-Gm-Message-State: AOAM532GKWopbB6ARc8YUgE7esLX1ggHPMfQJBqmJ+YeiWn10lQC/qFR 5ta3fcgEClZsMuxyBQ/8txnzGzSe8nZlyPC82ESTpbU2 X-Google-Smtp-Source: ABdhPJyfyU3fXhqCz/Yw+MTQzOjJULfBrJxYeDVbSSEF2fG9ksO1GDmMsKvK8xBIu8wyhsSkHpyk2JlYaOssirXrnrw= X-Received: by 2002:ab0:36ba:: with SMTP id v26mr4124543uat.49.1590383889770; Sun, 24 May 2020 22:18:09 -0700 (PDT) MIME-Version: 1.0 References: <87wo5okhbo.fsf@toke.dk> <875zd6h3bu.fsf@toke.dk> <7FCC9B1F-7F4B-43E8-B557-88B2A845C28B@gmail.com> In-Reply-To: From: Avakash bhat Date: Mon, 25 May 2020 10:47:53 +0530 Message-ID: To: Cake List Cc: Jonathan Morton , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Dave Taht , Vybhav Pai , Shrinidhi Varna , "Mohit P. Tahiliani" , Deepak K Content-Type: multipart/alternative; boundary="000000000000ce6f1305a6721a1b" Subject: Re: [Cake] Query on ACK X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 05:18:10 -0000 --000000000000ce6f1305a6721a1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 > wrote: > > > > >> The ACK filter runs on enqueue, so if a queue has only ACKs in it, i= t > > >> 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 bul= k > 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 t= he > ack stream; the latter is a happy side effect. > > > > - Jonathan Morton > > > > -- > Make Music, Not War > > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729 > --000000000000ce6f1305a6721a1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
We had another query we would like to resolve.= We wanted to verify the working of ack filter in ns-3,=C2=A0
so = we decided to replicate the Fig 6 graph in the CAKE paper(https://ieeexplore.ieee.org/documen= t/8475045).=C2=A0
While trying to build the topology we reali= zed that we do not know the number of packets or bytes sent from=C2=A0
the source to the destination for each of the TCP connections ( We ar= e assuming it is a point to point connection with 4 TCP flows).=C2=A0
=

Could we get a bit more details about how the experimen= t was conducted?

Also is this the best way to veri= fy the correctness of our implementation?

Thanks,<= /div>
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...<= br> 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 i= n 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 bu= lk flow into a sparse flow, which is delivered promptly.=C2=A0 This is a go= od 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 th= e ack stream; the latter is a happy side effect.
>
>=C2=A0 - Jonathan Morton



--
Make Music, Not War

Dave T=C3=A4ht
CTO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-831-435-0729
--000000000000ce6f1305a6721a1b--