[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