This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue May 28 05:16:40 2024 Envelope-to: j@jasper.es Delivery-date: Sat, 14 Jul 2012 10:40:37 +0200 Received: from localhost ([127.0.0.1] helo=squeeze.vs19.net) by squeeze.vs19.net with esmtp (Exim 4.72) (envelope-from ) id 1Spxtw-0005DZ-Dp for j@jasper.es; Sat, 14 Jul 2012 10:40:34 +0200 Received: from pop3.telfort.nl [213.205.33.252] by squeeze.vs19.net with POP3 (fetchmail-6.3.18) for (single-drop); Sat, 14 Jul 2012 10:40:32 +0200 (CEST) Received: from cmgw-nl-2 (10.39.115.162) by mda-nl-2.mail.tiscali.sys (8.5.142) id 4FC4EF9001459F95 for jasper@telfort.nl; Sat, 14 Jul 2012 10:28:52 +0200 Received: from cpsmtpb-ews08.kpnxchange.com ([213.75.39.13]) by cmgw-nl-2 with id a8Un1j0030H1flR018UsaT; Sat, 14 Jul 2012 10:28:52 +0200 X-CNFS-Analysis: v=2.0 cv=YZ8/Fntf c=1 sm=2 a=UK1r566ZdBxH71SXbqIOeA==:17 a=nDghuxUhq_wA:10 a=IkcTkHD0fZMA:10 a=DVlMopWZ-8sA:10 a=W7ePzyinAAAA:8 a=VwQbUJbxAAAA:8 a=W0vUJOdyAAAA:8 a=-F7Y1Cgb6FzBsnNk1R4A:9 a=QEXdDO2ut3YA:10 a=x8gzFH9gYPwA:10 a=+5/qYxokF7T3NIdHdHbkPA==:117 Received: from cpsps-ews15.kpnxchange.com ([10.94.84.182]) by cpsmtpb-ews08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Jul 2012 10:28:30 +0200 Received: from vger.kernel.org ([209.132.180.67]) by cpsps-ews15.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 14 Jul 2012 10:28:30 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758118Ab2GNI1M (ORCPT ); Sat, 14 Jul 2012 04:27:12 -0400 Received: from mail-ey0-f174.google.com ([209.85.215.174]:44197 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757361Ab2GNI1I (ORCPT ); Sat, 14 Jul 2012 04:27:08 -0400 Received: by eaak11 with SMTP id k11so1265249eaa.19 for ; Sat, 14 Jul 2012 01:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=vNRPzca0NAD1dMEVbsje/tt+77kp3IlqEiYE Received: by 10.14.214.65 with SMTP id b41mr1349681eep.33.1342254426465; Sat, 14 Jul 2012 01:27:06 -0700 (PDT) Received: from [192.168.163.131] ([74.125.121.33]) by mx.google.com with ESMTPS id v49sm2370323eep.4.2012.07.14.01.27.04 (version=SSLv3 cipher=OTHER); Sat, 14 Jul 2012 01:27:05 -0700 (PDT) Subject: Re: resurrecting tcphealth From: Eric Dumazet To: Piotr Sawuk Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Sat, 14 Jul 2012 10:27:03 +0200 Message-Id: <1342254423.3265.9028.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 14 Jul 2012 08:28:30.0280 (UTC) FILETIME=[A6140480:01CD619A] X-RcptDomain: telfort.nl On Sat, 2012-07-14 at 09:56 +0200, Piotr Sawuk wrote: > On Sa, 14.07.2012, 03:31, valdis.kletnieks@vt.edu wrote: > > On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said: > > > >> >+ /* Course retransmit inefficiency- this packet has been received > >> twice. */ > >> >+ tp->dup_pkts_recv++; > >> I don't understand that comment, could you use a better sentence please? > > > > I think what was intended was: > > > > /* Curse you, retransmit inefficiency! This packet has been received at > least twice */ > > > > LOL, no. I think "course retransmit" is short for "course-grained timeout > caused retransmit" but I can't be sure since I'm not the author of these > lines. I'll replace that comment with the non-shorthand version though. > however, I think the real comment here should be: > > /*A perceived shortcoming of the standard TCP implementation: A > TCP receiver can get duplicate packets from the sender because it cannot > acknowledge packets that arrive out of order. These duplicates would happen > when the sender mistakenly thinks some packets have been lost by the network > because it does not receive acks for them but in reality they were > successfully received out of order. Since the receiver has no way of letting > the sender know about the receipt of these packets, they could potentially > be re-sent and re-received at the receiver. Not only do duplicate packets > waste precious Internet bandwidth but they hurt performance because the > sender mistakenly detects congestion from packet losses. The SACK TCP > extension speci cally addresses this issue. A large number of duplicate > packets received would indicate a signi cant bene t to the wide adoption of > SACK. The duplicatepacketsreceived metric is computed at the > receiver and counts these packets on a per-connection basis.*/ > > as copied from his thesis at [1]. also in the thesis he writes: > > In our limited experiment, the results indicated no duplicate packets were > received on any connection in the 18 hour run. This leads us to several > conclusions. Since duplicate ACKs were seen on many connections we know that > some packets were lost or reordered, but unACKed reordered packets never > caused a /coursegrainedtimeouts/ on our connections. Only these timeouts > will cause duplicate packets to be received since less severe out-of-order > conditions will be resolved with fast retransmits. The lack of course > timeouts > may be due to the quality of UCSD's ActiveWeb network or the paucity of > large gaps between received packet groups. It should be noted that Linux 2.2 > implements fast retransmits for up to two packet gaps, thus reducing the > need for course grained timeouts due to the lack of SACK. > > [1] https://sacerdoti.org/tcphealth/tcphealth-paper.pdf Not sure how pertinent is this paper today in 2012 I would prefer you add global counters, instead of per tcp counters that most applications wont use at all. Example of a more useful patch : add a counter of packets queued in Out Of Order queue ( in tcp_data_queue_ofo() ) "netstat -s" will display the total count, without any changes in userland tools/applications. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/