From: Luca Muscariello <luca.muscariello@gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Sebastian Moeller <moeller0@gmx.de>, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] benefits of ack filtering
Date: Wed, 29 Nov 2017 16:53:43 +0100 [thread overview]
Message-ID: <CAHx=1M77XYX9t6J_zG1oArOze1-nTRPB9bNQLRfwFRZjH3mQjQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1711291528260.32099@uplift.swm.pp.se>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson <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
> 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.
[-- Attachment #2: Type: text/html, Size: 1968 bytes --]
next prev parent reply other threads:[~2017-11-29 15:53 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 21:48 Dave Taht
2017-11-29 6:09 ` Mikael Abrahamsson
2017-11-29 9:34 ` Sebastian Moeller
2017-11-29 12:49 ` Mikael Abrahamsson
2017-11-29 13:13 ` Luca Muscariello
2017-11-29 14:31 ` Mikael Abrahamsson
2017-11-29 14:36 ` Jonathan Morton
2017-11-29 15:24 ` Andrés Arcia-Moret
2017-11-29 15:53 ` Luca Muscariello [this message]
[not found] ` <CAJq5cE3qsmy8EFYZmQsLL_frm8Tty9Gkm92MQPZ649+kpM1oMw@mail.gmail.com>
2017-11-29 16:13 ` Jonathan Morton
2017-11-30 7:03 ` Michael Welzl
2017-11-30 7:24 ` Dave Taht
2017-11-30 7:45 ` Dave Taht
2017-11-30 7:48 ` Jonathan Morton
2017-11-30 8:00 ` Luca Muscariello
2017-11-30 10:24 ` Eric Dumazet
2017-11-30 13:04 ` Mikael Abrahamsson
2017-11-30 15:51 ` Eric Dumazet
2017-12-01 0:28 ` David Lang
2017-12-01 7:09 ` Jan Ceuleers
2017-12-01 12:53 ` Toke Høiland-Jørgensen
2017-12-01 13:13 ` [Bloat] [Make-wifi-fast] " Кирилл Луконин
2017-12-01 13:22 ` Luca Muscariello
2017-12-11 17:42 ` Simon Barber
2017-12-01 13:17 ` [Bloat] " Luca Muscariello
2017-12-01 13:40 ` Toke Høiland-Jørgensen
2017-12-01 17:42 ` Dave Taht
2017-12-01 20:39 ` Juliusz Chroboczek
2017-12-03 5:20 ` [Bloat] [Make-wifi-fast] " Bob McMahon
2017-12-03 10:35 ` Juliusz Chroboczek
2017-12-03 11:40 ` Jan Ceuleers
2017-12-03 13:57 ` Juliusz Chroboczek
2017-12-03 14:07 ` Mikael Abrahamsson
2017-12-03 19:53 ` Juliusz Chroboczek
2017-12-03 14:09 ` Ryan Mounce
2017-12-03 19:54 ` Juliusz Chroboczek
2017-12-03 20:14 ` Sebastian Moeller
2017-12-03 22:27 ` Dave Taht
2017-12-03 15:25 ` Robert Bradley
2017-12-04 3:44 ` Dave Taht
2017-12-04 14:38 ` David Collier-Brown
2017-12-04 15:44 ` Juliusz Chroboczek
2017-12-04 17:17 ` David Collier-Brown
2017-12-03 19:04 ` Bob McMahon
2017-12-01 21:17 ` Bob McMahon
2017-12-01 8:45 ` [Bloat] " Sebastian Moeller
2017-12-01 10:45 ` Luca Muscariello
2017-12-01 18:43 ` Dave Taht
2017-12-01 18:57 ` Luca Muscariello
2017-12-01 19:36 ` Dave Taht
2017-11-30 14:51 ` Neal Cardwell
2017-11-30 15:55 ` Eric Dumazet
2017-11-30 15:57 ` Neal Cardwell
2017-11-29 16:50 ` Sebastian Moeller
2017-12-12 19:27 ` Benjamin Cronce
2017-12-12 20:04 ` Dave Taht
2017-12-12 21:03 ` David Lang
2017-12-12 21:29 ` Jonathan Morton
2017-12-12 22:03 ` Jonathan Morton
2017-12-12 22:21 ` David Lang
[not found] ` <CAJq5cE3nfSQP0GCLjp=X0T-iHHgAs=YUCcr34e3ARgkrGZe-wg@mail.gmail.com>
2017-12-12 22:41 ` Jonathan Morton
2017-12-13 9:46 ` Mikael Abrahamsson
2017-12-13 10:03 ` Jonathan Morton
2017-12-13 12:11 ` Sebastian Moeller
2017-12-13 12:18 ` Jonathan Morton
2017-12-13 12:36 ` Sebastian Moeller
2017-12-13 12:39 ` Luca Muscariello
2017-11-29 18:21 ` Juliusz Chroboczek
2017-11-29 18:41 ` Dave Taht
2017-11-29 23:29 ` Steinar H. Gunderson
2017-11-29 23:59 ` Stephen Hemminger
2017-11-30 0:21 ` Eric Dumazet
2017-12-11 20:15 ` Benjamin Cronce
2017-11-29 18:28 ` Juliusz Chroboczek
2017-11-29 18:48 ` Dave Taht
2017-12-11 18:30 ` Jonathan Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHx=1M77XYX9t6J_zG1oArOze1-nTRPB9bNQLRfwFRZjH3mQjQ@mail.gmail.com' \
--to=luca.muscariello@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
--cc=swmike@swm.pp.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox