idnits 2.17.1 draft-aranda-dispatch-q4s-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1112 has weird spacing: '...ketloss follo...' == Line 3332 has weird spacing: '...tion of serve...' == 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 (July 5, 2019) is 1757 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7230 (ref. '1') (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (ref. '2') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (ref. '3') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7233 (ref. '4') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (ref. '5') (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (ref. '6') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2818 (ref. '7') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4566 (ref. '10') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4634 (ref. '14') (Obsoleted by RFC 6234) ** Obsolete normative reference: RFC 793 (ref. '16') (Obsoleted by RFC 9293) -- Duplicate reference: RFC3550, mentioned in '18', was also mentioned in '8'. Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft 3 Intended status: Informational J.J. Garcia Aranda 4 Expires: January 2020 Nokia 5 M. Cortes 6 J. Salvachua 7 Univ. Politecnica de Madrid 8 M. Narganes 9 Tecnalia 10 I. Martinez Sarriegui 11 Optiva Media 13 July 5, 2019 15 The Quality for Service Protocol 16 draft-aranda-dispatch-q4s-10.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on January 5, 2020. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. 54 Abstract 56 This memo describes an application level protocol for the 57 communication of end-to-end QoS compliance information based on 58 the Hypertext Transfer Protocol (HTTP) and the Session 59 Description Protocol (SDP). The Quality for Service Protocol 60 (Q4S) provides a mechanism to negotiate and monitor latency, 61 jitter, bandwidth, and packet, and to alert whenever one of the 62 negotiated conditions is violated. 64 Implementation details on the actions to be triggered upon 65 reception/detection of QoS alerts exchanged by the protocol are 66 out of scope of this document, it is application dependent (e.g., 67 act to increase quality or reduce bit-rate) or network dependent 68 (e.g., change connection's quality profile). 70 This protocol specification is the product of research conducted 71 over a number of years, and is presented here as a permanent 72 record and to offer a foundation for future similar work. It does 73 not represent a standard protocol and does not have IETF 74 consensus. 76 Table of Contents 78 1 Introduction...................................................5 79 1.1 Scope....................................................6 80 1.2 Motivation...............................................7 81 1.3 Summary of Features......................................8 82 1.4 Differences with OWAMP/TWAMP.............................9 83 2 Terminology....................................................9 84 3 Overview of Operation.........................................10 85 4 Q4S Messages..................................................21 86 4.1 Requests................................................21 87 4.2 Responses...............................................22 88 4.3 Header Fields...........................................23 89 4.3.1 Common Q4S Header Fields..........................23 90 4.3.2 Specific Q4S Request Header Fields................24 91 4.3.3 Specific Q4S Response Header Fields...............25 92 4.4 Bodies..................................................26 93 4.4.1 Encoding..........................................26 94 5 Q4S Method Definitions........................................26 95 5.1 BEGIN...................................................27 96 5.2 READY...................................................27 97 5.3 PING....................................................27 98 5.4 BWIDTH..................................................28 99 5.5 Q4S-ALERT...............................................28 100 5.6 Q4S-RECOVERY............................................28 101 5.7 CANCEL..................................................29 102 6 Response Codes................................................29 103 6.1 100 Trying..............................................30 104 6.2 Success 2xx.............................................30 105 6.2.1 200 OK............................................30 106 6.3 Redirection 3xx.........................................30 107 6.4 Request Failure 4xx.....................................30 108 6.4.1 400 Bad Request...................................30 109 6.4.2 404 Not Found.....................................30 110 6.4.3 405 Method Not Allowed............................31 111 6.4.4 406 Not Acceptable................................31 112 6.4.5 408 Request Timeout...............................31 113 6.4.6 413 Request Entity Too Large......................31 114 6.4.7 414 Request-URI Too Long..........................31 115 6.4.8 415 Unsupported Media Type........................31 116 6.4.9 416 Unsupported URI Scheme........................31 117 6.5 Server Failure 5xx......................................32 118 6.5.1 500 Server Internal Error.........................32 119 6.5.2 501 Not Implemented...............................32 120 6.5.3 503 Service Unavailable...........................32 121 6.5.4 504 Server Time-out...............................32 122 6.5.5 505 Version Not Supported.........................32 123 6.5.6 513 Message Too Large.............................33 124 6.6 Global Failures 6xx.....................................33 125 6.6.1 600 session does not exist........................33 126 6.6.2 601 quality level not allowed.....................33 127 6.6.3 603 Session not allowed...........................33 128 6.6.4 604 authorization not allowed.....................33 129 7 Protocol......................................................33 130 7.1 Protocol Phases.........................................33 131 7.2 SDP Structure...........................................35 132 7.2.1 "qos-level" attribute.............................36 133 7.2.2 "alerting-mode" attribute.........................37 134 7.2.3 "alert-pause" attribute...........................37 135 7.2.4 "recovery-pause" attribute........................37 136 7.2.5 "public-address" attributes.......................38 137 7.2.6 "latency" attribute...............................38 138 7.2.7 "jitter" attribute................................38 139 7.2.8 "bandwidth" attribute.............................38 140 7.2.9 "packetloss" attribute............................39 141 7.2.10 "flow" attributes.................................39 142 7.2.11 "measurement" attributes..........................40 143 7.2.12 "max-content-length" attribute....................42 145 7.3 Measurements............................................42 146 7.3.1 Latency...........................................42 147 7.3.2 Jitter............................................43 148 7.3.3 Bandwidth.........................................43 149 7.3.4 Packet loss.......................................46 150 7.4 Handshake Phase.........................................46 151 7.5 Negotiation Phase.......................................47 152 7.5.1 Stage 0: Measurement of Latencies and Jitter......49 153 7.5.2 Stage 1: Measurement of Bandwidth and Packet Loss.52 154 7.5.3 Quality Constraints Not Reached...................55 155 7.5.3.1 Actuator Role..................................57 156 7.5.3.2 Policy Server Role.............................58 157 7.5.4 QoS Level Changes.................................58 158 7.6 Continuity Phase........................................59 159 7.7 Termination Phase.......................................62 160 7.8 Dynamic Constraints And Flows...........................63 161 7.9 Qos-level Upgrade And Downgrade Operation...............64 162 8 General User Agent Behavior...................................66 163 8.1 Roles in Peer-to-Peer Scenarios.........................66 164 8.2 Multiple Quality Sessions in Parallel...................67 165 8.3 General Client bBhavior.................................67 166 8.3.1 Generating Requests...............................68 167 8.4 General Server Behavior.................................69 168 9 Implementation Recommendations................................70 169 9.1 Default Client Constraints..............................70 170 9.2 Latency and Jitter Measurements.........................70 171 9.3 Bandwidth Measurements..................................71 172 9.4 Packet Loss Measurement Resolution......................72 173 9.5 Measurements and Reactions..............................72 174 9.6 Instability Treatments..................................72 175 9.6.1 Loss of Control Packets...........................73 176 9.6.2 Outlier Samples...................................73 177 9.7 Scenarios...............................................73 178 9.7.1 Client to ACP.....................................74 179 9.7.2 Client to Client..................................74 180 10 Security Considerations.......................................74 181 10.1 Confidentiality Issues..................................74 182 10.2 Integrity of Measurements and Authentication............75 183 10.3 Privacy of Measurements.................................75 184 10.4 Availability Issues.....................................75 185 10.5 Bandwidth Occupancy Issues..............................75 186 11 Future Code Point Requirements................................76 187 11.1 Service Port............................................76 188 12 References....................................................77 189 12.1 Normative References....................................77 190 12.2 Informative References..................................78 191 13 Acknowledgments...............................................80 192 14 Contributors..................................................81 193 15 Authors' Addresses............................................83 195 1 Introduction 197 The World Wide Web (WWW) is a distributed hypermedia system 198 which has gained widespread acceptance among Internet users. 199 Although WWW browsers support other, preexisting Internet 200 application protocols, the primary protocol used between WWW 201 clients and servers became the HyperText Transfer Protocol (HTTP) 202 (RFC 7230 [1], RFC 7231 [2], RFC 7232 [3], RFC 7233 [4], RFC 7234 203 [5], and RFC 7235 [6]). Since then, HTTP over TLS (known as HTTPS 204 and described in RFC 2818 [7]) has become an imperative for 205 providing secure and authenticated WWW access. The mechanisms 206 described in this document are equally applicable to HTTP and 207 HTTPS. 209 The ease of use of the Web has prompted its widespread employment 210 as a client/server architecture for many applications. Many of 211 such applications require the client and the server to be able to 212 communicate each other and exchange information with certain 213 quality constraints. 215 Quality in communications at the application level consists of 216 four measurable parameters: 218 o Latency: The time a message takes to travel from source to 219 destination. It may be approximated to RTT/2 (Round trip 220 time), assuming the networks are symmetrical. In this context 221 we will consider the statistical median formula. 223 o Jitter: latency variation. There are some formulas to 224 calculate Jitter, and in this context we will consider the 225 arithmetic mean formula. 227 o Bandwidth: bit rate of communication. To assure quality, a 228 protocol must assure the availability of the bandwidth needed 229 by the application. 231 o Packet loss: The percentage of packet loss is closely related 232 to bandwidth and jitter. Affects bandwidth because a high 233 packet loss implies sometimes retransmissions that also 234 consumes extra bandwidth, other times the retransmissions are 235 not achieved (for example in video streaming over UDP) and 236 the information received is less than the required bandwidth. 237 In terms of jitter, a packet loss sometimes is seen by the 238 destination like a larger time between arrivals, causing a 239 jitter growth. 241 Any other communication parameter such as throughput, is not a 242 network parameter because it depends on protocol window size and 243 other implementation-dependent aspects. 245 The Quality for Service Protocol (Q4S) provides a mechanism for 246 quality monitoring based on an HTTP syntax and the Session 247 Description protocol (SDP) in order to be easily integrated in 248 WWW, but it may be used by any type of application, not only those 249 based on HTTP. Quality requirements may be needed by any type of 250 application that communicates using any kind of protocol, 251 especially those with real-time constraints. Depending on the 252 nature of each application the constraints may be different 253 leading to different parameter thresholds that need to be met. 255 Q4S is an application level Client/Server protocol that 256 continuously measures session quality for a given flow (or set of 257 flows), end-to-end (e2e) and in real-time; raising alerts if 258 quality parameters are below a given pre-negotiated threshold and 259 sending recoveries when quality parameters are restored. Q4S 260 describes when these notifications, alerts and recoveries, need to 261 be sent and the entity receiving them. The actions undertaken by 262 the receiver of the alert are out of scope of the protocol. 264 Q4S is session-independent from the application flows, to minimize 265 the impact on them. To perform the measurements, two control flows 266 are created on both communication paths (forward and reverse 267 directions). 269 This protocol specification is the product of research conducted 270 over a number of years, and is presented here as a permanent 271 record and to offer a foundation for future similar work. It does 272 not represent a standard protocol and does not have IETF 273 consensus. 275 1.1 Scope 277 The purpose of Q4S is to measure end-to-end network quality in 278 real-time. Q4S does not transport any application data. It means 279 that Q4S is designed to be used jointly with other transport 280 protocols such as Real Time Protocol (RTP)(RFC 3550 [8]), 281 Transmission Control Protocol (TCP) (RFC 793 [16]), Quick UDP 282 Internet Connections (QUIC)[9] , HTTP [1], etc. 284 Some existent transport protocols are focused in real-time media 285 transport and certain connection metrics are available, which is 286 the case of RTP and Real Time Control Protocol (RTCP)[8]. Other 287 protocols such as QUIC provide low connection latencies as well as 288 advanced congestion control. These protocols transport data 289 efficiently and provide lot of functionalities. However, there are 290 currently no other quality measurement protocols offering the same 291 level of function as Q4S. See Section 1.4 for a discussion of the 292 IETF's OWAMP and TWAMP quality measurement protocols. 294 Q4S enable applications to become reactive under e2e network 295 quality changes. To achieve it, an independent Q4S stack 296 application must run in parallel to target application. Then, Q4S 297 metrics may be used to trigger actions on target application such 298 as speed adaptation to latency in multiuser games, bitrate control 299 at streaming services, intelligent commutation of delivery node at 300 Content Delivery Networks, and whatever target application allow. 302 1.2 Motivation 304 Monitoring quality of service (QoS) in computer networks is useful 305 for several reasons: 307 o Enable real-time services and applications to verify whether 308 network resources achieve a certain QoS level. This helps 309 real-time services and applications to run through the 310 Internet, allowing the existence of Application Content 311 Providers (ACPs) which offer guaranteed real-time services to 312 the final users. 314 o Real-time monitoring allows applications to adapt themselves 315 to network conditions (Application-based QoS) and/or request 316 more network quality to the Internet Service Provider (ISP) 317 (if the ISP offers this possibility). 319 o Monitoring may also be required by Peer to Peer (P2P) real- 320 time applications for which Q4S can be used 322 o Enable ISPs to offer QoS to any ACP or final user application 323 in an accountable way 325 o Enable e2e negotiation of QoS parameters, independently of 326 the ISPs of both endpoints. 328 A protocol to monitor QoS must address the following issues: 330 o Must be ready to be used in conjunction with current standard 331 protocols and applications, without forcing a change on them. 333 o Must have a formal and compact way to specify quality 334 constraints desired by the application to run. 336 o Must have measurement mechanisms avoiding application 337 disruption and minimizing network resources consumption. 339 o Must have specific messages to alert about the violation of 340 quality constraints in different directions (forward and 341 reverse), because network routing may not be symmetrical, and 342 of course, quality constraints may not be symmetrical. 344 o After having alerted about the violation of quality 345 constraints, must have specific messages to inform about 346 recovery of quality constraints in corresponding directions 347 (forward and reverse). 349 o Must protect the data (constrains, measurements, QoS levels 350 demanded from the network) in order to avoid the injection of 351 malicious data in the measurements. 353 1.3 Summary of Features 355 The Quality for Service Protocol (Q4S) is a message-oriented 356 communication protocol that can be used in conjunction with any 357 other application-level protocol. Q4S is a measurement protocol. 358 Any action taken derived from its measurements are out of scope of 359 the protocol. These actions depend on application provider and may 360 be application-level adaptive reactions, may involve requests to 361 ISP, or whatever application provider decide. 363 The benefits in quality measurements provided by Q4S can be used 364 by any type of application that uses any type of protocol for data 365 transport. It provides a quality monitoring scheme for any 366 communication that takes place between the client and the server, 367 not only for the Q4S communication itself. 369 Q4S does not establish multimedia sessions and it does not 370 transport application data. It monitors the fulfillment of the 371 quality requirements of the communication between the client and 372 the server, and therefore does not impose any restrictions on the 373 type of application, protocol or the type of usage of the 374 monitored quality connection. 376 Some applications may vary their quality requirements dynamically 377 for any given quality parameter. Q4S is able to adapt to the 378 changing application needs modifying the parameter thresholds to 379 the new values and monitoring the network quality according to the 380 new quality constraints. It will raise alerts if the new 381 constraints are violated. 383 Q4S session lifetime is composed of four phases with different 384 purposes: Handshake, Negotiation, Continuity and Termination. 385 Negotiation and Continuity phases perform network parameter 386 measurements as per a negotiated measurement procedure. Different 387 measurement procedures could be used inside Q4S, although one 388 default measurement mechanism is needed for compatibility reasons 389 and is the one defined in this document. Basically, Q4S defines 390 how to transport application quality requirements and measurement 391 results between client and server and providing monitoring and 392 alerting too. 394 Q4S must be executed just before starting a client-server 395 application which needs a quality connection in terms of latency, 396 jitter, bandwidth and/or packet loss. Once client and server have 397 succeeded in establishing communication under quality constraints, 398 the application can start, and Q4S continues measuring and 399 alerting if necessary. 401 The quality parameters can be suggested by the client in the first 402 message of the handshake phase, but it's the server that accepts 403 these parameter values or forces others. The server is in charge 404 of deciding the final values of quality connection. 406 1.4 Differences with OWAMP/TWAMP 408 OWAMP (RFC 4656) [27] and TWAMP (RFC 5357) [28] are two protocols 409 to measure network quality in terms of RTT, but has a different 410 goal than Q4S. The main difference is the scope: Q4S is designed 411 to assist reactive applications, while OWAMP/TWAMP is designed 412 just to measure network delay. 414 Differences can be summarized in the following points: 416 . OWAMP/TWAMP is not intended for measuring availability of 417 resources (certain Bandwidth availability for example) but 418 only RTT. However, Q4S is intended for measuring required 419 bandwidth, packet-loss, jitter and latency in both 420 directions. Available bandwidth is not measured by Q4S, but 421 required bandwidth for specific application. 423 . OWAMP/TWAMP does not have responsivity control (which 424 defines the speed of protocol reactions under network quality 425 changes), because this protocol is designed to measure 426 network performance, not to assist reactive applications and 427 does not detect the fluctuations of quality in certain time 428 intervals to take reactive actions. However, responsivity 429 control is a key feature of Q4S. 431 . OWAMP/TWAMP is not intended to run in parallel with reactive 432 applications, but Q4S' goal is to run in parallel and assist 433 reactive applications to take decisions based on Q4S ALERT 434 packets which may trigger actions. 436 2 Terminology 438 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 439 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 440 "MAY", and "OPTIONAL" in this document are to be interpreted as 441 described in BCP 14 RFC 2119 [11] RFC 8174 [21] when, and only 442 when, they appear in all capitals, as shown here. 444 3 Overview of Operation 446 This section introduces the basic operation of Q4S using simple 447 examples. This section is of tutorial nature and does not contain 448 any normative statements. 450 The first example shows the basic functions of a Q4S: 451 communication establishment between a client and a server, quality 452 requirement negotiations for the requested application, 453 application start and continuous quality parameter measurements, 454 and finally communication termination. 456 The client triggers the establishment of the communication 457 requesting a specific service or application from the server. This 458 first message must have a special URI (RFC 3986)[12], which may 459 force the use of the Q4S protocol if it is implemented in a 460 standard web browser. This message consists of a Q4S BEGIN method, 461 which can optionally include a proposal for the communication 462 quality requirements in an SDP body. This option gives the client 463 a certain negotiation capacity about quality requirements, but it 464 will be the server who finally decides about the stated 465 requirements. 467 This request is answered by the server with a Q4S 200 OK response 468 letting the client know that it accepts the request. This response 469 message must contain an SDP body with: 471 o The assigned Q4S session id. 473 o The quality constraints required by the requested 474 application. 476 o The measurement procedure to use. 478 o The alerting mode: there are two different scenarios for 479 sending alerts that trigger actions either on the network or 480 in the application when measurements identify violated 481 quality constraints. In both cases, alerts are triggered by 482 the server. 484 o a) Q4S-aware-network scenario: the network is Q4S aware, 485 and reacts by itself to these alerts. In this scenario 486 Q4S ALERT messages are sent by the server to the client, 487 and network elements inspect and process these alert 488 messages. The alerting mode in this scenario is called 489 Q4S-aware-network alerting mode. 491 o b) Reactive scenario: As shown in Figure 1, the network 492 is not Q4S aware. In this scenario alert notifications 493 are sent to a specific node, called an Actuator, which is 494 in charge of taking decisions regarding what actions to 495 trigger: either to change application behavior to adapt 496 it to network conditions and/or invoke a network policy 497 server in order to reconfigure the network and request 498 more quality for application flows. 500 +------+ +-----------+ 501 | App |<----- app flows---------->|Application| 502 |Client| +-----------+ 503 +------+ A 504 | 505 +------+ +------+ +--------+ 506 | Q4S |<----Q4S---->| Q4S |<----->|Actuator| 507 |Client| |Server| +--------+ 508 +------+ +------+ | 509 V 510 +-------------+ 511 |policy server| 512 +-------------+ 514 Figure 1 Reactive scenario 516 o The format of messages exchanged between the server stack and 517 the Actuator, doesn't follow Q4S codification rules, but 518 their format will be implementation dependent. In this way, 519 we will call the messages sent from the server stack to the 520 Actuator "notifications" (e.g., alert notifications), and the 521 messages sent from the Actuator to the server stack in 522 response to notifications "acknowledges" (e.g., alert 523 acknowledges). 525 o alert-pause: The amount of time between consecutive alerts. 526 In the Q4S-aware-network scenario, the server has to wait 527 this period of time between Q4S ALERT messages sent to the 528 client. In the Reactive scenario, the server stack has to 529 wait this period of time between alert notifications sent to 530 the Actuator. Measurements are not stopped in Negotiation or 531 Continuity Phases during this period of time, but no alerts 532 are sent even with violated network quality constraints in 533 order to leave time for network reconfiguration or for 534 application adjustments. 536 o recovery-pause: The amount of time the Q4S server waits 537 before trying to recover the initial qos-level. After having 538 detected violation of quality constraints several times, the 539 qos-level will have been increased accordingly. If this 540 violation detection finally stops, the server waits for a 541 period of time (recovery time) and if the situation persists, 542 it tries to recover to previous qos-level values gradually by 543 sending Q4S RECOVERY messages to the client, in the Q4S- 544 aware-network scenario, or recovery notifications to the 545 Actuator, in the Reactive scenario. 547 It is important to highlight that any Q4S 200 OK response sent by 548 the server to the client at any time during the life of a quality 549 session may contain an SDP body with new values of quality 550 constraints required by the application. Depending on the phase 551 and the state of the measurement procedure within the specific 552 phase, the client will react accordingly so as to take into 553 account the new quality constraints in the measurement procedure. 555 Once the communication has been established (handshake phase is 556 finished), the protocol will verify that the communication path 557 between the client and the server meets the quality constraints on 558 both directions, from and to the server (negotiation phase). This 559 negotiation phase requires taking measurements of the quality 560 parameters: latencies, jitter, bandwidth and packet loss. This 561 phase is initiated with a client message containing a Q4S READY 562 method, which will be answered by the server with a Q4S 200 OK 563 response. 565 Negotiation measurements are achieved in two sequential stages: 567 o Stage 0: latency and jitter measurements 569 o Stage 1: bandwidth and packet loss measurements 571 Stage 0 measurements are being taken through Q4S PING messages 572 sent both from both the client and the server. All Q4S PING 573 requests will be answered by Q4S 200 OK messages to allow for 574 bidirectional measurements. 576 Different client and server implementations may send a different 577 number of PING messages for measuring, although at least 255 578 messages should be considered to perform the latency measurement. 579 The Stage 0 measurements only may be considered ended when neither 580 client nor server receive new PING messages after an 581 implementation-dependent guard time. Only after, client can send a 582 "READY 1" message. 584 After a pre-agreed number of measurements have been performed, 585 determined by the measurement procedure sent by the server, three 586 scenarios may be possible: 588 a) Measurements do not meet the requirements: in this case the 589 stage 0 is repeated after sending an alert from the server to 590 the client or from the server stack to the Actuator, depending 591 on the alerting mode defined in the Handshake phase. Notice 592 that measurements continue to be taken but no alerts are sent 593 during the alert-pause time. In the Reactive scenario, the 594 Actuator will decide either to forward the alert notification 595 to the network policy server or to the application, depending 596 on where reconfiguration actions have to be taken. 598 b) Measurements do meet the requirements: in this case client 599 moves to stage 1 sending a new READY message. 601 c) At any time during the measurement procedure, the Q4S 200 OK 602 message sent by the server to the client, in response to a Q4S 603 PING message, contains an SDP body with new values of quality 604 constraints required by the application; this means the 605 application has varied their quality requirements dynamically 606 and therefore quality thresholds used while monitoring quality 607 parameters have to be changed to the new constraints. In this 608 case the client moves to the beginning of the Stage 0 for 609 initiating the negotiation measurements again. 611 Stage 1 is optional. Its purpose is to measure the availability of 612 application needed bandwidth. This stage can be skipped by client 613 sending a "READY 2" message after completion of stage 0 when 614 bandwidth requirements is set to cero kbps in the SDP. Stage 1 615 measurements are achieved through Q4S BWIDTH messages sent both 616 from the client and the server. Unlike PING messages, Q4S BWIDTH 617 requests will not be answered. 619 If Stage 0 and 1 meet the application quality constraints, the 620 application may start. Q4S will enter the continuity phase 621 measuring the network quality parameters through the Q4S PING 622 message exchange on both connection paths, and raising alerts in 623 case of violation. . 625 Once the client wants to terminate the quality session it sends a 626 Q4S CANCEL message, which will be acknowledged by the server with 627 another Q4S CANCEL message. Termination of quality sessions are 628 always initiated by the client because Q4S TCP requests follow the 629 client server schema. 631 Figure 2 depicts the message exchange in a successful scenario. 633 +-------------------------------------------+ 634 | | 635 | Client Server | 636 | | 637 Handshake | --------- Q4S BEGIN -----------> | 638 | <-------- Q4S 200 OK ----------- | 639 | | 640 Negotiation | | 641 (Stage 0) | --------- Q4S READY 0----------> | 642 | <-------- Q4S 200 OK ----------- | 643 | | 644 | --------- Q4S PING ------------> | 645 | <-------- Q4S 200 OK ----------- | 646 | <-------- Q4S PING ------------- | 647 | -------- Q4S 200 OK ----------> | 648 | --------- Q4S PING ------------> | 649 | <-------- Q4S PING ------------- | 650 | --------- Q4S 200 OK ----------> | 651 | <-------- Q4S 200 OK ----------- | 652 | ... | 653 Negotiation | | 654 (Stage 1) | --------- Q4S READY 1----------> | 655 | <-------- Q4S 200 OK ----------- | 656 | | 657 | --------- Q4S BWITDH ----------> | 658 | <-------- Q4S BWIDTH------------ | 659 | --------- Q4S BWITDH ----------> | 660 | <-------- Q4S BWIDTH------------ | 661 | ... | 662 Continuity | --------- Q4S READY 2 ---------> | 663 | <-------- Q4S 200 OK ----------- | app 664 start 665 | | 666 | --------- Q4S PING ------------> | 667 | <-------- Q4S 200 OK ----------- | 668 | <-------- Q4S PING ------------- | 669 | -------- Q4S 200 OK ----------> | 670 | | 671 Termination | --------- Q4S CANCEL ----------> | app end 672 | <-------- Q4S CANCEL ----------- | 673 | | 674 +-------------------------------------------+ 675 Figure 2 Successful Q4S message exchange. 677 Client and server measurements are included into PING and BWIDTH 678 messages, allowing both sides of the communication to be are aware 679 of all measurements in both directions. 681 The following two examples show the behavior of the Q4S protocol 682 when: quality constraints are violated, alerts are generated; and, 683 later on, violation of quality constraints stops leading to the 684 execution of the recovery process. The first example (Figure 3) 685 shows the Q4S-aware-network alerting mode scenario: 687 +-------------------------------------------+ 688 | | 689 | Client Server | 690 | | 691 Handshake | --------- Q4S BEGIN -----------> | 692 | <-------- Q4S 200 OK ----------- | 693 | | 694 Negotiation | | 695 (Stage 0) | --------- Q4S READY 0----------> | 696 | <-------- Q4S 200 OK ----------- | 697 | | 698 | --------- Q4S PING ------------> | 699 | <-------- Q4S 200 OK ----------- | 700 | <-------- Q4S PING ------------- | 701 | -------- Q4S 200 OK ----------> | 702 | ... | 703 | | 704 | <-------- Q4S ALERT ------------ | 705 | -------- Q4S ALERT ------------> | 706 | (alert-pause start) | 707 Repetition | | 708 of Stage 0 | --------- Q4S READY 0----------> | 709 | <-------- Q4S 200 OK ----------- | 710 | | 711 | --------- Q4S PING ------------> | 712 | <-------- Q4S 200 OK ----------- | 713 | <-------- Q4S PING ------------- | 714 | ... | 715 Negotiation | | 716 (Stage 1) | --------- Q4S READY 1----------> | 717 | <-------- Q4S 200 OK ----------- | 718 | | 719 | --------- Q4S BWITDH ----------> | 720 | <-------- Q4S BWIDTH------------ | 721 | ... | 722 | | 723 Continuity | --------- Q4S READY 2 ---------> | 724 | <-------- Q4S 200 OK ----------- | app 725 start 726 | | 727 | --------- Q4S PING ------------> | 728 | <-------- Q4S 200 OK ----------- | 729 | <-------- Q4S PING ------------- | 730 | -------- Q4S 200 OK ----------> | 731 | ... | 732 |(alert-pause expires & | 733 | violated constraints) | 734 | <-------- Q4S ALERT ------------ | 735 | --------- Q4S ALERT -----------> | 736 | | 737 | (alert-pause start) | 738 | --------- Q4S PING ------------> | 739 | <-------- Q4S 200 OK ----------- | 740 | <-------- Q4S PING ------------- | 741 | --------- Q4S 200 OK ----------> | 742 | ... | 743 |(alert-pause expires & | 744 | violated constraints) | 745 | <-------- Q4S ALERT ------------ | 746 | --------- Q4S ALERT -----------> | 747 | (alert-pause) | 748 | --------- Q4S PING ------------> | 749 | <-------- Q4S 200 OK ----------- | 750 | <-------- Q4S PING ------------- | 751 | -------- Q4S 200 OK ----------> | 752 | ... | 753 |(alert-pause expires & | 754 | Fullfilled constraints) | 755 | | 756 | (recovery-pause start) | 757 | | 758 | --------- Q4S PING ------------> | 759 | <-------- Q4S 200 OK ----------- | 760 | <-------- Q4S PING ------------- | 761 | -------- Q4S 200 OK ----------> | 762 | ... | 763 |(recovery-pause expires & | 764 | Fullfilled constraints) | 765 | <--------- Q4S RECOVERY --------- | 766 | -------- Q4S RECOVERY -----------> | 767 | | 768 | (recovery-pause start) | 769 | --------- Q4S PING ------------> | 770 | <-------- Q4S 200 OK ----------- | 771 | <-------- Q4S PING ------------- | 772 | -------- Q4S 200 OK ----------> | 773 | ... | 774 | | 775 Termination | --------- Q4S CANCEL ----------> | app end 776 | <-------- Q4S CANCEL ----------- | 777 | | 778 +-------------------------------------------+ 779 Figure 3 Q4S-aware-network alerting mode. 781 In this Q4S-aware-network alerting mode scenario, the server may 782 send Q4S alerts to the client at any time on detection of violated 783 quality constraints. This alerting exchange must not interrupt the 784 continuity quality parameter measurements between client and 785 server. 787 The second example depicted in the figure 4 represents the 788 Reactive scenario, in which alert notifications are sent from the 789 server stack to the Actuator which is in charge of deciding either 790 to act over application behavior and/or invoke a network policy 791 server. The Actuator is an entity that has a pre-defined set of 792 different quality levels and decides how to act depending on the 793 actions stated for each of these levels; it can take actions for 794 making adjustments on the application or it can send a request to 795 the policy server for acting on the network. The policy server 796 also has a pre-defined set of different quality levels pre-agreed 797 upon between the Application Content Provider and the ISP. The 798 Reactive alerting mode is the default mode. 800 +-------------------------------------------+ 801 | | 802 | Client Server Actuator | 803 Handshake | ----- Q4S BEGIN -----> | 804 | <---- Q4S 200 OK ----- | 805 | | 806 Negotiation | | 807 (Stage 0) | ----- Q4S READY 0----> | 808 | <---- Q4S 200 OK ----- | 809 | | 810 | ----- Q4S PING ------> | 811 | <---- Q4S 200 OK ----- | 812 | <---- Q4S PING ------- | 813 | ---- Q4S 200 OK ----> | 814 | ... | 815 | (alert-pause start) | 816 | --alert | 817 | notification--> | 818 | | 819 | <--alert | 820 | acknowledge--- | 821 | | 822 Repetition | | 823 of Stage 0 | ----- Q4S READY 0----> | 824 | <---- Q4S 200 OK ----- | 825 | | 826 | ----- Q4S PING ------> | 827 | <---- Q4S 200 OK ----- | 828 | <---- Q4S PING ------- | 829 | ... | 830 |(alert-pause expires & | 831 | violated constraints) | 832 | | 833 | --alert | 834 | notification--> | 835 | | 836 | <--alert | 837 | acknowledge--- | 838 | | 839 | ----- Q4S PING ------> | 840 | <---- Q4S 200 OK ----- | 841 | <---- Q4S PING ------- | 842 | ... | 843 Negotiation | | 844 (Stage 1) | ----- Q4S READY 1----> | 845 | <---- Q4S 200 OK ----- | 846 | | 847 | ----- Q4S BWITDH ----> | 848 | <---- Q4S BWIDTH------ | 849 | ... | 851 Continuity | ----- Q4S READY 2 ---> | 852 | <---- Q4S 200 OK ----- | app 853 start 854 | | 855 |(alert-pause expires & | 856 | fulfilled constraints) | 857 | | 858 |(recovery-pause start) | 859 | ----- Q4S PING ------> | 860 | <---- Q4S 200 OK ----- | 861 | <---- Q4S PING ------- | 862 | ----- Q4S PING ------> | 863 | | 864 |(recovery-pause expires & | 865 | fulfilled constraints) | 866 | | 867 | --recovery | 868 | notification--> | 869 | | 870 | <--recovery | 871 | acknowledge--- | 872 | | 873 |(recovery-pause start) | 874 | <---- Q4S 200 OK ----- | 875 | <---- Q4S PING ------- | 876 | ----- Q4S 200 OK ----> | 877 | ----- Q4S PING ------> | 878 | ... | 879 | | 880 Termination | ----- Q4S CANCEL ----> | app end 881 | --cancel | 882 | notification--> | 883 | | 884 | <--cancel | 885 | acknowledge-- | 886 | <---- Q4S CANCEL ----- | 887 | | 888 +-------------------------------------------+ 889 Figure 4 Reactive alerting mode. 891 At the end of any Negotiation phase stage, the server sends an 892 alert notification to the Actuator if quality constraints are 893 violated. During the period of time defined by the alert-pause 894 parameter, no further alert notifications are sent, but 895 measurements are not interrupted. This way, both the client and 896 the server will detect network improvements as soon as possible. 897 In a similar way, during the continuity phase, the server may send 898 alert notifications at any time to the Actuator on detection of 899 violated quality constraints. This alerting exchange must not 900 interrupt the continuity measurements between client and server. 902 Finally, in the Termination phase, Q4S CANCEL messages sent from 903 the client to the server must be forwarded from the server to the 904 Actuator in order to release possible assigned resources for the 905 session. 907 4 Q4S Messages 909 Q4S is a text-based protocol and uses the UTF-8 charset (RFC 3629 910 [19]). A Q4S message is either a request or a response. 912 Both Request and Response messages use the basic format of 913 Internet Message Format (RFC 5322 [20]). Both types of messages 914 consist of a start-line, one or more header fields, an empty line 915 indicating the end of the header fields, and an optional message- 916 body. 918 The start-line, each message-header line, and the empty line MUST 919 be terminated by a carriage-return line-feed sequence (CRLF). 920 Note that the empty line MUST be present even if the message-body 921 is not. 923 generic-message = start-line CRLF 924 *message-header CRLF 925 CRLF 926 [ message-body ] 927 start-line = Request-Line / Status-Line 929 Much of Q4S's messages and header field syntax are identical to 930 HTTP/1.1. However, Q4S is not an extension of HTTP. 932 4.1 Requests 934 Q4S requests are distinguished by having a Request-Line for a 935 start-line. A Request-Line contains a method name, a Request-URI, 936 and the protocol version separated by a single space (SP) 937 character. 939 The Request-Line ends with CRLF. No CR or LF are allowed except in 940 the end-of-line CRLF sequence. No linear whitespace (LWS) is 941 allowed 942 in any of the elements. 944 Request-Line = Method SP Request-URI SP Q4S-Version CRLF 946 Method: This specification defines seven methods: BEGIN for 947 starting and negotiate quality sessions, READY for 948 synchronization of measurements, PING and BWIDTH for 949 quality measurements purpose, CANCEL for terminating 950 sessions, Q4S-ALERT for quality violations reporting, and 951 Q4S-RECOVERY for quality recovery reporting. 953 Request-URI: The Request-URI is a Q4S URI (RFC 2396) as described 954 in 7.4. The Request-URI MUST NOT contain unescaped spaces 955 or control characters and MUST NOT be enclosed in "<>". 957 Q4S-Version: Both request and response messages include the 958 version of Q4S in use. To be compliant with this 959 specification, applications sending Q4S messages MUST 960 include a Q4S-Version of "Q4S/1.0". The Q4S-Version string 961 is case-insensitive, but implementations MUST send upper- 962 case. Unlike HTTP/1.1, Q4S treats the version number as a 963 literal string. In practice, this should make no 964 difference. 966 4.2 Responses 968 Q4S responses are distinguished from requests by having a Status- 969 Line as their start-line. A Status-Line consists of the protocol 970 version followed by a numeric Status-Code and its associated 971 textual phrase, with each element separated by a single SP 972 character. No CR or LF is allowed except in the final CRLF 973 sequence. 975 Status-Line = Q4S-Version SP Status-Code SP Reason-Phrase CRLF 977 The Status-Code is a 3-digit integer result code that indicates 978 the outcome of an attempt to understand and satisfy a request. The 979 Reason-Phrase is intended to give a short textual description of 980 the Status-Code. The Status-Code is intended for use by automata, 981 whereas the Reason-Phrase is intended for the human user. A client 982 is not required to examine or display the Reason-Phrase. 984 While this specification suggests specific wording for the reason 985 phrase, implementations MAY choose other text, for example, in the 986 language indicated in the Accept-Language header field of the 987 request. 989 The first digit of the Status-Code defines the class of response. 990 The last two digits do not have any categorization role. For this 991 reason, any response with a status code between 100 and 199 is 992 referred to as a "1xx response", any response with a status code 993 between 200 and 299 as a "2xx response", and so on. Q4S/1.0 994 allows following values for the first digit: 996 1xx: Provisional -- request received, continuing to process 997 the request; 999 2xx: Success -- the action was successfully received, 1000 understood, and accepted; 1002 3xx: Redirection -- further action needs to be taken in 1003 order 1004 to complete the request; 1006 4xx: Request Failure -- the request contains bad syntax or 1007 cannot be fulfilled at this server; 1009 5xx: Server Error -- the server failed to fulfill an 1010 apparently valid request; 1012 6xx: Global Failure -- the request cannot be fulfilled at 1013 any 1014 server. 1016 The status codes are the same described in HTTP (RFC 7231 [2]). In 1017 the same way as HTTP, Q4S applications are not required to 1018 understand the meaning of all registered status codes, though such 1019 understanding is obviously desirable. However, applications MUST 1020 understand the class of any status code, as indicated by the first 1021 digit, and treat any unrecognized response as being equivalent to 1022 the x00 status code of that class. 1024 The Q4S-ALERT, Q4S-RECOVERY and CANCEL requests do not have to be 1025 responded. However, after receiving a Q4S-ALERT, Q4S-RECOVERY or 1026 CANCEL request, the server SHOULD send a Q4S-ALERT, Q4S-RECOVERY 1027 or CANCEL request to the client 1029 4.3 Header Fields 1031 Q4S header fields are identical to HTTP header fields in both 1032 syntax and semantics. 1034 Some header fields only make sense in requests or responses. These 1035 are called request header fields and response header fields, 1036 respectively. If a header field appears in a message not matching 1037 its category (such as a request header field in a response), it 1038 MUST be ignored. 1040 4.3.1 Common Q4S Header Fields 1042 These fields may appear in Request and Response messages. 1044 o Session-Id: the value for this header is the same session id 1045 used in SDP (embedded in "o" SDP parameter) and is assigned 1046 by the server. The messages without SDP MUST include this 1047 header. If a message has and SDP body, this header is 1048 optional. The method of allocation is up to the 1049 creating tool, but it is suggested that a UTC timestamp be 1050 used to ensure uniqueness. 1052 o Sequence-Number: sequential and cyclic positive integer 1053 number assigned to PING and BWIDTH messages, and acknowledged 1054 in 200 OK responses. 1056 o Timestamp: this optional header contains the system time 1057 (with the best possible accuracy). It indicates the time in 1058 which the PING request was sent. If this header is present in 1059 PING messages, then the 200 OK response messages MUST include 1060 this value. 1062 o Stage: this is used in client's READY requests and server's 1063 200 OK responses during the Negotiation and Continuity phases 1064 in order to synchronize the initiation of the measurements. 1065 Example: Stage: 0 1067 4.3.2 Specific Q4S Request Header Fields 1069 In addition to HTTP header fields, these are the specific Q4S 1070 request header fields 1072 o User-Agent: this header contains information about the 1073 implementation of the user agent. This is for statistical 1074 purposes, the tracing of protocol violations, and the 1075 automated recognition of user agents for the sake of 1076 tailoring responses to avoid particular user agent 1077 limitations. User agents SHOULD include this field with 1078 requests. The field MAY contain multiple product tokens and 1079 comments identifying the agent and any sub-products which 1080 form a significant part of the user agent. By convention, the 1081 product tokens are listed in order of their significance for 1082 identifying the application. 1084 o Signature: this header contains a digital signature that can 1085 be used by the network, actuator or policy server to validate 1086 the SDP, preventing security attacks. The signature is an 1087 optional header generated by the server according to the pre- 1088 agreed security policies between the Application Content 1089 Provider and the ISP. For example, a hash algorithm and 1090 encryption method such as SHA256 (RFC 4634 [14]) and RSA (RFC 1091 8017 [15]) based on the server certificate could be used. 1092 This certificate is supposed to be delivered by a 1093 Certification Authority (CA) or policy owner to the server. 1094 The signature is applied to the SDP body. 1096 Signature= RSA ( SHA256 (), ) 1098 If the signature is not present, other validation mechanism 1099 MAY be implemented in order to provide assured quality with 1100 security and control. 1102 o Measurements: this header carries the measurements of the 1103 quality parameters in PING and BWIDTH requests. The format 1104 is: 1106 Measurements: "l=" " "|[0..9999] ", j=" " "|[0..9999] ", pl=" 1107 " "|[0.00 .. 100.00] ", bw=" " "|[0..999999] 1109 Where "l" stands for latency followed by the measured value 1110 (in milliseconds)or an empty space, "j" stands for jitter 1111 followed by the measured value (in milliseconds) or an empty 1112 space, "pl" stands for packetloss followed by the measured 1113 value (in percentage with two decimals) or an empty space 1114 and "bw" stands for bandwidth followed by the measured value 1115 (in kbps) or an empty space. 1117 4.3.3 Specific Q4S Response Header Fields 1119 o Expires: its purpose is to provide a sanity check and allow 1120 the server to close inactive sessions. If the client does not 1121 send a new request before the expiration time, the server MAY 1122 close the session. The value MUST be an integer and the 1123 measurement units are milliseconds. 1125 In order to keep the session open the server MUST send a Q4S 1126 alert before the session expiration (Expires header), with 1127 the same quality levels and an alert cause of "keep-alive". 1128 The purpose of this alert is to avoid TCP sockets (which were 1129 opened with READY message) from being closed, specially in 1130 NAT scenarios. 1132 4.4 Bodies 1134 Requests, including new requests defined in extensions to this 1135 specification, MAY contain message bodies unless otherwise noted. 1136 The interpretation of the body depends on the request method. 1138 For response messages, the request method and the response status 1139 code determine the type and interpretation of any message body. 1140 All responses MAY include a body. 1142 The Internet media type of the message body MUST be given by the 1143 Content-Type header field. 1145 4.4.1 Encoding 1147 The body MUST NOT be compressed. This mechanism is valid for 1148 other protocols such as HTTP and SIP (RFC 3261 [22]), but 1149 a compression/coding scheme will limit certain logical 1150 implementations of the way the request is parsed, thus, making the 1151 protocol concept more implementation dependent. In addition, 1152 bandwidth calculation may not be valid if compression is used. 1153 Therefore, the HTTP request header "Accept-Encoding" cannot be 1154 used in Q4S with different values than "identity" and if it is 1155 present in a request, the server MUST ignore it. In addition, the 1156 response header "Content-Encoding" is optional, but if present, 1157 the unique permitted value is "identity". 1159 The body length in bytes MUST be provided by the Content-Length 1160 header field. The "chunked" transfer encoding of HTTP/1.1 MUST NOT 1161 be used for Q4S (Note: The chunked encoding modifies the body of a 1162 message in order to transfer it as a series of chunks, each one 1163 with its own size indicator.) 1165 5 Q4S Method Definitions 1167 The Method token indicates the method to be performed on the 1168 resource identified by the Request-URI. The method is case- 1169 sensitive. 1171 Method = "BEGIN" | "READY" | "PING" | "BWIDTH" | 1172 "Q4S-ALERT" | "Q4S-RECOVERY" | "CANCEL" | 1173 extension-method 1175 extension-method = token 1177 The list of methods allowed by a resource can be specified in an 1178 "Allow" header field (RFC 7231 [2]). The return code of the 1179 response always notifies the client when a method is currently 1180 allowed on a resource, since the set of allowed methods can change 1181 dynamically. Any server application SHOULD return the status code 1182 405 (Method Not Allowed) if the method is known, but not allowed 1183 for the requested resource, and 501 (Not Implemented) if the 1184 method is unrecognized or not implemented by the server. 1186 5.1 BEGIN 1188 The BEGIN method requests information from a resource identified 1189 by a Q4S URI. The semantics of this method is the starting of a 1190 quality session. 1192 This method is only used during the handshake phase to retrieve 1193 the SDP containing session id and all quality and operation 1194 parameters for the desired application to run. 1196 When a BEGIN message is received by the server, any current 1197 quality session MUST be cancelled, and a new session should be 1198 created. 1200 The response to a Q4S BEGIN request is not cacheable. 1202 5.2 READY 1204 The READY method is used to synchronize the starting time for 1205 sending of PING and BWIDTH messages over UDP between clients and 1206 servers. The stage header included in this method is mandatory. 1208 This message is only used in negotiation and continuity phases, 1209 and only just before making a measurement. Otherwise (out of this 1210 context), the server MUST ignore this method. 1212 5.3 PING 1214 This message is used during the negotiation and continuity phases 1215 to measure the RTT and jitter of a session. The message MUST be 1216 sent only over UDP ports. 1218 The fundamental difference between the PING and BWIDTH requests is 1219 reflected in the different measurements achieved with them. PING 1220 is a short message, and MUST be answered in order to measure RTT 1221 and jitter, whereas BWIDTH is a long message and MUST NOT be 1222 answered. 1224 PING is a request method that can be originated by client but also 1225 by server. Client MUST also answer the server PING messages, 1226 assuming a "server role" for these messages during measurement 1227 process. 1229 The Measurements header included in this method is mandatory, and 1230 provides updated measurements values for latency, jitter and 1231 packet loss to the counterpart. 1233 5.4 BWIDTH 1235 This message is used only during the Negotiation phase to measure 1236 the bandwidth and packet loss of a session. The message MUST be 1237 sent only over UDP ports. 1239 BWIDTH is a request method that can be originated by the client 1240 but also by server. Both (client and server) MUST NOT answer 1241 BWIDTH messages. 1243 The Measurements header included in this method is mandatory and 1244 provides updated measurements values for bandwidth and packet loss 1245 to the counterpart. 1247 5.5 Q4S-ALERT 1249 This is the request message that Q4S generates when the 1250 measurements indicate that quality constraints are being violated. 1251 It is used during the negotiation and continuity phases. 1253 This informative message indicates that the user experience is 1254 being degraded and includes the details of the problem (bandwidth, 1255 jitter, packet loss measurements). The Q4S-ALERT message does not 1256 contain any detail on the actions to be taken, which depends on 1257 the agreements between all involved parties. 1259 Q4S-ALERT request does not have to be answered with a response 1260 message unless there is an error condition, but with an answer 1261 formatted as a request Q4S-ALERT message. The response to a Q4S- 1262 ALERT request is not cacheable. 1264 This method MUST be initiated by the server in both alerting 1265 modes. In Q4S-aware-network alerting mode, the Q4S-ALERT messages 1266 are fired by the server and sent to the client, advising the 1267 network to react by itself. In Reactive alerting mode, alert 1268 notifications are triggered by the server stack and sent to the 1269 Actuator(see Figure1 "Reactive Scenario"). 1271 Client----q4s----SERVER STACK--->ACTUATOR-->APP OR POLICY SERVER 1273 The way in which the server stack notifies the Actuator is 1274 implementation dependent, and the communication between the 1275 Actuator and the network policy server is defined by the protocol 1276 and API that the policy server implements. 1278 5.6 Q4S-RECOVERY 1280 This is the request message that Q4S generates when the 1281 measurements indicate that quality constraints were being violated 1282 but they have been fulfilled during a period of time already 1283 (recovery pause). It is used during the negotiation and continuity 1284 phases. 1286 This informative message indicates that the qos-level could be 1287 increased gradually until the initial qos-level is recovered (the 1288 qos-level established at the beginning os the session of that was 1289 decreased during violation of constraints). The Q4S-RECOVERY 1290 message does not contain any detail on the actions to be taken, 1291 which depends on the agreements between all involved parties. 1293 Q4S-RECOVERY request MUST NOT be answered with a response message 1294 unless there is an error condition, but with an answer formatted 1295 as a request Q4S-RECOVERY message. The response to a Q4S-RECOVERY 1296 request is not cacheable. 1298 As for the Q4S-ALERT message, the Q4S-RECOVERY method is always 1299 initiated by the server in both alerting modes. In Q4S-aware- 1300 network alerting mode, the Q4S-RECOVERY messages are fired by the 1301 server and sent to the client, advising the network to react by 1302 itself. In Reactive alerting mode, recovery notifications are 1303 triggered by the server stack and sent to the Actuator(see Figure1 1304 "Reactive Scenario"). 1306 5.7 CANCEL 1308 The semantics of CANCEL message is the release of the Q4S session 1309 id and the possible resources assigned to the session. This 1310 message could be triggered by Q4S stack or by the application 1311 using the stack (through an implementation dependent API). 1313 In the same way as Q4S-ALERT, CANCEL must not be answered with a 1314 response message, but with an answer formatted as a request Q4S- 1315 CANCEL message. 1317 In the Reactive scenario, the server stack MUST react to the Q4S 1318 CANCEL messages received from the client by forwarding a cancel 1319 notification to the Actuator, in order to release possible 1320 assigned resources for the session (at application or at policy 1321 server). The Actuator MUST answer the cancel notification with a 1322 cancel acknowledge towards the server stack, acknowledging the 1323 reception. 1325 6 Response Codes 1327 Q4S response codes are used for TCP and UDP. However, in UDP only 1328 the response code 200 is used. 1330 The receiver of an unknown response code must take a generic 1331 action for the received error group (1XX, 2XX, 3XX, 4XX, 5XX, 1332 6XX). In case of unknown error group, the expected action should 1333 be the same as with 6XX error group. 1335 6.1 100 Trying 1337 This response indicates that the request has been received by the 1338 next-hop server and that some unspecified action is being taken on 1339 behalf of this request (for example, a database is being 1340 consulted). This response, like all other provisional responses, 1341 stops retransmissions of a Q4S-ALERT during the alert-pause time. 1343 6.2 Success 2xx 1345 2xx responses give information about success of a request. 1347 6.2.1 200 OK 1349 The request has succeeded. 1351 6.3 Redirection 3xx 1353 3xx responses give information about the user's new location, or 1354 about alternative services that might be able to satisfy the 1355 request. 1357 The requesting client SHOULD retry the request at the new 1358 address(es) given by the Location header field. 1360 6.4 Request Failure 4xx 1362 4xx responses are definite failure responses from a particular 1363 server. The client SHOULD NOT retry the same request without 1364 modification (for example, adding appropriate headers or SDP 1365 values). However, the same request to a different server might be 1366 successful. 1368 6.4.1 400 Bad Request 1370 The request could not be understood due to malformed syntax. The 1371 Reason-Phrase SHOULD identify the syntax problem in more detail, 1372 for example, "Missing Sequence-Number header field". 1374 6.4.2 404 Not Found 1376 The server has definitive information that the user does not exist 1377 at the domain specified in the Request-URI. This status is also 1378 returned if the domain in the Request-URI does not match any of 1379 the domains handled by the recipient of the request. 1381 6.4.3 405 Method Not Allowed 1383 The method specified in the Request-Line is understood, but not 1384 allowed for the address identified by the Request-URI. 1386 The response MUST include an Allow header field containing a list 1387 of valid methods for the indicated address. 1389 6.4.4 406 Not Acceptable 1391 The resource identified by the request is only able of generating 1392 response entities that have content characteristics not acceptable 1393 according to the Accept header field sent in the request. 1395 6.4.5 408 Request Timeout 1397 The server could not produce a response within a suitable amount 1398 of time, and the client MAY repeat the request without 1399 modifications at any later time 1401 6.4.6 413 Request Entity Too Large 1403 The server is refusing to process a request because the request 1404 entity-body is larger than the one that the server is willing or 1405 able to process. The server MAY close the connection to prevent 1406 the client from continuing the request. 1408 6.4.7 414 Request-URI Too Long 1410 The server is refusing to process the request because the Request- 1411 URI is longer than the one that the server accepts. 1413 6.4.8 415 Unsupported Media Type 1415 The server is refusing to process the request because the message 1416 body of the request is in a format not supported by the server for 1417 the requested method. The server MUST return a list of acceptable 1418 formats using the Accept, Accept-Encoding, or Accept-Language 1419 header field, depending on the specific problem with the content. 1421 6.4.9 416 Unsupported URI Scheme 1423 The server cannot process the request because the scheme of the 1424 URI in the Request-URI is unknown to the server. 1426 6.5 Server Failure 5xx 1428 5xx responses are failure responses given when a server itself is 1429 having trouble. 1431 6.5.1 500 Server Internal Error 1433 The server encountered an unexpected condition that prevented it 1434 from fulfilling the request. The client MAY display the specific 1435 error condition and MAY retry the request after several seconds. 1437 6.5.2 501 Not Implemented 1439 The server does not support the functionality required to fulfill 1440 the request. This is the appropriate response when a Server does 1441 not recognize the request method and it is not capable of 1442 supporting it for any user. 1444 Note that a 405 (Method Not Allowed) is sent when the server 1445 recognizes the request method, but that method is not allowed or 1446 supported. 1448 6.5.3 503 Service Unavailable 1450 The server is temporarily unable to process the request due to a 1451 temporary overloading or maintenance of the server. The server MAY 1452 indicate when the client should retry the request in a Retry-After 1453 header field. If no Retry-After is given, the client MUST act as 1454 if it had received a 500 (Server Internal Error) response. 1456 A client receiving a 503 (Service Unavailable) SHOULD attempt to 1457 forward the request to an alternate server. It SHOULD NOT forward 1458 any other requests to that server for the duration specified in 1459 the Retry-After header field, if present. 1461 Servers MAY refuse the connection or drop the request instead of 1462 responding with 503 (Service Unavailable). 1464 6.5.4 504 Server Time-out 1466 The server did not receive a timely response from an external 1467 server it accessed in attempting to process the request. 1469 6.5.5 505 Version Not Supported 1471 The server does not support, or refuses to support, the Q4S 1472 protocol version that was used in the request. The server is 1473 indicating that it is unable or unwilling to complete the request 1474 using the same major version as the client, other than with this 1475 error message. 1477 In the case that Q4S version is not supported, this error may be 1478 sent by the server in handshake phase just after receiving the 1479 first BEGIN message from client. 1481 6.5.6 513 Message Too Large 1483 The server was unable to process the request since the message 1484 length exceeded its capabilities. 1486 6.6 Global Failures 6xx 1488 6xx responses indicate that a server has definitive information 1489 about a particular policy not satisfied for processing the 1490 request. 1492 6.6.1 600 session does not exist 1494 The Session-Id is not valid 1496 6.6.2 601 quality level not allowed 1498 The QOS level requested is not allowed for the pair client/server 1500 6.6.3 603 Session not allowed 1502 The session is not allowed due to some policy (number of sessions 1503 allowed for the server is exceeded, or the time band of the Q4S- 1504 ALERT is not allowed for the pair client/server, etc.). 1506 6.6.4 604 authorization not allowed 1508 The policy server does not authorize the Q4S-ALERT quality session 1509 improvement operation due to an internal or external reason. 1511 7 Protocol 1513 This section describes the measurement procedures, the SDP 1514 structure of the Q4S messages, the different Q4S protocol phases 1515 and the messages exchanged in them. 1517 7.1 Protocol Phases 1519 All elements of the IP network contribute to the quality in 1520 terms of latency, jitter, bandwidth and packet loss. All these 1521 elements have their own quality policies in terms of priorities, 1522 traffic mode, etc. and each element has its own way to manage the 1523 quality. The purpose of a quality connection is to establish an 1524 end-to-end communication with enough quality for the application 1525 to function flawlessly. 1527 To monitor quality constraints of the application, four phases are 1528 defined and can be seen in figure 5: 1530 +---------------------------------------------------------------+ 1531 | | 1532 | | 1533 | Handshake ---> Negotiation -+--> Continuity ----> Termination | 1534 | A | (app start) | (app end) | 1535 | | V A V A | 1536 | | violated | violated | | 1537 | | constraints | constraints | | 1538 | | | | |_______| ____| | 1539 | | | | +-------+ | | 1540 | | | | | | 1541 | +------+ +---------------------+ | 1542 | | 1543 +---------------------------------------------------------------+ 1545 Figure 5 Session lifetime phases. 1547 o Handshake phase: in which the server is contacted by the 1548 client and in the answer message the quality constraints for 1549 the application is communicated embedded in an SDP. 1551 o Negotiation phase: in which the quality of the connection is 1552 measured in both directions (latency, jitter, bandwidth and 1553 packet loss), and Q4S messages may be sent in order to alert 1554 if the measured quality does not meet the constraints. This 1555 phase is iterative until quality constraints are reached, or 1556 the session is cancelled after a number of measurement cycles 1557 with consistent violation of the quality constraints. The 1558 number of measurement cycles executed depends on the qos- 1559 level which is incremented in each cycle until a maximum qos- 1560 level value is reached. Just after reaching the quality 1561 requirements, Q4S provides a simple optional mechanism using 1562 HTTP to start the application. 1564 o Continuity phase: in which quality is continuously measured. 1565 In this phase the measurements MUST avoid disturbing the 1566 application by consuming network resources. If quality 1567 constraints are not met, the server stack will notify the 1568 Actuator with an alert notification. If later the quality 1569 improves, the server stack will notify the Actuator, in this 1570 case with a recovery notification. After several alert 1571 notifications with no quality improvements, the Q4S stack 1572 SHOULD move to Termination phase. 1574 o Termination phase: in which the Q4S session is terminated. 1575 The application may be closed too or may not start. 1577 7.2 SDP Structure 1579 The original goal of SDP was to announce necessary information for 1580 the participants and multicast MBONE (Multicast Backbone) 1581 applications. Right now, its use has been extended to the 1582 announcement and the negotiation of multimedia sessions. The 1583 purpose of Q4S is not to establish media stream sessions, but to 1584 monitor a quality connection. This connection may be later used to 1585 establish any type of session including media sessions; Q4S does 1586 not impose any conditions on the type of communication requiring 1587 quality parameters. 1589 SDP will be used by Q4S to exchange quality constraints and will 1590 therefore always have all the media attributes ("m") set to zero. 1592 The SDP embedded in the messages is the container of the quality 1593 parameters. As these may vary depending on the direction of the 1594 communication (to and from the client) all quality parameters need 1595 to specify the uplink and downlink values: / . 1596 When one or both of these values are empty, it MUST be understood 1597 as needing no constraint on that parameter and/or that direction. 1599 The uplink direction MUST be considered as being the communication 1600 from the client to the server. The downlink direction MUST be 1601 considered as being the communication from the server to the 1602 client. 1604 The SDP information can comprise all or some of the following 1605 parameters shown in the example below. This is an example of an 1606 SDP message used by Q4S included in the 200 OK response to a Q4S 1607 BEGIN request. 1609 v=0 1610 o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33 1611 s=Q4S 1612 i=Q4S parameters 1613 t=0 0 1614 a=qos-level:0/0 1615 a=alerting-mode:Reactive 1616 a=alert-pause:5000 1617 a=public-address:client IP4 198.51.100.51 1618 a=public-address:server IP4 198.51.100.58 1619 a=measurement:procedure default(50/50,75/75,5000,40/80,100/256) 1620 a=latency:40 1621 a=jitter:10/10 1622 a=bandwidth:20/6000 1623 a=packetloss:0.50/0.50 1624 a=flow:app clientListeningPort TCP/10000-20000 1625 a=flow:app clientListeningPort UDP/15000-18000 1626 a=flow:app serverListeningPort TCP/56000 1627 a=flow:app serverListeningPort UDP/56000 1628 a=flow:q4s clientListeningPort UDP/55000 1629 a=flow:q4s clientListeningPort TCP/55001 1630 a=flow:q4s serverListeningPort UDP/56000 1631 a=flow:q4s serverListeningPort TCP/56001 1633 As quality constraints may be changed by applications at any time 1634 during the Q4S session lifetime, any Q4S 200 OK response sent by 1635 the server to the client in the Negotiation and Continuity phases 1636 could also include an SDP body with the new quality requirements 1637 stated by the applications from then on. Therefore, in response to 1638 any PING request sent by the client to the server, the server 1639 could send a Q4S 200 OK with an SDP message embedded that 1640 specifies new quality constraints requested by the application. 1642 7.2.1 "qos-level" attribute 1644 The "qos-level" attribute contains the QoS level for uplink and 1645 downlink. Default values are 0 for both directions. The meaning of 1646 each level is out of scope of Q4S, but a higher level SHOULD 1647 correspond to a better service quality. 1649 Appropriate attribute values: [0..9] "/" [0..9] 1651 The "qos-level" attribute may be changed during the session 1652 lifetime raising or lowering the value as necessary following the 1653 network measurements and the application needs. 1655 7.2.2 "alerting-mode" attribute 1657 The "alerting-mode" attribute specifies the player in charge of 1658 triggering Q4S alerts in case of constraint violation. There are 1659 two possible values: 1661 Appropriate attribute values: <"Q4S-aware-network"|"Reactive"> 1663 a) Q4S-aware-network: Q4S ALERT messages are triggered by the 1664 server to the client. In this case the network is supposed to 1665 be Q4S aware, and reacts by itself to these alerts. 1667 b) Reactive: alert notifications are sent by the server stack to 1668 the Actuator. In this case the network is not Q4S aware and a 1669 specific node (Actuator) is in charge of triggering tuning 1670 mechanisms., either on the network or in the application. 1672 The "alerting-mode" attribute is optional and if not present 1673 Reactive alerting mode is assumed. 1675 7.2.3 "alert-pause" attribute 1677 In the Q4S-aware-network scenario, the "alert-pause" attribute 1678 specifies the amount of time (in milliseconds) the server waits 1679 between consecutive Q4S ALERT messages sent to the client. In the 1680 Reactive scenario, the "alert-pause" attribute specifies the 1681 amount of time (in milliseconds) the server stack waits between 1682 consecutive alert notifications sent to the Actuator. Measurements 1683 are not stopped in Negotiation or Continuity Phases during this 1684 period of time, but no Q4S ALERT messages or alert notifications 1685 are fired, even with violated quality constraints, allowing either 1686 network reconfigurations or application adjustments. 1688 Appropriate attribute values: [0..60000] 1690 7.2.4 "recovery-pause" attribute 1692 In the Q4S-aware-network scenario, the "recovery-pause" attribute 1693 specifies the amount of time (in milliseconds) the server waits 1694 for initiating the qos-level recovery process. Once the recovery 1695 process has started, the "recovery-pause" attribute also states 1696 the amount of time (in milliseconds) between consecutive Q4S- 1697 RECOVERY messages sent by the server to the client (in the Q4S- 1698 aware-network scenario), or between recovery notifications sent by 1699 the server stack to the Actuator (in the Reactive scenario). 1701 Appropriate attribute values: [0..60000] 1703 7.2.5 "public-address" attributes 1705 This attribute contains the public IP address of the client and 1706 the server. The server fills these attributes with his own public 1707 IP address and the public IP address of the first message received 1708 from the client in the handshake phase. 1710 The purpose of these attributes is to make available the 1711 addressing information to network policy server or other external 1712 entities in charge of processing Q4S-ALERT messages. 1714 Appropriate attribute values:<"client"|"server"><"IP4"|"IP6"> 1715 1717 7.2.6 "latency" attribute 1719 The maximum latency (considered equal for uplink and downlink) 1720 tolerance are specified in the "latency" attribute, expressed in 1721 milliseconds. In the Q4S-aware-network scenario, if the latency 1722 constraints are not met, a Q4S-ALERT method will be sent to the 1723 client. In the Reactive scenario, if the latency constraints are 1724 not met, an alert notification will be sent to the Actuator. If 1725 the "latency" attribute is not present or has a 0 value, no 1726 latency constraints need to be met and no measurements MAY be 1727 taken. 1729 Appropriate attribute values: [0..9999] 1731 7.2.7 "jitter" attribute 1733 The maximum uplink and downlink jitter tolerance are specified in 1734 the "jitter" attribute, expressed in milliseconds. In the Q4S- 1735 aware-network scenario, if the jitter constraints are not met, a 1736 Q4S-ALERT method will be sent to the client. In the Reactive 1737 scenario, if the latency constraints are not met, an alert 1738 notification will be sent to the Actuator. If "jitter" attribute 1739 is not present or has a 0 value, no jitter constraints need to be 1740 met and no measurements MAY be taken. 1742 Appropriate attribute values: [0..9999] "/" [0..9999] 1744 7.2.8 "bandwidth" attribute 1746 The minimum uplink and downlink bandwidth are specified in the 1747 "bandwidth" attribute, expressed in kbps. In the Q4S-aware-network 1748 scenario, if the bandwidth constraints are not met, a Q4S-ALERT 1749 method will be sent to the client. In the Reactive scenario, an 1750 alert notification will be sent to the Actuator. If "bandwidth" 1751 attribute is not present or has a 0 value, no bandwidth 1752 constraints need to be met and no measurements MAY be taken. 1754 Appropriate attribute values: [0..99999] "/" [0..99999] 1756 7.2.9 "packetloss" attribute 1758 The maximum uplink and downlink packet loss tolerance are 1759 specified in the "packetloss" attribute expressed in percentage 1760 (two decimal accuracy). In the Q4S-aware-network scenario, if the 1761 packetloss constraints are not met, a Q4S-ALERT method will be 1762 sent to the client. In the Reactive scenario, an alert 1763 notification will be sent to the Actuator. If "packetloss" 1764 attribute is not present or has a 0 value, no packetloss 1765 constraints need to be met and no measurements MAY be taken. 1767 Appropriate attribute values: [0.00 ..100.00] "/"[0.00 ..100.00] 1769 7.2.10 "flow" attributes 1771 These attributes specify the flows (protocol, destination 1772 IP/ports) of data over TCP and UDP ports to be used in uplink and 1773 downlink communications. 1775 Several "flow" attributes can be defined. These flows identify the 1776 listening port (client or server), the protocol (TCP or UDP) (RFC 1777 793 [16] and RFC 768 [17]) with the range of ports that are going 1778 to be used by the application and, of course, by the Q4S protocol 1779 (for quality measurements). All defined flows (app and q4s) will 1780 be considered within the same quality profile, which is determined 1781 by the qos-level attribute in each direction. This allows to 1782 assume that measurements on q4s flows are the same experimented by 1783 the application which is using app flows. 1785 During negotiation and continuity phases the specified Q4S ports 1786 in the "flow:q4s" attributes of SDP will be used for Q4S messages. 1788 The Q4S flows comprise two UDP flows and two TCP flows (one uplink 1789 and one downlink for each one) whereas application traffic MAY 1790 consist of many flows, depending on its nature. The handshake 1791 phase takes place through the Q4S Contact URI, using the standard 1792 Q4S TCP port. However, the negotiation and continuity phases will 1793 take place on the specified Q4S ports (UDP and TCP) specified in 1794 the SDP. 1796 The "clientListeningPort" is a port in which the client listens 1797 for server requests and MUST be used as origin port of client 1798 responses. The "serverListeningPort" is a port in which server is 1799 listening for incoming messages from the client. The origin port 1800 of server responses may be different than "serverListeningPort" 1801 value. 1803 If "clientListeningPort" is zero (a=flow:q4s clientListeningPort 1804 TCP/0), the client MAY choose one randomly as per OS standard 1805 rules. Client ports inside the SDP must always be matched against 1806 actual received port values on the server side in order to deal 1807 with NAT/NATP devices. If zero value or incorrect value is 1808 present, server must set the value to the received origin port in 1809 the next message with SDP (200 OK, ALERT and CANCEL messages). 1811 Attribute values: 1812 <"q4s"|"app"> <"serverListeningPort"|"clientListeningPort"> 1813 <"UDP"|"TCP"> <0..65535>[ "-" [0..65535]] 1815 7.2.11 "measurement" attributes 1817 These attributes contain the measurement procedure and the results 1818 of the quality measurements. 1820 Measurement parameters are included using the session attribute 1821 "measurement". The first measurement parameter is the procedure. 1822 Q4S provides a "default" procedure for measurements, but others 1823 like RTP/RTCP might be used and defined later. This document will 1824 only define and explain the "default" procedure. 1826 In the initial client request a set of measurement procedures can 1827 be sent to the server for negotiation. One measurement procedure 1828 line MUST be included in the SDP message for each proposed method. 1829 The server MUST answer with only one line with the chosen 1830 procedure. 1832 For each procedure, a set of values of parameters separated by "," 1833 can be included in the same attribute line. The amount and type of 1834 parameters depends on the procedure type. 1836 In the following example the "default" procedure type is chosen: 1838 a=measurement:procedure default(50/50,75/75,5000,40/80,100/256) 1840 In the "default" procedure, the meaning of these parameters is: 1842 o The first parameter is the interval of time (in milliseconds) 1843 between PING requests during the negotiation phase. Uplink 1844 and downlink values from the client's point of view are 1845 separated by "/". This allows having different responsiveness 1846 values depending on the control resources used in each 1847 direction. 1849 o The second parameter is the time interval (in milliseconds) 1850 between PING requests during the continuity phase. Uplink and 1851 downlink values are separated by "/". This allows having two 1852 different responsiveness values depending on the control 1853 resources used in each direction. 1855 o The third parameter is the time interval to be used to 1856 measure bandwidth during the negotiation phase. 1858 o The fourth parameter indicates the window size for jitter and 1859 latency calculations. Uplink and downlink values are 1860 separated by "/". 1862 o The fifth parameter indicates the window size for packet loss 1863 calculations. Uplink and downlink values are separated by 1864 "/". 1866 There are four more measurement attributes: 1868 a=measurement:latency 45 1869 a=measurement:jitter 3/12 1870 a=measurement:bandwidth 200/9800 1871 a=measurement:packetloss 0.00/1.00 1873 The latency, jitter, bandwidth and packet-loss measurement 1874 attributes contain the values measured for each of these quality 1875 parameters in uplink and downlink directions. Notice that latency 1876 is considered equal for uplink and downlink directions. Quality 1877 parameter values in these measurement attributes provide a 1878 snapshot of the quality reached and MUST only be included in Q4S- 1879 ALERT messages in the SDP body such that they can be protected 1880 from malicious attacks as these alerts include a signature of the 1881 SDP body in the header. The rest of messages will include the 1882 measured values in the Measurements header. 1884 In the case of procedure "default", the valid values are: 1886 a=measurement:procedure default,[0..999]"/" [0..999] "," [0..999] 1887 "/" [0..999] "," [0..9999] "," [0..999]/[0..999] "," 1888 [0..999]/[0..999] 1890 7.2.12 "max-content-length" attribute 1892 The adaptation of measurement traffic to approximate the actual 1893 data streams' characteristics is convenient to accurately estimate 1894 the expected QoS for applications. Particularly, packet size can 1895 have a remarkable effect on bandwidth estimations. Moreover, this 1896 can produce problems depending on the MTU of the end hosts and 1897 links along the path. 1899 Therefore, the maximum content length MAY be set in an attribute 1900 denoted as "max-content-length". Its value MUST be given in bytes 1901 and MUST NOT include application, transport, network or link layer 1902 headers, i.e., size of the content length at the application 1903 layer. If not set, the value MUST be 1000 bytes. 1905 Furthermore, this attribute MAY be used to inform about MTU limits 1906 in end points, hence reducing possible bias as a result of 1907 network-layer fragmentation. 1909 For instance: 1911 a=max-content-length:1300 1913 7.3 Measurements 1915 This section describes the way quality parameters are measured as 1916 defined by the "default" procedure. Measurements MUST be taken for 1917 any quality parameter with constraints, that is, specified in the 1918 SDP attributes with non-zero values. For non-present attributes 1919 measurements MAY be omitted. 1921 7.3.1 Latency 1923 Latency measurements will be performed if the latency attribute 1924 and/or the application latency attribute are present and with non- 1925 zero values. 1927 Q4S defines a PING method in order to exchange packets between the 1928 client and the server. Based on this PING exchange the client and 1929 the server are able to calculate the round-trip time (RTT). The 1930 RTT is the sum of downlink latency (normally named "reverse 1931 latency") and uplink latency (normally named "forward latency"). 1933 At least 255 samples of RTT MUST be taken by the client and 1934 server. As the forward and reverse latencies are impossible to 1935 measure, client and server will assume that both latencies are 1936 identical (symmetric network assumption). The latency will 1937 therefore be calculated as the statistical median value of all the 1938 RTT samples divided by 2. 1940 7.3.2 Jitter 1942 Jitter measurements will be performed if the jitter attribute 1943 and/or the application jitter attribute are present and with non- 1944 zero values. 1946 The jitter can be calculated independently by the client and by 1947 the server. The downlink jitter is calculated by the client taking 1948 into account the time interval between PING requests as defined by 1949 the measurement procedure attribute in the first or second 1950 parameter depending on the Q4S protocol phase. The client and the 1951 server MUST send these PING requests at the specified intervals. 1952 The client measures the downlink jitter whereas the server 1953 measures the uplink jitter. Note that PING responses are not taken 1954 into account when calculating jitter values. 1956 Every time a PING request message is received by an endpoint 1957 (either server or client), the corresponding jitter value is 1958 updated using the Statistical Jitter value calculated on the first 1959 255 packets received using the arithmetic mean of the absolute 1960 values of elapsed times. 1962 Each endpoint sends a PING periodically with a fixed interval, 1963 each value of "elapsed time" (ET) should be very close to this 1964 interval. If a PING message is lost, the elapsed time value is 1965 doubled. Identifying lost PING messages, however, is not an issue 1966 because all PING messages are labeled with a Sequence-Number 1967 header. Therefore the receiver can discard this elapsed time 1968 value. 1970 In order to have the first jitter sample, the receiver MUST wait 1971 until it receives 3 PING requests, because each ET is the time 1972 between two PINGs and a Jitter needs at least two ET. 1974 The client measures the values of RTT and downlink jitter and the 1975 server measures RTT and uplink jitter, but all measurements are 1976 shared with the counterpart by means of "Measurements" header of 1977 PING message. 1979 7.3.3 Bandwidth 1981 Bandwidth measurements will be performed if the bandwidth 1982 attribute and/or the application bandwidth attribute is present 1983 and with non-zero values. 1985 In order to measure the available bandwidth, both the client and 1986 the server MUST start sending BWIDTH messages simultaneously using 1987 the UDP control ports exchanged during the handshake phase in the 1988 SDP message, at the needed rate to verify the availability of the 1989 bandwidth constraint in each direction. The messages are sent 1990 during the period of time defined in the third parameter of the 1991 SDP measurement default procedure attribute in millisecond units. 1993 a=measurement:procedure default(50/50,75/75,5000,256/256,256/256) 1995 +------------------------------------------------+ 1996 | Rate | 1997 | A | 1998 | | | 1999 |downlink rate-|-------------------+ <-- traffic | 2000 | | | sent by | 2001 | | | server | 2002 | | | | 2003 | | | | 2004 | | | | 2005 | | | | 2006 | | | | 2007 | | | | 2008 | | | | 2009 | | | | 2010 | | | | 2011 | | | | 2012 | | | | 2013 | | | | 2014 | uplink rate-|-------------------+ <-- traffic | 2015 | | | sent by | 2016 | | | client | 2017 | | | | 2018 | | | | 2019 | |---|---|---|---|---|----> time | 2020 | 0 1 2 3 4 5 (sec.) | 2021 | | 2022 +------------------------------------------------+ 2024 Figure 6 Bandwidth and packet loss measurements. 2026 The goal of these measurements is not to identify the available 2027 bandwidth of the communication path but to determine if the 2028 required bandwidth is available, meeting the application's 2029 constraints. Therefore, the requested bandwidth MUST be measured 2030 sending only the highest bit rate required by the bandwidth 2031 attribute. This is illustrated in Figure 6. 2033 During bandwidth measurement time, ALERTS are not expected, but 2034 only at the end of the measurement time. 2036 When measuring bandwidth, all BWIDTH requests sent MUST be 1 2037 kilobyte in length (UDP payload length by default), and MUST 2038 include a Sequence-Number header with a sequential number starting 2039 at 0, and their content MUST consist of randomly generated values 2040 to minimize the effect of compression elements along the path. The 2041 Sequence-Number MUST be incremented by 1 with each BWIDTH packet 2042 sent. If any measurement stage needs to be repeated, the sequence 2043 number MUST start at zero again. BWIDTH requests MUST NOT be 2044 answered. Examples: 2046 Client message: 2047 ========================= 2048 BWIDTH q4s://www.example.com Q4S/1.0 2049 User-Agent: q4s-ua-experimental-1.0 2050 Session-Id: 53655765 2051 Sequence-Number: 0 2052 Content-Type: text 2053 Content-Length: XXXX 2054 Measurements: l=22, j=10, pl=0.00, bw=3000 2056 VkZaU1FrNVZNVlZSV0doT1ZrZ (to complete up to "max-content- 2057 length" bytes UDP payload length) 2058 ========================= 2060 The client MUST send BWIDTH packets to the server to allow the 2061 server to measure the uplink bandwidth. The server MUST send 2062 BWIDTH packets to the client to allow the client to measure the 2063 downlink bandwidth. 2065 Server message: 2066 ========================= 2067 BWIDTH q4s://www.example.com Q4S/1.0 2068 Session-Id: 53655765 2069 Sequence-Number: 0 2070 Content-Type: text 2071 Content-Length: XXXX 2072 Measurements: l=22, j=7, pl=0.00, bw=200 2074 ZY0VaT1ZURlZVVmhyUFE9PQ (to complete up to max-content- 2075 length 2076 UDP payload length) 2077 ========================= 2079 7.3.4 Packet loss 2081 Packet loss and bandwidth are measured simultaneously using the 2082 BWIDTH packets sent by both the client and the server. Because the 2083 BWIDTH packets contain a Sequence-Number header incremented 2084 sequentially with each sent packet, lost packets can be easily 2085 identified. The lost packets MUST be counted during the 2086 measurement time. 2088 7.4 Handshake Phase 2090 The first phase consists of a Q4S BEGIN method issued from the 2091 client to the server as shown in Figure 7. 2093 The first Q4S message MUST have a special URI (RFC 3986 [12]), 2094 which forces the use of the Q4S protocol if it is implemented in a 2095 standard web browser. 2097 This URI, named "Contact URI", is used to request the start of a 2098 session. Its scheme MUST be: 2100 "q4s:" "//" host [":" port] [path["?" query] 2102 Optionally, the client can send the desired quality parameters 2103 enclosed in the body of the message as an SDP document. The server 2104 MAY take them into account when building the answer message with 2105 the final values in the SDP body, following a request / response 2106 schema (RFC 3264 [13]). 2108 If the request is accepted, the server MUST answer it with a Q4S 2109 200 OK message, which MUST contain an SDP body (RFC 4566 [10]) 2110 with the assigned session id (embedded in the "o" SDP parameter), 2111 the IP addresses to be used, the flow ports to be used, the 2112 measurement procedure to be followed and information about the 2113 required quality constraints. Additionally, the alerting-mode and 2114 alert-pause time parameters may be included. Q4S responses should 2115 use the protocol designator "Q4S/1.0". 2117 After these two messages are exchanged, the first phase is 2118 completed. The quality parameter thresholds have been sent to the 2119 client. The next step is to measure the actual quality of the 2120 communication path between the client and the server and alert if 2121 the Service Level Agreement (SLA) is being violated. 2123 +------------------------------------------------+ 2124 | | 2125 | Client Server | 2126 | | 2127 | ------- Q4S BEGIN ------------> | 2128 | | 2129 | <------ Q4S 200 OK ------------ | 2130 | | 2131 | | 2132 +------------------------------------------------+ 2134 Figure 7 Handshake phase. 2136 Example of Client Request and Server Answer: 2138 Client Request: 2139 ========================= 2140 BEGIN q4s://www.example.com Q4S/1.0 2141 Content-Type: application/sdp 2142 User-Agent: q4s-ua-experimental-1.0 2143 Content-Length: 142 2145 (SDP not shown) 2146 ========================= 2148 Server Answer: 2149 ========================= 2150 Q4S/1.0 200 OK 2151 Date: Mon, 10 Jun 2010 10:00:01 GMT 2152 Content-Type: application/sdp 2153 Expires: 3000 2154 Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 2155 Content-Length: 131 2157 (SDP not shown) 2158 ========================= 2160 The headers used are explained in section 4.3. 2162 7.5 Negotiation Phase 2164 The negotiation phase is in charge of measuring the quality 2165 parameters and verifying that the communication paths meet the 2166 required quality constraints on both directions as specified in 2167 the SDP body. 2169 The measured parameters will be compared with the quality 2170 constraints specified in the SDP body. If the quality session is 2171 compliant with all the quality constraints the application can 2172 start. 2174 o If the quality constraints are not met, a higher quality 2175 service level will be demanded. Depending on the scenario, 2176 this quality upgrade will be managed as follows: In the Q4S- 2177 aware-network scenario: a Q4S-ALERT method will be triggered 2178 by the server to the client and the client will answer with 2179 the same Q4S-ALERT method. After receiving the same Q4S-ALERT 2180 from the counterpart, no other alerts will be triggered by 2181 the server during the "alert-pause" period of time, in order 2182 to allow the network to react, but measurements will continue 2183 to be taken to achieve early detection of improved network 2184 quality conditions and a fast application start. 2186 o In the Reactive scenario: an alert notification will be sent 2187 by the server stack to the Actuator, and the Actuator will 2188 answer with an alert acknowledgement. After receiving the 2189 alert acknowledgement from the Actuator, the server stack 2190 will not send other alert notifications during the "alert- 2191 pause" period of time, in order to allow the Actuator to 2192 react and trigger actions on the application or on the policy 2193 server, but measurements will continue to be taken to achieve 2194 early detection of improved network quality conditions and a 2195 fast application start. 2197 In both scenarios stated above, if after several measurement 2198 cycles, the network constraints cannot be met the quality session 2199 is terminated. Concretely when under all possible actions taken by 2200 Actuator the quality remains below requirements, the session must 2201 be terminated. 2203 The steps to be taken in this phase depend on the measurement 2204 procedure exchanged during the handshake phase. This document only 2205 describes the "default" procedure, but others can be used, like 2206 RTP/RTCP (RFC 3550 [18]). 2208 Measurements of latency and jitter are done calculating the 2209 differences in arrival times of packets and can be achieved with 2210 little bandwidth consumption. The bandwidth measurement, on the 2211 other hand, involves higher bandwidth consumption in both 2212 directions (uplink and downlink). 2214 To avoid wasting unnecessary network resources these two types of 2215 measurements will be performed in two separate stages. If the 2216 required latencies and jitters cannot be reached, it makes no 2217 sense to waste network resources measuring bandwidth. In addition, 2218 if achieving the required latency and jitter thresholds implies 2219 upgrading the quality session level, the chance of obtaining 2220 compliant bandwidth measurements without retries is higher, saving 2221 network traffic again. Therefore, the default procedure, 2222 determines that the measurements are taken in two stages: 2224 o Stage 0: Measurement of latencies, jitters and packet loss 2226 o Stage 1: Measurement of bandwidths and packet loss 2228 Notice that packet loss can be measured in both stages, as all 2229 messages exchanged include a sequence-number header that allows 2230 for easy packet loss detection. 2232 The client starts the negotiation phase sending a READY request 2233 using the TCP Q4S ports defined in the SDP. This READY request 2234 includes a "Stage" header that indicates the measurement stage. 2236 If either jitter, latency or both are specified, the negotiation 2237 phase begins with the measurement of latencies and jitters (stage 2238 0). If none of those attributes are specified, stage 0 is skipped. 2240 7.5.1 Stage 0: Measurement of Latencies and Jitter 2242 The Stage 0 MUST start with a synchronization message exchange 2243 initiated with the client's READY message. 2245 Client request, READY message: 2246 ========================= 2247 READY q4s://www.example.com Q4S/1.0 2248 Stage: 0 2249 Session-Id: 53655765 2250 User-Agent: q4s-ua-experimental-1.0 2251 Content-Length: 0 2252 ========================= 2254 Server Response: 2255 ========================= 2256 Q4S/1.0 200 OK 2257 Session-Id: 53655765 2258 Stage:0 2259 Content-Length: 0 2260 ========================= 2262 This triggers the exchange of a sequence of PING requests and 2263 responses that will lead to the calculation of RTT (latency), 2264 jitter and packet loss. 2266 After receiving 200 OK, the client must send the first PING 2267 message and the server will wait to send PINGs until the reception 2268 of this first client PING. 2270 Client and server MUST send PING requests to each other. The 2271 Sequence-Number header of the first PING MUST be set to 0. Client 2272 and server will manage their own sequence numbers. 2274 +------------------------------------------------+ 2275 | | 2276 | Client Server | 2277 | | 2278 | --------- Q4S READY 0 ---------> | 2279 | <-------- Q4S 200 OK ----------- | 2280 | | 2281 | --------- Q4S PING ------------> | 2282 | <-------- Q4S 200 OK ----------- | 2283 | <-------- Q4S PING ------------- | 2284 | -------- Q4S 200 OK ----------> | 2285 | --------- Q4S PING ------------> | 2286 | <-------- Q4S PING ------------- | 2287 | --------- Q4S 200 OK ----------> | 2288 | <-------- Q4S 200 OK ----------- | 2289 | ... | 2290 | | 2291 +------------------------------------------------+ 2293 Figure 8 Simultaneous exchange of PING request and responses. 2295 Figure 8 shows an example of the PING request sent from the client 2296 and the server's response: 2298 Client Request: 2299 ========================= 2300 PING q4s://www.example.com Q4S/1.0 2301 Session-Id: 53655765 2302 Sequence-Number: 0 2303 User-Agent: q4s-ua-experimental-1.0 2304 Measurements: l=22, j=12, pl=0.20, bw= 2305 Content-Length: 0 2306 ========================= 2308 Server Response: 2309 ========================= 2310 Q4S/1.0 200 OK 2311 Session-Id: 53655765 2312 Sequence-Number: 0 2313 Content-Length: 0 2314 ========================= 2316 The function of the PING method is similar to the ICMP echo 2317 request message. The server MUST answer as soon as it receives the 2318 message. 2320 Both endpoints MUST send Q4S PING messages with the periodicity 2321 specified in the first parameter of SDP measurement procedure 2322 attribute, using always the same UDP ports and incrementing the 2323 Sequence-Number with each message. 2325 In the following example, the SDP measurement procedure attribute, 2326 this value is 50 milliseconds (from the client to the server) and 2327 60ms (from the server to the client). 2329 a=measurement:procedure default(50/60,50/50,5000,256/256,256/256) 2331 They MUST NOT wait for a response to send the next PING request. 2332 The "Sequence-Number" header value is incremented sequentially and 2333 MUST start at zero. If this stage is repeated, the initial 2334 Sequence-Number MUST start at zero again. 2336 All PING requests MUST contain a "Measurements" header, with the 2337 values of the latency, jitter and packet loss measured by each 2338 entity up to that moment. The client will send its measurements to 2339 the server and the server his measurements to the client. Example: 2341 Measurements: l=22, j=13, pl=0.10, bw= 2343 Where l stands for latency, j for jitter, pl for packetloss and bw 2344 for bandwidth. The bandwidth value is omitted, as it is not 2345 measured at this stage. 2347 Optionally the PING request can include a "Timestamp" header, with 2348 the time in which the message has been sent. In case the header is 2349 present, the server MUST include the header in the response 2350 without changing the value. 2352 A minimum number of PING messages MUST be exchanged in order to be 2353 able to measure latency, jitter and packet-loss with certain 2354 accuracy (at least 256 samples are RECOMMENDED to get a accurate 2355 packet loss measurement). Both the client and the server calculate 2356 the respective measured parameter values. The mechanisms to 2357 calculate the different parameters are described in section 7.3. 2359 At the end of this stage 0, there are three possibilities: 2361 o The latency, jitter and packet loss constraints are reached 2362 in both directions 2364 o The latency, jitter and packet loss constraints are not 2365 reached in one or both directions 2367 In the first case, Stage 0 is finished. Client and server are 2368 ready for Stage 1: bandwidth and packet loss measurement. The 2369 client moves to stage 1 by sending a READY message including the 2370 header "Stage: 1". 2372 If the bandwidth constraints are empty or with value zero, the 2373 negotiation phase MUST terminate and both client and server may 2374 initiate the Continuity Phase. In this case client moves to 2375 Continuity phase by sending a READY message including the header 2376 "Stage: 2". 2378 The second case, in which one or more quality constraints have not 2379 been met, is detailed in section 7.5.4. 2381 7.5.2 Stage 1: Measurement of Bandwidth and Packet Loss 2383 This stage begins in a similar way to stage 0, sending a READY 2384 request over TCP. This READY message "Stage" header value is 1. 2385 The server answers with a Q4S 200 OK message to synchronize the 2386 initiation of the measurements as shown in Figure 9. 2388 +------------------------------------------------+ 2389 | | 2390 | Client Server | 2391 | | 2392 | --------- Q4S READY 1 -----------> | 2393 | <-------- Q4S 200 OK ------------- | 2394 | | 2395 | --------- Q4S BWIDTH -----------> | 2396 | <-------- Q4S BWIDTH ------------ | 2397 | --------- Q4S BWIDTH -----------> | 2398 | <-------- Q4S BWIDTH ------------ | 2399 | ... | 2400 | | 2401 +------------------------------------------------+ 2402 Figure 9 Starting bandwidth and packet loss measurement 2404 Client Request: 2405 ========================= 2406 READY q4s://www.example.com Q4S/1.0 2407 User-Agent: q4s-ua-experimental-1.0 2408 Stage: 1 2409 Session-Id: 53655765 2410 Content-Length: 0 2412 ========================= 2414 Server Response: 2415 ========================= 2416 Q4S/1.0 200 OK 2417 Session-Id: 53655765 2418 Stage: 1 2419 Content-Length: 0 2421 ========================= 2423 Just after receiving the 200 OK, both the client and the server 2424 MUST start sending BWIDTH messages simultaneously using the UDP 2425 q4s ports. Section 7.3.3 describes the bandwidth measurement in 2426 detail. 2428 At the end of this stage 1, there are three possibilities: 2430 o The bandwidth and packet loss constraints are reached in both 2431 directions 2433 o The bandwidth and packet loss constraints are not reached in 2434 one both directions. 2436 In the first case, Stage 1 is finished. Client and server are 2437 ready for Continuity phase. The client moves to this phase by 2438 sending a READY message including the header "Stage: 2". The 2439 server answer MUST be 200 OK as shown in Figure 10. 2441 +------------------------------------------------+ 2442 | | 2443 | Client Server | 2444 | | 2445 | --------- Q4S READY 2 --------------> | 2446 | <---- Q4S 200 OK with trigger URI----- | 2447 | | 2448 | --------- HTTP GET ----------------> | 2449 | | 2450 | (Application starts) | 2451 | | 2452 +------------------------------------------------+ 2454 Figure 10 Trigger the application using HTTP URI 2456 Client Request: 2457 ========================= 2458 READY q4s://www.example.com Q4S/1.0 2459 User-Agent: q4s-ua-experimental-1.0 2460 Stage: 2 2461 Session-Id: 53655765 2462 Content-Length: 0 2464 ========================= 2466 Server Answer: 2467 ========================= 2468 Q4S/1.0 200 OK 2469 Date: Mon, 10 Jun 2010 10:00:01 GMT 2470 Session-Id: 53655765 2471 Trigger-URI: http://www.example.com/app_start 2472 Expires: 3000 2473 Content-Type: application/sdp 2474 Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 2475 Content-Length: 131 2477 (SDP not shown) 2478 ========================= 2480 If the "Trigger-URI" header is present, the client SHOULD send an 2481 HTTP request to this URI. 2483 The second case, with violated network constraints is explained in 2484 7.5.4. 2486 7.5.3 Quality Constraints Not Reached 2488 After finishing Stage 1 of the Negotiation phase, the client and 2489 the server have each other measured parameter values as these have 2490 been exchanged in the "Measurements" headers of the PING and 2491 BWIDTH messages. If there is one or more parameters that do not 2492 comply with the uplink or downlink application constraints 2493 required both the server and the client are aware of it. 2495 If there is any quality parameter that does not meet the uplink or 2496 downlink quality constraints specified in the SDP message, two 2497 scenarios are possible depending on the specified alerting-mode 2498 (if not present, default value is "Reactive" alerting mode): 2500 a) Q4S-aware-network alerting mode: the server MUST send a Q4S- 2501 ALERT message to the client including the digital signature 2502 header, and the client MUST answer with the same Q4S-ALERT 2503 message. The Signature header contains the signed hash value of 2504 the SDP body in order to protect all the SDP the data and 2505 therefore it MUST contain the measurement parameters in the 2506 body. 2508 Server request 2509 ========================= 2510 Q4S-ALERT q4s://www.example.com Q4S/1.0 2511 Host: www.example.com 2512 User-Agent: q4s-ua-experimental-1.0 2513 Session-Id: 53655765 2514 Content-Type: application/sdp 2515 Content-Length: 142 2517 v=0 2518 o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33 2519 s=Q4S 2520 i=Q4S parameters 2521 t=0 0 2522 a=qos-level:1/2 2523 a=alerting-mode: Q4S-aware-network 2524 a=alert-pause:5000 2525 a=public-address:client IP4 198.51.100.51 2526 a=public-address:server IP4 198.51.100.58 2527 a=latency:40 2528 a=jitter:10/10 2529 a=bandwidth:20/6000 2530 a=packetloss:0.50/0.50 2531 a=flow:app downlink TCP/10000-20000 2532 a=flow:app uplink TCP/56000 2533 a=flow:q4s downlink UDP/55000 2534 a=flow:q4s downlink TCP/55001 2535 a=flow:q4s uplink UDP/56000 2536 a=flow:q4s uplink TCP/56001 2537 a=measurement:procedure default(50/50,50/50,5000,256/256,256/256) 2538 a=measurement:latency 30 2539 a=measurement:jitter 6/4 2540 a=measurement:bandwidth 200/4000 2541 a=measurement:packetloss 0.20/0.33 2542 ========================= 2544 At this point, both client and server keep on measuring but 2545 without sending new Q4S ALERT messages during the "alert-pause" 2546 milliseconds. 2548 b) Reactive alerting mode: the server stack MUST send an alert 2549 notification to the Actuator, and the Actuator MUST answer with 2550 an acknowledgement to the received alert notification. The 2551 alert notification sent to the Actuator by the server stack 2552 doesn't follow Q4S message style but should have all the 2553 information the Actuator will need for the actions to be taken, 2554 which will be implementation dependent. 2556 At this point, during Negotiation phase, both client and server 2557 keep on measuring without sending new alert notifications to the 2558 Actuator during the "alert-pause" milliseconds specified in the 2559 SDP. This way, both client and server will detect any improvement 2560 in network conditions as soon as the network reacts. The 2561 application can start as soon as the number of measurements 2562 indicated in the measurement procedure attribute indicates that 2563 the quality parameters are met. 2565 Same applies to Continuity phase: the measurement dialog between 2566 client and server must not be interrupted by any possible ALERT 2567 message. 2569 7.5.3.1 Actuator Role 2571 Actuator receives notifications of unmet requirements from the Q4S 2572 server stack, and act upon the application or the network policy 2573 server, according to logic out of scope of this protocol. 2575 The Actuator logic activates mechanisms at application level 2576 or/and network level based on a quality level dictionary, in which 2577 each level meaning is implementation dependent and each level 2578 involve different actions based on rules to keep certain user 2579 experience quality. 2581 The type of actions that an Actuator can take at application level 2582 are application dependent and MAY involve: 2584 o Reduction of application functionalities, such as limitation 2585 of application speed or application options. 2587 o Reduction of application resources usage, such as reduction 2588 of frames per second in a video app or any other parameter 2589 modification in order to adapt to network conditions. 2591 Apart from actions at application level, the Actuator MAY act at 2592 network level if a network policy server is available. 2594 7.5.3.2 Policy Server Role 2596 A network policy server may be part of the reactive scenario and 2597 it is in charge of managing network quality provision. Network 2598 policy server may implement all or some of these features (but not 2599 exclusive to): 2601 o Server validation in terms of quality constraints. 2603 o Authentication (Signature validation) and security (block 2604 malicious clients) 2606 o Policy rules (following rules are only examples): 2608 - Maximum quality level allowed for the ACP 2610 - Time bands allowed for providing quality sessions 2612 - Number of simultaneous quality sessions allowed 2614 - Maximum time used by allowed quality sessions 2616 - Etc. 2618 If any of the policy rules fail, a Q4S-ALERT message MUST be 2619 answered by a 6XX error, indicating the cause. 2621 7.5.4 QoS Level Changes 2623 If any constraint was violated, server MAY trigger a Q4S-ALERT 2624 asking for higher qos-level attribute. The maximum qos-level 2625 allowed is 9, both uplink and downlink. 2627 If the qos-level has reached the maximum value for downlink or 2628 uplink without matching the constraints, then a CANCEL request 2629 MUST be sent by the client using the TCP port determined in the 2630 handshake phase in order to release the session. In reaction to 2631 the reception of the CANCEL request, the server MUST send a CANCEL 2632 request too. If no CANCEL request is received, the expiration time 2633 cancels the session at server side. 2635 Client Request: 2636 ========================= 2637 CANCEL q4s://www.example.com Q4S/1.0 2638 User-Agent: q4s-ua-experimental-1.0 2639 Session-Id: 53655765 2640 Content-Type: application/sdp 2641 Content-Length: 142 2643 (SDP not shown) 2644 ========================= 2646 Server Request in reaction to Client Request: 2647 ========================= 2648 CANCEL q4s://www.example.com Q4S/1.0 2649 Session-Id: 53655765 2650 Expires: 0 2651 Content-Type: application/sdp 2652 Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 2653 Content-Length: 131 2655 (SDP not shown) 2656 ========================= 2658 7.6 Continuity Phase 2660 During the negotiation phase, latency, jitter, bandwidth and 2661 packet loss have been measured. During the continuity phase 2662 bandwidth will not be measured again because bandwidth 2663 measurements may disturb application performance. 2665 This phase is supposed to be executed at the same time as the 2666 real-time application is being used. 2668 This document only covers the default procedure. The continuity 2669 operation with default procedure is based on a sliding window of 2670 samples. The number of samples involved in the sliding window may 2671 be different for jitter and latency than for packet-loss 2672 calculations according to the fifth and sixth parameters of the 2673 measurement procedure attribute. In the example, shown in Figure 2674 11, the jitter and latency sliding window comprises 40 samples 2675 whereas the size of the packet-loss sliding window is 100 samples: 2677 a=measurement:procedure default(50/50,75/75,5000,40/40,100/100) 2679 In addition, the sizes of these windows are configurable per 2680 direction: uplink and downlink values may differ. 2682 PING requests are sent continuously (in both directions) and when 2683 the Sequence-Number header reaches the maximum value, the client 2684 continues sending PING messages with the Sequence-Number header 2685 starting again at zero. When the server PING Sequence-Number 2686 header reaches the maximum value, it does the same, starting again 2687 from zero. 2689 On the client side, the measured values of downlink jitter, 2690 downlink packet loss and latency are calculated using the last 2691 samples, discarding older ones, in a sliding window schema. 2693 +--------------------------------------------------+ 2694 | | 2695 | 55 56 57 . . . 253 254 255 0 1 2 . . . 55 56 | 2696 | A A | 2697 | | | | 2698 | +-----------------------------------+ | 2699 | | 2700 +--------------------------------------------------+ 2702 Figure 11 Sliding samples window 2704 Only if the server detects that the measured values (downlink or 2705 uplink jitter, packet loss or latency) are not reaching the 2706 quality constraints, a Q4S ALERT is triggered and sent either to 2707 the client or to the Actuator, depending on the alerting mode, and 2708 the alert-pause timer is started. 2710 In Q4S-aware-network alerting mode shown in Figure 12, if the 2711 client receives a Q4S ALERT message, it MUST answer sending the 2712 Q4S ALERT request message back to the server including the SDP 2713 (with its corresponding digital signature). 2715 Both client and server will keep performing measurements but no 2716 other Q4S ALERT message MUST be sent during "alert-pause" 2717 milliseconds. The operations needed to act on the network and the 2718 agents in charge of them are out of scope of this draft. 2720 +------------------------------------------------+ 2721 | | 2722 | Client Server | 2723 | | 2724 | ... | 2725 | ----------- PING ----------> | 2726 | <--------- 200 OK ---------- | 2727 | <------- Q4S-ALERT --------- | 2728 | -------- Q4S-ALERT --------> | 2729 | <---------- PING ----------- | 2730 | ---------- 200 OK ---------> | 2731 | ----------- PING ----------> | 2732 | <--------- 200 OK ---------- | 2733 | <---------- PING ----------- | 2734 | ---------- 200 OK ---------> | 2735 | ... | 2736 | | 2737 +------------------------------------------------+ 2739 Figure 12 Continuity in Q4S-aware-network alerting mode 2741 In the Reactive scenario shown in Figure 13, if the server detects 2742 that the measured values (downlink or uplink jitter, packet loss 2743 or latency) are not reaching the quality constraints, an alert 2744 notification is triggered and sent to the Actuator. The Actuator 2745 MUST then answer to the server stack with an alert acknowledgement 2747 The measurement dialog between the client and the server MUST NOT 2748 be interrupted by any possible ALERT message. 2750 +------------------------------------------------+ 2751 | | 2752 | Client Server Actuator | 2753 | ... | 2754 | --- PING ----------> | 2755 | <-- 200 OK---------- | 2756 | <----- PING -------- | 2757 | <--- 200 OK -------- ---- alert | 2758 | notification --> | 2759 | | 2760 | --- PING ----------> <--- alert | 2761 | acknowledge --- | 2762 | <-- 200 OK---------- | 2763 | <----- PING -------- | 2764 | --- 200 OK --------> | 2765 | ... | 2766 | | 2767 +------------------------------------------------+ 2769 Figure 13 Continuity in Reactive alerting mode 2771 7.7 Termination Phase 2773 The Termination phase is the end point for the established Q4S 2774 session that is reached in the following cases: 2776 . A CANCEL message has been received. The client sends a 2777 CANCEL message due to the impossibility of the network to 2778 meet the required quality constraints. The client and server 2779 application will be notified by the respective Q4S stack. 2781 . Session expires: if after the Expires time no client or 2782 server activity is detected, that end cancels the session. 2784 . A BEGIN message has been received by the server. The pre- 2785 existing Q4S quality session is cancelled and a new session 2786 will be initiated. 2788 The meaning of Termination phase in terms of release of resources 2789 or accounting is application dependent and out of scope of the Q4S 2790 protocol. 2792 In Reactive alerting mode, Q4S CANCEL messages received by the Q4S 2793 server must cause the sending of cancel notifications sent from 2794 the server stack to the Actuator in order to release possible 2795 assigned resources for the session. 2797 7.7.1. Sanity Check of Quality Sessions 2799 A session may finish due to several reasons (client shutdown, 2800 client CANCEL request, constraints not reached, etc), and any 2801 session finished MUST release the assigned resources. 2803 In order to release the assigned server resources for the session, 2804 the "Expires" header indicates the maximum interval of time 2805 without exchanging any Q4S message. 2807 7.8 Dynamic Constraints And Flows 2809 Depending on the nature of the application, the quality 2810 constraints to be reached may evolve, changing some or all quality 2811 constraint values in any direction. 2813 The client MUST be able to deal with this possibility. When the 2814 server sends an SDP document attached to a response (200 OK, or 2815 Q4S-ALERT, etc), the client MUST take all the new received values, 2816 overriding any previous value in use. 2818 The dynamic changes on the quality constraints can be as a result 2819 of two possibilities: 2821 o The application communicates to the Q4S server a change in 2822 the constraints. In this case the application requirements 2823 can evolve and the Q4S server will be aware of them. 2825 o The application uses TCP flows. In that case, in order to 2826 guarantee a constant throughput, the nature of TCP behavior 2827 forces the use of a composite constraint function, which 2828 depends on RTT, packet loss and window control mechanism 2829 implemented in each TCP stack. 2831 TCP throughput can be less than actual bandwidth if the 2832 Bandwidth-Delay Product (BDP) is large or if the network suffers 2833 from a high packet loss rate. In both cases, TCP congestion 2834 control algorithms may result in a suboptimal performance. 2836 Different TCP congestion control implementations like Reno [23], 2837 High Speed TCP (RFC 3649 [24]), CUBIC [25], Compound TCP (CTCP 2838 [26]), etc. reach different throughputs under the same network 2839 conditions of RTT and packet loss. In all cases, depending on the 2840 RTT measured value, the Q4S server could change dynamically the 2841 packetloss constraints (defined in SDP) in order to make possible 2842 to reach a required throughput or vice versa (use packetloss 2843 measurement to change dynamically latency constraints). 2845 A general guideline to calculate the packetloss constraint and RTT 2846 constraint consists in approximating the throughput using a 2847 simplified formula, which should take into account the TCP stack 2848 implementation of the receiver, in addition to RTT and packet 2849 loss: 2851 Th= Function( RTT, packet loss, ...) 2853 Then, depending on RTT measured values, set dynamically the 2854 packetloss constraint. 2856 It is possible to easily calculate a worst-case boundary for the 2857 Reno algorithm, which should ensure for all algorithms that the 2858 target throughput is actually achieved. Except that, high-speed 2859 algorithms will then have even a larger throughput, if more 2860 bandwidth is available. 2862 For the Reno algorithm, the Mathis' formula may be used [23] for 2863 the upper bound on the throughput: 2865 Th <= (MSS/RTT)*(1 / sqrt{p}) 2867 In absence of packet loss, a practical limit for the TCP 2868 throughput is the receiver_window_size divided by the round-trip 2869 time. However, if the TCP implementation uses a window scale 2870 option, this limit can reach the available bandwidth value. 2872 7.9 Qos-level Upgrade And Downgrade Operation 2874 Each time the server detects violation of constraints, the alert 2875 mechanism is triggered, the alert-pause timer is started, and the 2876 qos-level is increased. When this happens repeatedly, and the qos- 2877 level reaches its maximum value (value 9), the session is 2878 cancelled. But when the violation of constraints stops before 2879 reaching qos-level maximum value, the recovery mechanism allows 2880 for the qos-level upgrade gradually. 2882 Following, this downgrade and upgrade of qos-level is explained 2883 with an example: 2885 1. A Q4S session is initiated successfully with qos-level=0. 2887 2. During the continuity phase, violation of constraints is 2888 detected; qos-level is increased to 1, a Q4S-ALERT is sent by 2889 the server to the client and alert-pause timer is started. 2891 3. Alert-pause timer expires and still violation of constraints 2892 is detected; qos-level is increased to 2, a Q4S-ALERT is sent 2893 by the server to the client and alert-pause timer is started. 2895 4. Alert-pause timer expires but violation of constraints has 2896 stopped; recovery-pause is started. 2898 5. Recovery-pause timer expires, and no violation of 2899 constraints has been detected meanwhile; qos-level is 2900 decreased to 1, a Q4S-RECOVERY is sent by the server to the 2901 client and recovery-pause timer is started again. 2903 6. Recovery-pause timer expires again and no violation of 2904 constraints has been detected meanwhile; qos-level is 2905 decreased to 0 and a Q4S-RECOVERY is sent by the server to 2906 the client; recovery-pause timer is not started this time as 2907 qos-level has reached its initial value. 2909 When the network configuration allows for the possibility of 2910 managing Q4S flows and application flows independently (either is 2911 a network-based QoS or a Q4S aware network), the qos-level 2912 downgrade process could be managed more efficiently using a 2913 strategy that allows for carrying out qos-level downgrades 2914 excluding app flows from SDP dynamically. The Q4S flows would be 2915 downgraded to allow for measurements on a lower quality level 2916 without interference of the application flows. A Q4S client MUST 2917 allow this kind of SDP modifications by the server. 2919 Periodically (every several minutes, depending on the 2920 implementation) a Q4S-ALERT could be triggered, in which the level 2921 is downgraded for Q4S flows, excluding application flows from the 2922 embedded SDP of that request. 2924 This mechanism allows to measure at lower levels of quality while 2925 application flows continue using a higher qos level value. 2927 o If the measurements in the lower level meet the quality 2928 constraints, then a Q4S-RECOVERY message to this lower qos- 2929 level may be triggered, in which the SDP includes the 2930 application flows in addition to Q4S flows. 2932 o If the measurements in the lower level do not meet the 2933 constraints, then a new Q4S-ALERT to the previous qos-level 2934 MUST be triggered, in which the SDP includes only the Q4S 2935 flows. 2937 +------------------------------------------------+ 2938 | | 2939 | qos-level | 2940 | A | 2941 | | | 2942 | 4| | 2943 | | | 2944 | 3| +------+ | 2945 | | | | | 2946 | 2| +----+ +----+ +--- | 2947 | | | | | | 2948 | 1| +----+ +-----+ | 2949 | | | | 2950 | 0+---+---------------------------------> time | 2951 | | 2952 +------------------------------------------------+ 2954 Figure 14 Possible evolution of qos-level 2956 This mechanism, illustrated in Figure 14, avoids the risk of 2957 disturbing the application, while the measurements are being run 2958 in lower levels. However, this optional optimization of resources 2959 MUST be used carefully. 2961 The chosen period to measure a lower qos level is implementation 2962 dependent. Therefore, it is not included as a measurement 2963 procedure parameter. It is RECOMMENDED to use a large value, such 2964 as 20 minutes. 2966 8 General User Agent Behavior 2968 8.1 Roles in Peer-to-Peer Scenarios 2970 In order to allow peer to peer applications, a Q4S User Agent (UA) 2971 MUST be able to assume both client and server role. The role 2972 assumed depends on who sends the first message. 2974 In a communication between two UAs, the UA that sends the Q4S 2975 BEGIN request in the first place, for starting the handshake 2976 phase, shall assume the client role. 2978 If both UASs send the BEGIN request at the same time, they will 2979 wait for a random time to restart again as shown in Figure 15. 2981 Otherwise, an UA may be configured to act only as server (e.g., 2982 content provider's side). 2984 +-----------------------------------------------+ 2985 | | 2986 | UA(Client) UA(Server) | 2987 | | 2988 | -------- Q4S BEGIN -------------> | 2989 | <------- Q4S BEGIN -------------- | 2990 | | 2991 | ------- Q4S BEGIN --------------> | 2992 | <------ Q4S 200 OK -------------- | 2993 | | 2994 | | 2995 +-----------------------------------------------+ 2997 Figure 15 P2P roles. 2999 8.2 Multiple Quality Sessions in Parallel 3001 A Q4S session is intended to be used for an application. It means 3002 that for using the application, the client MUST establish only one 3003 Q4S session against the server. Indeed, the relation between 3004 session-id and application is 1 to 1. 3006 If a user wants to participate in several independent Q4S sessions 3007 simultaneously against different servers (or against the same 3008 server) it can execute different Q4S clients to establish 3009 separately different Q4S sessions but it is NOT RECOMMENDED, 3010 because: 3012 o The establishment of a new Q4S session may affect other 3013 running applications over other Q4S sessions during bandwidth 3014 measurement. 3016 o If the negotiation phase is executed separately before 3017 running any application, the summation of bandwidth 3018 requirements could not be met when the applications are 3019 running in parallel. 3021 8.3 General Client bBhavior 3023 A Q4S Client has different behaviors. We will use letters X,Y,Z to 3024 designate each different behavior (follow the letter bullets in 3025 figure 16). 3027 X) When it sends messages over TCP (methods BEGIN, READY, Q4S- 3028 ALERT, Q4S-RECOVERY and CANCEL) it behaves strictly like a state 3029 machine that sends requests and waits for responses. Depending 3030 on the response type it enters in a new state. 3032 When it sends UDP messages (methods PING and BWIDTH), a Q4S client 3033 is not strictly a state machine that sends messages and waits for 3034 responses because: 3036 Y) At latency, jitter and packet loss measurement, the PING 3037 requests are sent periodically, not after receiving the response 3038 to the previous request. In addition, the client MUST answer the 3039 PING requests coming from the server, therefore the client 3040 assumes temporarily the role of a server. 3042 Z) At bandwidth and packet loss measurement stage, the client 3043 does not expect to receive responses when sending BWIDTH 3044 requests to the server. In addition, it MUST receive and process 3045 all server messages in order to achieve the downlink 3046 measurement. 3048 The Q4S-ALERT and CANCEL may have a conventional answer if an 3049 error is produced, otherwise the corresponding answer is formatted 3050 as a request message. 3052 +-----------+------------------------+-----------+-----------+ 3053 | Handshake | Negotiation |Continuity |Termination| 3054 | Phase | Phase | Phase | Phase | 3055 | | | | | 3056 | X ---------> Y --> X --> Z --> X ---> Y --> X ---> X | 3057 | | A | A | | A | | | 3058 | | | | | | | | | | | 3059 | | +-----+ +-----+ | +-----+ | | 3060 | | | | | 3061 +------------------------------------------------+-----------+ 3063 Figure 16 Phases & client behaviors. 3065 8.3.1 Generating Requests 3067 A valid Q4S request formulated by a Client MUST, at a minimum, 3068 contains the following header fields: 3070 o If no SDP is included: the header Session-Id and Sequence- 3071 Number are mandatory. 3073 o If SDP is included: Session-Id is embedded into SDP, 3074 therefore the inclusion of Session-Id header is optional but 3075 if present must have the same value. Measurements are 3076 embedded into the SDP only for Q4S-ALERT messages in order to 3077 be signed. 3079 At any time, if the server sends a new SDP with updated values, 3080 client MUST take it into account. 3082 8.4 General Server Behavior 3084 If a server does not understand a header field in a request (that 3085 is, the header field is not defined in this specification or in 3086 any supported extension), the server MUST ignore that header field 3087 and continue processing the message. 3089 The role of the server is changed at negotiation and continuity 3090 phases, in which server MUST send packets to measure jitter, 3091 latency and bandwidth. Therefore, the different behaviors of 3092 server are (follow the letter bullets in the figure 17): 3094 R) When the client sends messages over TCP (methods BEGIN, 3095 READY Q4S-ALERT, Q4S-RECOVERY and CANCEL) it behaves strictly 3096 like a state machine that receives messages and sends 3097 responses. 3099 When the client begins to send UDP messages (methods PING and 3100 BWIDTH), a Q4S server is not strictly a state machine that 3101 receives messages and sends responses because: 3103 S) At latency, jitter and packet loss measurement, the PING 3104 requests are sent periodically by the client but also by the 3105 server. In this case the server behaves as a server answering 3106 client requests but also behaves temporarily as a client, 3107 sending PING requests toward the client and receiving 3108 responses. 3110 T) At bandwidth and packet loss measurement, the server sends 3111 BWIDTH requests to the client. In addition, it MUST receive and 3112 process client messages in order to achieve the uplink 3113 measurement. 3115 The Q4S-ALERT and CANCEL may have a conventional answer if an 3116 error is produced, otherwise the corresponding answer is formatted 3117 as a request message. 3119 +-----------+------------------------+-----------+-----------+ 3120 | Handshake | Negotiation |Continuity |Termination| 3121 | Phase | Phase | Phase | Phase | 3122 | | | | | 3123 | R ---------> S --> R --> T --> R ---> S --> R ---> R | 3124 | | A | A | | A | | | 3125 | | | | | | | | | | | 3126 | | +-----+ +-----+ | +-----+ | | 3127 | | | | | 3128 +------------------------------------------------+-----------+ 3130 Figure 17 Phases & server behaviours. 3132 9 Implementation Recommendations 3134 9.1 Default Client Constraints 3136 To provide a default configuration, it would be good that the 3137 client had a configurable set of Quality headers in the 3138 implementation settings menu. Otherwise these quality headers will 3139 not be present in the first message. 3141 Different business models (out of scope of this proposal) may be 3142 achieved: depending on who pays for the quality session, the 3143 server can accept certain Client parameters sent in the first 3144 message, or force billing parameters on the server side. 3146 9.2 Latency and Jitter Measurements 3148 Different client and server implementations may send a different 3149 number of PING messages for measuring, although at least 255 3150 messages should be considered to perform the latency measurement. 3151 The Stage 0 measurements only may be considered ended when neither 3152 client nor server receive new PING messages after an 3153 implementation-dependent guard time. Only after, client can send a 3154 "READY 1" message. 3156 In execution systems, where the timers are not accurate, a 3157 recommended approach consists of including the optional header 3158 "Timestamp" in the PING request with the time in which the message 3159 has been sent. This allows an accurate measurement of the jitter 3160 even with no identical intervals of time between PINGs. 3162 9.3 Bandwidth Measurements 3164 In programming languages or Operating Systems with limited timers 3165 or clock resolution, it is recommended to use an approach based on 3166 several intervals to send messages of 1KB (= 8000 bits), in order 3167 to reach the required bandwidth consumption using a rate as close 3168 as possible to a constant rate. 3170 For example, if the resolution is 1 millisecond, and the bandwidth 3171 to reach is 11Mbps, a good approach consists of sending: 3173 1 message of 1KB every 1 millisecond + 3175 1 message of 1KB every 3 milliseconds + 3177 1 message of 1KB every 23 milliseconds 3179 The number of intervals depends on required bandwidth and accuracy 3180 that the programmer wants to achieve. 3182 Considering messages of 1KB (= 8000 bits), a general approach to 3183 determine these intervals is 3185 1) Compute Target bandwidth / 8000 bits. In the example above is 3186 11Mbps/8000 = 1375 messages per second 3188 2) Divide the number of messages per second by 1000 to determine 3189 the number of messages per millisecond. 1375/1000 = 1'375. The 3190 integer value is the number of messages per millisecond (in this 3191 case, one). The pending bandwidth is now 375 messages per second 3193 3) To achieve the 375 messages per second, use a sub-multiple of 3194 1000 which must be less than 375 3196 1000/2 = 500 > 375 3198 1000/3 = 333 < 375 3200 In this case a message every 3 ms is suitable. The new pending 3201 target bandwidth is 375 -333 = 42 messages per second 3203 4) Repeat the same strategy as point 3, to reach the pending 3204 bandwidth. In this case, 23 ms is suitable because: 3206 1000/22 = 45 >42 3208 1000/23 = 43 >42 3210 1000 / 24 = 41.6 < 42 3212 We can choose 24 ms but then we need to cover additional 0.4 3213 messages per second (42-41.6=0.4) and 43 is a number higher than 3214 42 but very close to it. 3216 In execution systems where the timers are not accurate, a 3217 recommended approach consists of checking at each interval the 3218 number of packets that should have been sent at this timestamp 3219 since origin and send the needed number of packets in order to 3220 reach the required bandwidth. 3222 The shorter packets are used, the more constant is the rate of 3223 bandwidth measurement. However, this may stress the execution 3224 system in charge of receiving and processing packets. As a 3225 consequence, some packets may be lost because of stack overflows. 3226 To deal with this potential issue, a larger packet is RECOMMENDED 3227 (2KB or more) taking into account the overhead produced by the 3228 chunks headers. 3230 9.4 Packet Loss Measurement Resolution 3232 Depending on application nature and network conditions, a packet 3233 loss resolution less than 1% may be needed. In such cases, there 3234 is no limit to the number of samples used for this calculation. A 3235 tradeoff between time and resolution should be reached in each 3236 case. For example, in order to have a resolution of 1/10000, the 3237 last 10000 samples should be considered in the packet loss 3238 measured value. 3240 The problem of this approach is the reliability of old samples. If 3241 the interval used between PING messages is 50ms, then to have a 3242 resolution of 1/1000 it takes 50 seconds and a resolution of 3243 1/10000 takes 500 seconds (more than 8 minutes). The reliability 3244 of a packet loss calculation based on a sliding window of 8 3245 minutes depends on how fast network conditions evolve. 3247 9.5 Measurements and Reactions 3249 Q4S can be used as a mechanism to measure and trigger network 3250 tuning and application level actions (i.e. lowering video bit- 3251 rate, reduce multiplayer interaction speed, etc) in real-time in 3252 order to reach the application constraints, addressing measured 3253 possible network degradation. 3255 9.6 Instability Treatments 3257 There are two scenarios in which Q4S can be affected by network 3258 problems: loss of Q4S packets and outlier samples. 3260 9.6.1 Loss of Control Packets 3262 Lost UDP packets (PING or BWIDTH messages) don't cause any 3263 problems for the Q4S state machine, but if TCP packets are 3264 delivered too late (which we will consider as "lost"), some 3265 undesirable consequences could arise. 3267 Q4S does have protection mechanisms to overcome these situations. 3268 Examples: 3270 o If a BEGIN packet is lost or its corresponding answer, after 3271 a certain timeout, the client SHOULD resend another BEGIN 3272 packet, resetting the session 3274 o If a READY packet is lost, after a certain timeout, the 3275 client SHOULD resend another READY packet. 3277 o If a QOS ALERT request is lost or its corresponding answer, 3278 after a certain timeout, the originator SHOULD resend another 3279 Q4S-ALERT packet. 3281 o If a CANCEL request is lost or its corresponding answer, 3282 after a certain timeout, the originator SHOULD resend another 3283 CANCEL packet. 3285 9.6.2 Outlier Samples 3287 Outlier samples are those jitter or latency values far from the 3288 general/average values of most samples. 3290 Hence Q4S default measurement method uses the statistical median 3291 formula for latency calculation, the outlier samples are 3292 neutralized. This is a very common filtering for noise or errors 3293 on signal and image processing. 3295 9.7 Scenarios 3297 Q4S could be used in two scenarios: 3299 o client to ACP (Application content provider) 3301 o client to client (peer to peer scenario) 3303 9.7.1 Client to ACP 3305 One server: 3307 It is the common scenario in which client contact server to 3308 establish a Q4S session. 3310 N servers: 3312 In Content Delivery Networks and in general applications where 3313 delivery of contents can be achieved by different delivery nodes, 3314 two working mechanisms can be defined 3316 o Starting mode: End-user may run Q4S against several delivery 3317 nodes and after some seconds choose the best one to start the 3318 multimedia session 3320 o Prevention mode: During streaming session, user keeps several 3321 Q4S dialogs against different alternative delivery nodes. In 3322 case of congestion, end-user MAY change to the best 3323 alternative delivery node 3325 9.7.2 Client to Client 3327 In order to solve the client to client scenario, a Q4S register 3328 function MUST be implemented. This allows clients contact each 3329 other for sending the BEGIN message. In this scenario, the 3330 Register server would be used by peers to publish their Q4S- 3331 Resource-Server header and their public IP address to make 3332 possible the assumption of server role. 3334 The register function is out of scope of this protocol version, 3335 because different HTTP mechanisms can be used and Q4S MUST NOT 3336 force any. 3338 10 Security Considerations 3340 10.1 Confidentiality Issues 3342 Hence Q4S does not transport any application data, Q4S does not 3343 jeopardize the security of application data. However, other 3344 certain considerations may take place, like identity impersonation 3345 and measurements privacy and integrity. 3347 10.2 Integrity of Measurements and Authentication 3349 Identity impersonation could potentially produce anomalous Q4S 3350 measurements. If this attack is based on spoofing of server IP 3351 address, it can be avoided using the digital signature mechanism, 3352 included in the SDP. The network can easily validate this digital 3353 signature using the public key of the server certificate. 3355 Integrity of Q4S measurements under any malicious manipulation 3356 (such as Man-in-the-Middle (MITM) attack) relay on the same 3357 mechanism, the SDP signature. 3359 The Signature header contains the signed hash value of the SDP 3360 body in order to protect all the SDP data, including the 3361 measurements. This signature not only protects the integrity of 3362 data but also authenticates the server. 3364 10.3 Privacy of Measurements 3366 This protocol could be supported over IPSec. Q4S relays on UDP and 3367 TCP, and IPSec supports both. If Q4S is used for application-based 3368 QoS, then IPsec is operationally valid but if Q4S is used to 3369 trigger network-based actions, then measurements could be wrong, 3370 unless IPSec ports be considered at any potential action over the 3371 network (such as prioritization of certain application flows). 3373 10.4 Availability Issues 3375 Any loss of connectivity may interrupt the availability of Q4S 3376 service, and results in higher packet-loss measurements, which is 3377 just the desired behavior in these situations. 3379 In order to mitigate availability issues caused by malicious 3380 attacks (such as DoS and DDoS), a good practice is to enable Q4S 3381 service only for authenticated users. Q4S can be launched after 3382 user is authenticated by the application. At this moment, his IP 3383 address is known and the Q4S service may be enabled for this IP 3384 address. Otherwise Q4S service should appear unreachable. 3386 10.5 Bandwidth Occupancy Issues 3388 Q4S bandwidth measurement is limited to the application needs. It 3389 means that all available bandwidth is not measured, but only the 3390 fraction required by the application. This allows other 3391 applications to use normally the rest of available bandwidth. 3393 However, a malicious Q4S client could re-starts Q4S sessions just 3394 after finishing the negotiation phase. The consequence would be to 3395 waste bandwidth for nothing. 3397 In order to mitigate this possible anomalous behavior, it is 3398 RECOMMENDED to configure the server to reject sessions from the 3399 same end-point when this situation is detected. 3401 11 Future Code Point Requirements 3403 If the ideas described in this document are pursued to become a 3404 protocol specification, then the code points described in this 3405 document will need to be assigned by IANA. 3407 11.1 Service Port 3409 The need for an assigned PORT is to make possible a future Q4S 3410 aware network, capable of react by itself to Q4S alerts. A 3411 specific port would simplify the identification of the protocol by 3412 network elements in charge of take possible reactive decisions. 3413 Therefore, the need for a port by IANA may be postponed to the 3414 need for a future Q4S aware network. 3416 Service Name: Q4S 3418 Transport Protocol(s): TCP 3420 Assignee : 3422 Name : Jose Javier Garcia Aranda 3424 Email: jose_javier.garcia_aranda@nokia.com 3426 Contact : 3428 Name : Jose Javier Garcia Aranda 3430 Email: jose_javier.garcia_aranda@nokia.com 3432 Description : The service associated with this request is in 3433 charge of the establishment of new Q4S sessions, and during the 3434 session manages the pass to a new protocol stage (handshake, 3435 negotiation and continuity) as well as inform of alerts when 3436 measurements do not meet the requirements. 3438 Reference : this document. This service does not use IP-layer 3439 broadcast, multicast, or anycast communication. 3441 12 References 3443 12.1 Normative References 3445 [1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3446 Transfer Protocol (HTTP/1.1): Message Syntax 3447 and Routing", RFC 7230, June 2014. 3449 [2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3450 Transfer Protocol (HTTP/1.1): Semantics and 3451 Content", RFC 7231, June 2014. 3453 [3] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3454 Transfer Protocol (HTTP/1.1): Conditional 3455 Requests", RFC 7232, June 2014. 3457 [4] Fielding, R., Ed., Y. Lafon, Ed. and J. Reschke, Ed. 3458 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 3459 RFC 7233, June 2014. 3461 [5] Fielding, R., Ed., M. Nottingham, Ed. and J. Reschke, Ed. 3462 "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, 3463 June 2014. 3465 [6] Fielding, R., Ed. and J. Reschke, Ed. "Hypertext Transfer 3466 Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. 3468 [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000 3470 [8] Schulzrinne, H., Casner, S., Frederick, R., and V. 3471 Jacobson, "RTP: A Transport Protocol for Real-Time 3472 Applications", STD 64, RFC 3550, July 2003. 3474 [9] Thomson, M., "Version-Independent Properties of QUIC", 3475 April 2019 3477 [10] Handley, M. and V. Jacobson, "SDP: Session Description 3478 Protocol", RFC 4566, July 2006. 3480 [11] Bradner, S., "Key words for use in RFCs to Indicate 3481 RequirementLevels", BCP 14, RFC 2119, March 1997. 3483 [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 3484 Resource Identifiers (URI): Generic Syntax", RFC 3986, 3485 January 2005. 3487 [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 3488 with SDP", RFC 3264, June 2002. 3490 [14] Eastlake, D. and Hansen, T. "US Secure Hash Algorithms", 3491 RFC 4634, May 1992. 3493 [15] Moriarty, K., Johnsson, J., B. Kaliski, "Public-Key 3494 Cryptography Standards (PKCS) #1: RSA Cryptography 3495 Specifications version 2.2", RFC 8017, November 2016. 3497 [16] Defense Advanced Research Projects Agency, " Transmission 3498 Control Protocol", RFC 793, September 1981. 3500 [17] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3501 August 1980. 3503 [18] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V. 3504 "RTP: A Transport Protocol for Real-Time Applications", RFC 3505 3550, july 2003. 3507 [19] Yergeau, F., "UTF-8, a transformation format of ISO 3508 10646", RFC 3629, November 2003. 3510 [20] Resnick, P., "Internet Message Format", RFC 5322, October 3511 2008 3513 [21] Leiba, S., "Ambiguity of Uppercase vs Lowercase in RFC 2119 3514 Key Words", RFC 8174, May 2007 3516 12.2 Informative References 3518 [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3519 A. Peterson, J., Sparks, R., Handley, M. and Schooler, E. , 3520 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 3522 [23] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The 3523 Macroscopic Behavior of the TCP Congestion Avoidance 3524 Algorithm", Computer Communications Review, 27(3), July 3525 1997. 3527 [24] Floyd, S., "HighSpeed TCP for a Large Congestion 3528 Windows", RFC 3649, December 2003. 3530 [25] Rhee, I., Xu, L., Ha, S., "CUBIC for Fast Long-Distance 3531 Networks", Internet-draft draft-rhee-tcpm-cubic-02, February 3532 2009. 3534 [26] Sridharan, M., Tan, K., Bansal, D., Thaler, D., "Compound 3535 TCP: A New TCP Congestion Control for High-Speed and Long 3536 Distance Networks", Internet-draft draft-sridharan-tcpm- 3537 ctcp-02, November, 2008. 3539 [27] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 3540 Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", 3541 RFC 4656, September 2006. 3543 [28] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 3544 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 3545 RFC 5357, October 2008. 3547 13 Acknowledgments 3549 Many people have made comments and suggestions contributing to 3550 this document. In particular, we would like to thank: 3552 Victor Villagra, Sonia Herranz, Clara Cubillo Pastor, Francisco 3553 Duran Pina, Michael Scharf, Jesus Soto Viso and Federico Guillen. 3555 Additionally, we want to thank the Spanish Centre for the 3556 Development of Industrial Technology (CDTI) as well as the Spanish 3557 Science and Tech Ministry which funds this initiative through 3558 their innovation programs. 3560 14 Contributors 3562 Jacobo Perez Lajo 3563 Nokia Spain 3564 Email: jacobo.perez@nokia.com 3566 Luis Miguel Diaz Vizcaino 3567 Nokia Spain 3568 Email: Luismi.Diaz@nokia.com 3570 Gonzalo Munoz Fernandez 3571 Nokia Spain 3572 Email: gonzalo.munoz_fernandez.ext@nokia.com 3574 Manuel Alarcon Granero 3575 Nokia Spain 3576 Email: manuel.alarcon_granero.ext@nokia.com 3578 Francisco Jose juan Quintanilla 3579 Nokia Spain 3580 Email: francisco_jose.juan_quintanilla.ext@nokia.com 3582 Carlos Barcenilla 3583 Universidad Politecnica de Madrid 3585 Juan Quemada 3586 Universidad Politecnica de Madrid 3587 Email: jquemada@dit.upm.es 3589 Ignacio Maestro 3590 Tecnalia Research & Innovation 3591 Email: ignacio.maestro@tecnalia.com 3593 Lara Fajardo Ibanez 3594 Optiva Media 3595 Email: lara.fajardo@optivamedia.com 3597 Pablo Lopez Zapico 3598 Optiva Media 3599 Email: Pablo.lopez@optivamedia.com 3601 David Muelas Recuenco 3602 Universidad Autonoma de Madrid 3603 Email: dav.muelas@uam.es 3604 Jesus Molina Merchan 3605 Universidad Autonoma de Madrid 3606 jesus.molina@uam.es 3608 Jorge E. Lopez de Vergara Mendez 3609 Universidad Autonoma de Madrid 3610 Email: jorge.lopez_vergara@uam.es 3612 Victor Manuel Maroto Ortega 3613 Optiva Media 3614 Email: victor.maroto@optivamedia.com 3616 15 Authors' Addresses 3618 Jose Javier Garcia Aranda 3619 Nokia 3620 C/Maria Tubau 9 3621 28050 Madrid 3622 Spain 3623 Phone: +34 91 330 4348 3624 Email: jose_javier.garcia_aranda@nokia.com 3626 Monica Cortes 3627 Universidad Politecnica de Madrid 3628 Avenida Complutense 30 3629 28040 Madrid 3630 Spain 3631 Email: cortesm@dit.upm.es 3633 Joaquin Salvachua 3634 Universidad Politecnica de Madrid 3635 Avenida Complutense 30 3636 28040 Madrid 3637 Spain 3638 Phone: +34 91 0672134 3639 Email: jsalvachua@dit.upm.es 3641 Maribel Narganes 3642 Tecnalia Research & Innovation 3643 Parque Cientifico y Tecnologico de Bizkaia 3644 Geldo Auzoa, Edificio 700 3645 E-48160 Derio (Bizkaia) 3646 Spain 3647 Phone: +34 946 430 850 3648 Email: maribel.narganes@tecnalia.com 3650 Inaki Martinez Sarriegui 3651 Optiva Media 3652 Edificio Europa II, 3653 Calle Musgo 2, 1G, 3654 28023 Madrid 3655 Spain 3656 Phone: +34 91 297 7271 3657 Email: inaki.martinez@optivamedia.com