idnits 2.17.1 draft-kazuho-quic-perf-metrics-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 166: '...d is not used and SHOULD be set to the...' RFC 2119 keyword, line 176: '...er of the packet MUST fill the Request...' RFC 2119 keyword, line 202: '... The list MUST contain two or more e...' RFC 2119 keyword, line 217: '... The packet MUST echo the value of t...' RFC 2119 keyword, line 288: '... A QUIC server MUST ignore a METRICS...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2018) is 2264 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-quic-transport-latest - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'QUIC-TRANSPORT' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Oku 3 Internet-Draft Fastly 4 Intended status: Standards Track February 12, 2018 5 Expires: August 16, 2018 7 Performance Metrics Subprotocol for QUIC 8 draft-kazuho-quic-perf-metrics-00 10 Abstract 12 This memo proposes a subprotocol that can be used to query the 13 performance metrics of a QUIC path. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 16, 2018. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. METRICS Packet . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. REQUEST Subtype . . . . . . . . . . . . . . . . . . . . . 5 53 3.2. RESPONSE Subtype . . . . . . . . . . . . . . . . . . . . 6 54 3.3. DENY Subtype . . . . . . . . . . . . . . . . . . . . . . 7 55 4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.1. Server State . . . . . . . . . . . . . . . . . . . . . . 8 57 5. Normative References . . . . . . . . . . . . . . . . . . . . 8 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 60 1. Introduction 62 Observation of upstream loss, reorder, and round-trip time is crucial 63 to diagnosing issues on the network. With TCP, it is possible for an 64 on-path device to make estimation of such metrics by observing the 65 sequence number and the ACK packets being sent in clear. But with 66 QUIC, packet number is never used twice and ACK is encrypted, hence 67 such on-path observation has become difficult. There is also an 68 ongoing discussion about encrypting the packet numbers to avoid 69 ossification and also to miminize privacy concern. Such change will 70 make observation even more challenging. 72 There have been proposals to include signals in each QUIC packet that 73 conveys enough information for diagnosis but does not cause 74 ossification nor privary issues. However, it is difficult if not 75 impossible to figure out an approach that will work well for the 76 lifetime of a transport protocol. 78 This memo proposes an alternative solution. In the proposal, an on- 79 path device willing to obtain the performance metrics of a QUIC path 80 sends a query to the server, and the server responds with the 81 necessary information to calculate such metrics. 83 There are three primary benefits in the approach: 85 o Observation becomes an active action rather than passive, giving 86 the endpoints a chance to record observation attempts as well as 87 rejecting undesirable ones. 89 o Observation becomes accurate due to the endpoints' knowledge of 90 what is being exchanged encypted. 92 o Flexibility against issues (both performance- and privacy-related) 93 that might arise in the future, since bits for observation no 94 longer exists hard-coded in each packet. The metrics protocol can 95 evolve indenpendently to the QUIC transport protocol. 97 2. Overview 99 An on-path device that is willing to query the performance metrics of 100 a QUIC path sends a METRICS packet of subtype REQUEST to the server- 101 side endpoint of the path. 103 When receiving the request packet, A QUIC server sends a response to 104 the client (not to the observer). The response can be either a 105 METRICS packet of subtype RESPONSE that contains the performance 106 metrics, or a METRICS packet of subtype DENY that indicates the 107 servers unwillingness to provide such information. An on-path device 108 that sent the request will witness the METRICS packet containing the 109 response and extract the necessary values. 111 3. METRICS Packet 113 A METRICS packet is used by a QUIC server and the on-path devices to 114 communicate the performance metrics of a QUIC path. 116 0 1 2 3 117 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 118 +-+-+-+-+-+-+-+-+ 119 |0|C|K| Type(5) | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | | 122 + [Connection ID (64)] + 123 | | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | | 126 + + 127 | | 128 + + 129 | Preamble (160) | 130 + + 131 | | 132 + + 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Subtype (8) | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 + + 139 | | 140 + Request UUID (128) + 141 | | 142 + + 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Payload (*) ... 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 1: METRICS packet format 150 The packet mimics a QUIC packet using the short packet header. But 151 instead of the encrypted packet number and the payload, Preamble 152 field directly follows the Connection ID field. 154 A Preamble field consisting of twenty (20) octets of zero indicates a 155 METRICS packet. 157 Subtype field is used to identify the role of the METRICS packet. 158 This document defines three subtypes: REQUEST, RESPONSE, REJECT. 160 Request UUID field contains an identifier that is used for 161 correlating a performance metrics request and the response. 163 Omit Connection ID flag indicates if the Connection ID field is 164 omitted. 166 Key Phase Bit and Type field is not used and SHOULD be set to the 167 same value as those found in the ordinary QUIC packets being 168 exchanged on the same path during the same time. 170 3.1. REQUEST Subtype 172 A METRICS packet of subtype REQUEST (0x0) is sent from an on-path 173 observer to the QUIC server to query the performance metrics of a 174 QUIC path that conveyed the packets it has observed. 176 The sender of the packet MUST fill the Request UUID field with a 177 sequence of random octets so that the request and the packets sent in 178 response can be correlated. 180 Figure 2 shows the payload format of the REQUEST subtype. 182 0 1 2 3 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Client IP Address (32/128) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Client Port (16) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Packet Fingerprints (*) ... 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 2: REQUEST subtype payload format 194 Client IP Address field and Client Port field contain the client-side 195 tuple of a QUIC path. 197 Packet Fingerprints field contains a list of the packets for which 198 the on-path device wants to obtain the metrics. Each element of the 199 list is thirty-six (36) octets long, containing the first thirty-six 200 (36) octets of the observed packets immediately following the 201 Connection ID field (or the Type field if Connection ID is omitted). 202 The list MUST contain two or more entries. 204 The length of each element (thirty-six (36) octets) has been chosen 205 so that an endpoint in posession of the key used for encrypting the 206 packet number can decrypt the packet number from the fingerprint, 207 when a symmetric cipher that requires an initialization vector 208 shorter than 33 octets is being used. 210 3.2. RESPONSE Subtype 212 A METRICS packet of subtype RESPONSE (0x1) is sent by a QUIC server 213 to indicate the performance metrics of the QUIC path related to the 214 packets that have been specified by the METRICS packet of subtype 215 REQUEST. 217 The packet MUST echo the value of the Request UUID found in the 218 METRICS packet of subtype REQUEST so that the on-path observer that 219 sent the request can determine the response. 221 Figure 3 shows the payload format of the METRICS subtype. 223 0 1 2 3 224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Number of Packets Sent (*) ... 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Number of Packets Lost (*) ... 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | SRTT (32) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | RTTVAR (32) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Distances (*) ... 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 3: METRICS subtype payload format 239 Number of Packets Sent field contains the cumulative number of 240 packets being sent on the path. Number of Packets Lost field 241 contains the cumulative number of packets sent on the path but were 242 deemed to be lost. The values are encoded using Variable-Length 243 Integer Encoding defined in [QUIC-TRANSPORT]. 245 SRTT field and RTTVAR field indicates the smoothed round-trip time 246 and the RTT variant, in the unit of microseconds, encoded as 32-bit 247 unsigned integers. 249 Distances field contains a sequence of integers representing the 250 distances between the packets specified by the request. 252 The field contains one less elements than the corresonponding Packet 253 Fingerprint field. Nth element of the Distances field corresponds to 254 the distance between the Nth element and the N+1th element of the 255 Packet Fingerprint field. 257 Distance between two packets (A and B) is defined as following: 259 o the integral part represents number of packets being sent between 260 the two, incremented by one 262 o the sign part is "+" if A was sent before B, else "-" 264 As an example, if packet B was sent right after A, the distance 265 between A and B is one "1". If packet B was sent two packets after 266 A, the distance is "2". If packet B was sent right before A, the 267 distance is "-1". 269 Each distance is converted to unsigned values using the following 270 formula, then encoded into variable length using Variable-Length 271 Integer Encoding defined in [QUIC-TRANSPORT]. 273 uint_distance = abs(distance * 2) + (distance < 0 ? 1 : 0) 275 By observing the packet, the on-path device that sent the request can 276 determine the losses or reorders between the packets it specified in 277 the request. 279 3.3. DENY Subtype 281 A METRICS packet of subtype DENY (0x2) is sent by a QUIC server to 282 inidicate its unwillingness to provide performance metrics. 284 There is no payload for the subtype. 286 4. Server Behavior 288 A QUIC server MUST ignore a METRICS packet of subtype REQUEST if any 289 of the following requirements is not being met. 291 o the destination IP address and port number match the server-side 292 tuple of the QUIC path 294 o values of Client IP Address field and Client Port field match the 295 client-side tuple of the QUIC path 297 o (unless omitted and permitted to be omitted during QUIC handshake) 298 value of the Connection ID field matches that of the QUIC path 300 o Packet Fingerprint field contains two or more entries 302 o all the packet numbers being recovered from the entries of Packet 303 Fingerprint field belong to the QUIC path 305 Once all the checks succeed, the server can send a METRICS packet of 306 subtype RESPONSE, or notify the rejection the request by sending a 307 packet of subtype DENY. 309 4.1. Server State 311 A QUIC server willing to let the on-path devices observe upstream 312 loss and / or reorder ratio needs to calculate the distances of the 313 packets being specified in the request. 315 A server can easily calculate the distances if it records the packet 316 numbers of all the packets it has sent over a given path. 318 On the other hand, a server can calculate the distances by retaining 319 very little state if it is implemented following the criteria shown 320 below. 322 o record the packet number of the first packet sent after switching 323 to the current path 325 o use a deterministic function (such as a keyed hash function) to 326 determine when to skip a packet number as a mitigitation against 327 opportunistic ACK attacks 329 o record the packet numbers of packets that were exchanged on a 330 prepared path (i.e. packet numbers of PATH_CHALLENGE and 331 PATH_RESPONSE) 333 The distance can be calculated as a subtraction of two packet 334 numbers, further subtracted by the number of skips and the number of 335 packets used for preparing new paths. 337 5. Normative References 339 [QUIC-TRANSPORT] 340 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 341 Multiplexed and Secure Transport", draft-ietf-quic- 342 transport-latest (work in progress). 344 Author's Address 346 Kazuho Oku 347 Fastly 349 Email: kazuhooku@gmail.com