[e2e] [tcpm] RTTM + timestamps

[Scheffenegger, Richard]

It appears to me, that somehow finer timestamp clock (and distinct from
that, value representation) resolution and larger timestamp range got
all mixed up in these discussions.



As I see it, there is no pressing need for timestamp clock counters
exceeding 32 bit; However, there is some room for improvement to make
better use of these bits (and if that is no longer sufficient, an
expansion would be required).

Using NTP4 [5] timestamps directly, as suggested, would implicitly
define the timestamp value resolution (the timestamp clock could still
run at a different granularity).

Shifting the existing 32-bit field so that the least significant bit
"counts" at the natural frequency of the timestamp clock appears to be a
different approach which can achieve similar goals.

Ideally, for RTT measurement purposes*, the timestamp clock should run
at a rate at least as high as the tcp clock. (Often, timestamp clock and
tcp clock are identical). Furthermore, to use timestamps effectively,
the timestamp clock should "tick" at least once per RTT. With heuristics
like Eifel, spurious RTO, and reordering  detection is not possible if
the timestamp clock resolution does not allow to resolve the Path RTT. 

On the other end of the constraints, PAWS only requires the timestamp
clock to tick once per sequence number overflow, and otherwise as slow
as feasible...


But suggesting to change the timestamp clock rate to something
(significantly) higher than the TCP clock rate does not necessarily
require larger timestamp fields of 64 or 128 bits... It only allows to
cover extreme edge cases at the same time, without adaptive heuristics.


There may also be some misconceptions around
http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiatio
n-02 where the number of significant bits to signal a clock rate is
mistaken to imply that the timestamp clock MUST run at a similar high
frequency. Quite the opposite - the timestamp clock duration is signaled
with 10 significant bits, across a few orders of magnitude (in the
draft, between 16 sec and 8 ns - the latter allowing a clock source like
a x86_64 RDTSC at optimal resolution).

Using NTP4 [5] timestamps directly would not only possibly imply a clock
resolution of the sender, which is actually never used, but also enable
direct manipulation of timestamp values. However, TCPCT only provide
some means of signaling larger timestamp clock values, without
stipulating their content at all. If native NTP timestamp format were to
be used, the only possible protection would be a random timestamp
offset, unique for each tcp flow. Nevertheless, for certain time-based
heuristics, for example CUBIC, such a static offset doesn't help at all
(a malicious user can still manipulate the reflected timestamps to cause
the sender more data to send, than intended). Larger timestamps could
not be used for anything more advanced than simple (and crude) RTT
measurements / PAWS detection, while very expensive workarounds (i.e.
Linux with the fix for the CUBIC exploit) become necessary.

The draft aims at providing the means to open up the interpretation of a
timestamp value by the receiver, which includes different semantics
under certain circumstances, providing means to protect the value
against tampering, and of course shifting the timestamp clock value so
that it can be used optimally for a specific environment (WAN or LAN,
high or low speed, emphasis on PAWS or emphasis on enhanced TCP
congestion control heuristics using RTT / OWDV as input).




*) In addition to RTT measurements, one way delay variance (OWDV)
measurements would need a timestamp clock resolution at least a few
(binary) magnitudes more granular than the RTT of the path.


Richard Scheffenegger


> -----Original Message-----
> From: William Allen Simpson [mailto:william.allen.simpson at gmail.com]
> Sent: Donnerstag, 28. Juli 2011 22:48
> To: end2end-interest at postel.org
> Cc: Scheffenegger, Richard
> Subject: Re: [e2e] [tcpm] RTTM + timestamps
> 
> On 7/28/11 8:37 AM, Detlef Bosau wrote:
> >  From what I've seen from Richard, Richards concern is to get TCP
RTT
> samples with a much finer resolution than we do today.
> >
> > Particularly your own work targets at the feasibility for the RTT
> sampling mechanism from RFC 2988 (IIRC) for WWAN.
> >
> > While I don't think that we really have an issue with the TCP clock
> resolution, at least no new one, finding suitable RTOs for WWAN is an
> important issue for TCP in conjunction with WWAN.
> >
> A couple of years ago, when I first asked this list about TCPCT
related
> work, *several* folks wanted finer grained resolution.  So, I added
the
> 64-bit NTP4-format timestamps.  Then, many months later, a naysayer
> raised
> the possibility that NTP5 will someday replace NTP4.  I had to redo
the
> format to be even more extensible, rendering my extant code
> obsolete....
> 
> But I don't know anybody actually writing the code for 64-bit
> timestamps
> though, let alone NTP5-sized.  Would folks be interested in a draft
> describing them?  Would that help move things along?