[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9a29f298-410e-c8cb-9b7a-8e80c0450f71@gmail.com>
Date: Fri, 18 May 2018 08:20:00 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Kevin Darbyshire-Bryant <kevin@...byshire-bryant.me.uk>,
Cong Wang <xiyou.wangcong@...il.com>
Cc: Toke Høiland-Jørgensen <toke@...e.dk>,
Cake List <cake@...ts.bufferbloat.net>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [Cake] [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter
On 05/18/2018 04:18 AM, Kevin Darbyshire-Bryant wrote:
>
> Speaking as a user of cake’s ack filtering, although it may be an odd place, it is incredibly useful in my linux based home router middle box that usefully extracts extra usable bandwidth from my asymmetric link. And whilst ack compression/reduction/filtering call it what you will, will come to the linux TCP stack, as yet other OS stacks are less enlightened and benefit from the router’s tweaking/meddling/interference.
>
>
Kevin, there is no doubt the feature might be useful.
But it has to be properly implemented, or we risk to block future TCP improvements.
An ACK filter MUST parse the TCP options.
1) If some options can not be understood, ACK MUST not be dropped.
2) SACK options MUST be carefully analyzed
3) Timestamps also need some care.
Too many middle-boxes are breaking TCP, we do not want to carry another TCP blackhole in upstream linux,
that would be a shame.
conntrack had bugs that seriously impacted TCP Fastopen deployment for example.
Powered by blists - more mailing lists