[tcpm] TCP retransmission timeouts (RFC 2988)
"Ian McDonald" <ian.mcdonald@jandi.co.nz> Wed, 29 August 2007 22:43 UTC
Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQWGS-0007wv-0B; Wed, 29 Aug 2007 18:43:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQWGO-0007tq-4q for tcpm@ietf.org; Wed, 29 Aug 2007 18:43:52 -0400
Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQWGM-00052c-3g for tcpm@ietf.org; Wed, 29 Aug 2007 18:43:51 -0400
Received: by wa-out-1112.google.com with SMTP id k40so445406wah for <tcpm@ietf.org>; Wed, 29 Aug 2007 15:43:49 -0700 (PDT)
Received: by 10.114.209.1 with SMTP id h1mr21054wag.1188427428868; Wed, 29 Aug 2007 15:43:48 -0700 (PDT)
Received: by 10.114.196.9 with HTTP; Wed, 29 Aug 2007 15:43:48 -0700 (PDT)
Message-ID: <5640c7e00708291543h58e73d2cj456eb248338988e9@mail.gmail.com>
Date: Thu, 30 Aug 2007 10:43:48 +1200
From: Ian McDonald <ian.mcdonald@jandi.co.nz>
To: tcpm@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Subject: [tcpm] TCP retransmission timeouts (RFC 2988)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org
(Resent to tcpm list, instead of iccrg) After some discussion on the Linux networking list I thought I'd ask the question here. In RFC 2988 Section 2.4 says: (2.4) Whenever RTO is computed, if it is less than 1 second then the RTO SHOULD be rounded up to 1 second. Traditionally, TCP implementations use coarse grain clocks to measure the RTT and trigger the RTO, which imposes a large minimum value on the RTO. Research suggests that a large minimum RTO is needed to keep TCP conservative and avoid spurious retransmissions [AP99]. Therefore, this specification requires a large minimum RTO as a conservative approach, while at the same time acknowledging that at some future point, research may show that a smaller minimum RTO is acceptable or superior. Given that Linux, BSD etc use 200 milliseconds, not 1 second I am wondering whether there has in fact been any research done as mentioned in last sentence. It seems a very high timeout especially on two locally connected devices. Apologies if I'm asking on the wrong list. Regards, Ian -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm
- [tcpm] TCP retransmission timeouts (RFC 2988) Ian McDonald
- Re: [tcpm] TCP retransmission timeouts (RFC 2988) Mark Allman