Re: [tcpm] TCP tuning
Marco Mellia <mellia@tlc.polito.it> Wed, 03 February 2010 22:56 UTC
Return-Path: <mellia@tlc.polito.it>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337653A686A for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 14:56:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.14
X-Spam-Level:
X-Spam-Status: No, score=0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5wvsDzukr4C for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 14:56:00 -0800 (PST)
Received: from polito.it (atena.polito.it [130.192.3.45]) by core3.amsl.com (Postfix) with ESMTP id B727D3A680D for <tcpm@ietf.org>; Wed, 3 Feb 2010 14:55:59 -0800 (PST)
X-ExtScanner: Niversoft's FindAttachments (free)
Received: from [151.62.47.151] (account d003516@polito.it HELO [192.168.1.2]) by atena.polito.it (CommuniGate Pro SMTP 5.2.16) with ESMTPSA id 30327958 for tcpm@ietf.org; Wed, 03 Feb 2010 23:56:42 +0100
Received-SPF: none receiver=atena.polito.it; client-ip=151.62.47.151; envelope-from=mellia@tlc.polito.it
Message-ID: <4B69FF26.2010802@tlc.polito.it>
Date: Wed, 03 Feb 2010 23:56:38 +0100
From: Marco Mellia <mellia@tlc.polito.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: tcpm@ietf.org
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <D70C30EF-91E3-4DB6-B0C7-0A6328C77E6A@ifi.uio.no> <4B69B5AC.1090209@isi.edu> <d1c2719f1002031225w24f1bb2anf89467fffe8e5971@mail.gmail.com> <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no>
In-Reply-To: <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [tcpm] TCP tuning
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2010 22:56:00 -0000
Just to try summarizing some points: - Increasing the initial window can benefit short-lived connections. But it can be dangerous, especially on low speed links, and equipments with small buffers. For example, an adsl modem has definitively a small buffer, which is typically overloaded by uploading p2p traffic... initial bursts of "several packet" (e.g., an email with attachments, a POST command with some data in it, etc.) will cause packet losses with high probability. At the end, the latency will be higher... Note that this will happen on any congested link too... - Reducing the RTO timeout is a possibility to get rid of the initial latency due to packet loss during three-way handshake. 3s seems to be too conservative these days. But there are cases in which RTT can be larger than 2s. E.g., 2.5G GSM networks, or congested 3G networks. And these kind of access networks are today more and more popular... and more and more congested... So this calls for a conservative approach. On the flip side, - someone is already hacking the TCP rules: - google is "retransmitting" the SYN-ACK with a timeout of about 200ms. This causes spurious retransmission on practically all tcp connection on a 2.5G network (I remember a paper from FTW showing this...) - windows O.S. (at least XP) is triggering the fast retransmit at the third ACK, not at the third DUPLICATE ack check http://support.microsoft.com/?scid=kb%3Ben-us%3B224829&x=11&y=11 if you don't believe it! Default value is 2 duplicate packets) - large initial windows are commonly seems. 16kB of initial window can be easily observed in any network. I suspect this is related to TCP Offloading Engines (TOE), that perform segmentation at the NIC, or the use of jumbo ethernet frames (9kB) -- the OS sees a "MSS" of 16kB (or 9kB), the initial windows is 1 segment => 10 (6) packets of 1500B each are then generated by the TOE. This supports the position "at the end, it will work in 95% of the cases". Researchers did a lot of studies about TCP latency. But are typically ignored by IETF. -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Skypeid: mgmellia | | Tel: +39-011-564-4173 | | Cel: +39-331-6714789 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www.telematica.polito.it | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux.
- [tcpm] TCP tuning Lars Eggert
- Re: [tcpm] TCP tuning Adam Langley
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning Stefanos Harhalakis
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Adam Langley
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Biswas, Anumita
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Biswas, Anumita
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Murali Bashyam
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Marco Mellia
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mike Belshe
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Alexander Zimmermann
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning Andrew Yourtchenko
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mike Belshe
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Joe Touch