netdev - Re: [PATCH net-next v2] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <1771240333.25844.1466068055580@office.mailbox.org>
Date:	Thu, 16 Jun 2016 11:07:35 +0200 (CEST)
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Daniel Metz <dmetz@...um.de>, Eric Dumazet <edumazet@...gle.com>
Cc:	Yuchung Cheng <ycheng@...gle.com>, netdev <netdev@...r.kernel.org>,
	Daniel Metz <daniel.metz@...de-schwarz.com>
Subject: Re: [PATCH net-next v2] tcp: use RFC6298 compliant TCP RTO
 calculation

> On June 15, 2016 at 10:38 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> I guess the problem is that some folks use smaller rto than
> RTAX_RTO_MIN , look at tcp_rto_min()

Due to the nature of the Linux calculation, this is probably more of a reason to use the RFC 6298 calculation. When a smaller MinRTO as 200ms is used, the Linux “advantage” to account for Delayed ACKs up to 200ms is decreased. Assuming a MinRTO of 0ms, the Linux ability and the RFC ability to account for sudden Delayed ACKs is pretty equal: zero. 

To illustrate this: RTT: 50ms, RTTVAR: 0ms, MinRTO: 50ms, Delayed ACKs: 200ms. 

Before any ACK is delayed:

Linux RTO ~ 100+ms (tested) 
RFC 6298 RTO ~ 50+ms (tested) 

RTT of first delayed ACK if it is not shortened due to another data packet: ~250ms 

This is not tied to the RTT:
RTT 1000ms, RTTVAR: 0ms, MinRTO: 50ms, Delayed ACKs: 200ms 

Before any ACK is delayed:

Linux RTO ~ 1050+ms (tested) 
RFC 6298 RTO ~ 1000+ms (tested)

RTT of first delayed ACK if it is not shortened due to another data packet: ~1200ms 

A RFC 6298 problem we run in so far was with extremely steady RTTs and sender limited data. A Spurious Retransmission occurred from time to time in this case.

Hagen