idnits 2.17.1 draft-morton-ippm-capacity-metric-protocol-01.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 : ---------------------------------------------------------------------------- ** There are 25 instances of too long lines in the document, the longest one being 56 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Note: uint16_t srIndexConf is the table index of the configured *fixed* sending rate index to use. The client can request the specified rate, or the server can use this field to coerce a maximum rate in its response. If the server sets to 0 in its response, client SHALL not use fixed rate. -- The document date (July 12, 2021) is 1017 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2330' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1043, but no explicit reference was found in the text == Unused Reference: 'RFC8468' is defined on line 1075, but no explicit reference was found in the text == Unused Reference: 'LS-SG12-A' is defined on line 1088, but no explicit reference was found in the text == Unused Reference: 'LS-SG12-B' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: 'RFC2544' is defined on line 1102, but no explicit reference was found in the text == Unused Reference: 'RFC5136' is defined on line 1112, but no explicit reference was found in the text == Unused Reference: 'RFC6815' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'RFC7312' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'RFC7799' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'TR-471' is defined on line 1141, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ippm-capacity-metric-method-10 ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Downref: Normative reference to an Informational RFC: RFC 7479 ** Downref: Normative reference to an Informational RFC: RFC 8468 Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Ciavattone 3 Internet-Draft A. Morton 4 Intended status: Standards Track AT&T Labs 5 Expires: January 13, 2022 July 12, 2021 7 Test Protocol for One-way IP Capacity Measurement 8 draft-morton-ippm-capacity-metric-protocol-01 10 Abstract 12 This memo addresses the problem of protocol support for measuring 13 Network Capacity metrics in RFC xxxx: draft-ietf-ippm-capacity- 14 metric-method, where the method deploys a feedback channel from the 15 receiver to control the sender's transmission rate in near-real-time. 16 It supplies a simple protocol to perform the measurements. 18 See Section 10: The authors seek feedback to determine what 19 additional features will be necessary for an IETF Standards Track 20 Protocol, beyond what is present in the running code available now. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 13, 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Scope, Goals, and Applicability . . . . . . . . . . . . . . . 3 59 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 60 4. General Parameters and Definitions . . . . . . . . . . . . . 4 61 5. Setup Request and Response Exchange . . . . . . . . . . . . . 6 62 5.1. Setup Response Processing at the Client . . . . . . . . . 9 63 6. Test Activation Request and Response . . . . . . . . . . . . 9 64 6.1. nTest Activation Request at the client . . . . . . . . . 10 65 6.2. Test Activation Request - server response . . . . . . . . 11 66 6.3. Test Activation Response action at the client . . . . . . 13 67 7. Test Stream Transmission and Measurement Feedback Messages . 13 68 7.1. Test Packet PDU and Roles . . . . . . . . . . . . . . . . 13 69 7.2. Status PDU . . . . . . . . . . . . . . . . . . . . . . . 16 70 8. Stopping the Test . . . . . . . . . . . . . . . . . . . . . . 21 71 9. Method of Measurement . . . . . . . . . . . . . . . . . . . . 21 72 9.1. Running Code . . . . . . . . . . . . . . . . . . . . . . 22 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 75 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 78 13.2. Informative References . . . . . . . . . . . . . . . . . 25 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 81 1. Introduction 83 The IETF's efforts to define Network and Bulk Transport Capacity have 84 been chartered and finally progressed after over twenty years. 86 Over that time, the performance community has seen development of 87 Informative definitions in [RFC3148] for Framework for Bulk Transport 88 Capacity (BTC), RFC 5136 for Network Capacity and Maximum IP-layer 89 Capacity, and the Experimental metric definitions and methods in 90 [RFC8337], Model-Based Metrics for BTC. 92 This memo looks at the problem of measuring Network Capacity metrics 93 defined in [I-D.ietf-ippm-capacity-metric-method] where the method 94 deploys a feedback channel from the receiver to control the sender's 95 transmission rate in near-real-time. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14[RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 2. Scope, Goals, and Applicability 107 The scope of this memo is to define a protocol to measure the Maximum 108 IP-Layer Capacity metric and according to the standardized method. 110 The continued goal is to harmonize the specified metric and method 111 across the industry, and this protocol supports the specifications of 112 IETF and other Standards Development Organizations. 114 All active testing protocols currently defined by the IPPM WG are 115 UDP-based, but this protocol specifies both control and test 116 protocols using UDP transport. Also, the control protocol continues 117 operating during testing to convey results and dynamic 118 configurations. 120 The primary application of the protocol described here is the same as 121 in Section 2 of [RFC7479] where: 123 o The access portion of the network is the focus of this problem 124 statement. The user typically subscribes to a service with 125 bidirectional access partly described by rates in bits per second. 127 3. Protocol Overview 129 The test protocol memo describes the communication between two test 130 end-points. One end-point takes the role of server, awaiting 131 connection requests on a well-known port from the other end-point, 132 the client. 134 The client, requires specification of a test direction parameter 135 (upstream or downstream test) as well as the hostname or IP address 136 of the server in order to begin the setup and configuration 137 exchanges. 139 The protocol uses UDP transport and has four phases: 141 1. Setup Request and Response Exchange: client and server confirm 142 matching protocol versions, authentication mode, and jumbo 143 datagram support, or reject the connection. The server also 144 communicates the ephemeral port for further communication when 145 accepting the request. 147 2. Test Activation Request and Response: the client composes a 148 request conveying parameters such as the testing direction, the 149 duration of the test interval and test sub-intervals, and various 150 thresholds. The server then chooses to accept, ignore or modify 151 any of the test parameters, and communicates the set that will be 152 used unless the client rejects the modifications. Note that the 153 Test Activiation echange has opened any firewalls and network 154 address/port translators for the test connection and the traffic 155 that follows. 157 3. Test Stream Transmission and Measurement Feedback Messages: 158 Testing proceeds with one end-point sending load PDUs and the 159 other end-point receiving the load PDUs and sending frequent 160 status messages to communicate status and transmission conditions 161 there. The feedback messsages are input to a load-control 162 algorithm at the server, which controls future sending rates at 163 either end-point as needed. The choice to locate the load- 164 control algorithm at the server, regardlesss of transmiision 165 direction, means that the algorithm can be updated more easily at 166 a host within the network, and at a fewer number of hosts than 167 the number of clients. 169 4. Stopping the Test: The server initiates the phase to stop the 170 test by setting the STOP1 indication in load PDUs or sstatus 171 feedback messages. The client acknowledges by setting the STOP2 172 in further load PDUs or messages, and a graceful connection 173 termination at each end-point follows. (Since the load PDUs and 174 feedback messages are used, this phase is kind of a sub-phase of 175 3.) 177 4. General Parameters and Definitions 179 This section lists the REQUIRED input factors to specify a Sender or 180 Receiver metric. 182 o Src, the address of a host (such as the globally routable IP 183 address). 185 o Dst, the address of a host (such as the globally routable IP 186 address). 188 o MaxHops, the limit on the number of Hops a specific packet may 189 visit as it traverses from the host at Src to the host at Dst 190 (implemented in the TTL or Hop Limit). 192 o T0, the time at the start of measurement interval, when packets 193 are first transmitted from the Source. 195 o I, the nominal duration of a measurement interval at the 196 destination (default 10 sec) 198 o dt, the nominal duration of m equal sub-intervals in I at the 199 destination (default 1 sec) 201 o dtn, the beginning boundary of a specific sub-interval, n, one of 202 m sub-intervals in I 204 o FT, the feedback time interval between status feedback messages 205 communicating measurement results, sent from the receiver to 206 control the sender. The results are evaluated to determine how to 207 adjust the current offered load rate at the sender (default 50ms) 209 o Tmax, a maximum waiting time for test packets to arrive at the 210 destination, set sufficiently long to disambiguate packets with 211 long delays from packets that are discarded (lost), such that the 212 distribution of one-way delay is not truncated. 214 o F, the number of different flows synthesized by the method 215 (default 1 flow) 217 o flow, the stream of packets with the same n-tuple of designated 218 header fields that (when held constant) result in identical 219 treatment in a multi-path decision (such as the decision taken in 220 load balancing). Note: The IPv6 flow label MAY be included in the 221 flow definition when routers have complied with [RFC6438] 222 guidelines. 224 o Type-P, the complete description of the test packets for which 225 this assessment applies (including the flow-defining fields). 226 Note that the UDP transport layer is one requirement for test 227 packets specified below. Type-P is a parallel concept to 228 "population of interest" defined in clause 6.1.1 of[Y.1540]. 230 o PM, a list of fundamental metrics, such as loss, delay, and 231 reordering, and corresponding target performance threshold. At 232 least one fundamental metric and target performance threshold MUST 233 be supplied (such as One-way IP Packet Loss [RFC7680] equal to 234 zero). 236 A non-Parameter which is required for several metrics is defined 237 below: 239 o T, the host time of the *first* test packet's *arrival* as 240 measured at the destination Measurement Point, or MP(Dst). There 241 may be other packets sent between source and destination hosts 242 that are excluded, so this is the time of arrival of the first 243 packet used for measurement of the metric. 245 Note that time stamp format and resolution, sequence numbers, etc. 246 will be established by the chosen test protocol standard or 247 implementation. 249 5. Setup Request and Response Exchange 251 The client SHALL begin the Control protocol connection by sending a 252 Setup Request message to the server's control port. 254 The client SHALL simultaneously start a test initiation timer so that 255 if the control protocol fails to complete all exchanges in the 256 allocated time, the client software SHALL exit (close the UDP socket 257 and indicate an error message to the user). 259 (Note: in version 8, the watchdog time is configured, in udpst.h, as 260 #define WARNING_NOTRAFFIC 1 // Receive traffic stopped warning 261 threshold (sec) #define TIMEOUT_NOTRAFFIC (WARNING_NOTRAFFIC + 4) or 262 5 seconds) 264 The Setup Request message PDU SHALL be organized as follows: 266 uint16_t controlId; // Control ID = 0xACE1 267 uint16_t protocolVer; // Protocol version = 0x08 268 uint8_t cmdRequest; // Command request = 1 (request) 269 uint8_t cmdResponse; // Command response = 0 270 uint16_t reserved1; // Reserved (alignment) 271 uint16_t testPort; // Test port on server (=0 for Request) 272 uint8_t jumboStatus; // Jumbo datagram support status (BOOL) 273 uint8_t authMode; // Authentication mode 274 uint32_t authUnixTime;// Authentication time stamp 275 unsigned char authDigest[AUTH_DIGEST_LENGTH] // SHA256_DIGEST_LENGTH = 32 oct 277 The UDP PDU format layout SHALL be as follows (big-endian AB): 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | controlId | protocolVer | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | cmdRequest | cmdResponse | reserved1 | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | testPort | jumboStatus | authMode | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | authUnixTime | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 | | 292 | | 293 | | 294 | authDigest[AUTH_DIGEST_LENGTH](256 bits) | 295 | | 296 | | 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 When the server receives the Setup Request it SHALL validate the 301 request by checking the protocol version, the jumbo datagram support 302 indicator, and the authentication data if utilized. If the client 303 has selected options for: 305 o Jumbo datagram support status (BOOL), 307 o Authentication mode, and 309 o Authentication time stamp 311 that do not match the server configuration, the server MUST reject 312 the Setup Request. 314 (Note: in version 8, the watchdog time is configured, in udpst.h, as 315 #define WARNING_NOTRAFFIC 1 // Receive traffic stopped warning 316 threshold (sec) #define TIMEOUT_NOTRAFFIC (WARNING_NOTRAFFIC + 4) or 317 5 seconds) 319 If the Setup Request must be rejected (due to any of the reasons in 320 the Command response codes listed below), a Setup Response SHALL be 321 sent back to the client with a corresponding command response value 322 indicating the reason for the rejection. 324 uint16_t controlId; // Control ID = 0xACE1 325 uint16_t protocolVer; // Protocol version = 0x08 326 uint8_t cmdRequest; // Command request = 2 (reply) 327 uint8_t cmdResponse; // Command response = 328 uint16_t reserved1; // Reserved (alignment) 329 uint16_t testPort; // Test port on server (available port in Response) 330 uint8_t jumboStatus; // Jumbo datagram support status (BOOL) 331 uint8_t authMode; // Authentication mode 332 uint32_t authUnixTime;// Authentication time stamp 333 unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets, MBZ 335 Command Response Codes 336 Control Header Setup Request Code CHSR_CRSP_NONE 0 = None 337 Control Header Setup Request Code CHSR_CRSP_ACKOK 1 = Acknowledgement 338 Control Header Setup Request Code CHSR_CRSP_BADVER 2 = Bad Protocol Version 339 Control Header Setup Request Code CHSR_CRSP_BADJS 3 = Invalid Jumbo datagram option 340 Control Header Setup Request Code CHSR_CRSP_AUTHNC 4 = Unexpected Authentication in Setup Request 341 Control Header Setup Request Code CHSR_CRSP_AUTHREQ 5 = Authentication missing in Setup Request 342 Control Header Setup Request Code CHSR_CRSP_AUTHINV 6 = Invalid authentication method 343 Control Header Setup Request Code CHSR_CRSP_AUTHFAIL 7 = Authentication failure 344 Control Header Setup Request Code CHSR_CRSP_AUTHTIME 8 = Authentication time is invalid in Setup Request 346 If the server finds that the Setup Request matches its configuration 347 and is otherwise acceptable, the server SHALL initiate a new 348 connection for the client, using a new UDP socket allocated from the 349 UDP ephemeral port range. Then, the server SHALL start a watchdog 350 timer (to terminate the connection in case the client goes silent), 351 and sends the Setup Response back to the client (see below for 352 composition). 354 If the Setup Request is accepted by the server, a Setup Response 355 SHALL be sent back to the client with a corresponding command 356 response value indicating 1 = Acknowledgement. 358 uint16_t controlId; // Control ID = 0xACE1 359 uint16_t protocolVer; // Protocol version = 0x08 360 uint8_t cmdRequest; // Command request = 2 (reply) 361 uint8_t cmdResponse; // Command response = 1 (Acknowledgement) 362 uint16_t reserved1; // Reserved (alignment) 363 uint16_t testPort; // Test port on server (available port in Response) 364 uint8_t jumboStatus; // Jumbo datagram support status (BOOL) 365 uint8_t authMode; // Authentication mode 366 uint32_t authUnixTime;// Authentication time stamp 367 unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets, MBZ 368 ... 370 The new connection is associated with a new UDP socket allocated from 371 the UDP ephemeral port range at the server. The server SHALL set a 372 timer for the new connection as a watchdog (in case the client goes 373 quiet) and send the Setup response back to the client. 375 (Note: in version 8, the watchdog time-out is configured at 5 376 seconds) 378 The Setup Response SHALL include the port number at the server for 379 the new socket, and this UDP port-pair SHALL be used for all 380 subsequent communication. The server SHALL also include the values 381 of: 383 o Jumbo datagram support status (BOOL), 385 o Authentication mode, and 387 o Authentication time stamp 389 for the client's use on the new connection in its Setup Response, and 390 the remaining 32 octets MUST Be Zero (MBZ). 392 Finally, the new UDP connection associated with the new socket and 393 port number is opened, and the server awaits communication there. 395 If a Test Activation request is not subsequently received from the 396 client on this new port number before the watchdog timer expires, the 397 server SHALL close the socket and deallocate the port. 399 5.1. Setup Response Processing at the Client 401 When the client receives the Setup response from the server it first 402 checks the cmdResponse value. If this value indicates an error the 403 client SHALL display/report a relevant message to the user or 404 management process and exit. If the client receives a Command 405 Response code (CRSP) that is not equal to one of the codes defined 406 above, then the client MUST terminate the connection and terminate 407 operation of the current Setup Request. If the Command Response code 408 (CRSP) value indicates success the client SHALL compose a Test 409 Activation Request with all the test parameters it desires such as 410 the test direction, the test duration, etc. 412 6. Test Activation Request and Response 414 This section is divided accrding to the sending and processing of the 415 client, server, and again at the client. 417 6.1. nTest Activation Request at the client 419 Upon a successful setup, the client SHALL then send the Test 420 Activation Request to the UDP port number the server communicated in 421 the Setup Response. 423 The client SHALL compose Test Activation Request as follows: 425 uint16_t controlId; // Control ID 426 uint16_t protocolVer; // Protocol version 427 uint8_t cmdRequest; // Command request, 1 = upstream, 2 = downstream 428 uint8_t cmdResponse; // Command response (set to 0) 429 uint16_t lowThresh; // Low delay variation threshold 430 uint16_t upperThresh; // Upper delay variation threshold 431 uint16_t trialInt; // Status feedback/trial interval (ms) 432 uint16_t testIntTime; // Test interval time (sec) 433 uint8_t subIntPeriod; // Sub-interval period (sec) 434 uint8_t ipTosByte; // IP ToS byte for testing 435 uint16_t srIndexConf; // Configured sending rate index (see Note below) 436 uint8_t useOwDelVar; // Use one-way delay instead of RTT 437 uint8_t highSpeedDelta; // High-speed row adjustment delta 438 uint16_t slowAdjThresh; // Slow rate adjustment threshold 439 uint16_t seqErrThresh; // Sequence error threshold 440 uint8_t ignoreOooDup; // Ignore Out-of-Order/Duplicate datagrams 441 uint8_t reserved1; // (Alignment) 442 uint16_t reserved2; // (Alignment) 444 Control Header Test Activation Command Request Values: 445 CHTA_CREQ_NONE 0 = No Request 446 CHTA_CREQ_TESTACTUS 1 = Request test in Upstream direction (client to server, client takes the role of sending test packets) 447 CHTA_CREQ_TESTACTDS 2 = Request test in Downstream direction (server to client, client takes the role of receiving test packets) 449 Control Header Test Activation Command Response Values: 450 CHTA_CRSP_NONE 0 = Used by client when making a Request 451 CHTA_CRSP_ACKOK 1 = Used by Server in affirmative Response 452 CHTA_CRSP_BADPARAM 2 = Used by Server to indicate an error; bad parameter; reject; 454 Note: uint16_t srIndexConf is the table index of the configured 455 *fixed* sending rate index to use. The client can request the 456 specified rate, or the server can use this field to coerce a maximum 457 rate in its response. If the server sets to 0 in its response, 458 client SHALL not use fixed rate. 460 The UDP PDU format of the Test Activation Request is as follows (big- 461 endian AB): 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | controlId | protocolVer | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | cmdRequest | cmdResponse | lowThresh | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | upperThresh | trialInt | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | testIntTime | subIntPeriod | ipTosByte | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | srIndexConf | useOwDelVar |highSpeedDelta | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | slowAdjThresh | seqErrThresh | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | ignoreOooDup | reserved1 | reserved2 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Note: This is only 28 octets of the 56 octet PDU sent, the rest are MBZ 481 for a Test Activation Request. 483 The client SHALL use the configuration for 485 o Jumbo datagram support status (BOOL), 487 o Authentication mode, and 489 o Authentication time stamp 491 requested and confirmed by the server. 493 6.2. Test Activation Request - server response 495 After the server receives the Test Activation request on the new 496 connection, it MUST choose to accept, ignore or modify any of the 497 test parameters. 499 When the server sends the Test Activation response back, it SHALL set 500 the cmd Response field to: 502 uint8_t cmdResponse;// Command response (set to 1, ACK, or 2 error) 504 The server SHALL include all the test parameters again to make the 505 client aware of any changes. 507 If the client has requested an upstream test, the server SHALL 508 include the transmission parameters from the first row of the sending 509 rate table. 511 The remaining 28 octets of the Test Activation Request (normally read 512 from the first row of the sending rate table) are called the Sending 513 Rate Structure, and SHALL be organized as follows: 515 uint32_t txInterval1; // Transmit interval (us) 516 uint32_t udpPayload1; // UDP payload (bytes) 517 uint32_t burstSize1; // UDP burst size per interval 518 uint32_t txInterval2; // Transmit interval (us) 519 uint32_t udpPayload2; // UDP payload (bytes) 520 uint32_t burstSize2; // UDP burst size per interval 521 uint32_t udpAddon2; // UDP add-on (bytes) 523 with 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | txInterval1 | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | udpPayload1 | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | burstSize1 | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | txInterval2 | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | udpPayload2 | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | burstSize2 | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | udpAdddon2 | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Note that the server additionally has the option of completely 542 rejecting the request and sending back an appropriate command 543 response value: 545 uint8_t cmdResponse; // Command response (set to 2, error) 547 If activation continues, the new connection is prepared for an 548 upstream OR downstream test. 550 In the case of a downstream test, the server prepares to send with 551 either a single timer to send status PDUs at the specified interval 552 OR dual timers to send load PDUs based on the first row of the 553 sending rate table. 555 The server SHALL then send a Test Activation response back to the 556 client, update the watchdog timer with a new time-out value, and set 557 a test duration timer to eventually stop the test. 559 The new connection is now ready for testing. 561 6.3. Test Activation Response action at the client 563 When the client receives the Test Activation response, it first 564 checks the command response value. 566 If the client receives a Test Activation command response value that 567 indicates an error, the client SHALL display/report a relevant 568 message to the user or management process and exit. 570 If the client receives a Test Activation command response value that 571 is not equal to one of the codes defined above, then the client MUST 572 terminate the connection and terminate operation of the current Setup 573 Request. 575 If the client receives a Test Activation command response value that 576 indicates success (CHTA_CRSP_ACKOK) the client SHALL update its 577 configuration to use any test parameters modified by the server. 579 Next, the client SHALL prepare its connection for either an upstream 580 test with dual timers set to send load PDUs (based on the starting 581 transmission parameters sent by the server), OR a downstream test 582 with a single timer to send status PDUs at the specified interval. 584 Then, the client SHALL stop the test initiation timer, set a new 585 time-out value for the watchdog timer, and start the timer (in case 586 the server goes quiet). 588 The connection is now ready for testing. 590 7. Test Stream Transmission and Measurement Feedback Messages 592 This section describes the testing phase of the protocol. The roles 593 of sender and receiver vary depending whether the direction of 594 testing is from server to client, or the reverse. 596 7.1. Test Packet PDU and Roles 598 Testing proceeds with one end point sending load PDUs, based on 599 transmission parameters from the sending rate table, and the other 600 end point receiving the load PDUs and sending status messages to 601 communicate the traffic conditions at the receiver. 603 The watchdog timer at the receiver SHALL be reset each time a test 604 PDU is received. 606 When the server is sending Load PDUs in the role of sender, it SHALL 607 use the transmission parameters directly from the sending rate table 608 via the index that is currently selected (which was based on the 609 feedback in its received status messages). 611 However, when the client is sending load PDUs in the role of sender, 612 it SHALL use the discreet transmission parameters that were 613 communicated by the server in its periodic status messages (and not 614 referencing a sending rate table). This approach allows the server 615 to control the individual sending rates as well as the algorithm used 616 to decide when and how to adjust the rate. 618 The server uses a load adjustment algorithm which evaluates 619 measurements, either it's own or the contents of received feedback 620 messages. This algorithm is unique to udpst; it provides the ability 621 to search for the Maximum IP Capacity that is absent from other 622 testing tools. Although the algorithm depends on the protocol, it is 623 not part of the protocol per se. 625 The current algorithm has three paths to its decision on the next 626 sending rate: 628 1. When there are no impairments present (no sequence errors, low 629 delay variation), resulting in sending rate increase. 631 2. When there are low impairments present (no sequence errors but 632 higher levels of delay variation), so the same sending rate is 633 retained. 635 3. When the impairment levels are above the thresholds set for this 636 purpose and "congestion" is inferred, resulting in sending rate 637 decrease. 639 The algorithm also has two modes for increasing/decreasing the 640 sending rate: 642 o A high-speed mode to achieve high sending rates quickly, but also 643 back-off quickly when "congestion" is inferred from the 644 measurements. Any two consecutive feedback intervals that have a 645 sequence number anomaly and/or contain an upper delay variation 646 threshold exception in both of the two consecutive intervals, 647 count as the two consecutive feedback measurements required to 648 declare "congestion" within a test. 650 o A single-step mode where all rate adjustments use the minimum 651 increase or decrease of one step in the sending rate table. The 652 single step mode continues after the first inference of 653 "congestion" from measured impairments. 655 On the other hand, the test configuration MAY use a fixed sending 656 rate requested by the client, using the field below: 658 uint16_t srIndexConf; // Configured sending rate index 660 The client MAY communicate the desired fixed rate in it's activation 661 request. 663 The Load PDU SHALL have the following format and field definitions: 665 uint16_t loadId; // Load ID (=0xBEEF for the LOad PDU) 666 uint8_t testAction; // Test action (= 0x00 normally, until test stop) 667 uint8_t rxStopped; // Receive traffic stopped indicator (BOOL) 668 uint32_t lpduSeqNo; // Load PDU sequence number (starts at 1) 669 uint16_t udpPayload; // UDP payload LENGTH(bytes) 670 uint16_t spduSeqErr; // Status PDU sequence error count 671 // 672 uint32_t spduTime_sec; // Send time in last received status PDU 673 uint32_t spduTime_nsec; // Send time in last received status PDU 674 uint32_t lpduTime_sec; // Send time of this load PDU 675 uint32_t lpduTime_nsec; // Send time of this load PDU 677 Test Action Codes 678 TEST_ACT_TEST 0 // normal 679 TEST_ACT_STOP1 1 // normal stop at end of test: server sends in STATUS or Test PDU 680 TEST_ACT_STOP2 2 // ACK of STOP1: sent by client in STATUS or Test PDU 682 The Test Load UDP PDU format is as follows (big-endian AB): 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | loadId | testAction | rxStopped | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | lpduSeqNo | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | udpPayload | spduSeqErr | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | spduTime_sec | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | spduTime_nsec | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | lpduTime_sec | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | lpduTime_nsec | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 . MBZ = udpPayload - 28 octets . 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 . . 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 . . 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 . . 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 . . 711 7.2. Status PDU 713 The receiver SHALL send a Status PDU to the sender during a test at 714 the configured feedback interval. 716 The Status Header PDU SHALL have the following format and field 717 definitions: 719 // Status feedback header for UDP payload of status PDUs 720 // 722 uint16_t statusId; // Status ID = 0xFEED 723 uint8_t testAction; // Test action 724 uint8_t rxStopped; // Receive traffic stopped indicator (BOOL) 725 uint32_t spduSeqNo; // Status PDU sequence number (starts at 1) 726 // 727 struct sendingRate srStruct; // Sending Rate Structure (28 octets) 728 // 729 uint32_t subIntSeqNo; // Sub-interval sequence number 730 struct subIntStats sisSav; // Sub-interval Saved Stats Structure (52 octets) 731 // 732 uint32_t seqErrLoss; // Loss sum 733 uint32_t seqErrOoo; // Out-of-Order sum 734 uint32_t seqErrDup; // Duplicate sum 735 // 736 uint32_t clockDeltaMin; // Clock delta minimum (either RTT or 1-way delay) 737 uint32_t delayVarMin; // Delay variation minimum 738 uint32_t delayVarMax; // Delay variation maximum 739 uint32_t delayVarSum; // Delay variation sum 740 uint32_t delayVarCnt; // Delay variation count 741 uint32_t rttMinimum; // Minimum round-trip time sampled 742 uint32_t rttSample; // Last round-trip time sample 743 uint8_t delayMinUpd; // Delay minimum(s) updated observed, communicated in both directions. 744 uint8_t reserved2; // (alignment) 745 uint16_t reserved3; // (alignment) 746 // 747 uint32_t tiDeltaTime; // Trial interval delta time 748 uint32_t tiRxDatagrams; // Trial interval receive datagrams 749 uint32_t tiRxBytes; // Trial interval receive bytes 750 // 751 uint32_t spduTime_sec; // Send time of this status PDU 752 uint32_t spduTime_nsec; // Send time of this status PDU 754 The Status feedback UDP payload PDUs format is as follows (big-endian 755 AB): 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | statusId | testAction | rxStopped | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | spduSeqNo | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 . Sending Rate Structure (28 octets) . 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | subIntSeqNo | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 . Sub-interval Saved Stats Structure (52 octets) . 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | seqErrLoss | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | seqErrOoo | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | seqErrDup | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | clockDeltaMin | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | delayVarMin | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | delayVarMax | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | delayVarSum | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | delayVarCnt | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | rttMinimum | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | rttSample | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | delayMinUpd | reserved2 | reserved3 | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | tiDeltaTime | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | tiRxDatagrams | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | tiRxBytes | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | spduTime_sec | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | spduTime_nsec | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Note that the Sending Rate Structure (28 octets) is defined in the 804 Test Activation section. 806 Also note that the Sub-interval Saved Stats Structure (52 octets) 807 SHALL be included (and populated as required when the server is in 808 the receiver role) as defined below. 810 The Sub-interval saved statistics structure for received traffic 811 measurements SHALL be organized and formatted as follows: 813 uint32_t rxDatagrams; // Received datagrams 814 uint32_t rxBytes; // Received bytes 815 uint32_t deltaTime; // Time delta 816 uint32_t seqErrLoss; // Loss sum 817 uint32_t seqErrOoo; // Out-of-Order sum 818 uint32_t seqErrDup; // Duplicate sum 819 uint32_t delayVarMin; // Delay variation minimum 820 uint32_t delayVarMax; // Delay variation maximum 821 uint32_t delayVarSum; // Delay variation sum 822 uint32_t delayVarCnt; // Delay variation count 823 uint32_t rttMinimum; // Minimum round-trip time 824 uint32_t rttMaximum; // Maximum round-trip time 825 uint32_t accumTime; // Accumulated time 826 ---------------------------------------------------------------------------- 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | rxDatagrams | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | rxBytes | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | deltaTime | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | seqErrLoss | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | seqErrOoo | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | seqErrDup | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | delayVarMin | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | delayVarMax | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | delayVarSum | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | delayVarCnt | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | rttMinimum | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | rttMaximum | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | accumTime | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 Note that the 52 octet saved statistics structure above has slight 859 differences from the 40 octets that follow in the status feedback 860 PDU, particularly the time-related fields. 862 Upon receiving the Status Feedback PDU or expiration of the feedback 863 interval, the server SHALL perform calculations required by the Load 864 adjustment algorithm and adjust its sending rate, or signal that the 865 client do so in its role as as sender. 867 8. Stopping the Test 869 When the test duration timer on the server expires, it SHALL set the 870 connection test action to STOP and also starts marking all outgoing 871 load or status PDUs with a test action of STOP1. 873 uint8_t testAction; // Test action (server sets STOP1) 875 This is simply a non-reversible state for all future messages sent 876 from the server. 878 When the client receives a load or status PDU with the STOP1 879 indication, it SHALL finalize testing, display the test results, and 880 also mark its connection with a test action of STOP (so that any PDUs 881 received subsequent to the STOP1 are ignored). 883 With the test action of the client's connection set to STOP, the very 884 next expiry of a send timer for either a load or status PDU SHALL 885 cause the client to schedule an immediate end time to exit. 887 The client SHALL then send all subsequent load or status PDUs with a 888 test action of STOP2 890 uint8_t testAction; // Test action (client sets STOP2) 892 as confirmation to the server, and a graceful termination of the test 893 can begin. 895 When the server receives the STOP2 confirmation in the load or status 896 PDU, the server SHALL schedule an immediate end time for the 897 connection which closes the socket and deallocates it. 899 In a non-graceful test stop, the watchdog/quiet timers at each end- 900 point will expire, notifications SHALL be made and the test action of 901 each end-point's connection SHALL be set to STOP. 903 9. Method of Measurement 905 The architecture of the method REQUIRES two cooperating hosts 906 operating in the roles of Src (test packet sender) and Dst 907 (receiver), with a measured path and return path between them. 909 The duration of a test duration, parameter I, MUST be constrained in 910 a production network, since this is an active test method and it will 911 likely cause congestion on the Src to Dst host path during a test. 913 9.1. Running Code 915 This section is for the benefit of the Document Shepherd's form, and 916 will be deleted prior to final review. 918 Much of the development of the method and comparisons with existing 919 methods conducted at IETF Hackathons and elsewhere have been based on 920 the example udpst Linux measurement tool (which is a working 921 reference for further development) [udpst]. The current project: 923 o is a utility that can function as a client or server daemon 925 o requires a successful client-initiated setup handshake between 926 cooperating hosts and allows firewalls to control inbound 927 unsolicited UDP which either go to a control port [expected and w/ 928 authentication] or to ephemeral ports that are only created as 929 needed. Firewalls protecting each host can both continue to do 930 their job normally. This aspect is similar to many other test 931 utilities available. 933 o is written in C, and built with gcc (release 9.3) and its standard 934 run-time libraries 936 o allows configuration of most of the parameters described in 937 Sections 4 and 7. 939 o supports IPv4 and IPv6 address families. 941 o supports IP-layer packet marking. 943 10. Security Considerations 945 Active metrics and measurements have a long history of security 946 considerations. The security considerations that apply to any active 947 measurement of live paths are relevant here. See [RFC4656] and 948 [RFC5357]. 950 When considering privacy of those involved in measurement or those 951 whose traffic is measured, the sensitive information available to 952 potential observers is greatly reduced when using active techniques 953 which are within this scope of work. Passive observations of user 954 traffic for measurement purposes raise many privacy issues. We refer 955 the reader to the privacy considerations described in the Large Scale 956 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 957 which covers active and passive techniques. 959 There are some new considerations for Capacity measurement as 960 described in this memo. 962 1. Cooperating source and destination hosts and agreements to test 963 the path between the hosts are REQUIRED. Hosts perform in either 964 the Src or Dst roles. 966 2. It is REQUIRED to have a user client-initiated setup handshake 967 between cooperating hosts that allows firewalls to control 968 inbound unsolicited UDP traffic which either goes to a control 969 port [expected and w/authentication] or to ephemeral ports that 970 are only created as needed. Firewalls protecting each host can 971 both continue to do their job normally. 973 3. Client-server authentication and integrity protection for 974 feedback messages conveying measurements is RECOMMENDED. To 975 accomodate different host limitations and testing circumstances, 976 different modes of operation are recommended: 978 A. Unathenticated mode (for all phases) 979 AND 980 B. OPTIONAL Authenticated set-up only 981 SHA-256 HMAC time-window verification (5 min time stamp verification) 982 (could add silent failure option) 984 -=-=-=-=-=-=-=-=-=- 986 C. Encrypted setup and test-activation 987 (currently using OpenSSL Library, so KISS, but may be too slow for 988 test packets) 990 -=-=-=-=--=- Old/lowpower host performance impacts -=-=-=-=-=-=- 992 D. Encrypted feedback messages 994 E. Integrity protection for test packets SHA-256 HMAC 996 F. Encrypted test packets (maybe also valuable to defeat compression on links) 998 4. Hosts MUST limit the number of simultaneous tests to avoid 999 resource exhaustion and inaccurate results. 1001 5. Senders MUST be rate-limited. This can be accomplished using a 1002 pre-built table defining all the offered load rates that will be 1003 supported (Section 8.1). The recommended load-control search 1004 algorithm results in "ramp up" from the lowest rate in the table. 1006 6. Service subscribers with limited data volumes who conduct 1007 extensive capacity testing might experience the effects of 1008 Service Provider controls on their service. Testing with the 1009 Service Provider's measurement hosts SHOULD be limited in 1010 frequency and/or overall volume of test traffic (for example, the 1011 range of I duration values SHOULD be limited). 1013 The exact specification of these features was hopefully accomplished 1014 during this protocol development. 1016 11. IANA Considerations 1018 This memo requests IANA to assign a UDP port. 1020 12. Acknowledgments 1022 Thanks to . 1024 13. References 1026 13.1. Normative References 1028 [I-D.ietf-ippm-capacity-metric-method] 1029 Morton, A., Geib, R., and L. Ciavattone, "Metrics and 1030 Methods for One-way IP Capacity", draft-ietf-ippm- 1031 capacity-metric-method-10 (work in progress), April 2021. 1033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1034 Requirement Levels", BCP 14, RFC 2119, 1035 DOI 10.17487/RFC2119, March 1997, 1036 . 1038 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1039 "Framework for IP Performance Metrics", RFC 2330, 1040 DOI 10.17487/RFC2330, May 1998, 1041 . 1043 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1044 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1045 September 1999, . 1047 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1048 Zekauskas, "A One-way Active Measurement Protocol 1049 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 1050 . 1052 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1053 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1054 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1055 . 1057 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1058 for Equal Cost Multipath Routing and Link Aggregation in 1059 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1060 . 1062 [RFC7479] Moonesamy, S., "Using Ed25519 in SSHFP Resource Records", 1063 RFC 7479, DOI 10.17487/RFC7479, March 2015, 1064 . 1066 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1067 Ed., "A One-Way Loss Metric for IP Performance Metrics 1068 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1069 2016, . 1071 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1072 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1073 May 2017, . 1075 [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. 1076 Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for 1077 the IP Performance Metrics (IPPM) Framework", RFC 8468, 1078 DOI 10.17487/RFC8468, November 2018, 1079 . 1081 13.2. Informative References 1083 [copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet, 1084 "copycat: Testing Differential Treatment of New Transport 1085 Protocols in the Wild (ANRW '17)", July 2017, 1086 . 1088 [LS-SG12-A] 1089 12, I. S., "LS - Harmonization of IP Capacity and Latency 1090 Parameters: Revision of Draft Rec. Y.1540 on IP packet 1091 transfer performance parameters and New Annex A with Lab 1092 Evaluation Plan", May 2019, 1093 . 1095 [LS-SG12-B] 1096 12, I. S., "LS on harmonization of IP Capacity and Latency 1097 Parameters: Consent of Draft Rec. Y.1540 on IP packet 1098 transfer performance parameters and New Annex A with Lab & 1099 Field Evaluation Plans", March 2019, 1100 . 1102 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1103 Network Interconnect Devices", RFC 2544, 1104 DOI 10.17487/RFC2544, March 1999, 1105 . 1107 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 1108 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 1109 DOI 10.17487/RFC3148, July 2001, 1110 . 1112 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 1113 RFC 5136, DOI 10.17487/RFC5136, February 2008, 1114 . 1116 [RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, 1117 "Applicability Statement for RFC 2544: Use on Production 1118 Networks Considered Harmful", RFC 6815, 1119 DOI 10.17487/RFC6815, November 2012, 1120 . 1122 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 1123 Framework for IP Performance Metrics (IPPM)", RFC 7312, 1124 DOI 10.17487/RFC7312, August 2014, 1125 . 1127 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1128 Aitken, P., and A. Akhter, "A Framework for Large-Scale 1129 Measurement of Broadband Performance (LMAP)", RFC 7594, 1130 DOI 10.17487/RFC7594, September 2015, 1131 . 1133 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1134 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1135 May 2016, . 1137 [RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk 1138 Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March 1139 2018, . 1141 [TR-471] Morton, A., "Broadband Forum TR-471: IP Layer Capacity 1142 Metrics and Measurement", July 2020, 1143 . 1146 [udpst] udpst Project Collaborators, "UDP Speed Test Open 1147 Broadband project", December 2020, 1148 . 1150 [Y.1540] Y.1540, I. R., "Internet protocol data communication 1151 service - IP packet transfer and availability performance 1152 parameters", December 2019, 1153 . 1155 [Y.Sup60] Morton, A., "Recommendation Y.Sup60, (09/20) Interpreting 1156 ITU-T Y.1540 maximum IP-layer capacity measurements", 1157 September 2020, 1158 . 1160 Authors' Addresses 1162 Len Ciavattone 1163 AT&T Labs 1164 200 Laurel Avenue South 1165 Middletown,, NJ 07748 1166 USA 1168 Email: lencia@att.com 1170 Al Morton 1171 AT&T Labs 1172 200 Laurel Avenue South 1173 Middletown,, NJ 07748 1174 USA 1176 Phone: +1 732 420 1571 1177 Fax: +1 732 368 1192 1178 Email: acm@research.att.com