TCP Maintenance and Minor Extensions (tcpm) R. Scheffenegger Internet-Draft NetApp, Inc. Intended status: Experimental M. Kuehlewind Expires: January 16, 2014 University of Stuttgart B. Trammell ETH Zurich July 15, 2013 Encoding of Time Intervals for the TCP Timestamp Option draft-trammell-tcpm-timestamp-interval-01.txt Abstract 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 compact encoding for exposing the timestamp interval to a receiver, and discusses applications therefor. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 16, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Scheffenegger, et al. Expires January 16, 2014 [Page 1] Internet-Draft Timestamp Intervals July 2013 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Timestamp interval exposure . . . . . . . . . . . . . . . . . 3 3.1. Interval encoding requirements . . . . . . . . . . . . . 3 3.2. Interval encoding specification . . . . . . . . . . . . . 4 3.3. Timestamp Interval experimental TCP option . . . . . . . 6 4. Guidelines for defined-interval timestamp export . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Methodology for one-way delay variation measurement using known timestamp intervals . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Timestamp option originally introduced in [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). While [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. This document specifies a compact encoding for timestamp intervals which can be exported via any number of mechanisms, either through a new TCP option, by piggybacking on the timestamp option as in [I-D.scheffenegger-tcpm-timestamp-negotiation], or through other in- or out-of-band means. This document specifies an experimental TCP Scheffenegger, et al. Expires January 16, 2014 [Page 2] Internet-Draft Timestamp Intervals July 2013 option for experiments with interval exposure separate from any other mechanism. 2. Terminology 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 [RFC2119]. Terms defined in [RFC1323] are used in this document as defined there. This document defines the following additional term: Timestamp interval 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. 3. Timestamp interval exposure 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. 3.1. Interval encoding requirements 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. 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. 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 Scheffenegger, et al. Expires January 16, 2014 [Page 3] Internet-Draft Timestamp Intervals July 2013 many clock sources may provide less than maximum precision (due to e.g. interrupt jitter), there should be some way to represent variable precision. As a timestamp interval will need to be bound to a connection in-band at runtime, a space-efficient encoding is necessary. These requirements indicate a reduced-precision encoding of a fixed- point interval, expressed in seconds, as described in the next subsection. 3.2. Interval encoding specification 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 than they actually support. 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 Figure 1. Scheffenegger, et al. Expires January 16, 2014 [Page 4] Internet-Draft Timestamp Intervals July 2013 MSb LSb 41 37 31 23 15 7 0 +----+------+--------+--------+--------+-------+ | int| frac | full value +----+------+--------+--------+--------+-------+ / \ +-+ \ / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | scale | value | encoded interval +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15 11 10 0 Figure 1: Timestamp interval encoding using scaled fixed-point integer 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. A sender explicitly signals that it uses an irregular timestamp clock by sending zero for both scale and value (i.e., 0x0000). Combinations of a value of zero and a non-zero scale are reserved for future use. These values MUST NOT be sent as a timestamp interval, and SHOULD presently be interpreted by the receiver as exposing an irregular timestamp clock. 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 with maximum precision are given in Table 1. Encodings for 9-bit precision, the maximum available from common software interrupt clock sources, are given in Table 2. Scheffenegger, et al. Expires January 16, 2014 [Page 5] Internet-Draft Timestamp Intervals July 2013 +----------+-----------+-------+-------+----------+ | interval | frequency | scale | value | combined | +----------+-----------+-------+-------+----------+ | 16 s | 0.06 Hz | 0x1f | 0x7ff | 0xffff | | 1 s | 1 Hz | 0x1c | 0x400 | 0xe400 | | 0.5 s | 2 Hz | 0x1b | 0x400 | 0xdc00 | | 100 ms | 10 Hz | 0x18 | 0x666 | 0xc666 | | 10 ms | 100 Hz | 0x15 | 0x51f | 0xad1f | | 4 ms | 250 Hz | 0x14 | 0x419 | 0xa419 | | 1 ms | 1 kHz | 0x12 | 0x418 | 0x9418 | | 200 us | 5 kHz | 0x0f | 0x68e | 0x7e8e | | 50 us | 20 kHz | 0x0d | 0x68e | 0x6e8e | | 1 us | 1 MHz | 0x08 | 0x432 | 0x4432 | | 60 ns | 16.7 MHz | 0x04 | 0x407 | 0x2407 | | none | -------- | 0x00 | 0x000 | 0x0000 | +----------+-----------+-------+-------+----------+ Table 1: Encodings for common timestamp intervals with maximum precision +----------+-----------+-------+-------+----------+ | interval | frequency | scale | value | combined | +----------+-----------+-------+-------+----------+ | 1.0 s | 1 Hz | 0x1e | 0x100 | 0xf100 | | 0.5 s | 2 Hz | 0x1d | 0x100 | 0xe900 | | 100 ms | 10 Hz | 0x1a | 0x199 | 0xd199 | | 10 ms | 100 Hz | 0x17 | 0x147 | 0xb947 | | 4 ms | 250 Hz | 0x16 | 0x106 | 0xb106 | | 1 ms | 1 kHz | 0x14 | 0x106 | 0xa106 | | 200 us | 5 kHz | 0x11 | 0x1a3 | 0x89a3 | | 50 us | 20 kHz | 0x0f | 0x1a3 | 0x79a3 | | 1 us | 1 MHz | 0x0a | 0x10c | 0x510c | | 60 ns | 16.7 MHz | 0x06 | 0x101 | 0x3101 | | none | -------- | 0x00 | 0x000 | 0x0000 | +----------+-----------+-------+-------+----------+ Table 2: Encodings for common timestamp intervals with 9-bit precision 3.3. Timestamp Interval experimental TCP option This section specifies an experimental TCP option, using an ExID and magic number as described in [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 Section 3.2 above. If the receiver uses timestamp interval information, it stores the interval for the duration of the connection, or until a subsequent Timestamp Interval Scheffenegger, et al. Expires January 16, 2014 [Page 6] Internet-Draft Timestamp Intervals July 2013 option is received. The receiver may assume the Timestamp Interval is applicable from the point of receipt of the option; i.e. that all subsequent received segments with the same or a subsequent sequence number as the segment containing the option export timestamps with the stated option. 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. This option MUST NOT appear in a segment in which a TCP Timestamp option is also not present. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind = 253 | Length = 8 | ExID = 0x75ec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | more magic = 0xffee | encoded advertised interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Structure of Timestamp Interval Experimental TCP option for interval export Should timestamp interval exposure prove useful, and a separate TCP Option be chosen as the preferred method to send it in-band, this option would have a length of 4, and the use of an ExID and magic number would preserve word alignment in implementations transitioning from experimental to production TCP Option usage. 4. Guidelines for defined-interval timestamp export As noted above, implementations SHOULD NOT indicate more precision than they support. As common software interrupt clock sources provide about 9 bits of precision, these should be indicated with 2 leading zero bits in the value field. Low variance software clocks (e.g. CPU cycle counters) should be indicated with a single leading zero bit, and hardware injecting the timestamp into the header with high precision should use the full precision. Similarly, if the clock source exhibits a very high variability (e.g. when running in a virtualized environment), 3 or more leading zeros should be used in the value field. Timestamp intervals faster than about 1 ms SHOULD be implemented by inserting the timestamp "late" before transmitting a segment to avoid unnecessary timing jitter. Intervals on the order of 1us or less are intended for use with for hardware-assisted implementations, e.g. direct use of a (shifted) CPU cycle counter as clock source. Scheffenegger, et al. Expires January 16, 2014 [Page 7] Internet-Draft Timestamp Intervals July 2013 5. IANA Considerations This document uses the Experimental Option Experiment Identifier (ExID) 0x75ec ffee to identify the Timestamp Interval experimental option in Section 3.3; an application for this codepoint in the IANA TCP Experimental Option ExID registry has already been submitted. 6. Security Considerations [EDITOR'S NOTE: discuss implications of misuse -- what can I break by sending a bad interval?] 7. References 7.1. Normative References [I-D.ietf-tcpm-experimental-options] Touch, J., "Shared Use of Experimental TCP Options", draft-ietf-tcpm-experimental-options-06 (work in progress), June 2013. [I-D.scheffenegger-tcpm-timestamp-negotiation] Scheffenegger, R., Kuehlewind, M., and B. Trammell, "Additional negotiation in the TCP Timestamp Option field during the TCP handshake", draft-scheffenegger-tcpm- timestamp-negotiation-05 (work in progress), October 2012. [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [Chirp] Kuehlewind, M. and B. Briscoe, "Chirping for Congestion Control - Implementation Feasibility", Nov 2010, . [I-D.ietf-ledbat-congestion] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", draft- ietf-ledbat-congestion-10 (work in progress), September 2012. Appendix A. Methodology for one-way delay variation measurement using known timestamp intervals Scheffenegger, et al. Expires January 16, 2014 [Page 8] Internet-Draft Timestamp Intervals July 2013 New congestion control algorithms are currently proposed, that react on the measured one-way delay variation (see [I-D.ietf-ledbat-congestion], [Chirp]). This control variable is updated after each received ACK. C(t) = TSval(t) - TSecr(t) V(t) = C(t) - C(t-1) 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. [EDITOR'S NOTE: the following refers to a mask field which doesn't exist anymore, needs a rewrite. Shouldn't we define C(t) = (TSecr(t) - TSval(t)) * (TSinterval(remote) / TSinterval(local))?] 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): remote interval C = (TSecr >> local mask) - (TSval >> remote mask) * --------------- t local interval V(t) = C(t) - C(t-1) [EDITOR'S NOTE: the following refers to field definitions from the old TS nego draft; needs a rewrite.] Scheffenegger, et al. Expires January 16, 2014 [Page 9] Internet-Draft Timestamp Intervals July 2013 The adjustment factor can be calculated once during the timestamp capability negotiation phase, and pure integer arithmetic can be used during per-segment processing: EXP.min = min(EXP.loc, EXP.rem) EXP.rem -= EXP.min EXP.loc -= EXP.min FRAC.rem = (0x800 | FRAC.rem) << EXP.rem FRAC.loc = (0x800 | FRAC.loc) << EXP.loc and assuming that the local clock tick duration is lower ADJ = FRAC.rem / FRAC.loc with ADJ being a integer variable. For higher precision, two appropriately calculated integers can be used. 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. Though specified for endpoint usage for congestion control, the difference betwen interarrival and interdeparture time used by this algorithm is applicable for passive measurement of jitter, as well. Authors' Addresses Richard Scheffenegger NetApp, Inc. Am Euro Platz 2 1120 Vienna Austria Phone: +43 1 3676811 3146 Email: rs@netapp.com Scheffenegger, et al. Expires January 16, 2014 [Page 10] Internet-Draft Timestamp Intervals July 2013 Mirja Kuehlewind University of Stuttgart Pfaffenwaldring 47 70569 Stuttgart Germany Email: mirja.kuehlewind@ikr.uni-stuttgart.de Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 13 Email: trammell@tik.ee.ethz.ch Scheffenegger, et al. Expires January 16, 2014 [Page 11]