Re: Why using timestamp based RTTM simplifies TCP sender?

From: Mike Silbersack (silby_at_silby.com)
Date: 11/28/04

  • Next message: Chuck Swiger: "Re: FreeBSD 5.3 Networking performance problem" 
    Date: Sun, 28 Nov 2004 13:49:14 -0600 (CST)
To: Heinz Knocke <knockefreebsd@o2.pl>

    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
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Chuck Swiger: "Re: FreeBSD 5.3 Networking performance problem"

    Relevant Pages

    • Re: IEEE 1588 support in NTP?
      ... It doesn't make a lot of sense to moo time based on a herd of TSU counters unless each cow in the herd is wrangled to a common timescale. ... If each cow in the herd has a frequency error up to 100 PPM and the accuracy expectation is one microsecond, the moo needs to be adjusted on the order of 100 times each second. ... In my favorite the frame format leaves space for two timestamps following the checksum. ... identifier and timestmap of the packet just sent. ...
      (comp.protocols.time.ntp)
    • Re: bin/118005: Can No Longer SSH into 7.0 host
      ... LAN I cannot ssh into this host. ... implement timestamps and pass all tests that were added to FreeBSD ... This packet differs significantly from any other packet the client ...
      (freebsd-net)
    • Re: Fire Engine??
      ... Do the timestamps need to be precise and accurately reflect the ... Or, for TCP timestamps, would it be ... Apart from TCP, precise timestamps are only used for packet capture, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Reading time offset from ntp variables using ntpq
      ... Page 50 defines the timestamps in the NTP packet as Reference, Originate, Receive, and Transmit. ... I just wanted to use NTP as a tool to measure the time drift of my system clock and now you pull the dreaded "read the architecture briefing" weapon on me. ...
      (comp.protocols.time.ntp)
    • Re: Fire Engine??
      ... >> the packet has arrived. ... Or, for TCP timestamps, would it be ... reasonable choice for a configurable option, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)