Why using timestamp based RTTM simplifies TCP sender?
silby at silby.com
Sun Nov 28 11:49:17 PST 2004
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
Mike "Silby" Silbersack
More information about the freebsd-net