From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 37DDA3CB37 for ; Thu, 17 May 2018 07:04:56 -0400 (EDT) Received: by mail-pf0-x244.google.com with SMTP id a22-v6so1929200pfn.6 for ; Thu, 17 May 2018 04:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ISZpez4WjrONwkUk1pcNeTC0AFKyBX5q//MppfRbITQ=; b=OV/pOQEEPKfGSibxuycUQAYt5/4Kivp11K8mmDINQXA3vKV/VWPqVbDdnSYlzgkwRt u3zdCB6uxGhzclcr3uX0MRlwIJ7zzXBmcVmEJQ0J4RS5Ipo1SELYzDDh9kvxvEkHfyle GO1ARcmQ/47MY7RwdRkr4AqcUrTuSHdxjjGsOqARaYnKFslHGBrpW9y4kK5/5gjt9Cl1 SW1AmcrXVzbJTDdAEpLmDteNjV7s/WWX7eQ6s/d0A8xrO057YknHOVC6cNrblHnX2yk6 b67E+u3HJRxoq0fGxd0IsmvsF1w1eN32ghTXoQt0ovzpmxKIVLSH4fOjhBz9JPYnXfwl vBVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ISZpez4WjrONwkUk1pcNeTC0AFKyBX5q//MppfRbITQ=; b=pCsTyABGSVuoY6bwFYEaZooHl7mRXYzqs0RCQDKfIKAFn2thVErBK3Ca3dhyH6l4NW OumRtIR90C+L7bkiFEFDqjqwrd7u4+MzuazfPeGUb8M0d296MJnkuS1iHRUTZaAP4AV2 l01iatVz4deJNPIsJzHGCi0WT3qGXMKhLeR9/2dxNllx1vtyb23CLknSvRgkLj/HR9gR D/mn8TwEIb2eGXlWB4JopGGhSZCFwnIiiUoTSKN4daLnOkFDZga0e5VJyXKyRkmPoPXv 6qWaSTrXGD5laiMEkrs91tBi6RWnlfLH+NkZo/9W8/FjVZY7xtRaqqQKb/DSXcW2fHUX IyEQ== X-Gm-Message-State: ALKqPweyTVjt98q2/7kgHnlFNU7HiwaKHQ4BbUf4/hbA5yTMhOrKNI+7 TglsfL7gAdh4p7QRBPNN7MzsKJia X-Google-Smtp-Source: AB8JxZqPvdYJbnnS7dyx/U5/Jf09ci+sh9vACFN5BtHRGbb/c6wKWPawZNQRVu2Dag/r3KAdch/ktw== X-Received: by 2002:a62:5841:: with SMTP id m62-v6mr4720622pfb.116.1526555095302; Thu, 17 May 2018 04:04:55 -0700 (PDT) Received: from [192.168.86.235] (c-67-180-167-114.hsd1.ca.comcast.net. [67.180.167.114]) by smtp.gmail.com with ESMTPSA id v186-v6sm8223505pfb.45.2018.05.17.04.04.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 04:04:54 -0700 (PDT) To: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , netdev@vger.kernel.org Cc: cake@lists.bufferbloat.net References: <152650253056.25701.10138252969621361651.stgit@alrua-kau> <152650254614.25701.1377066681230937234.stgit@alrua-kau> From: Eric Dumazet Message-ID: Date: Thu, 17 May 2018 04:04:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <152650254614.25701.1377066681230937234.stgit@alrua-kau> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Cake] [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter 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, 17 May 2018 11:04:56 -0000 On 05/16/2018 01:29 PM, Toke Høiland-Jørgensen wrote: > The ACK filter is an optional feature of CAKE which is designed to improve > performance on links with very asymmetrical rate limits. On such links > (which are unfortunately quite prevalent, especially for DSL and cable > subscribers), the downstream throughput can be limited by the number of > ACKs capable of being transmitted in the *upstream* direction. > ... > > Signed-off-by: Toke Høiland-Jørgensen > --- > net/sched/sch_cake.c | 260 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 258 insertions(+), 2 deletions(-) > > I have decided to implement ACK compression in TCP stack itself. First step is to take care of SACK, which are the main source of the bloat, since we send one SACK for every incoming out-of-order packet. These SACK are not only causing pain on the network, they also cause the sender to send one MSS at a time (TSO auto defer is not engaged in this case), thus starting to fill its RTX queue with pathological skbs (1-MSS each), increasing processing time. I see that your ACK filter does not take care of this common case :) Doing the filtering in TCP has the immense advantage of knowing the RTT and thus be able to use heuristics causing less damage.