netdev
[Top] [All Lists]

Re: RFC 1323

To: "R Harper" <rharper333@xxxxxxxxxxx>
Subject: Re: RFC 1323
From: rick jones <rick.jones2@xxxxxx>
Date: Mon, 4 Apr 2005 09:56:06 -0700
Cc: netdev@xxxxxxxxxxx
In-reply-to: <BAY20-F2375830DACBEC22EDD913C923B0@phx.gbl>
References: <BAY20-F2375830DACBEC22EDD913C923B0@phx.gbl>
Sender: netdev-bounce@xxxxxxxxxxx

Another question, as I understand the RFC, the timestamp are only relevant to the box generating them. Are TCP implementation different in how the TSval data is represented?

They certainly can be - for the PAWS portion of 1323 the fields in the "timestamp" options only have to be monotonic nondecreasing so they can extend the sequence number space. From my brief perusal of the RFC, sender's are free to have them be more or less whatever they want, and as networks become faster (10G) looks like higher resolution will be desired.


[I wonder when even the extra 32 bits will not be enough :) ]

With the recent dust-up about ID'ing systems based on their clock skew, it would not surprise me to see someone suggest that the options should just be for PAWS and not for RTTM.

Is it possible to make use of the timestamp in an intermediate box, e.g. estimating RTT in a box that a TCP connection passes?

If you know that the sender is using the option for timing, and know the resolution - basically that means knowing what the sender is running.


rick jones
there is no rest for the wicked, yet the virtuous have no pillows


<Prev in Thread] Current Thread [Next in Thread>
  • RFC 1323, R Harper
    • Re: RFC 1323, rick jones <=