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.