From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 977E73B29D for ; Mon, 25 May 2020 05:43:02 -0400 (EDT) Received: by mail-lj1-x234.google.com with SMTP id c11so17895962ljn.2 for ; Mon, 25 May 2020 02:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5Bg/55HY6b5xt3DAP/QXmPviwuecdB1Xirdc8qw79JQ=; b=Pk0azXJWzlwcejy328MP5waen+AOKdeqZmk3os5xaCg1WxMAsPtQv73vS87EtQekSP GaY2MhIuEqUExt+5Rzhti/23F2aNEjTlL09Al9wRedc1kyZxfpe6ZiU53FnM4v1+9iDq 3gmRNaY/rrPSq2tA9r0Vep/DU/kNkPIoXqSK9Wbuzcw2p00d7fntkfFD0zecca1U9a2w cgNwOU1wD4UbMiKl0HpV75M+uNlKQNvJn5rClXUJqlLmJLJJsL4ZhYzndFUi2uGukEOf Ni+sj1whxWyKP0T608DfSCPu2thinekR7FynuyRBB5y47wZogTS2FaGTNf5yZUA2kcKE HfTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5Bg/55HY6b5xt3DAP/QXmPviwuecdB1Xirdc8qw79JQ=; b=Rfkba1ZWj0PpoHOlznrZUYVt2AY+mrJKXIwOM90q7cm4SM+QRnA5xC44PZm7I/8s5K jstRtk/1nZuNGcyZvILHgQrMg4RDb1FZBWLb2FjYWN5+TVGPcK3SMhf0ydo7NEaPtFoF Gu3JlF0loZ8GRm2+nc+4inyVTGmnhixzop4U9yQ53WCTHJwwJPUFHyTTIQ+CgiFnvrLK qP/df1OygUe3afPYLQnnSqprSDWpyBiOGwZmFQQ+bXfoJabvi5Y5f+iFPR61zRca6dT2 tcdoL0QONWb83oDa1qpyDDDKIPQqdfGlKvCdy9kbr283YSY9RKSklsQSRqJlze9K2YUJ j3Tw== X-Gm-Message-State: AOAM5304tG3JHhHbN3qZIk8vBAPW3z2FOROExNoMN3WfHZJiOAzTGCK/ YsyPKLozT22im/0pmifxa0w= X-Google-Smtp-Source: ABdhPJy1X2PKF+PK4vRhCbsDcN6EXrUI9N+URIt9oOOKmIdckL/pZS8Ugyudsx8N8aWvv7UrSr6iwA== X-Received: by 2002:a2e:574e:: with SMTP id r14mr11891866ljd.411.1590399781257; Mon, 25 May 2020 02:43:01 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-237-52-nat-p.elisa-mobile.fi. [83.245.237.52]) by smtp.gmail.com with ESMTPSA id c22sm4713566lfm.25.2020.05.25.02.42.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 02:43:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Jonathan Morton In-Reply-To: Date: Mon, 25 May 2020 12:42:58 +0300 Cc: Cake List , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Dave Taht , Vybhav Pai , Shrinidhi Varna , "Mohit P. Tahiliani" , Deepak K Content-Transfer-Encoding: quoted-printable Message-Id: <48938727-0CFF-4B72-B82B-49E0535E9B82@gmail.com> References: <87wo5okhbo.fsf@toke.dk> <875zd6h3bu.fsf@toke.dk> <7FCC9B1F-7F4B-43E8-B557-88B2A845C28B@gmail.com> To: Avakash bhat X-Mailer: Apple Mail (2.3445.9.5) 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 09:43:02 -0000 > On 25 May, 2020, at 8:17 am, Avakash bhat = wrote: >=20 > We had another query we would like to resolve. We wanted to verify the = working of ack filter in ns-3,=20 > so we decided to replicate the Fig 6 graph in the CAKE = paper(https://ieeexplore.ieee.org/document/8475045).=20 > While trying to build the topology we realized that we do not know the = number of packets or bytes sent from=20 > 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).=20 >=20 > Could we get a bit more details about how the experiment was = conducted? I believe this was conducted using the RRUL test in Flent. This opens = four saturating TCP flows in each direction, and also sends a small = amount of latency measuring traffic. On this occasion I don't think we = added any simulated path delays, and only imposed the quoted asymmetric = bandwidth limits (30Mbps down, 1Mbps up). > Also is this the best way to verify the correctness of our = implementation? Obviously with limited space in our paper, we could only include a small = selection of test results. Many other tests were run in practice, and = we have expanded our test repertoire since. In particular, we now routinely run tests with a simulated typical = Internet path delay inserted, eg. 20ms, 80ms, 160ms baseline RTTs to = represent reaching a local-ish CDN, across the Atlantic, and from Europe = to the US West Coast. You will also want to include multiple traffic = mixes in the analysis, in particular different congestion control = algorithms (at least Reno and CUBIC), and running with ECN both enabled = and disabled at the endpoints. A useful torture test we used was to send many bulk flows up the narrow = side of the link and a single bulk flow down the wide side. For = example, 50:1 flow counts with 1:10, 1:20 and 1:30 bandwidth = asymmetries. The acks of the single flow then have to compete with the = heavy load of the many flows, and the total goodput of that single flow = is an important metric, along with both the total goodput and the Jain's = fairness of the upload traffic. This should show a particularly strong = effect of the ack filter, as otherwise individual acks have to be = dropped by the AQM, which Codel is not very good at adapting to quickly. In evaluating the above, you will want to be vigilant not only for = observed gross performance, but also the extent to which the ack filter = preserves or loses information from the ack stream. This is = particularly true in the runs without ECN, in which congestion signals = can only be applied through packet loss, and the feedback of that signal = is through dup-acks and SACK. I think you will find that the = "aggressive" setting loses some information, and its performance suffers = accordingly in some cases. - Jonathan Morton