netdev - Re: [PATCH net] dctcp: more accurate tracking of packets delivery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADVnQymmRdR+6YexavkkPvdxrdi4zizZdsYbc3w9cKc4KdtwfA@mail.gmail.com>
Date:   Thu, 11 Apr 2019 12:52:02 -0400
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Yuchung Cheng <ycheng@...gle.com>,
        Soheil Hassas Yeganeh <soheil@...gle.com>,
        Florian Westphal <fw@...len.de>,
        Daniel Borkmann <daniel@...earbox.net>,
        Lawrence Brakmo <brakmo@...com>,
        Abdul Kabbani <akabbani@...gle.com>,
        "Tilmans, Olivier (Nokia - BE/Antwerp)" 
        <olivier.tilmans@...ia-bell-labs.com>,
        "De Schepper, Koen (Nokia - BE/Antwerp)" 
        <koen.de_schepper@...ia-bell-labs.com>,
        Bob Briscoe <research@...briscoe.net>
Subject: Re: [PATCH net] dctcp: more accurate tracking of packets delivery

On Thu, Apr 11, 2019 at 8:55 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> After commit e21db6f69a95 ("tcp: track total bytes delivered with ECN CE marks")
> core TCP stack does a very good job tracking ECN signals.
>
> The "sender's best estimate of CE information" Yuchung mentioned in his
> patch is indeed the best we can do.
>
> DCTCP can use tp->delivered_ce and tp->delivered to not duplicate the logic,
> and use the existing best estimate.
>
> This solves some problems, since current DCTCP logic does not deal with losses
> and/or GRO or ack aggregation very well.
>
> This also removes a dubious use of inet_csk(sk)->icsk_ack.rcv_mss
> (this should have been tp->mss_cache), and a 64 bit divide.
>
> Finally, we can see that the DCTCP logic, calling dctcp_update_alpha() for
> every ACK could be done differently, calling it only once per RTT.
>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Cc: Yuchung Cheng <ycheng@...gle.com>
> Cc: Neal Cardwell <ncardwell@...gle.com>
> Cc: Soheil Hassas Yeganeh <soheil@...gle.com>
> Cc: Florian Westphal <fw@...len.de>
> Cc: Daniel Borkmann <daniel@...earbox.net>
> Cc: Lawrence Brakmo <brakmo@...com>
> Cc: Abdul Kabbani <akabbani@...gle.com>
> ---

Thanks, Eric!

There is a slight change in semantics, switching from bytes to
packets. But my sense is that the new semantics of packet-based
counting are a better approach, and a closer fit to the design in the
DCTCP paper from SIGCOMM 2010, which talks about measuring "the
fraction of packets that were marked in the last window of data", and
using that to estimate "the probability that the queue size is greater
than K".

Acked-by: Neal Cardwell <ncardwell@...gle.com>

thanks,
neal