Re: [tcpm] Minimum RTO
Jerry Chu <hkchu@google.com> Tue, 10 April 2012 20:57 UTC
Return-Path: <hkchu@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47B411E814B for <tcpm@ietfa.amsl.com>; Tue, 10 Apr 2012 13:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level:
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vho5CGRVhGPY for <tcpm@ietfa.amsl.com>; Tue, 10 Apr 2012 13:57:06 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A014811E8149 for <tcpm@ietf.org>; Tue, 10 Apr 2012 13:57:05 -0700 (PDT)
Received: by lbok13 with SMTP id k13so200948lbo.31 for <tcpm@ietf.org>; Tue, 10 Apr 2012 13:57:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=8RTa1zdPkKR1E8fktgbEK0UpoIbvFYTwRPLlhRRYRHI=; b=IMhcND8MsB0dwvdOpri0VrxVkpBhgal1UMBWG/dcWrgMRUjYdAukRYPAWxnNbabr1l pt5DyBTmSp3v0efcAR7ZEvOJXwxBITqPHaNlqIP48K+8FIHovV3f0JWR5kg5muMHUtvV YdoWhlFLcVIN5CXcfihZTiQ9TLMEaCm3y7TKWvIt8UbD/t8isc5yTLJ9VyzpVRS4FGTx avkhQ0mEtYVZrGFu+bPKYOK/dPuD5r3MJkF/yD2a6LR/+eOkGrtcfw/OrcW4cMiLP+hq 57AHKZEtfnHnLoZuJunkiEAr9l2ulOhIhJCWNka7v/1aREkWJsv3V8c2S/GlZdsGzOOf ZL/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=8RTa1zdPkKR1E8fktgbEK0UpoIbvFYTwRPLlhRRYRHI=; b=dsQk/UNrlbEiESuMKT8vRBqC2kaNsM5YUwvAavdKr4QLuCwCVeVWi3amJKLM/+1Fda b3sObfowJNbDhVuznWJ7/6CqMZFIfVT2Yu5cgKMNF4j3sjypZzpW+JzcJoqqpzERkGYB EzkF04IDwobVlLE4qyycHt7rzYuRh0X4dmoltgTfooehN2ajnAFkERw5Cyj0zxZ2pd4p uqhZNlkq3HMFdb6DvSY+5jRBPiSpLI7i4sUgrk/rdHxzmXQLQCVhlmTsePOAZzRo3q8d 7NUbNN50rEqbux4CUQOPqAlK6/QG7YVyrtNS47vrIcQeH6IUcpMG27UjFYVZfx4MMNpO 7t9A==
Received: by 10.152.103.134 with SMTP id fw6mr16023975lab.20.1334091424578; Tue, 10 Apr 2012 13:57:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.103.134 with SMTP id fw6mr16023969lab.20.1334091424484; Tue, 10 Apr 2012 13:57:04 -0700 (PDT)
Received: by 10.152.29.236 with HTTP; Tue, 10 Apr 2012 13:57:04 -0700 (PDT)
In-Reply-To: <2A08B7ACA17C9F4BAA8D5395DF908D731DED9A27@SEAEMBX02.olympus.F5Net.com>
References: <2A08B7ACA17C9F4BAA8D5395DF908D731DED9A27@SEAEMBX02.olympus.F5Net.com>
Date: Tue, 10 Apr 2012 13:57:04 -0700
Message-ID: <CAPshTCh_vn6qKAs8_X3VFVT=nBOL4rg80s7SMjk=KDiG3yjHmw@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: Mark Lloyd <M.Lloyd@f5.com>
Content-Type: multipart/alternative; boundary="f46d040716eb744eed04bd595dfd"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkBDiz0P6BvT3AW5Ze1Oyh/bzIFCN972b7NacWH7oD8hEfjubho7E+NWpYMqaZV8iqiJY+NAs0dEV59UixLTsK2ESg9I/T1bRCWvgMnuiz8hwNgof00+awiSBKNfL0fkXWkniHW
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] Minimum RTO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 10 Apr 2012 20:57:08 -0000
Mark, RFC6298 is mainly for reducing the initial RTO from 3secs to 1sec. We did not touch the minimum RTO due to a lack of consensus and also for fear of opening a prolonged debate. Besides, OSes have reduced minRTO anyway as you noted. Personally I don't think a somewhat arbitrary RTO lower bound is really necessary, but delayed acks complicate the matter. Jerry On Tue, Apr 10, 2012 at 12:52 PM, Mark Lloyd <M.Lloyd@f5.com> wrote: > Reading RFC 6298 > > http://tools.ietf.org/html/rfc6298 > > > (2.4) Whenever RTO is computed, if it is less than 1 second, then the > RTO SHOULD be rounded up to 1 second. > > > While troubleshooting a problem that involves minimum RTO, I found that > RFC 6298 suggests a 1 second value for minimum RTO that is not honored in > the implementations I have tested, and even in these implementation TCP > does not do a good job of handling packet loss in a common scenario I > tested. > > I use two Linux hosts as my test. They are setup to imitate the kind of > connection that would be used for a database or RPC transaction. > > My server does a netcat command that loops back data as it is received: > > touch /tmp/testfile > tail -f /tmp/testfile | sudo nc -l 1000 >>/tmp/testfile > > The client sends data, then echos a response simulating a TCP conversation > of small transactions. > > touch /tmp/testfile > echo hello >/tmp/testfile > tail -f /tmp/testfile | nc 10.10.30.121 1000 >>/tmp/testfile > > I then setup a wan emulator to simulate a 1% loss rate back to the client. > > I'm showing frames leading up to the packet loss to show the what the > traffic looks like up to the packet loss. > > Server side: > > Frm Time > Num Delta > 1941 0.0000830 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646100 - 1538646106, > Ack=1257857589, > 1942 0.0005920 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857589 - 1257857595, > Ack=1538646106 > 1943 0.0000920 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646106 - 1538646112, > Ack=1257857595 > 1944 0.0005590 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857595 - 1257857601, > Ack=1538646112 > 1945 0.0000730 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646112 - 1538646118, > Ack=1257857601 > 1946 0.0005770 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857601 - 1257857607, > Ack=1538646118 > 1947 0.0000930 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646118 - 1538646124, > Ack=1257857607 > 1948 0.0006190 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857607 - 1257857613, > Ack=1538646124 > 1949 0.0000790 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646124 - 1538646130, > Ack=1257857613 > 1950 0.0005110 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857613 - 1257857619, > Ack=1538646130 > 1951 0.0000850 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646130 - 1538646136, > Ack=1257857619 > Packet 1951 will be lost in > transit. Note 205ms gap. > > 1952 0.2053670 Client -> Server TCP:[ReTransmit > #1950]Flags=...AP..., SrcPort=55552, DstPort=1001, PayloadLen=6, > Seq=1257857613 - 1257857619 > 1953 0.0000420 Server -> Client TCP:Flags=...A...., > SrcPort=1001, DstPort=55552, PayloadLen=0, Seq=1538646136, Ack=1257857619 > 1954 0.0007630 Server -> Client TCP:[ReTransmit #1951] > Flags=...AP..., SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646130 - > 1538646136, Ack=1257857619 > 1955 0.0006640 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857619 - 1257857625, > Ack=1538646136 > > Client side: > > 1928 0.0006400 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646094 - 1538646100, > Ack=1257857583 > 1929 0.0000690 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857583 - 1257857589, > Ack=1538646100 > 1930 0.0006200 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646100 - 1538646106, > Ack=1257857589 > 1931 0.0000690 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857589 - 1257857595, > Ack=1538646106 > 1932 0.0006300 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646106 - 1538646112, > Ack=1257857595 > 1933 0.0000730 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857595 - 1257857601, > Ack=1538646112 > 1934 0.0005230 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646112 - 1538646118, > Ack=1257857601 > 1935 0.0000830 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857601 - 1257857607, > Ack=1538646118 > 1936 0.0006140 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646118 - 1538646124, > Ack=1257857607 > 1937 0.0000750 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857607 - 1257857613, > Ack=1538646124 > 1938 0.0006230 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646124 - 1538646130, > Ack=1257857613 > 1939 0.0000650 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857613 - 1257857619, > Ack=1538646130 > Packet does not arrive from > server. Client retransmits in 205ms. > > 1940 0.2053300 Client -> Server TCP:[ReTransmit #1939] > Flags=...AP..., SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857613 - > 1257857619, Ack=1538646130 > 1941 0.0006840 Server -> Client TCP:Flags=...A...., > SrcPort=1001, DstPort=55552, PayloadLen=0, Seq=1538646136, Ack=1257857619 > 1942 0.0006970 Server -> Client TCP:Flags=...AP..., > SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646130 - 1538646136, > Ack=1257857619, > 1943 0.0001120 Client -> Server TCP:Flags=...AP..., > SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857619 - 1257857625, > Ack=15386461 > > Linux responds in ~200ms, not the suggested 1 second, but this is still > not very helpful. The RTO of 200ms recovers better than the suggested > minimum RTO, but 200ms is way too long as we have a sub-millisecond RTT. A > similar test with a Windows host showed a minimum RTO of ~300ms. > > > 1. Why was the now quaint 1 second minimum RTO carried over into RFC 6298? > 2. Is there a way we can get the minimum RTO down below even 200ms in a > low latency network without breaking other TCP features? > > I can see some discussion on the internet about this but I don't see > movement to come up reasonable modern value the most recent RFC 6298. > > e.g. > http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-consider-00.txt > > > Also, note, that in addition to the experiments discussed in [AP99], > the Linux TCP implementation has been using various non-standard RTO > mechanisms for many years seemingly without large scale problems > (e.g., using different EWMA gains). Also, a number of > implementations use minimum RTOs that are less than the 1 second > specified in [RFC2988]. While the precise implications of this may > show more spurious retransmits (per [AP99]) we are aware of no large > scale problems caused by this change to the minimum RTO > > Mark Lloyd | Enterprise Network Engineer > F5 Networks > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >
- [tcpm] Minimum RTO Mark Lloyd
- Re: [tcpm] Minimum RTO Jerry Chu
- Re: [tcpm] Minimum RTO Mark Allman
- Re: [tcpm] Minimum RTO Anantha Ramaiah (ananth)
- Re: [tcpm] Minimum RTO Hagen Paul Pfeifer
- Re: [tcpm] Minimum RTO Murari Sridharan