idnits 2.17.1 draft-morton-ippm-capacity-metric-protocol-02.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 26 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 (October 25, 2021) is 913 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 1157, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'RFC8468' is defined on line 1185, but no explicit reference was found in the text == Unused Reference: 'LS-SG12-A' is defined on line 1198, but no explicit reference was found in the text == Unused Reference: 'LS-SG12-B' is defined on line 1205, but no explicit reference was found in the text == Unused Reference: 'RFC2544' is defined on line 1212, but no explicit reference was found in the text == Unused Reference: 'RFC5136' is defined on line 1227, but no explicit reference was found in the text == Unused Reference: 'RFC6815' is defined on line 1236, but no explicit reference was found in the text == Unused Reference: 'RFC7312' is defined on line 1242, but no explicit reference was found in the text == Unused Reference: 'RFC7799' is defined on line 1253, but no explicit reference was found in the text == Unused Reference: 'RFC8972' is defined on line 1266, but no explicit reference was found in the text == Unused Reference: 'TR-471' is defined on line 1272, but no explicit reference was found in the text ** 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 (~~), 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: April 28, 2022 October 25, 2021 7 Test Protocol for One-way IP Capacity Measurement 8 draft-morton-ippm-capacity-metric-protocol-02 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 April 28, 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 . . . . . . . . . . . . . . . . . . . . . . 4 60 4. General Parameters and Definitions . . . . . . . . . . . . . 5 61 5. Setup Request and Response Exchange . . . . . . . . . . . . . 7 62 5.1. Setup Response Processing at the Client . . . . . . . . . 11 63 6. Test Activation Request and Response . . . . . . . . . . . . 11 64 6.1. Test Activation Request at the client . . . . . . . . . . 11 65 6.2. Test Activation Request - server response . . . . . . . . 13 66 6.3. Test Activation Response action at the client . . . . . . 15 67 7. Test Stream Transmission and Measurement Feedback Messages . 15 68 7.1. Test Packet PDU and Roles . . . . . . . . . . . . . . . . 15 69 7.2. Status PDU . . . . . . . . . . . . . . . . . . . . . . . 18 70 8. Stopping the Test . . . . . . . . . . . . . . . . . . . . . . 23 71 9. Method of Measurement . . . . . . . . . . . . . . . . . . . . 24 72 9.1. Running Code . . . . . . . . . . . . . . . . . . . . . . 24 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 75 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 77 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 78 13.2. Informative References . . . . . . . . . . . . . . . . . 28 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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 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 -02 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) as well as the hostname or IP address 169 of the server in order to begin the setup and configuration exchanges 170 with the server. 172 The protocol uses UDP transport and has four phases: 174 1. Setup Request and Response Exchange: The client requests to begin 175 a test by communicating its protocol version, intended security 176 mode, and jumbo datagram support. The server either confirms 177 matching configuration or rejects the connection. The server 178 also communicates the ephemeral port for further communication 179 when accepting the client's request. 181 2. Test Activation Request and Response: the client composes a 182 request conveying parameters such as the testing direction, the 183 duration of the test interval and test sub-intervals, and various 184 thresholds. The server then chooses to accept, ignore or modify 185 any of the test parameters, and communicates the set that will be 186 used unless the client rejects the modifications. Note that the 187 client assumes that the Test Activation exchange has opened any 188 co-located firewalls and network address/port translators for the 189 test connection (in response to the Request packet on the 190 ephemeral port) and the traffic that follows. If the Test 191 Activation is rejected or fails, the client assumes that the 192 firewall will close the address/port combination after the 193 firewall's configured idle traffic time-out. 195 3. Test Stream Transmission and Measurement Feedback Messages: 196 Testing proceeds with one end-point sending load PDUs and the 197 other end-point receiving the load PDUs and sending frequent 198 status messages to communicate status and transmission conditions 199 there. The feedback messsages are input to a load-control 200 algorithm at the server, which controls future sending rates at 201 either end-point as needed. The choice to locate the load- 202 control algorithm at the server, regardlesss of transmiision 203 direction, means that the algorithm can be updated more easily at 204 a host within the network, and at a fewer number of hosts than 205 the number of clients. 207 4. Stopping the Test: The server initiates the phase to stop the 208 test by setting the STOP1 indication in load PDUs or sstatus 209 feedback messages. The client acknowledges by setting the STOP2 210 in further load PDUs or messages, and a graceful connection 211 termination at each end-point follows. (Since the load PDUs and 212 feedback messages are used, this phase is kind of a sub-phase of 213 3.) If the Test traffic stops or the communication path fails, 214 the client assumes that the firewall will close the address/port 215 combination after the firewall's configured idle traffic time- 216 out. 218 4. General Parameters and Definitions 220 This section lists the REQUIRED input factors to specify a Sender or 221 Receiver metric. 223 o Src, the address of a host (such as the globally routable IP 224 address). 226 o Dst, the address of a host (such as the globally routable IP 227 address). 229 o MaxHops, the limit on the number of Hops a specific packet may 230 visit as it traverses from the host at Src to the host at Dst 231 (implemented in the TTL or Hop Limit). 233 o T0, the time at the start of measurement interval, when packets 234 are first transmitted from the Source. 236 o I, the nominal duration of a measurement interval at the 237 destination (default 10 sec) 239 o dt, the nominal duration of m equal sub-intervals in I at the 240 destination (default 1 sec) 242 o dtn, the beginning boundary of a specific sub-interval, n, one of 243 m sub-intervals in I 245 o FT, the feedback time interval between status feedback messages 246 communicating measurement results, sent from the receiver to 247 control the sender. The results are evaluated to determine how to 248 adjust the current offered load rate at the sender (default 50ms) 250 o Tmax, a maximum waiting time for test packets to arrive at the 251 destination, set sufficiently long to disambiguate packets with 252 long delays from packets that are discarded (lost), such that the 253 distribution of one-way delay is not truncated. 255 o F, the number of different flows synthesized by the method 256 (default 1 flow) 258 o flow, the stream of packets with the same n-tuple of designated 259 header fields that (when held constant) result in identical 260 treatment in a multi-path decision (such as the decision taken in 261 load balancing). Note: The IPv6 flow label MAY be included in the 262 flow definition when routers have complied with [RFC6438] 263 guidelines. 265 o Type-P, the complete description of the test packets for which 266 this assessment applies (including the flow-defining fields). 267 Note that the UDP transport layer is one requirement for test 268 packets specified below. Type-P is a parallel concept to 269 "population of interest" defined in clause 6.1.1 of[Y.1540]. 271 o PM, a list of fundamental metrics, such as loss, delay, and 272 reordering, and corresponding target performance threshold. At 273 least one fundamental metric and target performance threshold MUST 274 be supplied (such as One-way IP Packet Loss [RFC7680] equal to 275 zero). 277 A non-Parameter which is required for several metrics is defined 278 below: 280 o T, the host time of the *first* test packet's *arrival* as 281 measured at the destination Measurement Point, or MP(Dst). There 282 may be other packets sent between source and destination hosts 283 that are excluded, so this is the time of arrival of the first 284 packet used for measurement of the metric. 286 Note that time stamp format and resolution, sequence numbers, etc. 287 will be established by this memo. 289 5. Setup Request and Response Exchange 291 All messages defined in this section SHALL use UDP transport. The 292 hosts SHALL calculate and include the UDP checksum, or check the UDP 293 checksum as neccessary. 295 The client SHALL begin the Control protocol connection by sending a 296 Setup Request message to the server's control port. 298 The client SHALL simultaneously start a test initiation timer so that 299 if the control protocol fails to complete all exchanges in the 300 allocated time, the client software SHALL exit (close the UDP socket 301 and indicate an error message to the user). 303 (Note: in version 8, the watchdog time-out is configured, in udpst.h, 304 as #define WARNING_NOTRAFFIC 1 // Receive traffic stopped warning 305 threshold (sec) #define TIMEOUT_NOTRAFFIC (WARNING_NOTRAFFIC + 4) or 306 5 seconds) 308 The Setup Request message PDU SHALL be organized as follows: 310 uint16_t controlId; // Control ID = 0xACE1 311 uint16_t protocolVer; // Protocol version = 0x08 312 uint8_t cmdRequest; // Command request = 1 (request) 313 uint8_t cmdResponse; // Command response = 0 314 uint16_t reserved1; // Reserved (alignment) 315 uint16_t testPort; // Test port on server (=0 for Request) 316 uint8_t jumboStatus; // Jumbo datagram support status (BOOL) 317 uint8_t authMode; // Authentication mode 318 uint32_t authUnixTime;// Authentication time stamp 319 unsigned char authDigest[AUTH_DIGEST_LENGTH] // SHA256_DIGEST_LENGTH = 32 oct 321 The UDP PDU format layout SHALL be as follows (big-endian AB): 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | controlId | protocolVer | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | cmdRequest | cmdResponse | reserved1 | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | testPort | jumboStatus | authMode | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | authUnixTime | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | | 335 | | 336 | | 337 | | 338 | authDigest[AUTH_DIGEST_LENGTH](256 bits) | 339 | | 340 | | 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 When the server receives the Setup Request it SHALL validate the 345 request by checking the protocol version, the jumbo datagram support 346 indicator, and the authentication data if utilized. If the client 347 has selected options for: 349 o Jumbo datagram support status (BOOL), 351 o Authentication mode, and 353 o Authentication time stamp 355 that do not match the server configuration, the server MUST reject 356 the Setup Request. 358 (Note: in version 8, the watchdog time is configured, in udpst.h, as 359 #define WARNING_NOTRAFFIC 1 // Receive traffic stopped warning 360 threshold (sec) #define TIMEOUT_NOTRAFFIC (WARNING_NOTRAFFIC + 4) or 361 5 seconds) 363 If the Setup Request must be rejected (due to any of the reasons in 364 the Command response codes listed below), a Setup Response SHALL be 365 sent back to the client with a corresponding command response value 366 indicating the reason for the rejection. 368 uint16_t controlId; // Control ID = 0xACE1 369 uint16_t protocolVer; // Protocol version = 0x08 370 uint8_t cmdRequest; // Command request = 2 (reply) 371 uint8_t cmdResponse; // Command response = 372 uint16_t reserved1; // Reserved (alignment) 373 uint16_t testPort; // Test port on server (available port in Response) 374 uint8_t jumboStatus; // Jumbo datagram support status (BOOL) 375 uint8_t authMode; // Authentication mode 376 uint32_t authUnixTime;// Authentication time stamp 377 unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets, MBZ 379 Command Response Codes 380 Control Header Setup Request Code CHSR_CRSP_NONE 0 = None 381 Control Header Setup Request Code CHSR_CRSP_ACKOK 1 = Acknowledgement 382 Control Header Setup Request Code CHSR_CRSP_BADVER 2 = Bad Protocol Version 383 Control Header Setup Request Code CHSR_CRSP_BADJS 3 = Invalid Jumbo datagram option 384 Control Header Setup Request Code CHSR_CRSP_AUTHNC 4 = Unexpected Authentication in Setup Request 385 Control Header Setup Request Code CHSR_CRSP_AUTHREQ 5 = Authentication missing in Setup Request 386 Control Header Setup Request Code CHSR_CRSP_AUTHINV 6 = Invalid authentication method 387 Control Header Setup Request Code CHSR_CRSP_AUTHFAIL 7 = Authentication failure 388 Control Header Setup Request Code CHSR_CRSP_AUTHTIME 8 = Authentication time is invalid in Setup Request 390 @@@@ To Do: How do we communicate multiple errors when the server 391 sends the Setup Response? Is an error hierarchy possible, where Bad 392 Protocol Version means that none of the other aspects (higher error 393 numbers) were checked? New text to address this issue appears below: 395 There is a hierarchy of Command Response codes, beginning with: "2 = 396 Bad Protocol Version", which SHALL be checked first because it is a 397 fixed field length and the most reliable check. The server SHOULD 398 communicate the first error condition detected in the order listed 399 below: 401 3 = Invalid Jumbo datagram option 402 5 = Authentication missing in Setup Request 403 4 = Unexpected Authentication in Setup Request 404 6 = Invalid authentication method (SHA-256 not used) 405 7 = Authentication failure (both shared secret and time) 406 8 = Authentication time is invalid in Setup Request (replay attack) 408 The only circumstance when a server would not communicate the 409 appropriate Command Response Code for an error condition above is 410 when an attack has been detected, in which case the server will allow 411 setup attempts with errors to terminate silently. 413 @@@@ Or, if multiple error codes are wanted, would a flag system work 414 better? For an expanded field multiple error codes, we could use 415 decimal values that set 1 bit in the cmdResponse (0,1,2,4,8,...) for 416 each code, and expand the cmdResponse field to 16 bits by using the 417 nearby reserved field as shown below (and moving the fields within 418 the 32-bit word): 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | controlId | protocolVer | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | reserved1 | cmdRequest | cmdResponse | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 @@@@ - end text for discussion - 430 If the server finds that the Setup Request matches its configuration 431 and is otherwise acceptable, the server SHALL initiate a new 432 connection for the client, using a new UDP socket allocated from the 433 UDP ephemeral port range. Then, the server SHALL start a watchdog 434 timer (to terminate the connection in case the client goes silent), 435 and sends the Setup Response back to the client (see below for 436 composition). 438 If the Setup Request is accepted by the server, a Setup Response 439 SHALL be sent back to the client with a corresponding command 440 response value indicating 1 = Acknowledgement. 442 uint16_t controlId; // Control ID = 0xACE1 443 uint16_t protocolVer; // Protocol version = 0x08 444 uint8_t cmdRequest; // Command request = 2 (reply) 445 uint8_t cmdResponse; // Command response = 1 (Acknowledgement) 446 uint16_t reserved1; // Reserved (alignment) 447 uint16_t testPort; // Test port on server (available port in Response) 448 uint8_t jumboStatus; // Jumbo datagram support status (BOOL) 449 uint8_t authMode; // Authentication mode 450 uint32_t authUnixTime;// Authentication time stamp 451 unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets, MBZ 452 ... 454 The new connection is associated with a new UDP socket allocated from 455 the UDP ephemeral port range at the server. The server SHALL set a 456 timer for the new connection as a watchdog (in case the client goes 457 quiet) and send the Setup response back to the client. 459 (Note: in version 8, the watchdog time-out is configured at 5 460 seconds) 462 The Setup Response SHALL include the port number at the server for 463 the new socket, and this UDP port-pair SHALL be used for all 464 subsequent communication. The server SHALL also include the values 465 of: 467 o Jumbo datagram support status (BOOL), 469 o Authentication mode, and 471 o Authentication time stamp 473 for the client's use on the new connection in its Setup Response, and 474 the remaining 32 octets MUST Be Zero (MBZ). 476 Finally, the new UDP connection associated with the new socket and 477 port number is opened, and the server awaits communication there. 479 If a Test Activation request is not subsequently received from the 480 client on this new port number before the watchdog timer expires, the 481 server SHALL close the socket and deallocate the port. 483 5.1. Setup Response Processing at the Client 485 When the client receives the Setup response from the server it first 486 checks the cmdResponse value. If this value indicates an error the 487 client SHALL display/report a relevant message to the user or 488 management process and exit. If the client receives a Command 489 Response code (CRSP) that is not equal to one of the codes defined 490 above, then the client MUST terminate the connection and terminate 491 operation of the current Setup Request. If the Command Response code 492 (CRSP) value indicates success the client SHALL compose a Test 493 Activation Request with all the test parameters it desires such as 494 the test direction, the test duration, etc. 496 6. Test Activation Request and Response 498 This section is divided according to the sending and processing of 499 the client, server, and again at the client. 501 All messages defined in this section SHALL use UDP transport. The 502 hosts SHALL calculate and include the UDP checksum, or check the UDP 503 checksum as neccessary. 505 6.1. Test Activation Request at the client 507 Upon a successful setup, the client SHALL then send the Test 508 Activation Request to the UDP port number the server communicated in 509 the Setup Response. 511 @@@@ To Do: Add Options for UDP payload content (beyond the Test 512 PDU), such as all zeroes, all ones, alternating one and zero, and 513 pseudo-random. 515 The client SHALL compose Test Activation Request as follows: 517 uint16_t controlId; // Control ID 518 uint16_t protocolVer; // Protocol version 519 uint8_t cmdRequest; // Command request, 1 = upstream, 2 = downstream 520 uint8_t cmdResponse; // Command response (set to 0) 521 uint16_t lowThresh; // Low delay variation threshold 522 uint16_t upperThresh; // Upper delay variation threshold 523 uint16_t trialInt; // Status feedback/trial interval (ms) 524 uint16_t testIntTime; // Test interval time (sec) 525 uint8_t subIntPeriod; // Sub-interval period (sec) 526 uint8_t ipTosByte; // IP ToS byte for testing 527 uint16_t srIndexConf; // Configured sending rate index (see Note below) 528 uint8_t useOwDelVar; // Use one-way delay instead of RTT 529 uint8_t highSpeedDelta; // High-speed row adjustment delta 530 uint16_t slowAdjThresh; // Slow rate adjustment threshold 531 uint16_t seqErrThresh; // Sequence error threshold 532 uint8_t ignoreOooDup; // Ignore Out-of-Order/Duplicate datagrams 533 uint8_t reserved1; // (Alignment) 534 uint16_t reserved2; // (Alignment) 536 Control Header Test Activation Command Request Values: 537 CHTA_CREQ_NONE 0 = No Request 538 CHTA_CREQ_TESTACTUS 1 = Request test in Upstream direction (client to server, client takes the role of sending test packets) 539 CHTA_CREQ_TESTACTDS 2 = Request test in Downstream direction (server to client, client takes the role of receiving test packets) 541 Control Header Test Activation Command Response Values: 542 CHTA_CRSP_NONE 0 = Used by client when making a Request 543 CHTA_CRSP_ACKOK 1 = Used by Server in affirmative Response 544 CHTA_CRSP_BADPARAM 2 = Used by Server to indicate an error; bad parameter; reject; 546 Note: uint16_t srIndexConf is the table index of the configured 547 *fixed* sending rate index to use. The client can request the 548 specified rate, or the server can use this field to coerce a maximum 549 rate in its response. If the server sets to 0 in its response, 550 client SHALL not use fixed rate. 552 The UDP PDU format of the Test Activation Request is as follows (big- 553 endian AB): 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | controlId | protocolVer | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | cmdRequest | cmdResponse | lowThresh | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | upperThresh | trialInt | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | testIntTime | subIntPeriod | ipTosByte | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | srIndexConf | useOwDelVar |highSpeedDelta | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | slowAdjThresh | seqErrThresh | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | ignoreOooDup | reserved1 | reserved2 | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Note: This is only 28 octets of the 56 octet PDU sent, the rest are MBZ 573 for a Test Activation Request. 575 The client SHALL use the configuration for 577 o Jumbo datagram support status (BOOL), 579 o Authentication mode, and 581 o Authentication time stamp 583 requested and confirmed by the server. 585 6.2. Test Activation Request - server response 587 After the server receives the Test Activation request on the new 588 connection, it MUST choose to accept, ignore or modify any of the 589 test parameters. 591 When the server sends the Test Activation response back, it SHALL set 592 the cmd Response field to: 594 uint8_t cmdResponse;// Command response (set to 1, ACK, or 2 error) 596 The server SHALL include all the test parameters again to make the 597 client aware of any changes. 599 If the client has requested an upstream test, the server SHALL 600 include the transmission parameters from the first row of the sending 601 rate table. 603 The remaining 28 octets of the Test Activation Request (normally read 604 from the first row of the sending rate table) are called the Sending 605 Rate Structure, and SHALL be organized as follows: 607 uint32_t txInterval1; // Transmit interval (us) 608 uint32_t udpPayload1; // UDP payload (bytes) 609 uint32_t burstSize1; // UDP burst size per interval 610 uint32_t txInterval2; // Transmit interval (us) 611 uint32_t udpPayload2; // UDP payload (bytes) 612 uint32_t burstSize2; // UDP burst size per interval 613 uint32_t udpAddon2; // UDP add-on (bytes) 615 with 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | txInterval1 | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | udpPayload1 | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | burstSize1 | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | txInterval2 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | udpPayload2 | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | burstSize2 | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | udpAdddon2 | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Note that the server additionally has the option of completely 634 rejecting the request and sending back an appropriate command 635 response value: 637 uint8_t cmdResponse; // Command response (set to 2, error) 639 If activation continues, the new connection is prepared for an 640 upstream OR downstream test. 642 In the case of a downstream test, the server prepares to send with 643 either a single timer to send status PDUs at the specified interval 644 OR dual timers to send load PDUs based on the first row of the 645 sending rate table. 647 The server SHALL then send a Test Activation response back to the 648 client, update the watchdog timer with a new time-out value, and set 649 a test duration timer to eventually stop the test. 651 The new connection is now ready for testing. 653 6.3. Test Activation Response action at the client 655 When the client receives the Test Activation response, it first 656 checks the command response value. 658 If the client receives a Test Activation command response value that 659 indicates an error, the client SHALL display/report a relevant 660 message to the user or management process and exit. 662 If the client receives a Test Activation command response value that 663 is not equal to one of the codes defined above, then the client MUST 664 terminate the connection and terminate operation of the current Setup 665 Request. 667 If the client receives a Test Activation command response value that 668 indicates success (CHTA_CRSP_ACKOK) the client SHALL update its 669 configuration to use any test parameters modified by the server. 671 Next, the client SHALL prepare its connection for either an upstream 672 test with dual timers set to send load PDUs (based on the starting 673 transmission parameters sent by the server), OR a downstream test 674 with a single timer to send status PDUs at the specified interval. 676 Then, the client SHALL stop the test initiation timer, set a new 677 time-out value for the watchdog timer, and start the timer (in case 678 the server goes quiet). 680 The connection is now ready for testing. 682 7. Test Stream Transmission and Measurement Feedback Messages 684 This section describes the testing phase of the protocol. The roles 685 of sender and receiver vary depending whether the direction of 686 testing is from server to client, or the reverse. 688 All messages defined in this section SHALL use UDP transport. The 689 hosts SHALL calculate and include the UDP checksum, or check the 690 received UDP checksum before further processing, as neccessary. 692 7.1. Test Packet PDU and Roles 694 Testing proceeds with one end point sending load PDUs, based on 695 transmission parameters from the sending rate table, and the other 696 end point receiving the load PDUs and sending status messages to 697 communicate the traffic conditions at the receiver. 699 The watchdog timer at the receiver SHALL be reset each time a test 700 PDU is received. See non-graceful test stop in Section 8 for 701 handling the watchdog/NOTRAFFIC time-out expiration at each end- 702 point. 704 When the server is sending Load PDUs in the role of sender, it SHALL 705 use the transmission parameters directly from the sending rate table 706 via the index that is currently selected (which was based on the 707 feedback in its received status messages). 709 However, when the client is sending load PDUs in the role of sender, 710 it SHALL use the discreet transmission parameters that were 711 communicated by the server in its periodic status messages (and not 712 referencing a sending rate table). This approach allows the server 713 to control the individual sending rates as well as the algorithm used 714 to decide when and how to adjust the rate. 716 The server uses a load adjustment algorithm which evaluates 717 measurements, either it's own or the contents of received feedback 718 messages. This algorithm is unique to udpst; it provides the ability 719 to search for the Maximum IP Capacity that is absent from other 720 testing tools. Although the algorithm depends on the protocol, it is 721 not part of the protocol per se. 723 The current algorithm has three paths to its decision on the next 724 sending rate: 726 1. When there are no impairments present (no sequence errors, low 727 delay variation), resulting in sending rate increase. 729 2. When there are low impairments present (no sequence errors but 730 higher levels of delay variation), so the same sending rate is 731 retained. 733 3. When the impairment levels are above the thresholds set for this 734 purpose and "congestion" is inferred, resulting in sending rate 735 decrease. 737 The algorithm also has two modes for increasing/decreasing the 738 sending rate: 740 o A high-speed mode to achieve high sending rates quickly, but also 741 back-off quickly when "congestion" is inferred from the 742 measurements. Any two consecutive feedback intervals that have a 743 sequence number anomaly and/or contain an upper delay variation 744 threshold exception in both of the two consecutive intervals, 745 count as the two consecutive feedback measurements required to 746 declare "congestion" within a test. 748 o A single-step mode where all rate adjustments use the minimum 749 increase or decrease of one step in the sending rate table. The 750 single step mode continues after the first inference of 751 "congestion" from measured impairments. 753 On the other hand, the test configuration MAY use a fixed sending 754 rate requested by the client, using the field below: 756 uint16_t srIndexConf; // Configured sending rate index 758 The client MAY communicate the desired fixed rate in it's activation 759 request. 761 The Load PDU SHALL have the following format and field definitions: 763 uint16_t loadId; // Load ID (=0xBEEF for the LOad PDU) 764 uint8_t testAction; // Test action (= 0x00 normally, until test stop) 765 uint8_t rxStopped; // Receive traffic stopped indicator (BOOL) 766 uint32_t lpduSeqNo; // Load PDU sequence number (starts at 1) 767 uint16_t udpPayload; // UDP payload LENGTH(bytes) 768 uint16_t spduSeqErr; // Status PDU sequence error count 769 // 770 uint32_t spduTime_sec; // Send time in last received status PDU 771 uint32_t spduTime_nsec; // Send time in last received status PDU 772 uint32_t lpduTime_sec; // Send time of this load PDU 773 uint32_t lpduTime_nsec; // Send time of this load PDU 775 Test Action Codes 776 TEST_ACT_TEST 0 // normal 777 TEST_ACT_STOP1 1 // normal stop at end of test: server sends in STATUS or Test PDU 778 TEST_ACT_STOP2 2 // ACK of STOP1: sent by client in STATUS or Test PDU 780 The Test Load UDP PDU format is as follows (big-endian AB): 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | loadId | testAction | rxStopped | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | lpduSeqNo | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | udpPayload | spduSeqErr | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | spduTime_sec | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | spduTime_nsec | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | lpduTime_sec | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | lpduTime_nsec | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 . MBZ = udpPayload - 28 octets . 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 . . 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 . . 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 . . 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 . . 809 7.2. Status PDU 811 The receiver SHALL send a Status PDU to the sender during a test at 812 the configured feedback interval. 814 The watchdog timer at the test PDU sender SHALL be reset each time a 815 Status PDU is received. See non-graceful test stop in Section 8 for 816 handling the watchdog/NOTRAFFIC time-out expiration at each end- 817 point. 819 @@@@ To Do: What protections from bit errors (checksum) or on-path 820 attacks (something stronger) are warrented for teh Status PDUs? 821 These PDUs are a key part of the server-client control loop. Added a 822 requirement to calculate and include/check the UDP checksum. 824 The Status Header PDU SHALL have the following format and field 825 definitions: 827 // Status feedback header for UDP payload of status PDUs 828 // 830 uint16_t statusId; // Status ID = 0xFEED 831 uint8_t testAction; // Test action 832 uint8_t rxStopped; // Receive traffic stopped indicator (BOOL) 833 uint32_t spduSeqNo; // Status PDU sequence number (starts at 1) 834 // 835 struct sendingRate srStruct; // Sending Rate Structure (28 octets) 836 // 837 uint32_t subIntSeqNo; // Sub-interval sequence number 838 struct subIntStats sisSav; // Sub-interval Saved Stats Structure (52 octets) 839 // 840 uint32_t seqErrLoss; // Loss sum 841 uint32_t seqErrOoo; // Out-of-Order sum 842 uint32_t seqErrDup; // Duplicate sum 843 // 844 uint32_t clockDeltaMin; // Clock delta minimum (either RTT or 1-way delay) 845 uint32_t delayVarMin; // Delay variation minimum 846 uint32_t delayVarMax; // Delay variation maximum 847 uint32_t delayVarSum; // Delay variation sum 848 uint32_t delayVarCnt; // Delay variation count 849 uint32_t rttMinimum; // Minimum round-trip time sampled 850 uint32_t rttSample; // Last round-trip time sample 851 uint8_t delayMinUpd; // Delay minimum(s) updated observed, communicated in both directions. 852 uint8_t reserved2; // (alignment) 853 uint16_t reserved3; // (alignment) 854 // 855 uint32_t tiDeltaTime; // Trial interval delta time 856 uint32_t tiRxDatagrams; // Trial interval receive datagrams 857 uint32_t tiRxBytes; // Trial interval receive bytes 858 // 859 uint32_t spduTime_sec; // Send time of this status PDU 860 uint32_t spduTime_nsec; // Send time of this status PDU 862 The Status feedback UDP payload PDUs format is as follows (big-endian 863 AB): 865 0 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | statusId | testAction | rxStopped | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | spduSeqNo | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 . Sending Rate Structure (28 octets) . 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | subIntSeqNo | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 . Sub-interval Saved Stats Structure (52 octets) . 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | seqErrLoss | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | seqErrOoo | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | seqErrDup | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | clockDeltaMin | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | delayVarMin | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | delayVarMax | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | delayVarSum | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | delayVarCnt | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | rttMinimum | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | rttSample | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | delayMinUpd | reserved2 | reserved3 | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | tiDeltaTime | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | tiRxDatagrams | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | tiRxBytes | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | spduTime_sec | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | spduTime_nsec | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 Note that the Sending Rate Structure (28 octets) is defined in the 912 Test Activation section. 914 Also note that the Sub-interval Saved Stats Structure (52 octets) 915 SHALL be included (and populated as required when the server is in 916 the receiver role) as defined below. 918 The Sub-interval saved statistics structure for received traffic 919 measurements SHALL be organized and formatted as follows: 921 uint32_t rxDatagrams; // Received datagrams 922 uint32_t rxBytes; // Received bytes 923 uint32_t deltaTime; // Time delta 924 uint32_t seqErrLoss; // Loss sum 925 uint32_t seqErrOoo; // Out-of-Order sum 926 uint32_t seqErrDup; // Duplicate sum 927 uint32_t delayVarMin; // Delay variation minimum 928 uint32_t delayVarMax; // Delay variation maximum 929 uint32_t delayVarSum; // Delay variation sum 930 uint32_t delayVarCnt; // Delay variation count 931 uint32_t rttMinimum; // Minimum round-trip time 932 uint32_t rttMaximum; // Maximum round-trip time 933 uint32_t accumTime; // Accumulated time 934 ---------------------------------------------------------------------------- 936 0 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | rxDatagrams | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | rxBytes | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | deltaTime | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | seqErrLoss | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | seqErrOoo | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | seqErrDup | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | delayVarMin | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | delayVarMax | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | delayVarSum | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | delayVarCnt | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | rttMinimum | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | rttMaximum | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | accumTime | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 Note that the 52 octet saved statistics structure above has slight 967 differences from the 40 octets that follow in the status feedback 968 PDU, particularly the time-related fields. 970 Upon receiving the Status Feedback PDU or expiration of the feedback 971 interval, the server SHALL perform calculations required by the Load 972 adjustment algorithm and adjust its sending rate, or signal that the 973 client do so in its role as as sender. 975 @@@@ To Do: Additional measurements, like interface byte counters 976 from a client at a residential gateway, would change the Status 977 Feedback PDU (and the protocol version number as a result). 978 Interface byte counters seem useful for specific circumstances, such 979 as when the client application has acces to an interface that sees 980 all traffic to/from a service subscriber's location. 982 8. Stopping the Test 984 When the test duration timer on the server expires, it SHALL set the 985 connection test action to STOP and also starts marking all outgoing 986 load or status PDUs with a test action of STOP1. 988 uint8_t testAction; // Test action (server sets STOP1) 990 This is simply a non-reversible state for all future messages sent 991 from the server. 993 When the client receives a load or status PDU with the STOP1 994 indication, it SHALL finalize testing, display the test results, and 995 also mark its connection with a test action of STOP (so that any PDUs 996 received subsequent to the STOP1 are ignored). 998 With the test action of the client's connection set to STOP, the very 999 next expiry of a send timer for either a load or status PDU SHALL 1000 cause the client to schedule an immediate end time to exit. 1002 The client SHALL then send all subsequent load or status PDUs with a 1003 test action of STOP2 1005 uint8_t testAction; // Test action (client sets STOP2) 1007 as confirmation to the server, and a graceful termination of the test 1008 can begin. 1010 When the server receives the STOP2 confirmation in the load or status 1011 PDU, the server SHALL schedule an immediate end time for the 1012 connection which closes the socket and deallocates it. 1014 In a non-graceful test stop, the watchdog/NOTRAFFIC time-outs at each 1015 end-point will expire (sometimes at one end-point first), 1016 notifications in logs, STDOUT, and/or formateed output SHALL be made, 1017 and the test action of each end-point's connection SHALL be set to 1018 STOP. 1020 9. Method of Measurement 1022 The architecture of the method REQUIRES two cooperating hosts 1023 operating in the roles of Src (test packet sender) and Dst 1024 (receiver), with a measured path and return path between them. 1026 The duration of a test duration, parameter I, MUST be constrained in 1027 a production network, since this is an active test method and it will 1028 likely cause congestion on the Src to Dst host path during a test. 1030 9.1. Running Code 1032 This section is for the benefit of the Document Shepherd's form, and 1033 will be deleted prior to final review. 1035 Much of the development of the method and comparisons with existing 1036 methods conducted at IETF Hackathons and elsewhere have been based on 1037 the example udpst Linux measurement tool (which is a working 1038 reference for further development) [udpst]. The current project: 1040 o is a utility that can function as a client or server daemon 1042 o requires a successful client-initiated setup handshake between 1043 cooperating hosts and allows firewalls to control inbound 1044 unsolicited UDP which either go to a control port [expected and w/ 1045 authentication] or to ephemeral ports that are only created as 1046 needed. Firewalls protecting each host can both continue to do 1047 their job normally. This aspect is similar to many other test 1048 utilities available. 1050 o is written in C, and built with gcc (release 9.3) and its standard 1051 run-time libraries 1053 o allows configuration of most of the parameters described in 1054 Sections 4 and 7. 1056 o supports IPv4 and IPv6 address families. 1058 o supports IP-layer packet marking. 1060 10. Security Considerations 1062 Active metrics and measurements have a long history of security 1063 considerations. The security considerations that apply to any active 1064 measurement of live paths are relevant here. See [RFC4656] and 1065 [RFC5357]. 1067 When considering privacy of those involved in measurement or those 1068 whose traffic is measured, the sensitive information available to 1069 potential observers is greatly reduced when using active techniques 1070 which are within this scope of work. Passive observations of user 1071 traffic for measurement purposes raise many privacy issues. We refer 1072 the reader to the privacy considerations described in the Large Scale 1073 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 1074 which covers active and passive techniques. 1076 There are some new considerations for Capacity measurement as 1077 described in this memo. 1079 1. Cooperating source and destination hosts and agreements to test 1080 the path between the hosts are REQUIRED. Hosts perform in either 1081 the Src or Dst roles. 1083 2. It is REQUIRED to have a user client-initiated setup handshake 1084 between cooperating hosts that allows firewalls to control 1085 inbound unsolicited UDP traffic which either goes to a control 1086 port [expected and w/authentication] or to ephemeral ports that 1087 are only created as needed. Firewalls protecting each host can 1088 both continue to do their job normally. 1090 3. Client-server authentication and integrity protection for 1091 feedback messages conveying measurements is RECOMMENDED. To 1092 accomodate different host limitations and testing circumstances, 1093 different modes of operation are recommended: 1095 A. Unathenticated mode (for all phases) 1096 AND 1097 B. OPTIONAL Authenticated set-up only 1098 SHA-256 HMAC time-window verification (5 min time stamp verification) 1099 (could add silent failure option) 1101 -=-=-=-=-=-=-=-=-=- 1103 C. Encrypted setup and test-activation 1104 (currently using OpenSSL Library, so KISS, but may be too slow for 1105 test packets) 1107 -=-=-=-=--=- Old/lowpower host performance impacts -=-=-=-=-=-=- 1109 D. Encrypted feedback messages (maybe split into Integrity and encrypt?) 1111 E. Integrity protection for test packets SHA-256 HMAC 1113 F. Encrypted test packets (maybe also valuable to defeat compression on links) 1115 4. Hosts MUST limit the number of simultaneous tests to avoid 1116 resource exhaustion and inaccurate results. 1118 5. Senders MUST be rate-limited. This can be accomplished using a 1119 pre-built table defining all the offered load rates that will be 1120 supported (Section 8.1). The recommended load-control search 1121 algorithm results in "ramp up" from the lowest rate in the table. 1123 6. Service subscribers with limited data volumes who conduct 1124 extensive capacity testing might experience the effects of 1125 Service Provider controls on their service. Testing with the 1126 Service Provider's measurement hosts SHOULD be limited in 1127 frequency and/or overall volume of test traffic (for example, the 1128 range of I duration values SHOULD be limited). 1130 The exact specification of these features was hopefully accomplished 1131 during this protocol development. 1133 11. IANA Considerations 1135 This memo requests IANA to assign a UDP port. 1137 12. Acknowledgments 1139 Thanks to Ruediger Geib, Lincoln Lavoie, Can Desem, and Greg Mirsky 1140 for reviewing this draft and providing helpful suggestions and areas 1141 for further development. 1143 13. References 1145 13.1. Normative References 1147 [I-D.ietf-ippm-capacity-metric-method] 1148 Morton, A., Geib, R., and L. Ciavattone, "Metrics and 1149 Methods for One-way IP Capacity", draft-ietf-ippm- 1150 capacity-metric-method-12 (work in progress), June 2021. 1152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1153 Requirement Levels", BCP 14, RFC 2119, 1154 DOI 10.17487/RFC2119, March 1997, 1155 . 1157 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1158 "Framework for IP Performance Metrics", RFC 2330, 1159 DOI 10.17487/RFC2330, May 1998, 1160 . 1162 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1163 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1164 September 1999, . 1166 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1167 for Equal Cost Multipath Routing and Link Aggregation in 1168 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1169 . 1171 [RFC7497] Morton, A., "Rate Measurement Test Protocol Problem 1172 Statement and Requirements", RFC 7497, 1173 DOI 10.17487/RFC7497, April 2015, 1174 . 1176 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1177 Ed., "A One-Way Loss Metric for IP Performance Metrics 1178 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1179 2016, . 1181 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1182 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1183 May 2017, . 1185 [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. 1186 Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for 1187 the IP Performance Metrics (IPPM) Framework", RFC 8468, 1188 DOI 10.17487/RFC8468, November 2018, 1189 . 1191 13.2. Informative References 1193 [copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet, 1194 "copycat: Testing Differential Treatment of New Transport 1195 Protocols in the Wild (ANRW '17)", July 2017, 1196 . 1198 [LS-SG12-A] 1199 12, I. S., "LS - Harmonization of IP Capacity and Latency 1200 Parameters: Revision of Draft Rec. Y.1540 on IP packet 1201 transfer performance parameters and New Annex A with Lab 1202 Evaluation Plan", May 2019, 1203 . 1205 [LS-SG12-B] 1206 12, I. S., "LS on harmonization of IP Capacity and Latency 1207 Parameters: Consent of Draft Rec. Y.1540 on IP packet 1208 transfer performance parameters and New Annex A with Lab & 1209 Field Evaluation Plans", March 2019, 1210 . 1212 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1213 Network Interconnect Devices", RFC 2544, 1214 DOI 10.17487/RFC2544, March 1999, 1215 . 1217 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 1218 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 1219 DOI 10.17487/RFC3148, July 2001, 1220 . 1222 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1223 Zekauskas, "A One-way Active Measurement Protocol 1224 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 1225 . 1227 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 1228 RFC 5136, DOI 10.17487/RFC5136, February 2008, 1229 . 1231 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1232 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1233 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1234 . 1236 [RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, 1237 "Applicability Statement for RFC 2544: Use on Production 1238 Networks Considered Harmful", RFC 6815, 1239 DOI 10.17487/RFC6815, November 2012, 1240 . 1242 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 1243 Framework for IP Performance Metrics (IPPM)", RFC 7312, 1244 DOI 10.17487/RFC7312, August 2014, 1245 . 1247 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1248 Aitken, P., and A. Akhter, "A Framework for Large-Scale 1249 Measurement of Broadband Performance (LMAP)", RFC 7594, 1250 DOI 10.17487/RFC7594, September 2015, 1251 . 1253 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1254 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1255 May 2016, . 1257 [RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk 1258 Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March 1259 2018, . 1261 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 1262 Two-Way Active Measurement Protocol", RFC 8762, 1263 DOI 10.17487/RFC8762, March 2020, 1264 . 1266 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 1267 and E. Ruffini, "Simple Two-Way Active Measurement 1268 Protocol Optional Extensions", RFC 8972, 1269 DOI 10.17487/RFC8972, January 2021, 1270 . 1272 [TR-471] Morton, A., "Broadband Forum TR-471: IP Layer Capacity 1273 Metrics and Measurement", July 2020, 1274 . 1277 [udpst] udpst Project Collaborators, "UDP Speed Test Open 1278 Broadband project", December 2020, 1279 . 1281 [Y.1540] Y.1540, I. R., "Internet protocol data communication 1282 service - IP packet transfer and availability performance 1283 parameters", December 2019, 1284 . 1286 [Y.Sup60] Morton, A., "Recommendation Y.Sup60, (09/20) Interpreting 1287 ITU-T Y.1540 maximum IP-layer capacity measurements", 1288 September 2020, 1289 . 1291 Authors' Addresses 1293 Len Ciavattone 1294 AT&T Labs 1295 200 Laurel Avenue South 1296 Middletown,, NJ 07748 1297 USA 1299 Email: lencia@att.com 1301 Al Morton 1302 AT&T Labs 1303 200 Laurel Avenue South 1304 Middletown,, NJ 07748 1305 USA 1307 Phone: +1 732 420 1571 1308 Fax: +1 732 368 1192 1309 Email: acm@research.att.com