[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180518.114238.2120564820986009221.davem@davemloft.net>
Date: Fri, 18 May 2018 11:42:38 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: edumazet@...gle.com
Cc: netdev@...r.kernel.org, toke@...e.dk, ncardwell@...gle.com,
ycheng@...gle.com, soheil@...gle.com, eric.dumazet@...il.com
Subject: Re: [PATCH v3 net-next 0/6] tcp: implement SACK compression
From: Eric Dumazet <edumazet@...gle.com>
Date: Thu, 17 May 2018 14:47:23 -0700
> When TCP receives an out-of-order packet, it immediately sends
> a SACK packet, generating network load but also forcing the
> receiver to send 1-MSS pathological packets, increasing its
> RTX queue length/depth, and thus processing time.
>
> Wifi networks suffer from this aggressive behavior, but generally
> speaking, all these SACK packets add fuel to the fire when networks
> are under congestion.
>
> This patch series adds SACK compression, but the infrastructure
> could be leveraged to also compress ACK in the future.
>
> v2: Addressed Neal feedback.
> Added two sysctls to allow fine tuning, or even disabling the feature.
>
> v3: take rtt = min(srtt, rcv_rtt) as Yuchung suggested, because rcv_rtt
> can be over estimated for RPC (or sender limited)
This looks great, series applied, thanks Eric.
So now we handle locally terminated traffic well, however we still need
something that handles traffic flowing through the system. And for that
reason the CAKE ACK filter still has merit.
I completely agree with you that it has to be implemented properly,
parse all TCP options and the SACK blocks, and pass the ACKs through
when there are options it doesn't understand or the SACK/timestampe/etc.
update contains new information that must be passed along and not dropper.
Thanks again.
Powered by blists - more mailing lists