This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sun May 19 13:45:26 2024 Envelope-to: j@jasper.es Delivery-date: Sat, 14 Jul 2012 10:10:13 +0200 Received: from localhost ([127.0.0.1] helo=squeeze.vs19.net) by squeeze.vs19.net with esmtp (Exim 4.72) (envelope-from ) id 1SpxQZ-00059u-Ey for j@jasper.es; Sat, 14 Jul 2012 10:10:12 +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:10:11 +0200 (CEST) Received: from cmgw-nl-1 (10.39.115.161) by mda-nl-1.mail.tiscali.sys (8.5.142) id 4FC4EF72018D73BE for jasper@telfort.nl; Sat, 14 Jul 2012 09:56:54 +0200 Received: from cpsmtpb-ews03.kpnxchange.com ([213.75.39.6]) by cmgw-nl-1 with id a7wp1j00107xxPZ017wu5T; Sat, 14 Jul 2012 09:56:54 +0200 X-CNFS-Analysis: v=2.0 cv=Np5TgrhJ c=1 sm=2 a=UK1r566ZdBxH71SXbqIOeA==:17 a=Q7zus9ReCAYA:10 a=IkcTkHD0fZMA:10 a=PXqtdfZIZd0A:10 a=xqWC_Br6kY4A:10 a=W7ePzyinAAAA:8 a=VwQbUJbxAAAA:8 a=W0vUJOdyAAAA:8 a=4r8b20WpCCD4hZOZnbcA:9 a=QEXdDO2ut3YA:10 a=x8gzFH9gYPwA:10 a=fItoyjh0bdv Received: from cpsps-ews14.kpnxchange.com ([10.94.84.181]) by cpsmtpb-ews03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Jul 2012 09:56:36 +0200 Received: from vger.kernel.org ([209.132.180.67]) by cpsps-ews14.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 14 Jul 2012 09:56:37 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757518Ab2GNH4b (ORCPT ); Sat, 14 Jul 2012 03:56:31 -0400 Received: from grace.univie.ac.at ([131.130.3.115]:44593 "EHLO grace.univie.ac.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751684Ab2GNH43 (ORCPT ); Sat, 14 Jul 2012 03:56:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=unet.univie.ac.at; s=rev2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:Message-ID; bh=s32MMMUm2enKfYTl/xQ7Pf0yQhPZDlB3VL61fqRin9Y=; b=JpAHT5OjTDt3hgjby1nUjfGl/ykWWemj8to Received: from jarvis.univie.ac.at ([131.130.3.112] helo=jarvis.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.80) (envelope-from ) id 1SpxDH-0006YG-LT; Sat, 14 Jul 2012 09:56:27 +0200 Received: from webmail.univie.ac.at ([2001:62a:4:1::80:17] helo=webmail.univie.ac.at) by jarvis.univie.ac.at with esmtp (Exim 4.80) (envelope-from ) id 1SpxDH-0001s6-Ju; Sat, 14 Jul 2012 09:56:27 +0200 Received: from 212.17.70.199 (SquirrelMail authenticated user a9702387) by webmail.univie.ac.at with HTTP; Sat, 14 Jul 2012 09:56:27 +0200 Message-Id: Date: Sat, 14 Jul 2012 09:56:27 +0200 Subject: Re: resurrecting tcphealth From: "Piotr Sawuk" To: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org User-Agent: SquirrelMail/1.4.19 Mime-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Univie-Virus-Scan: scanned by ClamAV on jarvis.univie.ac.at Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 14 Jul 2012 07:56:37.0111 (UTC) FILETIME=[31BD9870:01CD6196] X-RcptDomain: telfort.nl 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 -- 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/