From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hagen Paul Pfeifer Subject: Re: [PATCH net-next] tcp: use RFC6298 compliant TCP RTO calculation Date: Tue, 14 Jun 2016 08:17:03 +0200 Message-ID: <20160614061703.GA985@virgo.localdomain> References: <20160613204529.18826-1-dmetz@mytum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Daniel Metz , netdev , Eric Dumazet , Neal Cardwell , Pasi Sarolahti , Van Jacobson To: Yuchung Cheng Return-path: Received: from mx1.mailbox.org ([80.241.60.212]:46508 "EHLO mx1.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750947AbcFNGRV (ORCPT ); Tue, 14 Jun 2016 02:17:21 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: * 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