From owner-tcp-impl@grc.nasa.gov Fri Jul 11 16:46:50 2003 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16124 for ; Fri, 11 Jul 2003 16:46:49 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 995E368A50 for ; Fri, 11 Jul 2003 16:46:21 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h6BKODeM019287 for tcp-impl-outgoing; Fri, 11 Jul 2003 16:24:13 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h6BKOBLc019281 for ; Fri, 11 Jul 2003 16:24:12 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h6BKOBxT025044 for ; Fri, 11 Jul 2003 16:24:11 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B435B6899E for ; Fri, 11 Jul 2003 16:24:10 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA18453 for ; Fri, 11 Jul 2003 15:24:09 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id PAA06797 for ; Fri, 11 Jul 2003 15:24:08 -0500 (CDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h6BKN5e03412 for ; Fri, 11 Jul 2003 13:23:05 -0700 (PDT) Received: from XCH-NW-03.nw.nos.boeing.com ([192.42.226.68]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Fri, 11 Jul 2003 13:23:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Updating timestamps (ts_recent) in Linux Date: Fri, 11 Jul 2003 13:23:08 -0700 Message-ID: Thread-Topic: Updating timestamps (ts_recent) in Linux Thread-Index: AcNH6m3g2KazX44vR4KLcpKXjHtpFw== From: "Duke, Martin" To: X-OriginalArrivalTime: 11 Jul 2003 20:23:08.0390 (UTC) FILETIME=[3DF52060:01C347EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id h6BKOCLc019282 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit I've heard rumors that this has been discussed before on tcp-impl, but an extensive search found no messages on this topic. How do people feel about the way Linux decides what timestamp to echo? Specifically, although the behavior is compliant with RFC 1323, an old addendum to the RFC (http://www.kohala.com/start/tcplw-extensions.txt) pointed out some odd behavior. Essentially, if the connection goes down, the subsequent retransmissions will have later ts values. However, if an ACK was lost, the kernel currently does not update ts_recent with these values. If the channel comes back up and a retrans succeeds, the client will send an ack with an ts echo equal to the old value of ts_recent. As the difference between the echo and the current time is quite large, it will result in an extremely large RTT measurement, triggering a huge increase in the RTO. In an unreliable, bursty link, such as satellites, another outage could occur shortly thereafter, and an inappropriately long timeout can occur. The reason for the problem is that ts_recent is only updated if the receive window moves to the right. Ideally, packets with sequence numbers to the left of the window edge should trigger an update as well. There are certainly situations where the current Linux behavior is terrible, but I have yet to see an explanation for why this "bug" should not be fixed. I've heard criticisms of the document cited above as a whole but have yet to understand why updating ts_recent more frequently will break something. I know that BSD fixed this some time ago (Stevens talks about it in his book). Any thoughts? Martin Duke martin.duke@boeing.com