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 F1A533BA8E for ; Wed, 29 Nov 2017 08:13:05 -0500 (EST) Received: by mail-qk0-x22a.google.com with SMTP id b184so4216354qkc.13 for ; Wed, 29 Nov 2017 05:13:05 -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=ocfhWyb7oLwA58zwpmk2v/A5rjJdoKmCBqEYjlM+FtE=; b=Daehejkr1A6O2iZyJiKzw0JRUgPTQcXN/2dxkkV/swvvBUr5mnOcDKb4OOP1ii/Ole aqf+AyrnV2fJQvJFoKRA9CHePHIKPYibooXMNfnxa4oc1DhITViCmluMqwpvJv4El91J wrjAZAPTDxxA+VFDyuffUffnw4j23Jnc8uOCJhXcJhqswVyBgugP1Qft5+/m8euwgktU V6N4UNzRi37E3ob2wNtSGznWJsH1SCU6GEZyCpDlhfy5Bg2+AvoJD2aBrhTZx7t+2NR1 ZSg5p6FppTbKhiBKzMH+CcOi7nJkxEc0mgPQgOizMQWAsv6+0LWt0oaWDYtF12xbr2iB kinA== 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=ocfhWyb7oLwA58zwpmk2v/A5rjJdoKmCBqEYjlM+FtE=; b=JuBjtImv7BKhQA5z1fbxEycTTPAR+MeJwucThHDSXnp0n7NAo2azARAI5YjJ0Mzz/G TC/2LiHqwq/8/Fyrz8OrkrhXvX2vb7qZ1BBKekKHoScpMsnsA/DhoHveSMzdck5tk/rj z0f2D+fi+3CN48k7bdckrE+abKJkkAgHa3/ZxO8Ya9opANqvhKT9IcZr0g6CkReh1Og9 jWAG6rn+3JIgKE7SifVJTqwq4DU2ErP92XVpHrbbD0mFNwhFYdOd5ojpclZCedsgHIZQ G9DB8DB0wkE+sdpZmBX9xWY5nsy+Hc1bR8tWMeaayheht+zU56fhVe4MB/L1ZYHkW2Jt QhcA== X-Gm-Message-State: AJaThX6PWhpleggStAYJ9zI/s30HZlWDoawAk7lqo4HkjbQ/od6f5mK4 dWMxQBLNZrrWKk62FH2GFjDox7LxME88UHqOy2k= X-Google-Smtp-Source: AGs4zMYu7lBKKFoW1UXHR2+d/B7fqbKKDVuXuM6caIU6E6nMkLgJcx9RgFW3dXQ1rcYZccbbSAQ8B21D7KVAjPJUc4s= X-Received: by 10.55.157.133 with SMTP id g127mr4071938qke.280.1511961185485; Wed, 29 Nov 2017 05:13:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.191.227 with HTTP; Wed, 29 Nov 2017 05:13:05 -0800 (PST) In-Reply-To: References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> From: Luca Muscariello Date: Wed, 29 Nov 2017 14:13:05 +0100 Message-ID: To: Mikael Abrahamsson Cc: Sebastian Moeller , bloat Content-Type: multipart/alternative; boundary="001a114d8ad4600953055f1ee52b" 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 13:13:06 -0000 --001a114d8ad4600953055f1ee52b Content-Type: text/plain; charset="UTF-8" Did you check RFC 3449 ? https://tools.ietf.org/html/rfc3449#section-5.2.1 It would be interesting to know what is the minimum ACK rate to achieve full utilisation. Or the how the downlink rate depends on the uplink ACK rate. I'm sure I've seen this dependency in some old paper. On Wed, Nov 29, 2017 at 1:49 PM, Mikael Abrahamsson wrote: > On Wed, 29 Nov 2017, Sebastian Moeller wrote: > > Well, ACK filtering/thinning is a simple trade-off: redundancy versus >> bandwidth. Since the RFCs say a receiver should acknoledge every second >> full MSS I think the decision whether to filter or not should be kept to >> > > 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? > > Sounds like a lot of useless interrupts and handling by the stack, apart > from offloading it to the NIC to do a lot of handling of these mostly > useless packets so the CPU doesn't have to do it. > > Why isn't 1kPPS of ACKs sufficient for most usecases? > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --001a114d8ad4600953055f1ee52b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Did you check RFC 3449 ?

It would be interesting to know wh= at is the minimum ACK rate to achieve full utilisation.
Or the ho= w the downlink rate depends on the uplink ACK rate.
I'm sure = I've seen this dependency in some old paper.=C2=A0

=

On Wed, Nov= 29, 2017 at 1:49 PM, Mikael Abrahamsson <swmike@swm.pp.se> w= rote:
On Wed, 29 Nov 201= 7, Sebastian Moeller wrote:

Well, ACK filtering/thinning is a simple trade-off: redundancy versus bandw= idth. Since the RFCs say a receiver should acknoledge every second full MSS= I think the decision whether to filter or not should be kept to

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

Sounds like a lot of useless interrupts and handling by the stack, apart fr= om offloading it to the NIC to do a lot of handling of these mostly useless= packets so the CPU doesn't have to do it.

Why isn't 1kPPS of ACKs sufficient for most usecases?


--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

--001a114d8ad4600953055f1ee52b--