From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 7BD823BA8E for ; Wed, 29 Nov 2017 10:53:44 -0500 (EST) Received: by mail-qk0-x22e.google.com with SMTP id b123so4939573qkg.7 for ; Wed, 29 Nov 2017 07:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+yKnP9b9Zwyg/xEqT/5FfjTJOZ/XNUwarVVTO9f5adQ=; b=dOsof6VZXsVfcT85RYZtoLGHdEo78vtAOaMY6+09AgY512ueEnbHVh1XDgd7EkLn0A 3BxqQaLDv+mWO1fYymcb4NTpJW0QIPO/L8D9m49QFGJr7i2ZIoUuZKk15cnIw2UnZrcT 7T2tDLXZwO0joOY8T5tDs+z0AxUxQCEZVeTkqN3NZyl9ShhIIXJXEVKgs7ZUlQZ06oi3 IuWmIyheVh6z7G/yFQKDUuvrprtAjQtwkqlZMUKK9tW5d5oPNvpsqkoc0OL8BIafBj5L Qx5svdcR/CBihiExQ0M40vGnzSxwnJ+TAY3ttFUjKeMWEIuccU0+1u1CVKrJ2tqhUzFV 7joA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+yKnP9b9Zwyg/xEqT/5FfjTJOZ/XNUwarVVTO9f5adQ=; b=Ydqt4in7eD3B/UB2eCwnhFd0MvzcEjDTsbYRdnK8RHxlLRYpERkMpk5f6uMOe6dwIN Y0SHIHVNXe6S2eFCrOmU4BJnnDqoZgbYvZkArOj3DoabEPNvbV/69Ys39Zu5UyQ9RBBR OSEbD/AWXlYYposYZNiuOdwuHrRXuJBIp61Tqs/uJWIzbazEwhFgpysg8eO7RhAuTU9F IRB96J9VAGaYlUMBJcxuQt6LpkiCQlUZsNI1MQJcx+M2zQV8HoFlRhc7rGuA/4ZQGhU+ 9M10+vhAgbLDpz/nEK2Sb/FCtwBBrA7I3uvq34R3o5jBTf+tVq1iR/HozY1fqThByIQA VbYA== X-Gm-Message-State: AJaThX5Oo0ffD/fv0LsxVqm3R+vYr6QqEHxk5sR9JhTkzTLA3C5phXME fJoP+6WHZ4dapCH/OwM6qlLg+YaYqwMHnRuPTF4= X-Google-Smtp-Source: AGs4zMYLZdFdA+yKCR0xCtJR27LWTJh7crUcqWMhIuW6NB1apZdKtZvvBzJNyuEAhzftKR66x6yDZ1v2bdFsiO3lvUA= X-Received: by 10.55.16.80 with SMTP id a77mr4993408qkh.250.1511970824033; Wed, 29 Nov 2017 07:53:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.191.227 with HTTP; Wed, 29 Nov 2017 07:53:43 -0800 (PST) In-Reply-To: References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> From: Luca Muscariello Date: Wed, 29 Nov 2017 16:53:43 +0100 Message-ID: To: Mikael Abrahamsson Cc: Sebastian Moeller , bloat Content-Type: multipart/alternative; boundary="001a1145bc44e09cb4055f2123b2" Subject: Re: [Bloat] benefits of ack filtering X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 15:53:44 -0000 --001a1145bc44e09cb4055f2123b2 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson wrote: > On Wed, 29 Nov 2017, Luca Muscariello wrote: > > Why does it say to do this? What benefit is there to either end system to >>> send 35kPPS of ACKs in order to facilitate a 100 megabyte/s of TCP >>> transfer? >>> >> >> Did you check RFC 3449 ? >> https://tools.ietf.org/html/rfc3449#section-5.2.1 >> > > RFC3449 is all about middleboxes doing things. > > I wanted to understand why TCP implementations find it necessary to send > one ACK per 2xMSS at really high PPS. Especially when NIC offloads and > middleboxes frequently strip out this information anyway so it never > reaches the IP stack (right?). > > I would say because it is complex to guess at which PPS to work. You would need an adaptation mechanism. Need also to change the client and the server sides. The AckCC Jonathan has mentioned might be a solution to that. Probably an ACK pacer in the end host, out of the TCP stack, doing Ack filtering and decimation can be simpler to implement than the proper adaptation mechanism in TCP. Maybe inside sch_fq it would be doable. Maybe not. --001a1145bc44e09cb4055f2123b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson &= lt;swmike@swm.pp.se> wrote:
On = Wed, 29 Nov 2017, Luca Muscariello wrote:

Why does it say to do this? What benefit is there to either end system to send 35kPPS of ACKs in order to facilitate a 100 megabyte/s of TCP transfer= ?

 Did you check RFC 3449 ?
https://tools.ietf.org/html/rfc3449#section-5.= 2.1

RFC3449 is all about middleboxes doing things.

I wanted to understand why TCP implementations find it necessary to send on= e ACK per 2xMSS at really high PPS. Especially when NIC offloads and middle= boxes frequently strip out this information anyway so it never reaches the = IP stack (right?).

<= /blockquote>

I would say because it is complex to guess = at which PPS to work. You would need an adaptation mechanism. Need also to = change the client and the server sides. The AckCC Jonathan has mentioned=C2= =A0
might be a solution to that.
Probably an ACK pacer = in the end host, out of the TCP stack, doing Ack filtering and decimation c= an be simpler to implement than the proper adaptation mechanism in TCP.
Maybe inside sch_fq it would be doable. Maybe not.

=C2=A0
--001a1145bc44e09cb4055f2123b2--