From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 850DD3BA8E for ; Thu, 19 Apr 2018 03:49:36 -0400 (EDT) Received: by mail-qk0-x22a.google.com with SMTP id c136so4552524qkb.12 for ; Thu, 19 Apr 2018 00:49:36 -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=w56tn7gi5Mq+LR3uv5ku8EplEX7GwpKfdmgniufKWYk=; b=eazigtzgIYn+fOzBQc+lYymJqAA6kEWayGSQf+EANI2bIfimaWFG/hANANEjJmvgFd yBAJe5YErpZpeVY7dsP7v41FfqkbXk1ZFDQbvT8X9OKDlzpPViuKb10StDdo7Wfcisto a3PshKc9NoAGd7N6oUybBvZ+N0MbyJo9feHhZcxpH8y5ktpu87OtVaGTGm/FdQbQr4YI tm21q5/uiJrn4QraFRp992gIYNSdDLo0xbehbaV8FegIelntkjECgHc6JQB5ssZdkn/f OBkLUcFO8Nye3Yryju3z1Xfc9COa9+0ttTJlIu6vW+3YE5NxpZVI/sSxG0vkHp5mCjmg kTEg== 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=w56tn7gi5Mq+LR3uv5ku8EplEX7GwpKfdmgniufKWYk=; b=qJ4NDVqH7icpN+WAM/U74OfJMkca6qI+57GcU+BkrTpZVVb9lJXB34Q+Gd92Qb2tth dsflPNZ5gG6Xi4J2VJfm5GQ2V0vHByz7YpnOb8UBfbqaBP6yf+xsBl5ZA6P4y2J3iEA+ TIKMRP97bJBPQhGd+qxg5YKutBKe4ydrR1MiAJwFLq1JJUnDMADj5e8TvaRXPTUIPY0s /XGh72GujOy0u82eO4G5UUKDo+7oTzKD6M4G9/sBcyrvYLDWiaN3Th5j9HyQhH1RAD/D ztv9p63KO96GOLj153QtzNZVi7qJX280UYrUegj54veWQqqeOL/b34O9VdQATaU33F/q HUTw== X-Gm-Message-State: ALQs6tCgsG2NQL2WM0I5OHh9+S8h7G3q5mArGw7vto73rJL97KoqUSlM S3YPrkFUlY8hSNIAu4LRx3fgkFfsRgKLFOhbhog= X-Google-Smtp-Source: AB8JxZp/Bulgx+7a+M6m7cVch7HzzMHvjKZSrWMhbVe990H1HwCUbihtnjZMNR5rQ15tniXQqe4/Sllw0e4HM2Y6hMk= X-Received: by 10.55.176.193 with SMTP id z184mr4738110qke.120.1524124176077; Thu, 19 Apr 2018 00:49:36 -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: Luca Muscariello Date: Thu, 19 Apr 2018 07:49:25 +0000 Message-ID: To: Dave Taht Cc: Cake List , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: multipart/alternative; boundary="94eb2c07079e1bd950056a2ed0d9" 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: Thu, 19 Apr 2018 07:49:36 -0000 --94eb2c07079e1bd950056a2ed0d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think that this discussion is about trying to solve an almost impossible problem. When the link is in overload, and this is the case, there is nothing one can do with flow queuing or AQM. It is just too late to make something useful. Overload means that the number of active backlogged flows is just too large and the fair-share is too low for application in the first place and for the transport too. Jonathan tries to make TCP work in a desperate situation. In real life what would happen is that applications would just stop and so the number of flows would dicrease to normal numbers. For those apps that don=E2=80=99t stop the best approach would be to just k= ill in a selective manner, best if driven by a policy that is set by the user. This is why I think that any fix that tries to solve this problem in the queueing system should be avoided. It does not solve the real problem (overload) and introduces latency. My2c Luca On Wed, Apr 18, 2018 at 6: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 > --94eb2c07079e1bd950056a2ed0d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that this discussion is about trying to solve an almost i= mpossible problem.
When the link is in overload, and this is the case, = there is nothing one can do with flow queuing or AQM.

It is just too late to make somet= hing useful.

Overload me= ans that the number of active backlogged flows is just too large and the fa= ir-share is too low for application in the first place and for the transpor= t too.

Jonathan tries to= make TCP work in a desperate situation.=C2=A0

<= /div>
In real life what would happen is that applications = would just stop and so the number of flows would dicrease =C2=A0to normal n= umbers.
For those apps that don=E2=80=99t stop the b= est approach would be to just kill in a selective manner, best if driven by= a policy that is set by the user.

This is why I think that any fix that tries to solve this proble= m in the queueing system should be avoided. It does not solve the real prob= lem (overload) and introduces latency.

My2c

Luca= =C2=A0


On Wed, Apr 18, 2018 at 6= :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.dk> wrote: > Jonathan Morton <chromatix99@gmail.com> writes:
>
>>> On 18 Apr, 2018, at 6:17 pm, Sebastian Moeller <moeller0@gmx.de> 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@l= ists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



--

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

--94eb2c07079e1bd950056a2ed0d9--