idnits 2.17.00 (12 Aug 2021) /tmp/idnits60461/draft-ietf-ippm-capacity-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 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). -- The document date (February 25, 2022) is 78 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: 'I-D.ietf-ippm-capacity-metric-method' is defined on line 1153, but no explicit reference was found in the text == Unused Reference: 'RFC2330' is defined on line 1163, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: 'RFC6438' is defined on line 1172, but no explicit reference was found in the text == Unused Reference: 'RFC7680' is defined on line 1182, but no explicit reference was found in the text == Unused Reference: 'RFC8468' is defined on line 1191, but no explicit reference was found in the text == Unused Reference: 'LS-SG12-A' is defined on line 1209, but no explicit reference was found in the text == Unused Reference: 'LS-SG12-B' is defined on line 1216, but no explicit reference was found in the text == Unused Reference: 'RFC2544' is defined on line 1223, but no explicit reference was found in the text == Unused Reference: 'RFC5136' is defined on line 1238, but no explicit reference was found in the text == Unused Reference: 'RFC6815' is defined on line 1247, but no explicit reference was found in the text == Unused Reference: 'RFC7312' is defined on line 1253, but no explicit reference was found in the text == Unused Reference: 'RFC7799' is defined on line 1264, but no explicit reference was found in the text == Unused Reference: 'RFC8972' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'TR-471' is defined on line 1283, but no explicit reference was found in the text == Outdated reference: draft-ietf-ippm-capacity-metric-method has been published as RFC 9097 ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Downref: Normative reference to an Informational RFC: RFC 7497 ** Downref: Normative reference to an Informational RFC: RFC 8468 Summary: 4 errors (**), 0 flaws (~~), 17 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: August 29, 2022 February 25, 2022 7 Test Protocol for One-way IP Capacity Measurement 8 draft-ietf-ippm-capacity-protocol-01 10 Abstract 12 This memo addresses the problem of protocol support for measuring 13 Network Capacity metrics in RFC 9097, where the method deploys a 14 feedback channel from the receiver to control the sender's 15 transmission rate in near-real-time. This memo defines a simple 16 protocol to perform the RFC 9097 (and other) 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 August 29, 2022. 39 Copyright Notice 41 Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . . . . 4 60 4. General Parameters and Definitions . . . . . . . . . . . . . 5 61 5. Setup Request and Response Exchange . . . . . . . . . . . . . 5 62 5.1. Setup Response Processing at the Client . . . . . . . . . 10 63 6. Test Activation Request and Response . . . . . . . . . . . . 11 64 6.1. Test Activation Request at the client . . . . . . . . . . 11 65 6.2. Test Activation Response . . . . . . . . . . . . . . . . 13 66 6.3. Test Activation Response action at the client . . . . . . 15 67 7. Test Stream Transmission and Measurement Feedback Messages . 16 68 7.1. Test Packet PDU and Roles . . . . . . . . . . . . . . . . 16 69 7.2. Status PDU . . . . . . . . . . . . . . . . . . . . . . . 19 70 8. Stopping the Test . . . . . . . . . . . . . . . . . . . . . . 24 71 9. Method of Measurement . . . . . . . . . . . . . . . . . . . . 25 72 9.1. Running Code . . . . . . . . . . . . . . . . . . . . . . 25 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 75 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 78 13.2. Informative References . . . . . . . . . . . . . . . . . 29 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 [RFC9097] where the method deploys a feedback channel from 94 the receiver to control the sender's transmission rate in near-real- 95 time. 97 Although there are several test protocol already available for 98 support and manage active measurements, this protocol is a major 99 departure from their operation: 101 1. UDP transport is used for all setup, test activation, and control 102 messages, and for results feedback (not TCP), simplifying 103 operations. 105 2. TWAMP [RFC5357] and STAMP [RFC8762] use the philosophy that one 106 host is a Session-Reflector, sending test packets every time they 107 receive a test packet. This protocol supports a one-way test 108 with periodic status messages returned to the sender. These 109 messages are also a basis for on-path Round-trip delay 110 measurements, which are a key input to the load adjustment search 111 algorithm. 113 3. OWAMP [RFC4656] supports one-way testing with results Fetch at 114 the end of the test session. This protocol supports a one-way 115 test and requires periodic status messages returned to the sender 116 to support the load adjustment search algorithm. 118 4. The security features of OWAMP [RFC4656] and TWAMP [RFC5357] have 119 been described as "unusual", to the point that IESG approved 120 their use while also asking that these methods not be used again. 121 Further, the common OWAMP [RFC4656] and TWAMP [RFC5357] approach 122 to security is over 15 years old at this time. 124 Note: the -00 update of this draft will be the last that describes 125 version 8 of the protocol in the running code. Future updates of the 126 draft will correspond to protocol version 9 and higher versions. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14[RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2. Scope, Goals, and Applicability 138 The scope of this memo is to define a protocol to measure the Maximum 139 IP-Layer Capacity metric and according to the standardized method. 141 The continued goal is to harmonize the specified metric and method 142 across the industry, and this protocol supports the specifications of 143 IETF and other Standards Development Organizations. 145 All active testing protocols currently defined by the IPPM WG are 146 UDP-based, but this protocol specifies both control and test 147 protocols using UDP transport. Also, the control protocol continues 148 operating during testing to convey results and dynamic 149 configurations. 151 The primary application of the protocol described here is the same as 152 in Section 2 of [RFC7497] where: 154 o The access portion of the network is the focus of this problem 155 statement. The user typically subscribes to a service with 156 bidirectional access partly described by rates in bits per second. 158 3. Protocol Overview 160 This section gives an informative overview of the communication 161 protocol between two test end-points (without expressing 162 requirements: later sections provide details and requirements). 164 One end-point takes the role of server, awaiting connection requests 165 on a well-known port from the other end-point, the client. 167 The client requires configuration of a test direction parameter 168 (upstream or downstream test, where the client performs the role of 169 sender or receiver, respectively) as well as the hostname or IP 170 address of the server in order to begin the setup and configuration 171 exchanges with the server. 173 The protocol uses UDP transport and has four phases: 175 1. Setup Request and Response Exchange: The client requests to begin 176 a test by communicating its protocol version, intended security 177 mode, and jumbo datagram support. The server either confirms 178 matching configuration or rejects the connection. The server 179 also communicates the ephemeral port for further communication 180 when accepting the client's request. 182 2. Test Activation Request and Response: the client composes a 183 request conveying parameters such as the testing direction, the 184 duration of the test interval and test sub-intervals, and various 185 thresholds. The server then chooses to accept, ignore or modify 186 any of the test parameters, and communicates the set that will be 187 used unless the client rejects the modifications. Note that the 188 client assumes that the Test Activation exchange has opened any 189 co-located firewalls and network address/port translators for the 190 test connection (in response to the Request packet on the 191 ephemeral port) and the traffic that follows. If the Test 192 Activation Request is rejected or fails, the client assumes that 193 the firewall will close the address/port combination after the 194 firewall's configured idle traffic time-out. 196 3. Test Stream Transmission and Measurement Feedback Messages: 197 Testing proceeds with one end-point sending load PDUs and the 198 other end-point receiving the load PDUs and sending frequent 199 status messages to communicate status and transmission conditions 200 there. The feedback messsages are input to a load-control 201 algorithm at the server, which controls future sending rates at 202 either end-point as needed. The choice to locate the load- 203 control algorithm at the server, regardlesss of transmiision 204 direction, means that the algorithm can be updated more easily at 205 a host within the network, and at a fewer number of hosts than 206 the number of clients. 208 4. Stopping the Test: When the specified test duration has been 209 reached, the server initiates the phase to stop the test by 210 setting the STOP1 indication in load PDUs or status feedback 211 messages. The client acknowledges by setting the STOP2 in 212 further load PDUs or messages, and a graceful connection 213 termination at each end-point follows. (Since the load PDUs and 214 feedback messages are used, this phase is kind of a sub-phase of 215 3.) If the Test traffic stops or the communication path fails, 216 the client assumes that the firewall will close the address/port 217 combination after the firewall's configured idle traffic time- 218 out. 220 4. General Parameters and Definitions 222 For Parameters related to the Maximum IP-Layer Capacity Metric and 223 Method, please see Section 4 of [RFC9097]. 225 5. Setup Request and Response Exchange 227 All messages defined in this section SHALL use UDP transport. The 228 hosts SHALL calculate and include the UDP checksum, or check the UDP 229 checksum as neccessary. 231 The client SHALL begin the Control protocol connection by sending a 232 Setup Request message to the server's control port. 234 The client SHALL simultaneously start a test initiation timer so that 235 if the control protocol fails to complete all exchanges in the 236 allocated time, the client software SHALL exit (close the UDP socket 237 and indicate an error message to the user). 239 (Note: in version 8, the watchdog time-out is configured, in udpst.h, 240 as #define WARNING_NOTRAFFIC 1 // Receive traffic stopped warning 241 threshold (sec) #define TIMEOUT_NOTRAFFIC (WARNING_NOTRAFFIC + 4) or 242 5 seconds) 244 The Setup Request message PDU SHALL be organized as follows: 246 uint16_t controlId; // Control ID = 0xACE1 247 uint16_t protocolVer; // Protocol version = 0x08 248 uint8_t cmdRequest; // Command request = 1 (request) 249 uint8_t cmdResponse; // Command response = 0 250 * uint16_t maxBandwidth;// Required bandwidth (added in v9) 251 uint16_t testPort; // Test port on server (=0 for Request) 252 * uint8_t modifierBitmap;// Modifier bitmap (replaced jumboStatus in v9) 253 uint8_t authMode; // Authentication mode 254 uint32_t authUnixTime;// Authentication time stamp 255 unsigned char authDigest[AUTH_DIGEST_LENGTH] // SHA256_DIGEST_LENGTH = 32 oct 257 The UDP PDU format layout SHALL be as follows (big-endian AB): 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | controlId | protocolVer | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | cmdRequest | cmdResponse | maxBandwidth | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | testPort |modifierBitmap | authMode | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | authUnixTime | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | | 271 | | 272 | | 273 | | 274 | authDigest[AUTH_DIGEST_LENGTH](256 bits) | 275 | | 276 | | 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 When the server receives the Setup Request it SHALL validate the 281 request by checking the protocol version, the maxBandwidth requested 282 for the test, the modifierBitmap for use of options such as Jumbo 283 datagram status and traditional MTU (1500 bytes), and the 284 authentication data if utilized. If the client has selected options 285 for: 287 o Jumbo datagram support status (modifierBitmap), 288 o Traditional MTU (modifierBitmap), 290 o Authentication mode, and 292 o Authentication time stamp 294 that do not match the server configuration, the server MUST reject 295 the Setup Request. Note that a server implemenation of protocol 296 version 9 allows backward compatibility with version 8 when in use by 297 the client. 299 (Note: in version 8, the watchdog time is configured, in udpst.h, as 300 #define WARNING_NOTRAFFIC 1 // Receive traffic stopped warning 301 threshold (sec) #define TIMEOUT_NOTRAFFIC (WARNING_NOTRAFFIC + 4) or 302 5 seconds) 304 If the Setup Request must be rejected (due to any of the reasons in 305 the Command response codes listed below), a Setup Response SHALL be 306 sent back to the client with a corresponding command response value 307 indicating the reason for the rejection. 309 uint16_t controlId; // Control ID = 0xACE1 310 uint16_t protocolVer; // Protocol version = 0x08 311 uint8_t cmdRequest; // Command request = 2 (reply) 312 uint8_t cmdResponse; // Command response = 313 uint16_t maxBandwidth;// Required bandwidth (added in v9) 314 uint16_t testPort; // Test port on server (available port in Response) 315 uint8_t modifierBitmap;// Modifier bitmap (replaced jumboStatus, table below) 316 uint8_t authMode; // Authentication mode 317 uint32_t authUnixTime;// Authentication time stamp 318 unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets, MBZ 320 cmdResponse Code Field: Command Server Response Codes (CSRP) 321 CHSR_CRSP_NONE 0 = None 322 CHSR_CRSP_ACKOK 1 = Acknowledgement 323 CHSR_CRSP_BADVER 2 = Bad Protocol Version 324 CHSR_CRSP_BADJS 3 = Invalid Jumbo datagram option 325 CHSR_CRSP_AUTHNC 4 = Unexpected Authentication in Setup Request 326 CHSR_CRSP_AUTHREQ 5 = Authentication missing in Setup Request 327 CHSR_CRSP_AUTHINV 6 = Invalid authentication method 328 CHSR_CRSP_AUTHFAIL 7 = Authentication failure 329 CHSR_CRSP_AUTHTIME 8 = Authentication time is invalid in Setup Request 330 CHSR_CRSP_NOMAXBW 9 = No Maximum test Bit rate specified 331 CHSR_CRSP_CAPEXC 10 = Server Maximum Bit rate exceeded 332 CHSR_CRSP_BADTMTU 11 = MTU option does not match Server 334 maxBandwidth Field MSB Code Bit: 335 CHSR_USDIR_BIT 0x8000 Bandwidth upstream direction bit, Set for Upstream 337 modifierBitmap Code Field: Setup 338 CHSR_JUMBO_STATUS 0x01 = set when Jumbo frames allowed > 1Gbps 339 CHSR_TRADITIONAL_MTU 0x02 = set to use datagrams for 1500 byte packets 341 @@@@ To Do: How do we communicate multiple errors when the server 342 sends the Setup Response? This is the current practice, and more 343 codes have been added in v9. Is an error hierarchy sufficient, where 344 Bad Protocol Version means that none of the other aspects (higher 345 error numbers) were checked? 347 @@@@ Given that the list of error codes grows with the functionality, 348 a hierarchy is no longer possible. New text to address this issue 349 appears below: 351 There is a set of Command Response codes, beginning with: "2 = Bad 352 Protocol Version", one of which SHOULD be communicated to indicate 353 the cause when an error condition detected and testing cannot 354 proceed: 356 2 = Bad Protocol Version 357 3 = Invalid Jumbo datagram option 358 5 = Authentication missing in Setup Request 359 4 = Unexpected Authentication in Setup Request 360 6 = Invalid authentication method (SHA-256 not used) 361 7 = Authentication failure (both shared secret and time) 362 8 = Authentication time is invalid in Setup Request (replay attack) 363 9 = No Maximum test Bit rate specified 364 10 = Server Maximum Bit rate exceeded 365 11 = MTU option does not match Server 367 The exceptional circumstances when a server would not communicate the 368 appropriate Command Response Code for an error condition are when 370 1. the Setup Request PDU size is not correct (for supported versions 371 of the protocol), 373 2. the control ID is invalid, or 375 3. a directed attack has been detected, 377 in which case the server will allow setup attempts to terminate 378 silently. Attack detection is beyond the scope of this 379 specification. 381 When indicating a Bad Protocol Version error, the server SHALL update 382 the protocolVer field in the Setup Response to indicate the current 383 version supported. 385 @@@@ - end text for discussion - 387 If the server finds that the Setup Request matches its configuration 388 and is otherwise acceptable, the server SHALL initiate a new 389 connection for the client, using a new UDP socket allocated from the 390 UDP ephemeral port range. Then, the server SHALL start a watchdog 391 timer (to terminate the connection in case the client goes silent), 392 and sends the Setup Response back to the client (see below for 393 composition). 395 When the Setup Request is accepted by the server, a Setup Response 396 SHALL be sent back to the client with a corresponding command 397 response value indicating 1 = Acknowledgement. 399 uint16_t controlId; // Control ID = 0xACE1 400 uint16_t protocolVer; // Protocol version = 0x08 401 uint8_t cmdRequest; // Command request = 2 (reply) 402 uint8_t cmdResponse; // Command response = 1 (Acknowledgement) 403 uint16_t maxBandwidth;// Required bandwidth (added in v9) 404 uint16_t testPort; // Test port on server (available port in Response) 405 uint8_t modifierBitmap;// Modifier bitmap (replaced jumboStatus for v9) 406 uint8_t authMode; // Authentication mode 407 uint32_t authUnixTime;// Authentication time stamp 408 unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets, MBZ 410 (Note: in version 8, the watchdog time-out is configured at 5 411 seconds) 413 The Setup Response SHALL include the port number at the server for 414 the new socket, and this UDP port-pair SHALL be used for all 415 subsequent communication. The server SHALL confirm the values of: 417 o Jumbo datagram support status (modifierBitmap), 419 o Traditional MTU (modifierBitmap), 421 o Authentication mode, and 423 o Authentication time stamp 425 for the client's use on the new connection in its Setup Response, and 426 the authentication digest MUST Be Zero (MBZ). 428 Finally, the new UDP connection associated with the new socket and 429 port number is opened, and the server awaits communication there. 431 If a Test Activation Request is not subsequently received from the 432 client on this new port number before the watchdog timer expires, the 433 server SHALL close the socket and deallocate the port. 435 5.1. Setup Response Processing at the Client 437 When the client receives the Setup response from the server it first 438 checks the cmdResponse value. If this value indicates an error the 439 client SHALL display/report a relevant message to the user or 440 management process and exit. If the client receives a Command Server 441 Response code (CRSP) that is not equal to one of the codes defined 442 above, then the client MUST terminate the connection and terminate 443 operation of the current Setup Request. If the Command Server 444 Response code (CRSP) value indicates success the client SHALL compose 445 a Test Activation Request with all the test parameters it desires, 446 such as the test direction, the test duration, etc. 448 6. Test Activation Request and Response 450 This section is divided according to the sending and processing of 451 the client, server, and again at the client. 453 All messages defined in this section SHALL use UDP transport. The 454 hosts SHALL calculate and include the UDP checksum, or check the UDP 455 checksum as neccessary. 457 6.1. Test Activation Request at the client 459 Upon a successful setup, the client SHALL then send the Test 460 Activation Request to the UDP port number the server communicated in 461 the Setup Response. 463 The client SHALL compose Test Activation Request as follows: 465 uint16_t controlId; // Control ID 466 uint16_t protocolVer; // Protocol version 467 uint8_t cmdRequest; // Command request, 1 = upstream, 2 = downstream 468 uint8_t cmdResponse; // Command response (set to 0) 469 uint16_t lowThresh; // Low delay variation threshold 470 uint16_t upperThresh; // Upper delay variation threshold 471 uint16_t trialInt; // Status feedback/trial interval (ms) 472 uint16_t testIntTime; // Test interval time (sec) 473 uint8_t subIntPeriod; // Sub-interval period (sec) 474 uint8_t ipTosByte; // IP ToS byte for testing 475 uint16_t srIndexConf; // Configured sending rate index (see Note below) 476 uint8_t useOwDelVar; // Use one-way delay instead of RTT 477 uint8_t highSpeedDelta; // High-speed row adjustment delta 478 uint16_t slowAdjThresh; // Slow rate adjustment threshold 479 uint16_t seqErrThresh; // Sequence error threshold 480 uint8_t ignoreOooDup; // Ignore Out-of-Order/Duplicate datagrams 481 * uint8_t modifierBitmap; // Modifier bitmap (replaced reserved1 in v9) 482 * uint8_t rateAdjAlgo; // Rate adjust. algo. (replaced reserved2 in v9) 483 * uint8_t reserved1; // (Alignment) (replaced reserved2 in v9) 485 Control Header Test Activation Command Request Values: 486 CHTA_CREQ_NONE 0 = No Request 487 CHTA_CREQ_TESTACTUS 1 = Request test in Upstream direction (client to server, client takes the role of sending test packets) 488 CHTA_CREQ_TESTACTDS 2 = Request test in Downstream direction (server to client, client takes the role of receiving test packets) 490 modifierBitmap Code Field: Test Activation 491 CHTA_SRIDX_ISSTART 0x01 = Set when srIndexConf IS START rate for search 492 CHTA_RAND_PAYLOAD 0x02 = Set for RANDOMIZED UDP payload 494 rateAdjAlgo Values: 495 CHTA_RA_ALGO_B = 0 // 0 = Algo. B, allows Algo. expansion 496 CHTA_RA_ALGO_MIN = CHTA_RA_ALGO_B // Limit check (with Algo B only) 497 CHTA_RA_ALGO_MAX = CHTA_RA_ALGO_B // Limit check (with Algo B only) 499 Control Header Test Activation Command Response Values: 500 CHTA_CRSP_NONE 0 = Used by client when making a Request 501 CHTA_CRSP_ACKOK 1 = Used by Server in affirmative Response 502 CHTA_CRSP_BADPARAM 2 = Used by Server to indicate an error; bad parameter; reject; 504 Note: uint16_t srIndexConf is the table index of the configured fixed 505 or starting send rate (depending on whether CHTA_SRIDX_ISSTART is 506 cleared or set respectively). 508 The server MAY allow the client to specify any fixed or starting send 509 rate. 511 Otherwise, the server MAY enforce a maximum of the fixed or starting 512 send rate which the client can successfully request. If the client's 513 Test Activation Request exceeds the server's configured maximum, the 514 server MUST either reject the request, or coerce the value to the 515 configured maximum, and communicate that maximum to the client in the 516 Test Activation Response. The client can of course choose to end the 517 test, as appropriate. 519 The UDP PDU format of the Test Activation Request is as follows (big- 520 endian AB): 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | controlId | protocolVer | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | cmdRequest | cmdResponse | lowThresh | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | upperThresh | trialInt | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | testIntTime | subIntPeriod | ipTosByte | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | srIndexConf | useOwDelVar |highSpeedDelta | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | slowAdjThresh | seqErrThresh | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | ignoreOooDup |modifierBitmap | rateAdjAlgo | reserved1 | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Note: This is only 28 octets of the 56 octet PDU sent, the rest are MBZ 540 for a Test Activation Request. 542 The client SHALL use the configuration for 544 o Jumbo datagram support status, 546 o Traditional MTU, 548 o Authentication mode, and 550 o Authentication time stamp 552 requested in the Setup Request and confirmed by the server in the 553 Setup Response. 555 6.2. Test Activation Response 557 After the server receives the Test Activation Request on the new 558 connection, it MUST choose to accept, ignore or modify any of the 559 test parameters. 561 When the server sends the Test Activation Response, it SHALL set the 562 cmd Response field to: 564 uint8_t cmdResponse;// Command response (set to 1, ACK, or 2 error) 566 The server SHALL repeat all test parameters to indicate changes to 567 the client. 569 If the client has requested an upstream test, the server SHALL 571 o include the transmission parameters from the first row of the 572 sending rate table in the Sending Rate Structure (defined below), 573 OR 575 o use the parameters from the configured send rate index 576 (srIndexConf) of the sending rate table, or starting rate index 577 (indicated in the Test Activation modifierBitmap) when these 578 options are present. 580 The remaining 28 octets of the Test Activation Response (normally 581 read from the first row of the sending rate table) are called the 582 Sending Rate Structure, and SHALL be organized as follows: 584 uint32_t txInterval1; // Transmit interval (us) 585 uint32_t udpPayload1; // UDP payload (bytes) 586 uint32_t burstSize1; // UDP burst size per interval 587 uint32_t txInterval2; // Transmit interval (us) 588 uint32_t udpPayload2; // UDP payload (bytes) 589 uint32_t burstSize2; // UDP burst size per interval 590 uint32_t udpAddon2; // UDP add-on (bytes) 592 with 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | txInterval1 | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | udpPayload1 | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | burstSize1 | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | txInterval2 | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | udpPayload2 | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | burstSize2 | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | udpAdddon2 | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Note that the server additionally has the option of completely 611 rejecting the request and sending back an appropriate command 612 response value: 614 uint8_t cmdResponse; // Command response (set to 2, error) 616 If activation continues, the new connection is prepared for an 617 upstream OR downstream test. 619 In the case of a downstream test, the server SHALL prepare to send 620 with either a single timer to send status PDUs at the specified 621 interval OR dual timers to send load PDUs based on 623 o the transmission parameters from the first row of the sending rate 624 table in the Sending Rate Structure, OR 626 o the transmission parameters of the configured send rate index 627 (srIndexConf) of the sending rate table, or starting rate index 628 (indicated in the Test Activation modifierBitmap) when these 629 options are present. 631 The server SHALL then send a Test Activation Response back to the 632 client, update the watchdog timer with a new time-out value, and set 633 a test duration timer to eventually stop the test. 635 The new connection is now ready for testing. 637 6.3. Test Activation Response action at the client 639 When the client receives the Test Activation Response, it first 640 checks the command response value. 642 If the client receives a Test Activation Command Response value that 643 indicates an error, the client SHALL display/report a relevant 644 message to the user or management process and exit. 646 If the client receives a Test Activation Command Response value that 647 is not equal to one of the codes defined above, then the client MUST 648 terminate the connection and terminate operation of the current Setup 649 Request. 651 If the client receives a Test Activation Command Response value that 652 indicates success (CHTA_CRSP_ACKOK) the client SHALL update its 653 configuration to use any test parameters modified by the server. 655 Next, the client SHALL prepare its connection for either an upstream 656 test with dual timers set to send load PDUs (based on the starting 657 transmission parameters sent by the server), OR a downstream test 658 with a single timer to send status PDUs at the specified interval. 660 Then, the client SHALL stop the test initiation timer, set a new 661 time-out value for the watchdog timer, and start the timer (in case 662 the server goes quiet). 664 The connection is now ready for testing. 666 7. Test Stream Transmission and Measurement Feedback Messages 668 This section describes the testing phase of the protocol. The roles 669 of sender and receiver vary depending whether the direction of 670 testing is from server to client, or the reverse. 672 All messages defined in this section SHALL use UDP transport. The 673 hosts SHALL calculate and include the UDP checksum, or check the 674 received UDP checksum before further processing, as neccessary. 676 7.1. Test Packet PDU and Roles 678 Testing proceeds with one end point sending load PDUs, based on 679 transmission parameters from the sending rate table, and the other 680 end point receiving the load PDUs and sending status messages to 681 communicate the traffic conditions at the receiver. 683 The watchdog timer at the receiver SHALL be reset each time a test 684 PDU is received. See non-graceful test stop in Section 8 for 685 handling the watchdog/NOTRAFFIC time-out expiration at each end- 686 point. 688 When the server is sending Load PDUs in the role of sender, it SHALL 689 use the transmission parameters directly from the sending rate table 690 via the index that is currently selected (which was based on the 691 feedback in its received status messages). 693 However, when the client is sending load PDUs in the role of sender, 694 it SHALL use the discreet transmission parameters that were 695 communicated by the server in its periodic status messages (and not 696 referencing a sending rate table). This approach allows the server 697 to control the individual sending rates as well as the algorithm used 698 to decide when and how to adjust the rate. 700 The server uses a load adjustment algorithm which evaluates 701 measurements, either it's own or the contents of received feedback 702 messages. This algorithm is unique to udpst; it provides the ability 703 to search for the Maximum IP Capacity that is absent from other 704 testing tools. Although the algorithm depends on the protocol, it is 705 not part of the protocol per se. 707 The current algorithm (B) has three paths to its decision on the next 708 sending rate: 710 1. When there are no impairments present (no sequence errors, low 711 delay variation), resulting in sending rate increase. 713 2. When there are low impairments present (no sequence errors but 714 higher levels of delay variation), so the same sending rate is 715 retained. 717 3. When the impairment levels are above the thresholds set for this 718 purpose and "congestion" is inferred, resulting in sending rate 719 decrease. 721 The algorithm also has two modes for increasing/decreasing the 722 sending rate: 724 o A high-speed mode to achieve high sending rates quickly, but also 725 back-off quickly when "congestion" is inferred from the 726 measurements. Any two consecutive feedback intervals that have a 727 sequence number anomaly and/or contain an upper delay variation 728 threshold exception in both of the two consecutive intervals, 729 count as the two consecutive feedback measurements required to 730 declare "congestion" within a test. 732 o A single-step mode where all rate adjustments use the minimum 733 increase or decrease of one step in the sending rate table. The 734 single step mode continues after the first inference of 735 "congestion" from measured impairments. 737 On the other hand, the test configuration MAY use a fixed sending 738 rate requested by the client, using the field below: 740 uint16_t srIndexConf; // Configured sending rate index 742 The client MAY communicate the desired fixed rate in its activation 743 request. The reasons to conduct a fixed-rate test include stable 744 measurement at the maximum determined by the load adjustment (search) 745 algorithm, or the desire to test at a known subscribed rate without 746 searching. 748 The Load PDU SHALL have the following format and field definitions: 750 uint16_t loadId; // Load ID (=0xBEEF for the LOad PDU) 751 uint8_t testAction; // Test action (= 0x00 normally, until test stop) 752 uint8_t rxStopped; // Receive traffic stopped indicator (BOOL) 753 uint32_t lpduSeqNo; // Load PDU sequence number (starts at 1) 754 uint16_t udpPayload; // UDP payload LENGTH(bytes) 755 uint16_t spduSeqErr; // Status PDU sequence error count 756 // 757 uint32_t spduTime_sec; // Send time in last received status PDU 758 uint32_t spduTime_nsec; // Send time in last received status PDU 759 uint32_t lpduTime_sec; // Send time of this load PDU 760 uint32_t lpduTime_nsec; // Send time of this load PDU 762 Test Action Codes 763 TEST_ACT_TEST 0 // normal 764 TEST_ACT_STOP1 1 // normal stop at end of test: server sends in STATUS or Test PDU 765 TEST_ACT_STOP2 2 // ACK of STOP1: sent by client in STATUS or Test PDU 767 The Test Load UDP PDU format is as follows (big-endian AB): 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | loadId | testAction | rxStopped | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | lpduSeqNo | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | udpPayload | spduSeqErr | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | spduTime_sec | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | spduTime_nsec | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | lpduTime_sec | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | lpduTime_nsec | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 . MBZ = udpPayload - 28 octets . 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 . . 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 . . 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 . . 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 . . 796 7.2. Status PDU 798 The receiver SHALL send a Status PDU to the sender during a test at 799 the configured feedback interval. 801 The watchdog timer at the test PDU sender SHALL be reset each time a 802 Status PDU is received. See non-graceful test stop in Section 8 for 803 handling the watchdog/NOTRAFFIC time-out expiration at each end- 804 point. 806 @@@@ To Do: What protections from bit errors (checksum) or on-path 807 attacks (something stronger) are warrented for teh Status PDUs? 808 These PDUs are a key part of the server-client control loop. Added a 809 requirement to calculate and include/check the UDP checksum. 811 The Status Header PDU SHALL have the following format and field 812 definitions: 814 // Status feedback header for UDP payload of status PDUs 815 // 817 uint16_t statusId; // Status ID = 0xFEED 818 uint8_t testAction; // Test action 819 uint8_t rxStopped; // Receive traffic stopped indicator (BOOL) 820 uint32_t spduSeqNo; // Status PDU sequence number (starts at 1) 821 // 822 struct sendingRate srStruct; // Sending Rate Structure (28 octets) 823 // 824 uint32_t subIntSeqNo; // Sub-interval sequence number 825 struct subIntStats sisSav; // Sub-interval Saved Stats Structure (52 octets) 826 // 827 uint32_t seqErrLoss; // Loss sum 828 uint32_t seqErrOoo; // Out-of-Order sum 829 uint32_t seqErrDup; // Duplicate sum 830 // 831 uint32_t clockDeltaMin; // Clock delta minimum (either RTT or 1-way delay) 832 uint32_t delayVarMin; // Delay variation minimum 833 uint32_t delayVarMax; // Delay variation maximum 834 uint32_t delayVarSum; // Delay variation sum 835 uint32_t delayVarCnt; // Delay variation count 836 uint32_t rttMinimum; // Minimum round-trip time sampled 837 uint32_t rttSample; // Last round-trip time sample 838 uint8_t delayMinUpd; // Delay minimum(s) updated observed, communicated in both directions. 839 uint8_t reserved2; // (alignment) 840 uint16_t reserved3; // (alignment) 841 // 842 uint32_t tiDeltaTime; // Trial interval delta time 843 uint32_t tiRxDatagrams; // Trial interval receive datagrams 844 uint32_t tiRxBytes; // Trial interval receive bytes 845 // 846 uint32_t spduTime_sec; // Send time of this status PDU 847 uint32_t spduTime_nsec; // Send time of this status PDU 849 The Status feedback UDP payload PDUs format is as follows (big-endian 850 AB): 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | statusId | testAction | rxStopped | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | spduSeqNo | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 . Sending Rate Structure (28 octets) . 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | subIntSeqNo | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 . Sub-interval Saved Stats Structure (52 octets) . 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | seqErrLoss | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | seqErrOoo | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | seqErrDup | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | clockDeltaMin | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | delayVarMin | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | delayVarMax | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | delayVarSum | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | delayVarCnt | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | rttMinimum | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | rttSample | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | delayMinUpd | reserved2 | reserved3 | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | tiDeltaTime | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | tiRxDatagrams | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | tiRxBytes | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | spduTime_sec | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | spduTime_nsec | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 Note that the Sending Rate Structure (28 octets) is defined in the 899 Test Activation section. 901 Also note that the Sub-interval Saved Stats Structure (52 octets) 902 SHALL be included (and populated as required when the server is in 903 the receiver role) as defined below. 905 The Sub-interval saved statistics structure for received traffic 906 measurements SHALL be organized and formatted as follows: 908 uint32_t rxDatagrams; // Received datagrams 909 uint32_t rxBytes; // Received bytes 910 uint32_t deltaTime; // Time delta 911 uint32_t seqErrLoss; // Loss sum 912 uint32_t seqErrOoo; // Out-of-Order sum 913 uint32_t seqErrDup; // Duplicate sum 914 uint32_t delayVarMin; // Delay variation minimum 915 uint32_t delayVarMax; // Delay variation maximum 916 uint32_t delayVarSum; // Delay variation sum 917 uint32_t delayVarCnt; // Delay variation count 918 uint32_t rttMinimum; // Minimum round-trip time 919 uint32_t rttMaximum; // Maximum round-trip time 920 uint32_t accumTime; // Accumulated time 921 ---------------------------------------------------------------------------- 923 0 1 2 3 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | rxDatagrams | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | rxBytes | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | deltaTime | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | seqErrLoss | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | seqErrOoo | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | seqErrDup | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | delayVarMin | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | delayVarMax | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | delayVarSum | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | delayVarCnt | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | rttMinimum | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | rttMaximum | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | accumTime | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Note that the 52 octet saved statistics structure above has slight 954 differences from the 40 octets that follow in the status feedback 955 PDU, particularly the time-related fields. 957 Upon receiving the Status Feedback PDU or expiration of the feedback 958 interval, the server SHALL perform calculations required by the Load 959 adjustment algorithm and adjust its sending rate, or signal that the 960 client do so in its role as as sender. 962 @@@@ To Do: Additional measurements, like interface byte counters 963 from a client at a residential gateway, would change the Status 964 Feedback PDU (and the protocol version number as a result). 965 Interface byte counters seem useful for specific circumstances, such 966 as when the client application has acces to an interface that sees 967 all traffic to/from a service subscriber's location. 969 8. Stopping the Test 971 When the test duration timer on the server expires, it SHALL set the 972 connection test action to STOP and mark all outgoing load or status 973 PDUs with a test action of STOP1. 975 uint8_t testAction; // Test action (server sets STOP1) 977 This is simply a non-reversible state for all future messages sent 978 from the server. 980 When the client receives a load or status PDU with the STOP1 981 indication, it SHALL finalize testing, display the test results, and 982 also mark its connection with a test action of STOP (so that any PDUs 983 received subsequent to the STOP1 are ignored). 985 With the test action of the client's connection set to STOP, the very 986 next expiry of a send timer for either a load or status PDU SHALL 987 cause the client to schedule an immediate end time to exit. 989 The client SHALL then send all subsequent load or status PDUs with a 990 test action of STOP2 992 uint8_t testAction; // Test action (client sets STOP2) 994 as confirmation to the server, and a graceful termination of the test 995 can begin. 997 When the server receives the STOP2 confirmation in the load or status 998 PDU, the server SHALL schedule an immediate end time for the 999 connection which closes the socket and deallocates it. 1001 In a non-graceful test stop, the watchdog/NOTRAFFIC time-outs at each 1002 end-point will expire (sometimes at one end-point first), 1003 notifications in logs, STDOUT, and/or formateed output SHALL be made, 1004 and the test action of each end-point's connection SHALL be set to 1005 STOP. 1007 9. Method of Measurement 1009 The architecture of the method REQUIRES two cooperating hosts 1010 operating in the roles of Src (test packet sender) and Dst 1011 (receiver), with a measured path and return path between them. 1013 The duration of a test duration, parameter I, MUST be constrained in 1014 a production network, since this is an active test method and it will 1015 likely cause congestion on the Src to Dst host path during a test. 1017 9.1. Running Code 1019 This section is for the benefit of the Document Shepherd's form, and 1020 will be deleted prior to final review. 1022 Much of the development of the method and comparisons with existing 1023 methods conducted at IETF Hackathons and elsewhere have been based on 1024 the example udpst Linux measurement tool (which is a working 1025 reference for further development) [udpst]. The current project: 1027 o is a utility that can function as a client or server daemon 1029 o requires a successful client-initiated setup handshake between 1030 cooperating hosts and allows firewalls to control inbound 1031 unsolicited UDP which either go to a control port [expected and w/ 1032 authentication] or to ephemeral ports that are only created as 1033 needed. Firewalls protecting each host can both continue to do 1034 their job normally. This aspect is similar to many other test 1035 utilities available. 1037 o is written in C, and built with gcc (release 9.3) and its standard 1038 run-time libraries 1040 o allows configuration of most of the parameters described in 1041 Sections 4 and 7. 1043 o supports IPv4 and IPv6 address families. 1045 o supports IP-layer packet marking. 1047 10. Security Considerations 1049 Active metrics and measurements have a long history of security 1050 considerations. The security considerations that apply to any active 1051 measurement of live paths are relevant here. See [RFC4656] and 1052 [RFC5357]. 1054 When considering privacy of those involved in measurement or those 1055 whose traffic is measured, the sensitive information available to 1056 potential observers is greatly reduced when using active techniques 1057 which are within this scope of work. Passive observations of user 1058 traffic for measurement purposes raise many privacy issues. We refer 1059 the reader to the privacy considerations described in the Large Scale 1060 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 1061 which covers active and passive techniques. 1063 There are some new considerations for Capacity measurement as 1064 described in this memo. 1066 1. Cooperating source and destination hosts and agreements to test 1067 the path between the hosts are REQUIRED. Hosts perform in either 1068 the Src or Dst roles. 1070 2. It is REQUIRED to have a user client-initiated setup handshake 1071 between cooperating hosts that allows firewalls to control 1072 inbound unsolicited UDP traffic which either goes to a control 1073 port [expected and w/authentication] or to ephemeral ports that 1074 are only created as needed. Firewalls protecting each host can 1075 both continue to do their job normally. 1077 3. Client-server authentication and integrity protection for 1078 feedback messages conveying measurements is RECOMMENDED. To 1079 accomodate different host limitations and testing circumstances, 1080 different modes of operation are recommended: 1082 WG ver 01 proposal below: 1084 A. Unauthenticated mode (for all phases) 1085 AND 1086 B. OPTIONAL Authenticated set-up only 1087 SHA-256 HMAC time-window verification (5 min time stamp verification) 1088 (could add silent failure option) 1090 -=-=-=-=-=-=-=-=-=- Above options exist in Running Code -=-=-=-=-=- 1092 C. Encrypted Setup Exchange in a tunnel to well-known port: 1093 (remaining transmissions are on a new UDP port-pair, in the clear) 1095 D. Encrypt "all the things" 1096 (Reduce the options, provide the required protocol protection) 1098 Pre-WG 00 proposal below: 1100 A. Unauthenticated mode (for all phases) 1101 AND 1102 B. OPTIONAL Authenticated set-up only 1103 SHA-256 HMAC time-window verification (5 min time stamp verification) 1104 (could add silent failure option) 1106 -=-=-=-=-=-=-=-=-=-Above options exist in Running Code -=-=-=-=-=- 1108 C. Encrypted setup and test-activation 1109 (currently using OpenSSL Library, so KISS, but may be too slow for 1110 test packets) 1112 -=-=-=-=--=- Old/lowpower host performance impacts -=-=-=-=-=-=- 1114 D. Encrypted feedback messages (maybe split into Integrity and encrypt?) 1116 E. Integrity protection for test packets SHA-256 HMAC 1118 F. Encrypted test packets (maybe also valuable to defeat compression on links) 1120 4. Hosts MUST limit the number of simultaneous tests to avoid 1121 resource exhaustion and inaccurate results. 1123 5. Senders MUST be rate-limited. This can be accomplished using a 1124 pre-built table defining all the offered load rates that will be 1125 supported (Section 8.1). The recommended load-control search 1126 algorithm results in "ramp up" from the lowest rate in the table. 1128 6. Service subscribers with limited data volumes who conduct 1129 extensive capacity testing might experience the effects of 1130 Service Provider controls on their service. Testing with the 1131 Service Provider's measurement hosts SHOULD be limited in 1132 frequency and/or overall volume of test traffic (for example, the 1133 range of I duration values SHOULD be limited). 1135 The exact specification of these features was hopefully accomplished 1136 during this protocol development. 1138 11. IANA Considerations 1140 This memo requests IANA to assign a UDP port. 1142 12. Acknowledgments 1144 Thanks to Ruediger Geib, Lincoln Lavoie, Can Desem, and Greg Mirsky 1145 for reviewing this draft and providing helpful suggestions and areas 1146 for further development. Ken Kerpez and Chen Li have provided 1147 helpful reviews. 1149 13. References 1151 13.1. Normative References 1153 [I-D.ietf-ippm-capacity-metric-method] 1154 Morton, A., Geib, R., and L. Ciavattone, "Metrics and 1155 Methods for One-Way IP Capacity", draft-ietf-ippm- 1156 capacity-metric-method-12 (work in progress), June 2021. 1158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1159 Requirement Levels", BCP 14, RFC 2119, 1160 DOI 10.17487/RFC2119, March 1997, 1161 . 1163 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1164 "Framework for IP Performance Metrics", RFC 2330, 1165 DOI 10.17487/RFC2330, May 1998, 1166 . 1168 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1169 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1170 September 1999, . 1172 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1173 for Equal Cost Multipath Routing and Link Aggregation in 1174 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1175 . 1177 [RFC7497] Morton, A., "Rate Measurement Test Protocol Problem 1178 Statement and Requirements", RFC 7497, 1179 DOI 10.17487/RFC7497, April 2015, 1180 . 1182 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1183 Ed., "A One-Way Loss Metric for IP Performance Metrics 1184 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1185 2016, . 1187 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1188 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1189 May 2017, . 1191 [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. 1192 Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for 1193 the IP Performance Metrics (IPPM) Framework", RFC 8468, 1194 DOI 10.17487/RFC8468, November 2018, 1195 . 1197 [RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and 1198 Methods for One-Way IP Capacity", RFC 9097, 1199 DOI 10.17487/RFC9097, November 2021, 1200 . 1202 13.2. Informative References 1204 [copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet, 1205 "copycat: Testing Differential Treatment of New Transport 1206 Protocols in the Wild (ANRW '17)", July 2017, 1207 . 1209 [LS-SG12-A] 1210 12, I. S., "LS - Harmonization of IP Capacity and Latency 1211 Parameters: Revision of Draft Rec. Y.1540 on IP packet 1212 transfer performance parameters and New Annex A with Lab 1213 Evaluation Plan", May 2019, 1214 . 1216 [LS-SG12-B] 1217 12, I. S., "LS on harmonization of IP Capacity and Latency 1218 Parameters: Consent of Draft Rec. Y.1540 on IP packet 1219 transfer performance parameters and New Annex A with Lab & 1220 Field Evaluation Plans", March 2019, 1221 . 1223 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1224 Network Interconnect Devices", RFC 2544, 1225 DOI 10.17487/RFC2544, March 1999, 1226 . 1228 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 1229 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 1230 DOI 10.17487/RFC3148, July 2001, 1231 . 1233 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1234 Zekauskas, "A One-way Active Measurement Protocol 1235 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 1236 . 1238 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 1239 RFC 5136, DOI 10.17487/RFC5136, February 2008, 1240 . 1242 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1243 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1244 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1245 . 1247 [RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, 1248 "Applicability Statement for RFC 2544: Use on Production 1249 Networks Considered Harmful", RFC 6815, 1250 DOI 10.17487/RFC6815, November 2012, 1251 . 1253 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 1254 Framework for IP Performance Metrics (IPPM)", RFC 7312, 1255 DOI 10.17487/RFC7312, August 2014, 1256 . 1258 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1259 Aitken, P., and A. Akhter, "A Framework for Large-Scale 1260 Measurement of Broadband Performance (LMAP)", RFC 7594, 1261 DOI 10.17487/RFC7594, September 2015, 1262 . 1264 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1265 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1266 May 2016, . 1268 [RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk 1269 Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March 1270 2018, . 1272 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 1273 Two-Way Active Measurement Protocol", RFC 8762, 1274 DOI 10.17487/RFC8762, March 2020, 1275 . 1277 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 1278 and E. Ruffini, "Simple Two-Way Active Measurement 1279 Protocol Optional Extensions", RFC 8972, 1280 DOI 10.17487/RFC8972, January 2021, 1281 . 1283 [TR-471] Morton, A., "Broadband Forum TR-471: IP Layer Capacity 1284 Metrics and Measurement", July 2020, 1285 . 1288 [udpst] udpst Project Collaborators, "UDP Speed Test Open 1289 Broadband project", December 2020, 1290 . 1292 [Y.1540] Y.1540, I. R., "Internet protocol data communication 1293 service - IP packet transfer and availability performance 1294 parameters", December 2019, 1295 . 1297 [Y.Sup60] Morton, A., "Recommendation Y.Sup60, (09/20) Interpreting 1298 ITU-T Y.1540 maximum IP-layer capacity measurements", 1299 September 2020, 1300 . 1302 Authors' Addresses 1304 Len Ciavattone 1305 AT&T Labs 1306 200 Laurel Avenue South 1307 Middletown,, NJ 07748 1308 USA 1310 Email: lencia@att.com 1311 Al Morton 1312 AT&T Labs 1313 Chicago,, IL 60660 1314 USA 1316 Phone: +1 732 420 1571 1317 Email: acmorton@att.com