From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 021F93BA8E for ; Wed, 18 Apr 2018 12:34:58 -0400 (EDT) Received: by mail-lf0-x22c.google.com with SMTP id g203-v6so3566947lfg.11 for ; Wed, 18 Apr 2018 09:34:58 -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=pOcqo13cEWT51Ujwwqhct7RYLcXZJiLyaCDt/qmdd8M=; b=dtNAfm1pGqOpFbc0/7EB1CN6m5HAC684SJUR7orL4b6MqFCnmzq8rzaKi+cuWql/Ef CQyRkgvN9POsW9Vyxoe+De0CIKUu/S0b7fi2bfquPAE43LatgGxtqJM8dep+5uSmrYFW G8LscbRVn8bZ+UZYg0UlnFS6Bgq+Wfx/yXBw2eARy/4q5QpSxF4IXQXAao23OlzBQRFE nKMPvS8o6Z6h3HrFetlL7RrUDtcEp1RPYh1NJW8S2Tk+S0QpmheCgyVC7i69cSobcf36 bRavngKwLvGbumf7GGMwu8Rp+LuUnklO2sGaFqKG5spyTI/1xAVNTrFoxy2+O8SwempN 0ePA== 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=pOcqo13cEWT51Ujwwqhct7RYLcXZJiLyaCDt/qmdd8M=; b=j2LstvIsN1W+xlf9WFThHhPk7IudC992R5fwuLz3/GYCf1Mnb9wosvh1HELjpcdRQz 2d48hmzZ0aLXBi+HzTGfiVSQAt47RvzG1/edzcRT77lc0BRL2NT1JTnWrjgkGuTbxPe6 2JTS2krKYJXnohGoFeFuSKGcro1Pnhxx+ojpoaNIXFjTcJdD1fNqXtkIvWOYV0Sy04Qh VLq+nrbxpgBxGOxoy0Rdjlq9BaOI6ZOcojeU29ex9WyHf9RmK4zL59MxfzIA/fc7U1nF iwE+vuKeG8BdtIzNVx5UaLCPcN556JKBxaOHIeJuFt69lLRvCVVl4Iu6lLU6Yfy4OF0O 8NcA== X-Gm-Message-State: ALQs6tAvPmengvRQiv2xplJDUD347xKPHbQh1yideQme2nqlhOy5alkn 8lbfmMX3atr2zpVvv5saGvz6U6JyJa/XRTijYJQ= X-Google-Smtp-Source: AIpwx499NRvitCr2JhfbYRGayvTnseJ7ZWFHvdLPd5j1pcqgFLBQf64ilpt7Er8OQLxO3lM7muxSdu0vJKaJkTuOQzw= X-Received: by 2002:a19:740a:: with SMTP id v10-v6mr1946469lfe.59.1524069297691; Wed, 18 Apr 2018 09:34:57 -0700 (PDT) MIME-Version: 1.0 References: <87vacq419h.fsf@toke.dk> <874lk9533l.fsf@toke.dk> <87604o3get.fsf@toke.dk> <578552B2-5127-451A-AFE8-93AE9BB07368@gmail.com> <87r2nc1taq.fsf@toke.dk> <0BB8B1FD-6A00-49D6-806E-794BD53A449F@gmx.de> <3457DD8E-0292-4802-BD1E-B37771DCADA2@gmail.com> <87fu3s1om2.fsf@toke.dk> In-Reply-To: From: Georgios Amanakis Date: Wed, 18 Apr 2018 16:34:47 +0000 Message-ID: To: Dave Taht Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Cake List Content-Type: multipart/alternative; boundary="0000000000001a1ff4056a220981" Subject: Re: [Cake] A few puzzling Cake results 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: Wed, 18 Apr 2018 16:34:59 -0000 --0000000000001a1ff4056a220981 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Would making it active only for the 'ingress' mode be an option? Otherwise it has to be documented that when using ingress mode with lots of bulk flows on <20mbit/s the actual goodput is going to be less than the set one (eg for 9.8mbit/s set, 5.3 mbit/s actual). On Wed, Apr 18, 2018, 12:25 PM Dave Taht wrote: > I would like to revert this change. > > On Wed, Apr 18, 2018 at 9:11 AM, Toke H=C3=B8iland-J=C3=B8rgensen > wrote: > > Jonathan Morton writes: > > > >>> On 18 Apr, 2018, at 6:17 pm, Sebastian Moeller > wrote: > >>> > >>> Just a thought, in egress mode in the typical deployment we expect, > >>> the bandwidth leading into cake will be >> than the bandwidth out of > >>> cake, so I would argue that the package droppage might be acceptable > >>> on egress as there is bandwidth to "waste" while on ingress the issue > >>> very much is that all packets cake sees already used up parts of the > >>> limited transfer time on the bottleneck link and hence are more > >>> "precious", no? Users wanting this new behavior could still use the > >>> ingress keyword even on egress interfaces? > >> > >> Broadly speaking, that should indeed counter most of the negative > >> effects you'd expect from disabling this tweak in egress mode. But it > >> doesn't really answer the question of whether there's a compelling > >> *positive* reason to do so. I want to see a use case that holds up. > > > > What you're saying here is that you basically don't believe there are > > any applications where a bulk TCP flow would also want low queueing > > latency? :) > > > > -Toke > > _______________________________________________ > > Cake mailing list > > Cake@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cake > > > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --0000000000001a1ff4056a220981 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would making it active only for the 'ingress' mod= e be an option?

Otherwise it has to = be documented that when using ingress mode with lots of bulk flows on <2= 0mbit/s the actual goodput is going to be less than the set one (eg for 9.8= mbit/s set, 5.3 mbit/s actual).

On Wed, Apr 18, 2018, 12:25 PM Dave Taht <dave.taht@gmail.com> wrote:
I would like to revert this change.

On Wed, Apr 18, 2018 at 9:11 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.d= k> wrote:
> Jonathan Morton <chromatix99@gmail.com> writes:
>
>>> On 18 Apr, 2018, at 6:17 pm, Sebastian Moeller <moeller0@gmx.d= e> wrote:
>>>
>>> Just a thought, in egress mode in the typical deployment we ex= pect,
>>> the bandwidth leading into cake will be >> than the band= width out of
>>> cake, so I would argue that the package droppage might be acce= ptable
>>> on egress as there is bandwidth to "waste" while on = ingress the issue
>>> very much is that all packets cake sees already used up parts = of the
>>> limited transfer time on the bottleneck link and hence are mor= e
>>> "precious", no? Users wanting this new behavior coul= d still use the
>>> ingress keyword even on egress interfaces?
>>
>> Broadly speaking, that should indeed counter most of the negative<= br> >> effects you'd expect from disabling this tweak in egress mode.= But it
>> doesn't really answer the question of whether there's a co= mpelling
>> *positive* reason to do so. I want to see a use case that holds up= .
>
> What you're saying here is that you basically don't believe th= ere are
> any applications where a bulk TCP flow would also want low queueing > latency? :)
>
> -Toke
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ca= ke



--

Dave T=C3=A4ht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
--0000000000001a1ff4056a220981--