From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 15:58:44 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 A5BBF16A4CE for ; Sun, 28 Nov 2004 15:58:44 +0000 (GMT) Received: from poczta.o2.pl (mx.go2.pl [193.17.41.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0202343D58 for ; Sun, 28 Nov 2004 15:58:40 +0000 (GMT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (aaf223.warszawa.sdi.tpnet.pl [217.97.85.223]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by poczta.o2.pl (Postfix) with ESMTP id 232D313779A for ; Sun, 28 Nov 2004 16:58:36 +0100 (CET) Message-ID: <001601c4d563$4de0e740$df5561d9@ALFA> From: "Heinz Knocke" To: Date: Sun, 28 Nov 2004 16:59:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: 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 15:58:44 -0000 Hi everybody! While reading quite old but important RFC 1323 in chapter on RTT = measurement based on timestamps I found an opinion that:=20 " 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 ..." and "Furthermore, the option is probably useful for all TCP's, since it = simplifies the sender" 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?=20 Could any of you guys who are deep into TCP stack code could give me = some hints?=20 Thanks in advance! H.K