Re: [tcpm] Tuning TCP parameters for the 21st century

Michael Welzl <michawe@ifi.uio.no> Thu, 16 July 2009 08:39 UTC

Return-Path: <michawe@ifi.uio.no>
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 38C163A6A17 for <tcpm@core3.amsl.com>; Thu, 16 Jul 2009 01:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 CkyYgJkw3IQ1 for <tcpm@core3.amsl.com>; Thu, 16 Jul 2009 01:39:24 -0700 (PDT)
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 6DF4C28C150 for <tcpm@ietf.org>; Thu, 16 Jul 2009 01:39:06 -0700 (PDT)
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <michawe@ifi.uio.no>) id 1MRMV7-0006G6-Kt for tcpm@ietf.org; Thu, 16 Jul 2009 10:39:37 +0200
Received: from div-8021x-dhcp050.uio.no ([193.157.176.59]) by mail-mx3.uio.no with esmtp (Exim 4.69) (envelope-from <michawe@ifi.uio.no>) id 1MRMV7-0000PD-AG for tcpm@ietf.org; Thu, 16 Jul 2009 10:39:37 +0200
From: Michael Welzl <michawe@ifi.uio.no>
To: tcpm@ietf.org
In-Reply-To: <4A5E018C.8030604@isi.edu>
References: <d1c2719f0907131619t1a80997ep4080a3a721ef3627@mail.gmail.com> <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <d1c2719f0907141241p73e605adqc1d2e6f0db4eb3aa@mail.gmail.com> <4A5CE3D0.5000904@isi.edu> <d1c2719f0907141532i31d2b740hfa32209a8ccb156@mail.gmail.com> <4A5D0E8F.1040402@isi.edu> <d1c2719f0907141743n4952c9far54e3be36668577ed@mail.gmail.com> <4A5DE6BC.3090904@isi.edu> <7261633966bb7a55cebd4ce313069082.squirrel@webmail.uio.no> <4A5E018C.8030604@isi.edu>
Content-Type: text/plain
Date: Thu, 16 Jul 2009 10:39:49 +0200
Message-Id: <1247733589.4184.56.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.3 (2.10.3-10.fc7)
Content-Transfer-Encoding: 7bit
X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 1 sum msgs/h 1 total rcpts 1922 max rcpts/h 33 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, none, uiobl=NO, uiouri=_URIID_)
X-UiO-Scanned: D2667986F0AD802F0AC51879019E3ED1B500ED21
X-UiO-SPAM-Test: remote_host: 193.157.176.59 spam_score: 0 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 470 max/h 15 blacklist 0 greylist 0 ratelimit 0
Subject: Re: [tcpm] Tuning TCP parameters for the 21st century
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: Thu, 16 Jul 2009 08:39:25 -0000

> > - but what about retransmitting SYN/ACKs faster?
> > Since the other side already sent a SYN, it probably
> > isn't overloaded
> 
> That presumes the other side already sent a SYN and it's been received,
> and that the SYN/ACK is what's getting lost/delayed/retransmitted.  If
> not, that won't help.

Right -


> First find where things are going wrong empirically ;-)

We've done that. See, for example, fig. 2 (a) of
http://www.welzl.at/research/publications/networking2009.pdf
(page 7 of the pdf)

Since our goal in this paper was to document general failures
of connection setup, we did not strictly split our results
into the case of lost SYNs or lost SYN/ACKs in it.
Section 3 (end of page 3 / beginning of page 4) explains
how lost SYN/ACKs were incorporated in our measurements.


This paper is based on data produced by a student. The
data are more thoroughly documented in his (alas, German)
bachelor thesis. This document is here:
http://www.welzl.at/research/tools/syn-retransmit/benjamin_kaser_bak1.pdf
and the most relevant information is table 2 on page 47.
(Table 1 is similar, just for SYNs, not SYN/ACKs).

If you look at it, with or without German knowledge
you will be able to see the connection to table 1 in
the paper, where we exchanged columns with lines and
omitted some details - apparently just the crucial
ones  :-(    Anyway, the listed measurements are just
the same, and hence you can read the details in the
paper if you're interested in how we obtained our
data.

Table 2 on page 47 of the bachelor thesis has several
details about duplicate SYN/ACKs that we've seen,
e.g. classified by eventually successful and unsuccessful
connections. As a quick summary, in 3432744 connection
attempts, we have seen 56586 duplicate SYN/ACKs in total
(this is a cumulative number, i.e. 4 SYN/ACKs are counted
as 3). Counting only the occurrence of duplicate SYN/ACKs,
we saw them for 0,55% of the 3432744 connection attempts.
In general, the difference between duplicate SYN/ACK
occurrences and duplicate SYN occurrences is negligible
in our measurements.

As I just looked at the data again, I noticed a mistake:
in the paper, we wrote that the problem only happens for
around 0.5% of the connections, but this is really only
from the SYN table, not the SYN/ACK table in the bachelor
thesis. The SYN/ACK table covers the same measurement sets.
Hence, in total, it seems that we also saw > 1% lost SYNs
*or* SYN/ACKs, which exactly matches what Jerry Chu said.
 
BTW I maintain a small website about the whole thing:
http://www.welzl.at/research/tools/syn-retransmit/index.html

Cheers,
Michael