One document matched: draft-trammell-tcpm-timestamp-interval-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="exp" docName="draft-trammell-tcpm-timestamp-interval-00.txt">
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front>
<title abbrev="Timestamp Intervals">
Exposure of Time Intervals for the TCP Timestamp Option
</title>
<author fullname="Richard Scheffenegger"
initials="R." surname="Scheffenegger">
<organization>NetApp, Inc.</organization>
<address>
<postal>
<street>Am Euro Platz 2</street>
<city>1120 Vienna</city>
<country>Austria</country>
</postal>
<phone>+43 1 3676811 3146</phone>
<email>rs@netapp.com</email>
</address>
</author>
<author fullname="Mirja Kuehlewind"
initials="M." surname="Kuehlewind">
<organization>University of Stuttgart</organization>
<address>
<postal>
<street>Pfaffenwaldring 47</street>
<city>70569 Stuttgart</city>
<country>Germany</country>
</postal>
<email>mirja.kuehlewind@ikr.uni-stuttgart.de</email>
</address>
</author>
<author fullname="Brian Trammell"
initials="B." surname="Trammell">
<organization abbrev="ETH Zurich">
Swiss Federal Institute of Technology Zurich
</organization>
<address>
<postal>
<street>Gloriastrasse 35</street>
<city>8092 Zurich</city>
<country>Switzerland</country>
</postal>
<phone>+41 44 632 70 13</phone>
<email>trammell@tik.ee.ethz.ch</email>
</address>
</author>
<date month="October" day="14" year="2012"/>
<area>Transport</area>
<workgroup>TCP Maintenance and Minor Extensions (tcpm)</workgroup>
<keyword>TCP</keyword>
<keyword>timestamp</keyword>
<keyword>interval</keyword>
<abstract>
<t>The TCP Timestamp option would be useful for additional measurements
if it could be assumed that the interval between ticks of the timestamp
clock are regular, and if that interval were known. In practice, many
implementations do use a timestamp clock source that has a regular
interval. This draft specifies a mechanism for exposing the timestamp
interval to a receiver, and discusses applications therefor.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Timestamp option originally introduced in <xref target="RFC1323"/>
was designed to support only two very specific mechanisms, round trip
time measurement (RTTM), and protection against wrapped sequence numbers
(PAWS), assuming a particular TCP algorithm (Reno).</t>
<t>While <xref target="RFC1323"/> specifies only that timestamps "must be
at least approximately proportional to real time" to support RTTM, many
implementations generate timestamp values from a regular timing source.
Determining the real-time interval represented by a single tick makes
additional measurements possible. In addition to easing passive
measurements using the timestamp option, it also makes possible the
measurement of inter-departure time; the comparison of inter-departure time
to inter-arrival time can be used to one-way delay variation measurement,
useful for congestion control algorithms as well in QoS applications
[FIXME: others?]</t>
<t>This document specifies a compact encoding for timestamp intervals
which can be exported via multiple mechanisms, including an experimental
TCP option, or the mechanism described in <xref
target="I-D.scheffenegger-tcpm-timestamp-negotiation"/>.</t>
</section>
<section anchor="terms" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<t>Terms defined in <xref target="RFC1323"/> are used in this document as
defined there.</t>
<t>This document defines the following additional term:</t>
<t><list style="hanging">
<t hangText="Timestamp interval"><vspace />
The interval between two ticks of the timestamp clock source running at
a constant frequency. Note that the timestamp clock is not required to
be identical with the TCP clock, even though most implementations use
the same clock for practical purposes. </t>
</list></t>
</section>
<section title="Timestamp interval exposure">
<t>This section describes the requirements for interval encoding, then
specifies an interval to meet these requirements based on a 16-bit
reduced-precision encoding of a 42-bit fixed-point unsigned integer.</t>
<section title="Interval encoding requirements">
<t>The choice of a timestamp interval is generally
implementation-specific, and there are a small number of commonly
chosen intervals. However, a general solution must support not only
common cases, but uncommon ones, and provide future flexibility to
allow an implementation to dynamically choose new timestamp intervals
for new sockets, based on network conditions and specific requirements
for timestamp measurements.</t>
<t>There are some sensible bounds on the range of timestamp intervals
that must be reasonably supported. The minimum inter-packet interval
for 64-byte packets (i.e., back-to-back ACK segments) on a future 400
Gigabit Ethernet would be about 1ns; smaller intervals need not be
supported with current technology, even for applications for which a
unique timestamp for every packet would be useful. On the other side of
the scale, low-bandwidth, high-latency links may operate with timestamp
intervals on the order of seconds.</t>
<t>The precision required by timestamp interval export, on the other
hand, is determined by the applications for which the information will
be used and the precision of the underlying clock source. As many clock
sources may provide less than maximum precision (due to e.g. interrupt
jitter), there should be some way to represent variable precision.
[FIXME: justify why 11 bits is enough here.]</t>
<t>As a timestamp interval will need to be bound to a connection
in-band at runtime, a space-efficient encoding is necessary.</t>
<t>These requirements indicate a reduced-precision encoding of a
fixed-point interval, expressed in seconds, as described in the next
subsection.</t>
</section>
<section title="Interval encoding specification" anchor="sec-encoding">
<t>A 42-bit fixed-point unsigned integer with 4 bits before the decimal
point and 38 bits after, expressed in seconds, is sufficient to encode
an interval range from just under 16 seconds (0x3ff ffff ffff) down to
2^-38 s or 3.64 ps (0x000 0000 0001), meeting the range requirement.
Sufficient precision for the applications envisioned by this document
is provided by exporting just the 11 most significant bits of the
interval value (here, the "value"), coupled with a 5-bit "scale" which
locates the least significant bit of the value within the larger field:
a scale of 31 places the value field between bits 41 and 31 inclusive
of the fixed-point integer for the largest intervals, while a scale of
0 places the value field between bits 10 and 0 inclusive. By using a
scale such that the most significant bit of the value is not 1, less
than 11 bits of precision can be signaled, as well; implementations
SHOULD NOT represent more precision in an exported timestamp interval
Full precision export is available down to 2^-27 s (or 7.45 ns) with
diminishing precision down to 3.64 ps. This arrangement therefore
allows the representation of timestamp intervals over 13 orders of
magnitude and 11 bits of precision with only two octets. The details of
this encoding are illustrated in <xref target="fig-int-encoding"/>.</t>
<figure anchor="fig-int-encoding" title="Timestamp interval encoding using scaled fixed-point integer" align="center">
<artwork align="center"><![CDATA[
MSb LSb
4 3 3 2 1
1 7 1 3 5 7 0
+----+------+--------+--------+--------+-------+
| int| frac | full value
+----+------+--------+--------+--------+-------+
/ \
+-+ \
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| scale | value | encoded interval
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 0
5 1 0
MSb LSb
]]></artwork></figure>
<t>This encoded 16-bit interval is then exported for a given
connection as a standalone TCP option or as part of the extended
timestamp negotiation described in the following subsections.</t>
<t>A sender explicitly signals that it uses an irregular timestamp clock
by sending 0 for both scale and value.</t>
<t>For implementations that support only a single timestamp interval for
all flows in all situations, the encoded interval can be implemented as a
constant. Encodings for common timestamp intervals are given in <xref
target="tab-common-intervals"/>.</t>
<texttable anchor="tab-common-intervals" align="center"
title="Encodings for common timestamp intervals at maximum precision">
<ttcol align="right">interval</ttcol>
<ttcol align="right">frequency</ttcol>
<ttcol align="center">scale</ttcol>
<ttcol align="center">value</ttcol>
<ttcol align="center">combined</ttcol>
<c>16 s </c> <c>0.06 Hz </c> <c>0x1f</c> <c>0x7ff</c> <c>0xffff</c>
<c>1 s </c> <c> 1 Hz </c> <c>0x1c</c> <c>0x400</c> <c>0xe400</c>
<c>0.5 s </c> <c> 2 Hz </c> <c>0x1b</c> <c>0x400</c> <c>0xdc00</c>
<c>100 ms</c> <c>10 Hz </c> <c>0x18</c> <c>0x666</c> <c>0xc666</c>
<c> 10 ms</c> <c>100 Hz </c> <c>0x15</c> <c>0x51f</c> <c>0xad1f</c>
<c> 4 ms</c> <c>250 Hz </c> <c>0x14</c> <c>0x419</c> <c>0xa419</c>
<c> 1 ms</c> <c> 1 kHz</c> <c>0x12</c> <c>0x418</c> <c>0x9418</c>
<c>200 us</c> <c> 5 kHz</c> <c>0x0f</c> <c>0x68e</c> <c>0x7e8e</c>
<c> 50 us</c> <c>20 kHz</c> <c>0x0d</c> <c>0x68e</c> <c>0x6e8e</c>
<c> 1 us</c> <c> 1 MHz</c> <c>0x08</c> <c>0x432</c> <c>0x4432</c>
<c> 60 ns</c> <c>16.7 MHz</c> <c>0x04</c> <c>0x407</c> <c>0x2407</c>
<c> none </c> <c>--------</c> <c>0x00</c> <c>0x000</c> <c>0x0000</c>
</texttable>
<!-- minimum precision values from previous draft -->
<!-- <c>ADJ=31, INT=0x7FF</c>
<c>ADJ=31, INT=0x080</c>
<c>ADJ=31, INT=0x040</c>
<c>ADJ=31, INT=0x00C</c>
<c>ADJ=31, INT=0x001</c>
<c>ADJ=30, INT=0x001</c>
<c>ADJ=28, INT=0x001</c>
<c>ADJ=25, INT=0x001</c>
<c>ADJ=23, INT=0x001</c>
<c>ADJ=18, INT=0x001</c>
<c>ADJ=14, INT=0x001</c> -->
</section>
<section title="Timestamp Interval experimental TCP option">
<t>This section specifies an experimental TCP option, using
arbitrarily chosen magic numbers as described in <xref
target="I-D.ietf-tcpm-experimental-options"/>, for exporting
timestamp intervals. This option MAY appear in any TCP segment after
the SYN segment to advertise the sender's timestamp interval, encoded
as in <xref target="sec-encoding"/> above. If the receiver uses
timestamp interval information, it stores the interval for the
duration of the connection, or until a subsequent Timestamp Interval
option is received.</t>
<t>If a sender has previously sent a timestamp interval to a
receiver, and changes the timestamp interval on the connection, it
MUST send a new Timestamp Interval option.</t>
<t>This option MUST NOT appear in a segment in which a TCP Timestamp
option is also not present.</t>
<figure anchor="fig-option" title="Structure of Timestamp Interval Experimental TCP option for interval export" align="center">
<artwork align="center"><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind = 253 | Length = 8 | magic0 = 0x75ec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| magic1 = 0xffee | encoded advertised interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>[FIXME: specify how long after an advertisement of a new or
changed interval the interval must be valid for the connection.]</t>
</section>
<section title="Interval export during TS negotiation">
<t>[EDITOR'S NOTE: bind to new revision of the TS negotiation draft;
requires TS negotiation that can flexibly add 16 bits of content to
the negotiation handshake.]</t>
</section>
</section>
<section title="Timestamp interval negotiation">
<t>[EDITOR'S NOTE: describe here how a receiver could ask a sender for
a specific TS rate: an option with two encoded intervals could be
handled as consisting of an advertised interval (first interval) and a
requested interval (second interval). A sender that gets an interval
request must then send a ts interval option which advertises the
closest interval it is willing to support. This mechanism could also be
used to implicitly request that timestamps be turned on, if it is
decided that 1323 could be updated to support mid-connection
initialization of TS.]</t>
</section>
<!-- <section title="Timestamp interval estimation">
<t>[EDITOR'S NOTE: discuss ways to estimate timestamp intervals at the
receiver without additional export (e.g., algorithms based on PLLs or the
like); discuss how this can be used to defend against bad or malicious
timestamp interval export - adapt the following text?]</t>
<t>Today, each TCP host may use an arbitrary, locally defined clock
source to derive the timestamp value from. Even though only a handful
of typically used clock rates are implemented in common TCP stacks,
this does not guarantee that any future stack will choose the same
clock rate. This poses a problem for current state of the art
heuristics, which try to determine the senders timestamp clock rate by
pure passive observation of the TCP stream, and affects both advanced
heuristics in the partner host of a TCP session, or arbitrarily located
passive observation points to estimate TCP session parameters.</t>
<t>The proposed mechanism would reveal this information explicitly,
even though other environmental factors, such as the operation of a TCP
stack in a virtualized environment, may result in some deviations in
the actually used clock rate.</t>
<t>High-speed and real-time stacks would be expected to operate with
higher clock rates, while the observed variance in (known) timestamp
clock vs. reference clock could help in determining between physical
and virtual end hosts, for example.</t>
</section> -->
<section title="IANA Considerations">
<t>This document has no considerations for IANA.</t>
</section>
<section title="Security Considerations">
<t>[EDITOR'S NOTE: discuss implications of misuse -- what can I break by
sending a bad interval?]</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1323" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.I-D.scheffenegger-tcpm-timestamp-negotiation" ?>
<?rfc include="reference.I-D.ietf-tcpm-experimental-options" ?>
</references>
<references title="Informative References">
<!-- <?rfc include="reference.RFC.3522" ?> -->
<!-- <?rfc include="reference.RFC.4015" ?> -->
<!-- <?rfc include="reference.RFC.6013" ?> -->
<!-- <?rfc include="reference.RFC.6247" ?> -->
<!-- <?rfc include="reference.I-D.ietf-tcpm-tcp-security.xml"?> -->
<!-- <?rfc include="reference.I-D.ietf-tcpm-1323bis.xml"?> -->
<!-- <?rfc include="reference.I-D.ietf-tcpm-anumita-tcp-stronger-checksum"?> -->
<?rfc include="reference.I-D.ietf-ledbat-congestion"?>
<!-- <?rfc include="reference.I-D.blanton-tcp-reordering"?> -->
<!-- <?rfc include="reference.I-D.sabatini-tcp-sack"?> -->
<reference anchor="Chirp"
target="http://bobbriscoe.net/projects/netsvc_i-f/chirp_pfldnet10.pdf">
<front>
<title>Chirping for Congestion Control - Implementation Feasibility</title>
<author initials="M." surname="Kuehlewind">
<organization>University of Stuttgart</organization>
</author>
<author initials="B." surname="Briscoe">
<organization>British Telekom</organization>
</author>
<date month="Nov" year="2010"/>
</front>
</reference>
<!-- <reference anchor="Cho08"
target="http://ubinet.yonsei.ac.kr/v2/publication/hpmn_papaers/ic/2008_Enhanced%20Response%20Algorithm%20for%20Spurious%20TCP.pdf">
<front>
<title>Enhanced Response Algorithm for Spurious TCP
Timeout (ER-SRTO)</title>
<author initials="I." surname="Cho">
<organization>Yonsei University</organization>
</author>
<author initials="J." surname="Han">
<organization>Yonsei University</organization>
</author>
<author initials="J." surname="Lee">
<organization>Yonsei University</organization>
</author>
<date month="Jan" year="2008"/>
</front>
</reference> -->
<!-- <reference anchor="CUBIC"
target="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.153.3152&rep=rep1&type=pdf">
<front>
<title>CUBIC: A New TCP-Friendly High-Speed
TCP Variant</title>
<author initials="I." surname="Rhee">
<organization>NC State University</organization>
</author>
<author initials="S." surname="Ha">
<organization>NC State University</organization>
</author>
<author initials="L." surname="Xu">
<organization>University of Nebraska</organization>
</author>
<date month="Feb" year="2005"/>
</front>
</reference> -->
<!-- <reference anchor="BSD10"
target="http://caia.swin.edu.au/reports/100219A/CAIA-TR-100219A.pdf">
<front>
<title>Timing enhancements to the FreeBSD kernel to
support delay and rate based TCP mechanisms</title>
<author initials="D." surname="Hayes">
<organization>Swinburne University of Technology</organization>
</author>
<date month="Feb" year="2010"/>
</front>
</reference> -->
<!-- <reference anchor="Linux"
target="http://www.cs.clemson.edu/~westall/853/linuxtcp.pdf">
<front>
<title>Linux TCP</title>
<author initials="P." surname="Sarolahti">
<organization>Nokia</organization>
</author>
<date month="Apr" year="2007"/>
</front>
</reference> -->
<!-- <reference anchor="PH04"
target="citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.76.2748&rep=rep1&type=pdf">
<front>
<title>The Peak-Hopper: A New End-to-End
Retransmission Timer for Reliable Unicast Transport</title>
<author initials="H." surname="Eckstroem">
<organization>Ericsson</organization>
</author>
<author initials="R." surname="Ludwig">
<organization>Ericsson</organization>
</author>
<date month="Apr" year="2004"/>
</front>
</reference> -->
<!-- <reference anchor="Path99"
target="http://www.icir.org/mallman/papers/estimation.ps">
<front>
<title>On Estimating End-to-End Network Path Properties</title>
<author initials="M." surname="Allman">
<organization>NASA</organization>
</author>
<author initials="V." surname="Paxson">
<organization>ICSI</organization>
</author>
<date month="Sep" year="1999"/>
</front>
</reference> -->
</references>
<section title="Detailed use cases for timestamp interval export">
<t>[FIXME: frontmatter]</t>
<section title="Methodology for one-way delay variation measurement using
known timestamp intervals">
<t>New congestion control algorithms are currently proposed, that react
on the measured one-way delay variation (see <xref
target="I-D.ietf-ledbat-congestion"/>, <xref target="Chirp"/>). This
control variable is updated after each received ACK</t>
<t>C(t) = TSval(t) - TSecr(t)</t>
<t>V(t) = C(t) - C(t-1)</t>
<t>provided that the timestamp clocks at both ends are running at
roughly the same rate. Without prior knowledge of the timestamp clock
interval used by the partner, a sender can try to learn this interval
by observing the exchanged segments for a duration of a few RTTs.
However, such a scheme fails if the partner uses some form of implicit
integrity check of the timestamp values, which would appear as either
random scrambling of LSB bits in the timestamp, or give the impression
of much shorter clock intervals than what is actually used. If the
partner uses some form of segment counting as timestamp value, without
any direct relationship to the wall-clock time, the above formula will
fail to yield meaningful results. Finally the network conditions need
to remain stable during any such training phase, so that the sender can
arrive at reasonable estimates of the partners timestamp clock tick
duration.</t>
<t>This note addresses these concerns by providing a means by which
both host are required to use a timestamp clock that is closely related
to the wall-clock time, with known clock rate, and also provides means
by which a host can signal the use of a few LSB bits for timestamp
value integrity checks. To arrive at a valid one-way delay (OWD)
variation, first the timestamp received from the partner has to be
right-shifted by a known amount of bits as defined by the mask field.
Next the local and remote timestamp values need to be normalized to a
common base clock interval (typically, the local clock interval): </t>
<figure><artwork align="left"><![CDATA[
remote interval
C = (TSecr >> local mask) - (TSval >> remote mask) * ---------------
t local interval
]]></artwork></figure>
<t>V(t) = C(t) - C(t-1)</t>
<t>The adjustment factor can be calculated once during the timestamp
capability negotiation phase, and pure integer arithmetic can be used
during per-segment processing:</t>
<t>EXP.min = min(EXP.loc, EXP.rem)</t>
<t>EXP.rem -= EXP.min</t>
<t>EXP.loc -= EXP.min</t>
<t>FRAC.rem = (0x800 | FRAC.rem) << EXP.rem</t>
<t>FRAC.loc = (0x800 | FRAC.loc) << EXP.loc</t>
<t>and assuming that the local clock tick duration is lower</t>
<t>ADJ = FRAC.rem / FRAC.loc</t>
<t>with ADJ being a integer variable. For higher precision, two
appropriately calculated integers can be used.</t>
<t>Any previously required training on the remote clock interval can be
removed, resulting in a simpler and more dependable algorithm.
Furthermore, transient network effects during the training phase which
may result in a wrong inference of the remote clock interval are
eliminated completely.</t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 10:13:03 |