From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rick Jones Subject: TCP being hoodwinked into spurious retransmissions by lack of timestamps? Date: Mon, 03 Mar 2014 16:29:09 -0800 Message-ID: <53151E55.9000503@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: netdev@vger.kernel.org Return-path: Received: from g4t3425.houston.hp.com ([15.201.208.53]:10007 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755530AbaCDA3L (ORCPT ); Mon, 3 Mar 2014 19:29:11 -0500 Received: from g9t2301.houston.hp.com (g9t2301.houston.hp.com [16.216.185.78]) by g4t3425.houston.hp.com (Postfix) with ESMTP id 25674D1 for ; Tue, 4 Mar 2014 00:29:11 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g9t2301.houston.hp.com (Postfix) with ESMTP id E81DA64 for ; Tue, 4 Mar 2014 00:29:10 +0000 (UTC) Sender: netdev-owner@vger.kernel.org List-ID: I've been looking at some packet traces of an application looking to upload a Large Quantity (tm) of data to a server across the Big Bad Internet (tm). They've been Linux senders, and the destination while supporting SACK and window scaling does not support TCP timestamps. (TCP timestamp support was requested of the supplier of said server many many months ago now.) This destination system has been issuing RSTs at seemingly random points in the middle of a large fraction of the attempted transfers. In looking at the traces, they all seem to be variations on the theme of what is shown by: ftp://netperf.org/retrans_question/for_netdev.png which is a passing of ftp://netperf.org/retrans_question/for_netdev.pcap through tcptrace -nG and zoomed-in to the end. I've seen this with a 3.2.0 kernel as the sender, have reports of it happening with whatever is in Fedora Core 20, and the traces above are from a 3.11.0 kernel as the sender. The large quantity of (likely) unnecessary retransmissions shouldn't be triggering a RST by the receiver, but the failures consistently show that and I was wondering if the (spurious) retransmissions were perhaps "encouraged" (so to speak) by the lack of TCP Timestamps. happy benchmarking, rick jones