Date: Sun, 28 Nov 2004 13:49:14 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Heinz Knocke <knockefreebsd@o2.pl> Cc: freebsd-net@freebsd.org Subject: Re: Why using timestamp based RTTM simplifies TCP sender? Message-ID: <20041128134535.K50193@odysseus.silby.com> In-Reply-To: <001601c4d563$4de0e740$df5561d9@ALFA> References: <001601c4d563$4de0e740$df5561d9@ALFA>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041128134535.K50193>