netdev - Re: [PATCH net-next] tcp: use RFC6298 compliant TCP RTO calculation

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: <20160614061703.GA985@virgo.localdomain>
Date:	Tue, 14 Jun 2016 08:17:03 +0200
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Yuchung Cheng <ycheng@...gle.com>
Cc:	Daniel Metz <dmetz@...um.de>, netdev <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	Pasi Sarolahti <pasi.sarolahti@....fi>,
	Van Jacobson <vanj@...gle.com>
Subject: Re: [PATCH net-next] tcp: use RFC6298 compliant TCP RTO calculation

* Yuchung Cheng | 2016-06-13 15:38:24 [-0700]:

Hey Eric, Yuchung,

regarding the missed mdev_max_us: internal communication problem. Daniel well
respin a v2 removing the no longer required mdev_max_us.

>Thanks for the patch. I also have long wanted to evaluate Linux's RTO vs RFC's.
>
>Since this is not a small change, and your patch is only tested on
>emulation-based testbed AFAICT, I'd like to try your patch on Google
>servers to get more data. But this would take a few days to setup &
>collect.

Great - no hurry! We tried hard to find any downsides of RFC 6298 so far
without any result. If you have any special & concrete tests in mind: Daniel
will test it!

>Note that this paper
>https://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf has
>detailed rationale of current design (section 4). IMO having a "tight"
>RTO is less necessary now after TLP. I am also testing a new set of
>patches to install a quick reordering timer. But it's worth mentioning
>the paper in the commit message.

We had "difficulties" to find scenarios where the RTO kicks-in. For the
majority of use cases duplicate ACKs triggers TCP retransmission. For bulk
data transmissions almost 100% of retransmissions are triggered by duplicate
ACKs (except connection teardown). TLP will reduce the requirement for RTO
even further, also window probes helps sometimes. The use case we realized was
sender limited, non-continuous flows where a RFC 6298 compliant implementation
is better.

Thank you Yuchung, we will add an reference in v2.

Hagen