From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 19:49:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3255B16A4CE for ; Sun, 28 Nov 2004 19:49:17 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 8727F43D3F for ; Sun, 28 Nov 2004 19:49:16 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 60401 invoked from network); 28 Nov 2004 19:49:15 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 28 Nov 2004 19:49:15 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 28 Nov 2004 13:49:14 -0600 (CST) From: Mike Silbersack To: Heinz Knocke In-Reply-To: <001601c4d563$4de0e740$df5561d9@ALFA> Message-ID: <20041128134535.K50193@odysseus.silby.com> References: <001601c4d563$4de0e740$df5561d9@ALFA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: Why using timestamp based RTTM simplifies TCP sender? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2004 19:49:17 -0000 On Sun, 28 Nov 2004, Heinz Knocke wrote: > Hi everybody! > > While reading quite old but important RFC 1323 in chapter on RTT > measurement based on timestamps I found an opinion that: > > " A solution to these problems (rough RTT estimation) which actually > simplifies the sender substantially, is as follows: using TCP options, > the sender places a timestamp in each data segment, and the receiver > reflects these timestamps back in ACK segments ..." > > I really coldn't find many arguments, why adding another option will > simplify sender's code. I think that no matter what it does, it cannot > simplify because the stack needs to be backward compatible, so all > previous solutions must stay. Maybe Van Jacobson thought about the > situation when timestamp option becomes compulsory, making removal of > some old bytes possible? I think what Van Jacobson meant is that without timestamps, you run into problems when you have packets dropped. If you've retransmitted a packet, then receive an ACK for that packet, you will not know whether that's a highly delayed ACK for the original transmission, or the ACK for the retransmission. Therefore, timing is difficult. Comparatively, with timestamps, you never have to worry about such timing problems. You are correct that the non-TS code must remain in the TCP stack. However, I don't think complexity of the old code is what he was referring to. Mike "Silby" Silbersack