idnits 2.17.1 draft-trammell-tcpm-timestamp-interval-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2012) is 4205 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-tcpm-experimental-options-02 == Outdated reference: A later version (-05) exists of draft-scheffenegger-tcpm-timestamp-negotiation-04 ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions R. Scheffenegger 3 (tcpm) NetApp, Inc. 4 Internet-Draft M. Kuehlewind 5 Intended status: Experimental University of Stuttgart 6 Expires: April 17, 2013 B. Trammell 7 ETH Zurich 8 October 14, 2012 10 Exposure of Time Intervals for the TCP Timestamp Option 11 draft-trammell-tcpm-timestamp-interval-00.txt 13 Abstract 15 The TCP Timestamp option would be useful for additional measurements 16 if it could be assumed that the interval between ticks of the 17 timestamp clock are regular, and if that interval were known. In 18 practice, many implementations do use a timestamp clock source that 19 has a regular interval. This draft specifies a mechanism for 20 exposing the timestamp interval to a receiver, and discusses 21 applications therefor. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 17, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Timestamp interval exposure . . . . . . . . . . . . . . . . . 3 60 3.1. Interval encoding requirements . . . . . . . . . . . . . . 4 61 3.2. Interval encoding specification . . . . . . . . . . . . . 4 62 3.3. Timestamp Interval experimental TCP option . . . . . . . . 6 63 3.4. Interval export during TS negotiation . . . . . . . . . . 7 64 4. Timestamp interval negotiation . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Appendix A. Detailed use cases for timestamp interval export . . 8 71 A.1. Methodology for one-way delay variation measurement 72 using known timestamp intervals . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 The Timestamp option originally introduced in [RFC1323] was designed 78 to support only two very specific mechanisms, round trip time 79 measurement (RTTM), and protection against wrapped sequence numbers 80 (PAWS), assuming a particular TCP algorithm (Reno). 82 While [RFC1323] specifies only that timestamps "must be at least 83 approximately proportional to real time" to support RTTM, many 84 implementations generate timestamp values from a regular timing 85 source. Determining the real-time interval represented by a single 86 tick makes additional measurements possible. In addition to easing 87 passive measurements using the timestamp option, it also makes 88 possible the measurement of inter-departure time; the comparison of 89 inter-departure time to inter-arrival time can be used to one-way 90 delay variation measurement, useful for congestion control algorithms 91 as well in QoS applications [FIXME: others?] 93 This document specifies a compact encoding for timestamp intervals 94 which can be exported via multiple mechanisms, including an 95 experimental TCP option, or the mechanism described in 96 [I-D.scheffenegger-tcpm-timestamp-negotiation]. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 Terms defined in [RFC1323] are used in this document as defined 105 there. 107 This document defines the following additional term: 109 Timestamp interval 110 The interval between two ticks of the timestamp clock source 111 running at a constant frequency. Note that the timestamp clock is 112 not required to be identical with the TCP clock, even though most 113 implementations use the same clock for practical purposes. 115 3. Timestamp interval exposure 117 This section describes the requirements for interval encoding, then 118 specifies an interval to meet these requirements based on a 16-bit 119 reduced-precision encoding of a 42-bit fixed-point unsigned integer. 121 3.1. Interval encoding requirements 123 The choice of a timestamp interval is generally implementation- 124 specific, and there are a small number of commonly chosen intervals. 125 However, a general solution must support not only common cases, but 126 uncommon ones, and provide future flexibility to allow an 127 implementation to dynamically choose new timestamp intervals for new 128 sockets, based on network conditions and specific requirements for 129 timestamp measurements. 131 There are some sensible bounds on the range of timestamp intervals 132 that must be reasonably supported. The minimum inter-packet interval 133 for 64-byte packets (i.e., back-to-back ACK segments) on a future 400 134 Gigabit Ethernet would be about 1ns; smaller intervals need not be 135 supported with current technology, even for applications for which a 136 unique timestamp for every packet would be useful. On the other side 137 of the scale, low-bandwidth, high-latency links may operate with 138 timestamp intervals on the order of seconds. 140 The precision required by timestamp interval export, on the other 141 hand, is determined by the applications for which the information 142 will be used and the precision of the underlying clock source. As 143 many clock sources may provide less than maximum precision (due to 144 e.g. interrupt jitter), there should be some way to represent 145 variable precision. [FIXME: justify why 11 bits is enough here.] 147 As a timestamp interval will need to be bound to a connection in-band 148 at runtime, a space-efficient encoding is necessary. 150 These requirements indicate a reduced-precision encoding of a fixed- 151 point interval, expressed in seconds, as described in the next 152 subsection. 154 3.2. Interval encoding specification 156 A 42-bit fixed-point unsigned integer with 4 bits before the decimal 157 point and 38 bits after, expressed in seconds, is sufficient to 158 encode an interval range from just under 16 seconds (0x3ff ffff ffff) 159 down to 2^-38 s or 3.64 ps (0x000 0000 0001), meeting the range 160 requirement. Sufficient precision for the applications envisioned by 161 this document is provided by exporting just the 11 most significant 162 bits of the interval value (here, the "value"), coupled with a 5-bit 163 "scale" which locates the least significant bit of the value within 164 the larger field: a scale of 31 places the value field between bits 165 41 and 31 inclusive of the fixed-point integer for the largest 166 intervals, while a scale of 0 places the value field between bits 10 167 and 0 inclusive. By using a scale such that the most significant bit 168 of the value is not 1, less than 11 bits of precision can be 169 signaled, as well; implementations SHOULD NOT represent more 170 precision in an exported timestamp interval Full precision export is 171 available down to 2^-27 s (or 7.45 ns) with diminishing precision 172 down to 3.64 ps. This arrangement therefore allows the 173 representation of timestamp intervals over 13 orders of magnitude and 174 11 bits of precision with only two octets. The details of this 175 encoding are illustrated in Figure 1. 177 MSb LSb 178 4 3 3 2 1 179 1 7 1 3 5 7 0 180 +----+------+--------+--------+--------+-------+ 181 | int| frac | full value 182 +----+------+--------+--------+--------+-------+ 183 / \ 184 +-+ \ 185 / \ 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | scale | value | encoded interval 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 1 1 1 0 190 5 1 0 191 MSb LSb 193 Figure 1: Timestamp interval encoding using scaled fixed-point 194 integer 196 This encoded 16-bit interval is then exported for a given connection 197 as a standalone TCP option or as part of the extended timestamp 198 negotiation described in the following subsections. 200 A sender explicitly signals that it uses an irregular timestamp clock 201 by sending 0 for both scale and value. 203 For implementations that support only a single timestamp interval for 204 all flows in all situations, the encoded interval can be implemented 205 as a constant. Encodings for common timestamp intervals are given in 206 Table 1. 208 +----------+-----------+-------+-------+----------+ 209 | interval | frequency | scale | value | combined | 210 +----------+-----------+-------+-------+----------+ 211 | 16 s | 0.06 Hz | 0x1f | 0x7ff | 0xffff | 212 | 1 s | 1 Hz | 0x1c | 0x400 | 0xe400 | 213 | 0.5 s | 2 Hz | 0x1b | 0x400 | 0xdc00 | 214 | 100 ms | 10 Hz | 0x18 | 0x666 | 0xc666 | 215 | 10 ms | 100 Hz | 0x15 | 0x51f | 0xad1f | 216 | 4 ms | 250 Hz | 0x14 | 0x419 | 0xa419 | 217 | 1 ms | 1 kHz | 0x12 | 0x418 | 0x9418 | 218 | 200 us | 5 kHz | 0x0f | 0x68e | 0x7e8e | 219 | 50 us | 20 kHz | 0x0d | 0x68e | 0x6e8e | 220 | 1 us | 1 MHz | 0x08 | 0x432 | 0x4432 | 221 | 60 ns | 16.7 MHz | 0x04 | 0x407 | 0x2407 | 222 | none | -------- | 0x00 | 0x000 | 0x0000 | 223 +----------+-----------+-------+-------+----------+ 225 Table 1: Encodings for common timestamp intervals at maximum 226 precision 228 3.3. Timestamp Interval experimental TCP option 230 This section specifies an experimental TCP option, using arbitrarily 231 chosen magic numbers as described in 232 [I-D.ietf-tcpm-experimental-options], for exporting timestamp 233 intervals. This option MAY appear in any TCP segment after the SYN 234 segment to advertise the sender's timestamp interval, encoded as in 235 Section 3.2 above. If the receiver uses timestamp interval 236 information, it stores the interval for the duration of the 237 connection, or until a subsequent Timestamp Interval option is 238 received. 240 If a sender has previously sent a timestamp interval to a receiver, 241 and changes the timestamp interval on the connection, it MUST send a 242 new Timestamp Interval option. 244 This option MUST NOT appear in a segment in which a TCP Timestamp 245 option is also not present. 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Kind = 253 | Length = 8 | magic0 = 0x75ec | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | magic1 = 0xffee | encoded advertised interval | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 2: Structure of Timestamp Interval Experimental TCP option for 254 interval export 256 [FIXME: specify how long after an advertisement of a new or changed 257 interval the interval must be valid for the connection.] 259 3.4. Interval export during TS negotiation 261 [EDITOR'S NOTE: bind to new revision of the TS negotiation draft; 262 requires TS negotiation that can flexibly add 16 bits of content to 263 the negotiation handshake.] 265 4. Timestamp interval negotiation 267 [EDITOR'S NOTE: describe here how a receiver could ask a sender for a 268 specific TS rate: an option with two encoded intervals could be 269 handled as consisting of an advertised interval (first interval) and 270 a requested interval (second interval). A sender that gets an 271 interval request must then send a ts interval option which advertises 272 the closest interval it is willing to support. This mechanism could 273 also be used to implicitly request that timestamps be turned on, if 274 it is decided that 1323 could be updated to support mid-connection 275 initialization of TS.] 277 5. IANA Considerations 279 This document has no considerations for IANA. 281 6. Security Considerations 283 [EDITOR'S NOTE: discuss implications of misuse -- what can I break by 284 sending a bad interval?] 286 7. References 288 7.1. Normative References 290 [I-D.ietf-tcpm-experimental-options] 291 Touch, J., "Shared Use of Experimental TCP Options", 292 draft-ietf-tcpm-experimental-options-02 (work in 293 progress), October 2012. 295 [I-D.scheffenegger-tcpm-timestamp-negotiation] 296 Scheffenegger, R. and M. Kuehlewind, "Additional 297 negotiation in the TCP Timestamp Option field during the 298 TCP handshake", 299 draft-scheffenegger-tcpm-timestamp-negotiation-04 (work in 300 progress), July 2012. 302 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 303 for High Performance", RFC 1323, May 1992. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 7.2. Informative References 310 [Chirp] Kuehlewind, M. and B. Briscoe, "Chirping for Congestion 311 Control - Implementation Feasibility", Nov 2010, . 314 [I-D.ietf-ledbat-congestion] 315 Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 316 "Low Extra Delay Background Transport (LEDBAT)", 317 draft-ietf-ledbat-congestion-10 (work in progress), 318 September 2012. 320 Appendix A. Detailed use cases for timestamp interval export 322 [FIXME: frontmatter] 324 A.1. Methodology for one-way delay variation measurement using known 325 timestamp intervals 327 New congestion control algorithms are currently proposed, that react 328 on the measured one-way delay variation (see 329 [I-D.ietf-ledbat-congestion], [Chirp]). This control variable is 330 updated after each received ACK 332 C(t) = TSval(t) - TSecr(t) 334 V(t) = C(t) - C(t-1) 336 provided that the timestamp clocks at both ends are running at 337 roughly the same rate. Without prior knowledge of the timestamp 338 clock interval used by the partner, a sender can try to learn this 339 interval by observing the exchanged segments for a duration of a few 340 RTTs. However, such a scheme fails if the partner uses some form of 341 implicit integrity check of the timestamp values, which would appear 342 as either random scrambling of LSB bits in the timestamp, or give the 343 impression of much shorter clock intervals than what is actually 344 used. If the partner uses some form of segment counting as timestamp 345 value, without any direct relationship to the wall-clock time, the 346 above formula will fail to yield meaningful results. Finally the 347 network conditions need to remain stable during any such training 348 phase, so that the sender can arrive at reasonable estimates of the 349 partners timestamp clock tick duration. 351 This note addresses these concerns by providing a means by which both 352 host are required to use a timestamp clock that is closely related to 353 the wall-clock time, with known clock rate, and also provides means 354 by which a host can signal the use of a few LSB bits for timestamp 355 value integrity checks. To arrive at a valid one-way delay (OWD) 356 variation, first the timestamp received from the partner has to be 357 right-shifted by a known amount of bits as defined by the mask field. 358 Next the local and remote timestamp values need to be normalized to a 359 common base clock interval (typically, the local clock interval): 361 remote interval 362 C = (TSecr >> local mask) - (TSval >> remote mask) * --------------- 363 t local interval 365 V(t) = C(t) - C(t-1) 367 The adjustment factor can be calculated once during the timestamp 368 capability negotiation phase, and pure integer arithmetic can be used 369 during per-segment processing: 371 EXP.min = min(EXP.loc, EXP.rem) 373 EXP.rem -= EXP.min 375 EXP.loc -= EXP.min 377 FRAC.rem = (0x800 | FRAC.rem) << EXP.rem 379 FRAC.loc = (0x800 | FRAC.loc) << EXP.loc 381 and assuming that the local clock tick duration is lower 383 ADJ = FRAC.rem / FRAC.loc 385 with ADJ being a integer variable. For higher precision, two 386 appropriately calculated integers can be used. 388 Any previously required training on the remote clock interval can be 389 removed, resulting in a simpler and more dependable algorithm. 390 Furthermore, transient network effects during the training phase 391 which may result in a wrong inference of the remote clock interval 392 are eliminated completely. 394 Authors' Addresses 396 Richard Scheffenegger 397 NetApp, Inc. 398 Am Euro Platz 2 399 1120 Vienna 400 Austria 402 Phone: +43 1 3676811 3146 403 Email: rs@netapp.com 405 Mirja Kuehlewind 406 University of Stuttgart 407 Pfaffenwaldring 47 408 70569 Stuttgart 409 Germany 411 Email: mirja.kuehlewind@ikr.uni-stuttgart.de 413 Brian Trammell 414 Swiss Federal Institute of Technology Zurich 415 Gloriastrasse 35 416 8092 Zurich 417 Switzerland 419 Phone: +41 44 632 70 13 420 Email: trammell@tik.ee.ethz.ch