Summary This category includes multiple indexes to the registry entry: the element ID and metric name. ID (Identifier) 25 Name RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton Note that a mid-point observer only has the opportunity to compose a single RTDelay on the TCP Hand Shake. URI URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton Description RTDelay Singleton: This metric assesses the round-trip delay of TCP packets constituting a single connection, exchanged between two hosts. We consider the measurement of round-trip delay based on a single Observation Point [RFC7011] somewhere in the network. The Output is a single measurement of Round-trip delay, or Singleton. Change Controller IETF Version (of Registry Format) 1.0 Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called fixed parameters. Reference Definitions Although there is no RFC that describes passive measurement of Round- Trip Delay, the parallel definition for Active measurement is: Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2681] This metric definition uses the terms singleton and sample as defined in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the reference definition of the singleton (single value) Round-trip delay metric. Section 3.4 of [RFC2681] provides the reference definition expanded to cover a multi-singleton sample.) With the Observation Point [RFC7011] (OP) typically located between the hosts participating in the TCP connection, the Round-trip Delay metric requires two individual measurements between the OP and each host, such that the Spatial Composition [RFC6049]of the measurements yields a Round-trip Delay singleton (we are extending the composition of one-way subpath delays to subpath round-trip delay). Using the direction of TCP SYN transmission to anchor the nomenclature, host A sends the SYN and host B replies with SYN-ACK during connection establishment. The direction of SYN transfer is considered the Forward direction of transmission, from A through OP to B (Reverse is B through OP to A). Traffic filters reduce the packet stream at the OP to a Qualified bidirectional flow of packets. In the definitions below, Corresponding Packets are transferred in different directions and convey a common value in a TCP header field that establishes correspondence (to the extent possible). Examples may be found in the TCP timestamp fields. For a real number, RTD_fwd, >> the Round-trip Delay in the Forward direction from OP to host B at time T' is RTD_fwd << it is REQUIRED that OP observed a Qualified Packet to host B at wire-time T', that host B received that packet and sent a Corresponding Packet back to host A, and OP observed the Corresponding Packet at wire-time T' + RTD_fwd. For a real number, RTD_rev, >> the Round-trip Delay in the Reverse direction from OP to host A at time T'' is RTD_rev << it is REQUIRED that OP observed a Qualified Packet to host A at wire-time T'', that host A received that packet and sent a Corresponding Packet back to host B, and that OP observed the Corresponding Packet at wire-time T'' + RTD_rev. Ideally, the packet sent from host B to host A in both definitions above SHOULD be the same packet (or, when measuring RTD_rev first, the packet from host A to host B in both definitions should be the same). The REQUIRED Composition Function for a singleton of Round-trip Delay at time T (where T is the earliest of T' and T'' above) is: RTDelay = RTD_fwd + RTD_rev Note that when OP is located at host A or host B, one of the terms composing RTDelay will be zero or negligible. When the Qualified and Corresponding Packets are a TCP-SYN and a TCP- SYN-ACK, then RTD_fwd == RTD_HS_fwd. When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a TCP-ACK, then RTD_rev == RTD_HS_rev. The REQUIRED Composition Function for a singleton of Round-trip Delay for the connection Hand Shake: RTDelay_HS = RTD_HS_fwd + RTD_HS_rev Fixed Parameters Traffic Filters: o IPv4 header values: * DSCP: set to 0 * Protocol: Set to 06 (TCP) o IPv6 header values: * DSCP: set to 0 * Hop Count: set to 255 * Next Header: set to 6 (TCP) * Flow Label: set to zero * Extension Headers: none o TCP header values: * Flags: ACK, SYN, FIN, set as required * Timestamp Option (TSopt): Set + Section 3.2 of [RFC7323] Method of Measurement This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous methods for implementations. Reference Methods The foundation methodology for this metric is defined in Section 4 of [RFC7323] using the Timestamp Option with modifications that allow application at a mid-path Observation Point (OP) [RFC7011]. Further details and applicable heuristics were derived from [Strowes] and [Trammell-14]. The Traffic Filter at the OP is configured to observe a single TCP connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton of RTDelay as RTDelay_HS (composed using the forward and reverse measurement pair). RTDelay_HS SHALL be treated separately from other RTDelays on data-bearing packets and their ACKs. The RTDelay_HS value MAY be used as a sanity check on other Composed values of RTDelay. For payload bearing packets, the OP measures the time interval between observation of a packet with Sequence Number s, and the corresponding ACK with same Sequence number. When the payload is transferred from host A to host B, the observed interval is RTD_fwd. Because many data transfers are unidirectional (say, in the Forward direction from host A to host B), it is necessary to use pure ACK packets with Timestamp (TSval) and their Timestamp value echo to perform a RTD_rev measurement. The time interval between observation of the ACK from B to A, and the corresponding packet with Timestamp echo (TSecr) is the RTD_rev. Delay Measurement Filtering Heuristics: If Data payloads were transferred in both Forward and Reverse directions, then the Round-Trip Time Measurement Rule in Section 4.1 of [RFC7323] could be applied. This rule essentially excludes any measurement using a packet unless it makes progress in the transfer (advances the left edge of the send window, consistent with [Strowes]). A different heuristic from [Trammell-14] is to exclude any RTD_rev that is larger than previously observed values. This would tend to exclude Reverse measurements taken when the Application has no data ready to send, because considerable time could be added to RTD_rev from this source of error. Note that the above Heuristic assumes that host A is sending data. Host A expecting a download would mean that this heuristic should be applied to RTD_fwd. The statistic calculations to summarize the delay (RTDelay) SHALL be performed on the conditional distribution, conditioned on successful Forward and Reverse measurements which follow the Heuristics. Sources of Error: The principal source of RTDelay error is the host processing time to return a packet that defines the termination of a time interval. The heuristics above intend to mitigate these errors by excluding measurements where host processing time is a significant part of RTD_fwd or RTD_rev. A key source of RTLoss error is observation loss, described in section 3 of [Trammell-14]. Packet Stream Generation NA Traffic Filtering (observation) Details The Fixed Parameters above give a portion of the Traffic Filter. Other aspects will be supplied as Run-time Parameters (below). Sampling Distribution This metric requires a complete sample of all packets that qualify according to the Traffic Filter criteria. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. Src the IP address of the host in the host A Role (format ipv4- address-no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see Section 4 of [RFC6991]) Dst the IP address of the host in the host B (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see section 4 of [RFC6991]) T0 a time, the start of a measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Td is to be interpreted as the Duration of the measurement interval. The start time is controlled through other means. Td Optionally, the end of a measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]), or the duration (see T0). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Alternatively, the end of the measurement interval MAY be controlled by the measured connection, where the second pair of FIN and ACK packets exchanged between host A and B effectively ends the interval. TTL or Hop Limit Set at desired value. Roles host A launches the SYN packet to open the connection, and synonymous with an IP address. host B replies with the SYN-ACK packet to open the connection, and synonymous with an IP address. Output This category specifies all details of the Output of measurements using the metric. Type See subsection titles in Reference Definition for RTDelay Types. Reference Definition For all output types --- T0 the start of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. The end of the measurement interval MAY be controlled by the measured connection, where the second pair of FIN and ACK packets exchanged between host A and B effectively ends the interval. ... ... For RTDelay_HS -- the Round trip delay of the Handshake. Singleton The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] Metric Units The Round-trip Delay of the Hand Shake is expressed in seconds. Calibration Passive measurements at an OP could be calibrated against an active measurement (with loss emulation) at host A or B, where the active measurement represents the ground-truth. Administrative items Status Current Requester RFC8912 Revision 1.0 Revision Date YYYY-MM-DD Comments and Remarks None.