From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 515113B29E; Sat, 21 Jul 2018 16:01:20 -0400 (EDT) Received: by mail-qt0-x229.google.com with SMTP id h4-v6so13218246qtj.7; Sat, 21 Jul 2018 13:01:20 -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:content-transfer-encoding; bh=pog+rmGeznkKY8TiN7Kyxp2niplf2bE7nP7824sYpxc=; b=GLVL6gNrIzpOcitUTszlkNmEA2M2nKUrxyNIDmfag+2GGtel0uCyUX61EvV4xEyQ81 c/xDerg7Ul5aTqg85FG80AIIj5oW3DdJ0Hydt5v35z0NmS01L0lTjH6lTVOA79968W2j 4x9MkXM72Pr1hHZZjEJH1xXd+qJGeHATJFgnTIYExf0hnxWgPcLq4M+ojoatYHoWBLJK GMdI3TMkvfqI3y9hzWWvCa2pPmCouZ20eXBJa2hi4mE1gVkgoTho8ENhudR/az+a935B aWNQaIQ70/BoH9mAscbL20r88Eo+hPXETc3Rgi7AmEdWRV6KUBZcox2/jJBOFFW1Bp4S l5yw== 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:content-transfer-encoding; bh=pog+rmGeznkKY8TiN7Kyxp2niplf2bE7nP7824sYpxc=; b=A3RHEyE/MTxXwIeB+IwZ9TIhHAYicBu9K7VoqE4TBumaBdAzaKWdCWo/ssmn4sYp5k 6i2FpPqVr1lVbVLJtiW9obEdSgaPiSyOj1sDnDbKq9eRqMKeG1dAYS1JzfGKtVm8nPh/ TTa5J/AfFG2kC37qhcOcsBt+lGaIU22L59MbLc3XAzGPLdvDhsXqADkBzdC4pjcdTt9I thkXAsW6vz3OoBvK8slfMuoLYJ3ydJPiQDx+99NxgLS2dXCFfTKfVT1DVg77z3eYDcl+ yTJsVWlaZ/Lro09pLAUTrt6+jfW/+I4XcRGldhVgrQkwDqwGlwUQhGzxU5fHTc+0Agjb oWvA== X-Gm-Message-State: AOUpUlGvgHWDObp0S7ZF09oHS1+vOysZCRBsktwPFG1sed8RAUR41sdb CTolbWJwhnkuFl7zEShxOPNLkhKaRBehhyAmLD4= X-Google-Smtp-Source: AAOMgpcdc81MgxbWVvergC26Grak+Cc7sLrJVjZ0+me71zg/01i8LAm1XJW+nC510H93OWda0fu/a6+L05ody5EZUd0= X-Received: by 2002:ac8:354e:: with SMTP id z14-v6mr6845384qtb.261.1532203279790; Sat, 21 Jul 2018 13:01:19 -0700 (PDT) MIME-Version: 1.0 References: <4C129A60-21D3-4B78-A764-DC8E2CD7E4DF@gmail.com> <6839ba220fe4399eba3620620515fc1dd801a509.camel@gmail.com> In-Reply-To: <6839ba220fe4399eba3620620515fc1dd801a509.camel@gmail.com> From: Dave Taht Date: Sat, 21 Jul 2018 13:01:07 -0700 Message-ID: To: George Amanakis Cc: Jonathan Morton , Cake List , cerowrt-devel@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno 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: Sat, 21 Jul 2018 20:01:20 -0000 To summarize: A) I think the magic 85% figure only applies at lower bandwidths. B) We are at least partially in a pathological situation where CMTS =3D 380ms of buffering, token bucket fifo at 100mbit Cakebox: AQMing and trying to shape below 85mbit, gradually ramping up the signalling once per 100ms downwards. The cmts buffer fills more rapidly, particularly in slow start, while presenting packets to the inbound shaper at 100mbit. cake starts signalling, late, trying to achieve but at that point the apparent RTTs are still growing rapidly (because of the buffer building up in the cmts inflicting that RTT), so as fast as we signal, we've got such a big buffer built up in the CMTS that tcp only sees one signal per RTT which is mismatched against what cake is trying to thwart. The pathology persists. the idea for bobbie was that the goal for codel is wrong for inbound shaping, that instead of aiming for a rate, we needed to sum all the overage over our rate and reduce that until it all drains from cmts shaper. So, lets say (waving hands a bit here) we get 160mbits/sec for 8 seconds with an outbound shaped rate of 100. That 480mbits (independent of any signalling we did to try to reduce it) "stuck" up there. We're trying to gradually get it to 85mbits/sec, but the signalling is now so far behind the tcp's now observed actual rtt that it takes forever to get anywhere and we end up in steady state. The more, aggressive, flows you have, the worst this disparity gets. using perhaps cake's ingress estimator it seems possible to "bob" the rate down until it drains, or to work on more aggressively drain the built up queue than the gentle approach fq_codel uses, policer style. On Sat, Jul 21, 2018 at 11:18 AM Georgios Amanakis wr= ote: > > On Sat, 2018-07-21 at 10:47 -0700, Dave Taht wrote: > > for reference can you do a download and capture against flent-newark, > > while using the ping test? > > > > New data, this is what I did: > > 1) Started a ping test using the flent-fremont server. > 2) Started a tcp_8down test (for 15 seconds) using the flent-newark > server. I chose tcp_8down since fast.com was also using 8 flows. > 3) Captured on the host where the above tests ran. > > It seems to be working as expected here. > > Georgios --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619