Why using timestamp based RTTM simplifies TCP sender?

[Mike Silbersack]

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