idnits 2.17.1 draft-aranda-dispatch-q4s-07.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 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 1107 has weird spacing: '... header fiel...' == 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 (December 5, 2018) is 1966 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 4566 (ref. '2') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 793 (ref. '8') (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: June 2019 Nokia 5 M. Cortes 6 J. Salvachua 7 Univ. Politecnica de Madrid 8 M. Narganes 9 Tecnalia 10 I. Martinez Sarriegui 11 Optiva 13 December 5, 2018 15 The Quality for Service Protocol 16 draft-aranda-dispatch-q4s-07.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 documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on June 5, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. 53 Abstract 55 This memo describes an application level protocol for the standard 56 communication of e2e QoS compliance information using a protocol 57 based on Hypertext Transfer Protocol (HTTP), which forms the basis 58 for the World Wide Web, and Session Description Protocol (SDP). 59 Quality for Service Protocol (Q4S) provides a mechanism for latency, 60 jitter, bandwidth and packet loss negotiation and monitoring, 61 alerting whenever one of the negotiated conditions is violated. 63 Implementation details on the actions to be triggered upon 64 reception/detection of QoS alerts exchanged by the protocol are out 65 of scope of this draft, it is application dependent (e.g. increase 66 quality, reduce bit-rate) or even network dependent (e.g. change 67 connection's quality profile). 69 Table of Contents 71 1 Introduction...................................................5 72 1.1 Scope....................................................6 73 1.2 Motivation...............................................7 74 1.3 Summary of Features......................................8 75 1.4 Differences with OWAMP/TWAMP.............................9 76 2 Terminology...................................................10 77 3 Overview of Operation.........................................10 78 4 Q4S messages..................................................22 79 4.1 Requests................................................22 80 4.2 Responses...............................................23 81 4.3 Header Fields...........................................25 82 4.3.1 Common Q4S Header Fields..........................25 83 4.3.2 Specific Q4S Request Header Fields................25 84 4.3.3 Specific Q4S Response Header Fields...............27 85 4.4 Bodies..................................................27 86 4.4.1 Encoding..........................................27 87 5 Q4S method definitions........................................28 88 5.1 BEGIN...................................................28 89 5.2 READY...................................................28 90 5.3 PING....................................................29 91 5.4 BWIDTH..................................................29 92 5.5 Q4S-ALERT...............................................29 93 5.6 Q4S-RECOVERY............................................30 94 5.7 CANCEL..................................................31 95 6 Response codes................................................31 96 6.1 100 Trying..............................................31 97 6.2 Success 2xx.............................................31 98 6.2.1 200 OK............................................31 99 6.3 Redirection 3xx.........................................32 100 6.4 Request Failure 4xx.....................................32 101 6.4.1 400 Bad Request...................................32 102 6.4.2 404 Not Found.....................................32 103 6.4.3 405 Method Not Allowed............................32 104 6.4.4 406 Not Acceptable................................32 105 6.4.5 408 Request Timeout...............................33 106 6.4.6 413 Request Entity Too Large......................33 107 6.4.7 414 Request-URI Too Long..........................33 108 6.4.8 415 Unsupported Media Type........................33 109 6.4.9 416 Unsupported URI Scheme........................33 110 6.5 Server Failure 5xx......................................33 111 6.5.1 500 Server Internal Error.........................33 112 6.5.2 501 Not Implemented...............................33 113 6.5.3 503 Service Unavailable...........................34 114 6.5.4 504 Server Time-out...............................34 115 6.5.5 505 Version Not Supported.........................34 116 6.5.6 513 Message Too Large.............................34 117 6.6 Global Failures 6xx.....................................34 118 6.6.1 600 session does not exist........................35 119 6.6.2 601 quality level not allowed.....................35 120 6.6.3 603 Session not allowed...........................35 121 6.6.4 604 authorization not allowed.....................35 122 7 Protocol......................................................35 123 7.1 Protocol Phases.........................................35 124 7.2 SDP Structure...........................................37 125 7.2.1 "qos-level" attribute.............................38 126 7.2.2 "alerting-mode" attribute.........................39 127 7.2.3 "alert-pause" attribute...........................39 128 7.2.4 "recovery-pause" attribute........................39 129 7.2.5 "public-address" attributes.......................40 130 7.2.6 "latency" attribute...............................40 131 7.2.7 "jitter" attribute................................40 132 7.2.8 "bandwidth" attribute.............................40 133 7.2.9 "packetloss" attribute............................40 134 7.2.10 "flow" attributes.................................41 135 7.2.11 "measurement" attributes..........................42 136 7.3 Measurements............................................43 137 7.3.1 Latency...........................................44 138 7.3.2 Jitter............................................44 139 7.3.3 Bandwidth.........................................45 140 7.3.4 Packet loss.......................................47 141 7.4 Handshake Phase.........................................48 142 7.5 Negotiation phase.......................................49 143 7.5.1 Stage 0: Measurement of latencies and jitters.....51 144 7.5.2 Stage 1: Measurement of bandwidth and packet loss.54 145 7.5.3 Quality constraints not reached...................57 146 7.5.3.1 Actuator role..................................60 147 7.5.3.2 Policy server role.............................61 148 7.5.4 QoS Level changes.................................61 149 7.6 Continuity phase........................................62 150 7.7 Termination Phase.......................................65 151 7.8 Dynamic constraints and flows...........................66 152 7.9 Qos-level upgrade and downgrade operation...............67 153 8 General User Agent behavior...................................69 154 8.1 Roles in peer to peer scenarios.........................69 155 8.2 Multiple Quality sessions in parallel...................70 156 8.3 General client behavior.................................71 157 8.3.1 Generating requests...............................72 158 8.4 General server behavior.................................72 159 9 Implementation Recommendations................................73 160 9.1 Default client constraints..............................73 161 9.2 Latency and Jitter measurements.........................73 162 9.3 Bandwidth measurements..................................74 163 9.4 Packet loss measurement resolution......................75 164 9.5 Measurements and reactions..............................76 165 9.6 Instability treatments..................................76 166 9.6.1 Loss of control packets...........................76 167 9.6.2 Outlier samples...................................76 168 9.7 Scenarios...............................................77 169 9.7.1 Client to ACP.....................................77 170 9.7.2 Client to client..................................78 171 10 Security Considerations.......................................78 172 10.1 Confidentiality Issues..................................78 173 10.2 Integrity of measurements and authentication............78 174 10.3 Privacy of measurements.................................78 175 10.4 Availability issues.....................................79 176 10.5 Bandwidth occupancy issues..............................79 177 11 IANA Considerations...........................................79 178 11.1 Service Port............................................79 179 11.2 Protocol parameters.....................................80 180 12 References....................................................84 181 12.1 Normative References....................................84 182 12.2 Informative References..................................85 183 13 Acknowledgments...............................................86 184 14 Contributors..................................................87 185 15 Authors' Addresses............................................88 187 1 Introduction 189 The World Wide Web (WWW) is a distributed hypermedia system which 190 has gained widespread acceptance among Internet users. Although WWW 191 browsers support other, preexisting Internet application protocols, 192 the native and primary protocol used between WWW clients and servers 193 is the HyperText Transfer Protocol (HTTP) (RFC 7230[1] to RFC 7235). 194 The ease of use of the Web has prompted its widespread employment as 195 a client/server architecture for many applications. Many of such 196 applications require the client and the server to be able to 197 communicate each other and exchange information with certain quality 198 constraints. 200 Quality in communications at application level consists of four 201 measurable parameters: 203 o Latency: The time a message takes to travel from source to 204 destination. It may be approximated to RTT/2 (Round trip time), 205 assuming the networks are symmetrical. In this context we will 206 consider the statistical median formula. 208 o Jitter: latency variation. There are some formulas to calculate 209 Jitter, and in this context we will consider the arithmetic 210 mean formula. 212 o Bandwidth: bit rate of communication. To assure quality, a 213 protocol must assure the availability of the bandwidth needed 214 by the application. 216 o Packet loss: The percentage of packet loss is closely related 217 to bandwidth and jitter. Affects bandwidth because a high 218 packet loss implies sometimes retransmissions that also 219 consumes extra bandwidth, other times the retransmissions are 220 not achieved (for example in video streaming over UDP) and the 221 information received is less than the required bandwidth. In 222 terms of jitter, a packet loss sometimes is seen by the 223 destination like a larger time between arrivals, causing a 224 jitter growth. 226 Any other communication parameter such as throughput is not a 227 network parameter because depends on protocol window size and other 228 implementation-dependent aspects. 230 Q4S provides a mechanism for quality monitoring based on an HTTP 231 syntax and SDP in order to be easily integrated in WWW, but it may 232 be used by any type of application, not only those based on HTTP. 233 Quality requirements may be needed by any type of application that 234 communicates using any kind of protocol, especially those with real- 235 time constraints. Depending on the nature of each application the 236 constraints may be different leading to different parameter 237 thresholds that need to be met. 239 Q4S is an application level Client/Server protocol that continuously 240 measures session quality for a given flow (or set of flows), end-to- 241 end and in real-time; raising alerts if quality parameters are below 242 a given pre-negotiated threshold and sending recoveries when quality 243 parameters are restored. Q4S describes when these notifications, 244 alerts and recoveries, need to be sent and the entity receiving 245 them. The actions undertaken by the receiver of the alert are out of 246 scope of the protocol. 248 Q4S is session-independent from the application flows, to minimize 249 the impact on them. To perform the measurements, two control flows 250 are created on both communication paths (forward and reverse 251 directions). 253 1.1 Scope 255 The purpose of Q4S is to measure end-to-end network quality in real- 256 time. Q4S does not transport any application data. It means that Q4S 257 is designed to be used jointly with other transport protocols such 258 as RTP, TCP, QUIC, HTTP, etc. 260 Some existent transport protocols are focused in real-time media 261 transport and certain connection metrics are available (case of 262 RTP/RTCP). Other protocols such as QUIC provides low connection 263 latencies as well as advanced congestion control. These protocols 264 transport data efficiently and provides lot of functionalities. 265 However, there is not any other quality measurement protocol apart 266 from Q4S. 268 Q4S enable applications to become reactive under e2e network quality 269 changes. To achieve it, an independent Q4S stack application must 270 run in parallel to target application. Then, Q4S metrics may be used 271 to trigger actions on target application such as speed adaptation to 272 latency in multiuser games, bitrate control at streaming services, 273 intelligent commutation of delivery node at Content Delivery 274 Networks, and whatever target application allow. 276 1.2 Motivation 278 Monitoring quality of service (QoS) in computer networks is useful 279 for several reasons: 281 o Enable real-time services and applications to verify whether 282 network resources achieve a certain QoS level. This helps real- 283 time services and applications to run through the Internet, 284 allowing the existence of Application Content providers (ACPs) 285 which offer guaranteed real-time services to the final users. 287 o Real-time monitoring allows applications to adapt themselves to 288 network conditions (Application-based QoS) and/or request more 289 network quality to the ISP (if the ISP offers this 290 possibility). 292 o Monitoring may also be required by Peer to Peer (P2P) real-time 293 applications for which Q4S can be used 295 o Enable ISPs to offer QoS to any ACP or final user application 296 in an accountable way 298 o Enable e2e negotiation of QoS parameters, independently of the 299 Internet service providers of both endpoints. 301 A protocol to monitor QoS must address the following issues: 303 o Must be ready to be used in conjunction with current standard 304 protocols and applications, without forcing a change on them. 306 o Must have a formal and compact way to specify quality 307 constraints of the desired application to run. 309 o Must have measurement mechanisms avoiding application 310 disruption, minimizing network resources consumption. 312 o Must have specific messages to alert about the violation of 313 quality constraints in different directions (forward and 314 reverse), because network routing may not be symmetrical, and 315 of course, quality constraints may not be symmetrical. 317 o After having alerted about the violation of quality 318 constraints, must have specific messages to inform about 319 recovery of quality constraints in corresponding directions 320 (forward and reverse). 322 o Must protect the data (constrains, measurements, QoS levels 323 demanded from the network) in order to avoid the injection of 324 malicious data in the measurements. 326 1.3 Summary of Features 328 Quality for Service (Q4S) is a message-oriented communication 329 protocol that can be used in conjunction with any other application- 330 level protocol. Q4S protocol is a measurement protocol. Any taken 331 action derived from its measurements are out of scope of the 332 protocol. These actions depend on application provider and may be 333 application-level adaptive reactions, may involve requests to ISP, 334 or whatever application provider decide. 336 The benefits in quality measurements provided by Q4S can be used by 337 any type of application that uses any type of protocol for data 338 transport. It provides a quality monitoring scheme for any 339 communication that takes place between the client and the server, 340 not only for the Q4S communication itself. 342 Q4S does not establish multimedia sessions and it does not transport 343 application data. It monitors the fulfillment of the quality 344 requirements of the communication between the client and the server, 345 and therefore does not impose any restrictions on the type of 346 application, protocol or the type of usage of the monitored quality 347 connection. 349 Some applications may vary their quality requirements dynamically 350 for any given quality parameter. Q4S is able to adapt to the 351 changing application needs modifying the parameter thresholds to the 352 new values and monitoring the network quality according to the new 353 quality constraints. It will raise alerts if the new constraints are 354 violated. 356 Q4S session lifetime is composed of four phases with different 357 purposes: Handshake, Negotiation, Continuity and Termination. 358 Negotiation and Continuity phases perform network parameter 359 measurements as per a negotiated measurement procedure. Different 360 measurement procedures COULD be used inside Q4S, although one 361 default measurement mechanism is needed for compatibility reasons 362 and is the one defined in this draft. Basically, Q4S defines how to 363 transport application quality requirements and measurement results 364 between client and server and providing monitoring and alerting too. 366 Q4S must be executed just before starting a client-server 367 application which needs a quality connection in terms of latency, 368 jitter, bandwidth and/or packet loss. Once client and server have 369 succeeded in establishing communication under quality constraints, 370 the application can start, and Q4S continues measuring and alerting 371 if necessary. 373 The quality parameters can be suggested by the client in the first 374 message of the handshake phase, but it's the server that accepts 375 these parameter values or forces others. The server is in charge of 376 deciding the final values of quality connection. 378 1.4 Differences with OWAMP/TWAMP 380 OWAMP(RFC 4656) [19] and TWAMP(RFC 5357) [20] are two protocols to 381 measure network quality in terms of RTT, but has a different goal 382 than Q4S. The main difference is the scope: Q4S is designed for 383 assist reactive applications, while OWAMP/TWAMP is designed just to 384 measure network delay. 386 Differences can be summarized in the following points: 388 . OWAMP/TWAMP is not intended for measuring availability of 389 resources (certain Bandwidth availability for example) but only 390 RTT. However, Q4S is intended for measuring required bandwidth, 391 packet-loss, jitter and latency in both directions. Available 392 bandwidth is not measured by Q4S, but required bandwidth for 393 specific application. 395 . OWAMP/TWAMP does not have responsivity control (which defines 396 the speed of protocol reactions under network quality changes), 397 because this protocol is designed to measure network 398 performance, not to assist reactive applications and does not 399 detect the fluctuations of quality in certain time intervals to 400 take reactive actions. However, responsivity control is a key 401 feature of Q4S. 403 . OWAMP/TWAMP is not intended to run in parallel with reactive 404 applications, but Q4S' goal is to run in parallel and assist 405 reactive applications to take decisions based on Q4S ALERT 406 packets which may trigger actions. 408 2 Terminology 410 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 411 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 412 "OPTIONAL" in this document are to be interpreted as described in 413 BCP 14 RFC 2119 [3] RFC 8174 [13] when, and only when, they appear 414 in all capitals, as shown here. 416 3 Overview of Operation 418 This section introduces the basic operation of Q4S using simple 419 examples. This section is of tutorial nature and does not contain 420 any normative statements. 422 The first example shows the basic functions of a Q4S: communication 423 establishment between a client and a server, quality requirement 424 negotiations for the requested application, application start and 425 continuous quality parameter measurements, and finally communication 426 termination. 428 The client triggers the establishment of the communication 429 requesting a specific service or application from the server. This 430 first message must have a special URI (RFC 3986), which may force 431 the use of the Q4S protocol if it is implemented in a standard web 432 browser. This message consists of a Q4S BEGIN method, which can 433 optionally include a proposal for the communication quality 434 requirements in an SDP body. This option gives the client a certain 435 negotiation capacity about quality requirements, but it will be the 436 server who finally decides about the stated requirements. 438 This request is answered by the server with a Q4S 200 OK response 439 letting the client know that it accepts the request. This response 440 message must contain an SDP body with: 442 o The assigned Q4S session id. 444 o The quality constraints required by the requested application. 446 o The measurement procedure to use. 448 o The alerting mode: there are two different scenarios for 449 sending alerts that trigger actions either on the network or in 450 the application when measurements identify violated quality 451 constraints. In both cases, alerts are triggered by the server. 453 o a) Q4S-aware-network scenario: the network is Q4S aware, 454 and reacts by itself to these alerts. In this scenario Q4S 455 ALERT messages are sent by the server to the client, and 456 network elements inspect and process these alert messages. 457 The alerting mode in this scenario is called Q4S-aware- 458 network alerting mode. 460 o b) Reactive scenario: the network is not Q4S aware. In this 461 scenario alert notifications are sent to a specific node, 462 called Actuator, which is in charge of taking decisions 463 regarding what actions to trigger: either to change 464 application behavior to adapt it to network conditions 465 and/or invoke a network policy server in order to 466 reconfigure the network and request more quality for 467 application flows. 469 +------+ +-----------+ 470 | App |<----- app flows---------->|Application| 471 |Client| +-----------+ 472 +------+ A 473 | 474 +------+ +------+ +--------+ 475 | Q4S |<----Q4S---->| Q4S |<----->|Actuator| 476 |Client| |Server| +--------+ 477 +------+ +------+ | 478 V 479 +-------------+ 480 |policy server| 481 +-------------+ 483 Figure 1 Reactive scenario 485 o The format of messages exchanged between the server stack and 486 the Actuator, doesn't follow Q4S codification rules, but their 487 format will be implementation dependent. In this way, we will 488 call "notifications" to the messages sent from the server stack 489 to the Actuator (e.g. alert notifications), and "acknowledges" 490 to messages sent from the Actuator to the server stack in 491 response to notifications (e.g. alert acknowledges). 493 o alert-pause: the amount of time between consecutive alerts. In 494 the Q4S-aware-network scenario, the server has to wait this 495 period of time between Q4S ALERT messages sent to the client. 496 In the Reactive scenario, the server stack has to wait this 497 period of time between alert notifications sent to the 498 Actuator. Measurements are not stopped in Negotiation or 499 Continuity Phases during this period of time, but no alerts are 500 fired even with violated network quality constraints in order 501 to leave time for network reconfiguration or for application 502 adjustments 504 o recovery-pause: The amount of time the Q4S server waits before 505 trying to recover initial qos-level. After having detected 506 violation of quality constraints several times, the qos-level 507 will have been increased accordingly. If this violation 508 detection finally stops, the server waits for a period of time 509 (recovery time) and if the situation persists, it tries to 510 recover to previous qos-level values gradually by sending Q4S 511 RECOVERY messages to the client, in the Q4S-aware-network 512 scenario, or recovery notifications to the Actuator, in the 513 Reactive scenario. 515 It is important to highlight that any Q4S 200 OK response sent by 516 the server to the client at any time during the life of a quality 517 session may contain an SDP body with new values of quality 518 constraints required by the application. Depending on the phase and 519 the state of the measurement procedure within the specific phase, 520 the client will react accordingly so as to take into account the new 521 quality constraints in the measurement procedure. 523 Once the communication has been established (handshake phase is 524 finished), the protocol will verify that the communication path 525 between the client and the server meets the quality constraints on 526 both directions, from and to the server (negotiation phase). This 527 negotiation phase requires taking measurements of the quality 528 parameters: latencies, jitter, bandwidth and packet loss. This phase 529 is initiated with a client message containing a Q4S READY method, 530 which will be answered by the server with a Q4S 200 OK response. 532 Negotiation measurements are achieved in two sequential stages: 534 o Stage 0: latency and jitter measurements 536 o Stage 1: bandwidth and packet loss measurements 538 Stage 0 measurements are being taken through Q4S PING messages sent 539 both from both the client and the server. All Q4S PING requests will 540 be answered by Q4S 200 OK messages to allow for bidirectional 541 measurements. 543 Different client and server implementations may send a different 544 number of PING messages for measuring, although at least 255 545 messages should be considered to perform the latency measurement. 546 The Stage 0 measurements only may be considered ended when neither 547 client nor server receive new PING messages after an implementation- 548 dependent guard time. Only after, client can send a "READY 1" 549 message. 551 After a pre-agreed number of measurements have been performed, 552 determined by the measurement procedure sent by the server, three 553 scenarios may be possible: 555 a) Measurements do not meet the requirements: in this case the stage 556 0 is repeated after sending an alert from the server to the 557 client or from the server stack to the Actuator, depending on the 558 alerting mode defined in the Handshake phase. Notice that 559 measurements continue to be taken but no alerts are fired during 560 the alert-pause time. In the Reactive scenario, the Actuator will 561 decide either to forward the alert notification to the network 562 policy server or to the application, depending on where 563 reconfiguration actions have to be taken. 565 b) Measurements do meet the requirements: in this case client moves 566 to stage 1 sending a new READY message. 568 c) At any time during the measurement procedure, the Q4S 200 OK 569 message sent by the server to the client, in response to a Q4S 570 PING message, contains an SDP body with new values of quality 571 constraints required by the application; this means the 572 application has varied their quality requirements dynamically and 573 therefore quality thresholds used while monitoring quality 574 parameters have to be changed to the new constraints. In this 575 case the client moves to the beginning of the Stage 0 for 576 initiating the negotiation measurements again. 578 Stage 1 is optional. Its purpose is to measure the availability of 579 application needed bandwidth. This stage can be skipped by client 580 sending a "READY 2" message after completion of stage 0 when 581 bandwidth requirements is set to cero kbps in the SDP. Stage 1 582 measurements are achieved through Q4S BWIDTH messages sent both from 583 the client and the server. Unlike PING messages, Q4S BWIDTH requests 584 will not be answered. 586 If Stage 0 and 1 meet the application quality constraints, the 587 application may start. Q4S will enter the continuity phase measuring 588 the network quality parameters through the Q4S PING message exchange 589 on both connection paths, and raising alerts in case of violation. . 591 Once the client wants to terminate the quality session it sends a 592 Q4S CANCEL message, which will be acknowledged by the server with 593 another Q4S CANCEL message. Termination of quality sessions are 594 always initiated by the client because Q4S TCP requests follow the 595 client server schema. 597 This figure depicts the message exchange in a successful scenario. 599 +-------------------------------------------+ 600 | | 601 | Client Server | 602 | | 603 Handshake | --------- Q4S BEGIN -----------> | 604 | <-------- Q4S 200 OK ----------- | 605 | | 606 Negotiation | | 607 (Stage 0) | --------- Q4S READY 0----------> | 608 | <-------- Q4S 200 OK ----------- | 609 | | 610 | --------- Q4S PING ------------> | 611 | <-------- Q4S 200 OK ----------- | 612 | <-------- Q4S PING ------------- | 613 | -------- Q4S 200 OK ----------> | 614 | --------- Q4S PING ------------> | 615 | <-------- Q4S PING ------------- | 616 | --------- Q4S 200 OK ----------> | 617 | <-------- Q4S 200 OK ----------- | 618 | ... | 619 Negotiation | | 620 (Stage 1) | --------- Q4S READY 1----------> | 621 | <-------- Q4S 200 OK ----------- | 622 | | 623 | --------- Q4S BWITDH ----------> | 624 | <-------- Q4S BWIDTH------------ | 625 | --------- Q4S BWITDH ----------> | 626 | <-------- Q4S BWIDTH------------ | 627 | ... | 628 Continuity | --------- Q4S READY 2 ---------> | 629 | <-------- Q4S 200 OK ----------- | app start 630 | | 631 | --------- Q4S PING ------------> | 632 | <-------- Q4S 200 OK ----------- | 633 | <-------- Q4S PING ------------- | 634 | -------- Q4S 200 OK ----------> | 635 | | 636 Termination | --------- Q4S CANCEL ----------> | app end 637 | <-------- Q4S CANCEL ----------- | 638 | | 639 +-------------------------------------------+ 640 Figure 2 Successful Q4S message exchange. 642 Client and server measurements are included into PING and BWIDTH 643 messages, allowing both sides of the communication to be are aware 644 of all measurements in both directions. 646 The following two examples show the behavior of the Q4S protocol 647 when: quality constraints are violated, alerts are generated; and, 648 later on, violation of quality constraints stops leading to the 649 execution of the recovery process. The first example shows the Q4S- 650 aware-network alerting mode scenario: 652 +-------------------------------------------+ 653 | | 654 | Client Server | 655 | | 656 Handshake | --------- Q4S BEGIN -----------> | 657 | <-------- Q4S 200 OK ----------- | 658 | | 659 Negotiation | | 660 (Stage 0) | --------- Q4S READY 0----------> | 661 | <-------- Q4S 200 OK ----------- | 662 | | 663 | --------- Q4S PING ------------> | 664 | <-------- Q4S 200 OK ----------- | 665 | <-------- Q4S PING ------------- | 666 | -------- Q4S 200 OK ----------> | 667 | ... | 668 | | 669 | <-------- Q4S ALERT ------------ | 670 | -------- Q4S ALERT ------------> | 671 | (alert-pause start) | 672 Repetition | | 673 of Stage 0 | --------- Q4S READY 0----------> | 674 | <-------- Q4S 200 OK ----------- | 675 | | 676 | --------- Q4S PING ------------> | 677 | <-------- Q4S 200 OK ----------- | 678 | <-------- Q4S PING ------------- | 679 | ... | 680 Negotiation | | 681 (Stage 1) | --------- Q4S READY 1----------> | 682 | <-------- Q4S 200 OK ----------- | 683 | | 684 | --------- Q4S BWITDH ----------> | 685 | <-------- Q4S BWIDTH------------ | 686 | ... | 687 | | 688 Continuity | --------- Q4S READY 2 ---------> | 689 | <-------- Q4S 200 OK ----------- | app start 690 | | 691 | --------- Q4S PING ------------> | 692 | <-------- Q4S 200 OK ----------- | 693 | <-------- Q4S PING ------------- | 694 | -------- Q4S 200 OK ----------> | 695 | ... | 696 |(alert-pause expires & | 697 | violated constraints) | 698 | <-------- Q4S ALERT ------------ | 699 | --------- Q4S ALERT -----------> | 700 | | 701 | (alert-pause start) | 702 | --------- Q4S PING ------------> | 703 | <-------- Q4S 200 OK ----------- | 704 | <-------- Q4S PING ------------- | 705 | --------- Q4S 200 OK ----------> | 706 | ... | 707 |(alert-pause expires & | 708 | violated constraints) | 709 | <-------- Q4S ALERT ------------ | 710 | --------- Q4S ALERT -----------> | 711 | (alert-pause) | 712 | --------- Q4S PING ------------> | 713 | <-------- Q4S 200 OK ----------- | 714 | <-------- Q4S PING ------------- | 715 | -------- Q4S 200 OK ----------> | 716 | ... | 717 |(alert-pause expires & | 718 | Fullfilled constraints) | 719 | | 720 | (recovery-pause start) | 721 | | 722 | --------- Q4S PING ------------> | 723 | <-------- Q4S 200 OK ----------- | 724 | <-------- Q4S PING ------------- | 725 | -------- Q4S 200 OK ----------> | 726 | ... | 727 |(recovery-pause expires & | 728 | Fullfilled constraints) | 729 | --------- Q4S RECOVERY ---------> | 730 | <-------- Q4S RECOVERY ----------- | 731 | | 732 | (recovery-pause start) | 733 | --------- Q4S PING ------------> | 734 | <-------- Q4S 200 OK ----------- | 735 | <-------- Q4S PING ------------- | 736 | -------- Q4S 200 OK ----------> | 737 | ... | 738 | | 739 Termination | --------- Q4S CANCEL ----------> | app end 740 | <-------- Q4S CANCEL ----------- | 741 | | 742 +-------------------------------------------+ 743 Figure 3 Q4S-aware-network alerting mode. 745 In this Q4S-aware-network alerting mode scenario, the server may 746 send Q4S alerts to the client at any time on detection of violated 747 quality constraints. This alerting exchange must not interrupt the 748 continuity quality parameter measurements between client and server. 750 The second example depicted in the following figure represents the 751 Reactive scenario, in which alert notifications are sent from the 752 server stack to the Actuator which is in charge of deciding either 753 to act over application behavior and/or invoke a network policy 754 server. The Actuator is an entity that has a pre-defined set of 755 different quality levels and decides how to act depending on the 756 actions stated for each of these levels; it can take actions for 757 making adjustments on the application or it can send a request to 758 the policy server for acting on the network. The policy server also 759 has a pre-defined set of different quality levels pre-agreed upon 760 between the Application Content Provider and the ISP. The Reactive 761 alerting mode is the default mode. 763 +-------------------------------------------+ 764 | | 765 | Client Server Actuator | 766 Handshake | ----- Q4S BEGIN -----> | 767 | <---- Q4S 200 OK ----- | 768 | | 769 Negotiation | | 770 (Stage 0) | ----- Q4S READY 0----> | 771 | <---- Q4S 200 OK ----- | 772 | | 773 | ----- Q4S PING ------> | 774 | <---- Q4S 200 OK ----- | 775 | <---- Q4S PING ------- | 776 | ---- Q4S 200 OK ----> | 777 | ... | 778 | (alert-pause start) | 779 | --alert | 780 | notification--> | 781 | | 782 | <--alert | 783 | acknowledge--- | 784 | | 785 Repetition | | 786 of Stage 0 | ----- Q4S READY 0----> | 787 | <---- Q4S 200 OK ----- | 788 | | 789 | ----- Q4S PING ------> | 790 | <---- Q4S 200 OK ----- | 791 | <---- Q4S PING ------- | 792 | ... | 793 |(alert-pause expires & | 794 | violated constraints) | 795 | | 796 | --alert | 797 | notification--> | 798 | | 799 | <--alert | 800 | acknowledge--- | 801 | | 802 | ----- Q4S PING ------> | 803 | <---- Q4S 200 OK ----- | 804 | <---- Q4S PING ------- | 805 | ... | 806 Negotiation | | 807 (Stage 1) | ----- Q4S READY 1----> | 808 | <---- Q4S 200 OK ----- | 809 | | 810 | ----- Q4S BWITDH ----> | 811 | <---- Q4S BWIDTH------ | 812 | ... | 813 Continuity | ----- Q4S READY 2 ---> | 814 | <---- Q4S 200 OK ----- | app start 815 | | 816 |(alert-pause expires & | 817 | fulfilled constraints) | 818 | | 819 |(recovery-pause start) | 820 | ----- Q4S PING ------> | 821 | <---- Q4S 200 OK ----- | 822 | <---- Q4S PING ------- | 823 | ----- Q4S PING ------> | 824 | | 825 |(recovery-pause expires & | 826 | fulfilled constraints) | 827 | | 828 | --recovery | 829 | notification--> | 830 | | 831 | <--recovery | 832 | acknowledge--- | 833 | | 834 |(recovery-pause start) | 835 | <---- Q4S 200 OK ----- | 836 | <---- Q4S PING ------- | 837 | ----- Q4S 200 OK ----> | 838 | ----- Q4S PING ------> | 839 | ... | 840 | | 841 Termination | ----- Q4S CANCEL ----> | app end 842 | --cancel | 843 | notification--> | 844 | | 845 | <--cancel | 846 | acknowledge-- | 847 | <---- Q4S CANCEL ----- | 848 | | 849 +-------------------------------------------+ 850 Figure 4 Reactive alerting mode. 852 At the end of any Negotiation phase stage, the server sends an alert 853 notification to the Actuator if quality constraints are violated. 854 During the period of time defined by the alert-pause parameter, no 855 further alert notifications are sent, but measurements are not 856 interrupted. This way, both the client and the server will detect 857 network improvements as soon as possible. In a similar way, during 858 the continuity phase, the server may send alert notifications at any 859 time to the Actuator on detection of violated quality constraints. 860 This alerting exchange must not interrupt the continuity 861 measurements between client and server. 863 Finally, in the Termination phase, Q4S CANCEL messages sent from the 864 client to the server must be forwarded from the server to the 865 Actuator in order to release possible assigned resources for the 866 session. 868 4 Q4S messages 870 Q4S is a text-based protocol and uses the UTF-8 charset (RFC 3629 871 [11]). A Q4S message is either a request or a response. 873 Both Request and Response messages use the basic format of Internet 874 Message Format (RFC 5322 [12]). Both types of messages consist of a 875 start-line, one or more header fields, an empty line indicating the 876 end of the header fields, and an optional message-body. 878 generic-message = start-line 879 *message-header 880 CRLF 881 [ message-body ] 882 start-line = Request-Line / Status-Line 884 The start-line, each message-header line, and the empty line MUST be 885 terminated by a carriage-return line-feed sequence (CRLF). Note 886 that the empty line MUST be present even if the message-body is not. 888 Much of Q4S's messages and header field syntax are identical to 889 HTTP/1.1. However, Q4S is not an extension of HTTP. 891 4.1 Requests 893 Q4S requests are distinguished by having a Request-Line for a start- 894 line. A Request-Line contains a method name, a Request-URI, and the 895 protocol version separated by a single space (SP) character. 897 The Request-Line ends with CRLF. No CR or LF are allowed except in 898 the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed 899 in any of the elements. 901 Request-Line = Method SP Request-URI SP Q4S-Version CRLF 903 Method: This specification defines seven methods: BEGIN for starting 904 and negotiate quality sessions, READY for synchronization of 905 measurements, PING and BWIDTH for quality measurements 906 purpose, CANCEL for terminating sessions, Q4S-ALERT for 907 quality violations reporting, and Q4S-RECOVERY for quality 908 recovery reporting. 910 Request-URI: The Request-URI is a Q4S URI (RFC 2396) as described in 911 7.4. The Request-URI MUST NOT contain unescaped spaces or 912 control characters and MUST NOT be enclosed in "<>". 914 Q4S-Version: Both request and response messages include the version 915 of Q4S in use. To be compliant with this specification, 916 applications sending Q4S messages MUST include a Q4S-Version 917 of "Q4S/1.0". The Q4S-Version string is case-insensitive, 918 but implementations MUST send upper-case. Unlike HTTP/1.1, 919 Q4S treats the version number as a literal string. In 920 practice, this should make no difference. 922 4.2 Responses 924 Q4S responses are distinguished from requests by having a Status- 925 Line as their start-line. A Status-Line consists of the protocol 926 version followed by a numeric Status-Code and its associated textual 927 phrase, with each element separated by a single SP character. No CR 928 or LF is allowed except in the final CRLF sequence. 930 Status-Line = Q4S-Version SP Status-Code SP Reason-Phrase CRLF 932 The Status-Code is a 3-digit integer result code that indicates the 933 outcome of an attempt to understand and satisfy a request. The 934 Reason-Phrase is intended to give a short textual description of the 935 Status-Code. The Status-Code is intended for use by automata, 936 whereas the Reason-Phrase is intended for the human user. A client 937 is not required to examine or display the Reason-Phrase. 939 While this specification suggests specific wording for the reason 940 phrase, implementations MAY choose other text, for example, in the 941 language indicated in the Accept-Language header field of the 942 request. 944 The first digit of the Status-Code defines the class of response. 945 The last two digits do not have any categorization role. For this 946 reason, any response with a status code between 100 and 199 is 947 referred to as a "1xx response", any response with a status code 948 between 200 and 299 as a "2xx response", and so on. Q4S/1.0 allows 949 following values for the first digit: 951 1xx: Provisional -- request received, continuing to process 952 the request; 954 2xx: Success -- the action was successfully received, 955 understood, and accepted; 957 3xx: Redirection -- further action needs to be taken in order 958 to complete the request; 960 4xx: Request Failure -- the request contains bad syntax or 961 cannot be fulfilled at this server; 963 5xx: Server Error -- the server failed to fulfill an 964 apparently valid request; 966 6xx: Global Failure -- the request cannot be fulfilled at any 967 server. 969 The status codes are the same described in HTTP (RFC 2616 [1]). In 970 the same way as HTTP, Q4S applications are not required to 971 understand the meaning of all registered status codes, though such 972 understanding is obviously desirable. However, applications MUST 973 understand the class of any status code, as indicated by the first 974 digit, and treat any unrecognized response as being equivalent to 975 the x00 status code of that class. 977 The Q4S-ALERT, Q4S-RECOVERY and CANCEL requests do not have to be 978 responded. However, after receiving a Q4S-ALERT, Q4S-RECOVERY or 979 CANCEL request, the server SHOULD send a Q4S-ALERT, Q4S-RECOVERY or 980 CANCEL request to the client 982 4.3 Header Fields 984 Q4S header fields are identical to HTTP header fields in both syntax 985 and semantics. 987 Some header fields only make sense in requests or responses. These 988 are called request header fields and response header fields, 989 respectively. If a header field appears in a message not matching 990 its category (such as a request header field in a response), it MUST 991 be ignored. 993 4.3.1 Common Q4S Header Fields 995 These fields may appear in Request and Response messages. 997 o Session-Id: the value for this header is the same session id 998 used in SDP (embedded in "o" SDP parameter) and is assigned by 999 the server. The messages without SDP MUST include this header. 1000 If a message has and SDP body, this header is optional. The 1001 method of allocation is up to the creating tool, 1002 but it is suggested that a UTC timestamp be used to ensure 1003 uniqueness. 1005 o Sequence-Number: sequential and cyclic positive integer number 1006 assigned to PING and BWIDTH messages, and acknowledged in 200 1007 OK responses. 1009 o Timestamp: this optional header contains the system time (with 1010 the best possible accuracy). It indicates the time in which the 1011 PING request was sent. If this header is present in PING 1012 messages, then the 200 OK response messages MUST include this 1013 value. 1015 o Stage: this is used in client's READY requests and server's 1016 200 OK responses during the Negotiation and Continuity phases 1017 in order to synchronize the initiation of the measurements. 1018 Example: Stage: 0 1020 4.3.2 Specific Q4S Request Header Fields 1022 In addition to HTTP header fields, these are the specific Q4S 1023 request header fields 1024 o User-Agent: this header contains information about the 1025 implementation of the user agent. This is for statistical 1026 purposes, the tracing of protocol violations, and the automated 1027 recognition of user agents for the sake of tailoring responses 1028 to avoid particular user agent limitations. User agents SHOULD 1029 include this field with requests. The field MAY contain 1030 multiple product tokens and comments identifying the agent and 1031 any sub-products which form a significant part of the user 1032 agent. By convention, the product tokens are listed in order of 1033 their significance for identifying the application. 1035 o Signature: this header contains a digital signature that can be 1036 used by the network, actuator or policy server to validate the 1037 SDP, preventing security attacks. The signature is an optional 1038 header generated by the server according to the pre-agreed 1039 security policies between the Application Content Provider and 1040 the ISP. For example, a hash algorithm and encryption method 1041 such as MD5 (RFC 1321 [6]) and RSA (RFC 8017 [7]) based on the 1042 server certificate could be used. This certificate is supposed 1043 to be delivered by a Certification Authority (CA) or policy 1044 owner to the server. The signature is applied to the SDP body. 1046 Signature= RSA ( MD5 (), ) 1048 If the signature is not present, other validation mechanism MAY 1049 be implemented in order to provide assured quality with 1050 security and control. 1052 o Measurements: this header carries the measurements of the 1053 quality parameters in PING and BWIDTH requests. The format is: 1055 Measurements: "l=" " "|[0..9999] ", j=" " "|[0..9999] ", pl=" " 1056 "|[0.00 .. 100.00] ", bw=" " "|[0..9999] 1058 Where "l" stands for latency followed by the measured value or 1059 an empty space, "j" stands for jitter followed by the measured 1060 value or an empty space, "pl" stands for packetloss followed by 1061 the measured value in % or an empty space and "bw" stands for 1062 bandwidth followed by the measured value or an empty space. 1064 4.3.3 Specific Q4S Response Header Fields 1066 o Expires: its purpose is to provide a sanity check and allow the 1067 server to close inactive sessions. If the client does not send 1068 a new request before the expiration time, the server MAY close 1069 the session. The value MUST be an integer and the measurement 1070 units are milliseconds. 1072 In order to keep the session open the server MUST send a Q4S 1073 alert before the session expiration (Expires header), with the 1074 same quality levels and an alert cause of "keep-alive". The 1075 purpose of this alert is to avoid TCP sockets (which were 1076 opened with READY message) from being closed, specially in NAT 1077 scenarios. 1079 4.4 Bodies 1081 Requests, including new requests defined in extensions to this 1082 specification, MAY contain message bodies unless otherwise noted. 1083 The interpretation of the body depends on the request method. 1085 For response messages, the request method and the response status 1086 code determine the type and interpretation of any message body. All 1087 responses MAY include a body. 1089 The Internet media type of the message body MUST be given by the 1090 Content-Type header field. 1092 4.4.1 Encoding 1094 The body MUST NOT be compressed. This mechanism is valid for 1095 other protocols such as HTTP and SIP (RFC 3261 [14]), but 1096 a compression/coding scheme will limit certain logical 1097 implementations of the way the request is parsed, thus, making the 1098 protocol concept more implementation dependent. In addition, 1099 bandwidth calculation may not be valid if compression is used. 1100 Therefore, the HTTP request header "Accept-Encoding" cannot be used 1101 in Q4S with different values than "identity" and if it is present in 1102 a request, the server MUST ignore it. In addition, the response 1103 header "Content-Encoding" is optional, but if present, the unique 1104 permitted value is "identity". 1106 The body length in bytes MUST be provided by the Content-Length 1107 header field. The "chunked" transfer encoding of HTTP/1.1 MUST NOT 1108 be used for Q4S (Note: The chunked encoding modifies the body of a 1109 message in order to transfer it as a series of chunks, each one with 1110 its own size indicator.) 1112 5 Q4S method definitions 1114 The Method token indicates the method to be performed on the 1115 resource identified by the Request-URI. The method is case- 1116 sensitive. 1118 Method = "BEGIN" | "READY" | "PING" | "BWIDTH" | 1119 "Q4S-ALERT" | "Q4S-RECOVERY" | "CANCEL" | 1120 extension-method 1122 extension-method = token 1124 The list of methods allowed by a resource can be specified in an 1125 "Allow" header field (RFC 2616 [1] section 14.7). The return code of 1126 the response always notifies the client when a method is currently 1127 allowed on a resource, since the set of allowed methods can change 1128 dynamically. Any server application SHOULD return the status code 1129 405 (Method Not Allowed) if the method is known, but not allowed for 1130 the requested resource, and 501 (Not Implemented) if the method is 1131 unrecognized or not implemented by the server. 1133 5.1 BEGIN 1135 The BEGIN method requests information from a resource identified by 1136 a Q4S URI. The semantics of this method is the starting of a quality 1137 session. 1139 This method is only used during the handshake phase to retrieve the 1140 SDP containing session id and all quality and operation parameters 1141 for the desired application to run. 1143 When a BEGIN message is received by the server, any current quality 1144 session MUST be cancelled and a new session should be created. 1146 The response to a Q4S BEGIN request is not cacheable. 1148 5.2 READY 1150 The READY method is used to synchronize the starting time for 1151 sending of PING and BWIDTH messages over UDP between clients and 1152 servers. The stage header included in this method is mandatory. 1154 This message is only used in negotiation and continuity phases, and 1155 only just before making a measurement. Otherwise (out of this 1156 context), the server MUST ignore this method. 1158 5.3 PING 1160 This message is used during the negotiation and continuity phases to 1161 measure the RTT and jitter of a session. The message MUST be sent 1162 only over UDP ports. 1164 The fundamental difference between the PING and BWIDTH requests is 1165 reflected in the different measurements achieved with them. PING is 1166 a short message, and MUST be answered in order to measure RTT and 1167 jitter, whereas BWIDTH is a long message (1 Kbyte or more) and MUST 1168 NOT be answered. 1170 PING is a request method that can be originated by client but also 1171 by server. Client MUST also answer the server PING messages, 1172 assuming a "server role" for these messages during measurement 1173 process. 1175 The Measurements header included in this method is mandatory, and 1176 provides updated measurements values for latency, jitter and packet 1177 loss to the counterpart. 1179 5.4 BWIDTH 1181 This message is used only during the Negotiation phase to measure 1182 the bandwidth and packet loss of a session. The message MUST be sent 1183 only over UDP ports. 1185 BWIDTH is a request method that can be originated by the client but 1186 also by server. Both (client and server) MUST NOT answer BWIDTH 1187 messages. 1189 The Measurements header included in this method is mandatory and 1190 provides updated measurements values for bandwidth and packet loss 1191 to the counterpart. 1193 5.5 Q4S-ALERT 1195 This is the request message that Q4S generates when the measurements 1196 indicate that quality constraints are being violated. It is used 1197 during the negotiation and continuity phases. 1199 This informative message indicates that the user experience is being 1200 degraded and includes the details of the problem (bandwidth, jitter, 1201 packet loss measurements). The Q4S-ALERT message does not contain 1202 any detail on the actions to be taken, which depends on the 1203 agreements between all involved parties. 1205 Q4S-ALERT request does not have to be answered with a response 1206 message unless there is an error condition. However, after receiving 1207 a Q4S-ALERT request, the counterpart answers with a Q4S-ALERT 1208 request. The response to a Q4S-ALERT request is not cacheable. 1210 This method MUST be initiated by the server in both alerting modes. 1211 In Q4S-aware-network alerting mode, the Q4S-ALERT messages are fired 1212 by the server and sent to the client, advising the network to react 1213 by itself. In Reactive alerting mode, alert notifications are 1214 triggered by the server stack and sent to the Actuator(see Figure1 1215 "Reactive Scenario"). 1217 Client----q4s----SERVER STACK--->ACTUATOR-->APP OR POLICY SERVER 1219 The way in which the server stack notifies the Actuator is 1220 implementation dependent, and the communication between the Actuator 1221 and the network policy server is defined by the protocol and API 1222 that the policy server implements. 1224 5.6 Q4S-RECOVERY 1226 This is the request message that Q4S generates when the measurements 1227 indicate that quality constraints were being violated but they have 1228 been fulfilled during a period of time already (recovery pause). It 1229 is used during the negotiation and continuity phases. 1231 This informative message indicates that the qos-level could be 1232 increased gradually until the initial qos-level is recovered (the 1233 qos-level established at the beginning os the session of that was 1234 decreased during violation of constraints). The Q4S-RECOVERY message 1235 does not contain any detail on the actions to be taken, which 1236 depends on the agreements between all involved parties. 1238 Q4S- RECOVERY request MUST NOT be answered with a response message 1239 unless there is an error condition. However, after receiving a Q4S- 1240 RECOVERY request, the counterpart MUST answer with a Q4S- RECOVERY 1241 request. The response to a Q4S- RECOVERY request is not cacheable. 1243 As for the Q4S-ALERT message, the Q4S-RECOVERY method is always 1244 initiated by the server in both alerting modes. In Q4S-aware-network 1245 alerting mode, the Q4S-RECOVERY messages are fired by the server and 1246 sent to the client, advising the network to react by itself. In 1247 Reactive alerting mode, recovery notifications are triggered by the 1248 server stack and sent to the Actuator(see Figure1 "Reactive 1249 Scenario"). 1251 5.7 CANCEL 1253 The semantics of CANCEL message is the release of the Q4S session id 1254 and the possible resources assigned to the session. This message 1255 could be triggered by Q4S stack or by the application using the 1256 stack (through an implementation dependent API). 1258 In the same way as Q4S-ALERT, CANCEL must not be answered with a 1259 response message. However, if the server receives a CANCEL message, 1260 it must answer with a CANCEL request message towards the client, 1261 acknowledging the reception. 1263 In the Reactive scenario, the server stack MUST react to the Q4S 1264 CANCEL messages received from the client by forwarding a cancel 1265 notification to the Actuator, in order to release possible assigned 1266 resources for the session (at application or at policy server). The 1267 Actuator MUST answer the cancel notification with a cancel 1268 acknowledge towards the server stack, acknowledging the reception. 1270 6 Response codes 1272 Q4S response codes are used for TCP and UDP. However, in UDP only 1273 the response code 200 is used. 1275 6.1 100 Trying 1277 This response indicates that the request has been received by the 1278 next-hop server and that some unspecified action is being taken on 1279 behalf of this request (for example, a database is being consulted). 1280 This response, like all other provisional responses, stops 1281 retransmissions of a Q4S-ALERT during the alert-pause time. 1283 6.2 Success 2xx 1285 2xx responses give information about success of a request. 1287 6.2.1 200 OK 1289 The request has succeeded. 1291 6.3 Redirection 3xx 1293 3xx responses give information about the user's new location, or 1294 about alternative services that might be able to satisfy the 1295 request. 1297 The requesting client SHOULD retry the request at the new 1298 address(es) given by the Location header field. 1300 6.4 Request Failure 4xx 1302 4xx responses are definite failure responses from a particular 1303 server. The client SHOULD NOT retry the same request without 1304 modification (for example, adding appropriate headers or SDP 1305 values). However, the same request to a different server might be 1306 successful. 1308 6.4.1 400 Bad Request 1310 The request could not be understood due to malformed syntax. The 1311 Reason-Phrase SHOULD identify the syntax problem in more detail, for 1312 example, "Missing Sequence-Number header field". 1314 6.4.2 404 Not Found 1316 The server has definitive information that the user does not exist 1317 at the domain specified in the Request-URI. This status is also 1318 returned if the domain in the Request-URI does not match any of the 1319 domains handled by the recipient of the request. 1321 6.4.3 405 Method Not Allowed 1323 The method specified in the Request-Line is understood, but not 1324 allowed for the address identified by the Request-URI. 1326 The response MUST include an Allow header field containing a list of 1327 valid methods for the indicated address. 1329 6.4.4 406 Not Acceptable 1331 The resource identified by the request is only able of generating 1332 response entities that have content characteristics not acceptable 1333 according to the Accept header field sent in the request. 1335 6.4.5 408 Request Timeout 1337 The server could not produce a response within a suitable amount of 1338 time, and the client MAY repeat the request without modifications at 1339 any later time 1341 6.4.6 413 Request Entity Too Large 1343 The server is refusing to process a request because the request 1344 entity-body is larger than the one that the server is willing or 1345 able to process. The server MAY close the connection to prevent the 1346 client from continuing the request. 1348 6.4.7 414 Request-URI Too Long 1350 The server is refusing to process the request because the Request- 1351 URI is longer than the one that the server accepts. 1353 6.4.8 415 Unsupported Media Type 1355 The server is refusing to process the request because the message 1356 body of the request is in a format not supported by the server for 1357 the requested method. The server MUST return a list of acceptable 1358 formats using the Accept, Accept-Encoding, or Accept-Language header 1359 field, depending on the specific problem with the content. 1361 6.4.9 416 Unsupported URI Scheme 1363 The server cannot process the request because the scheme of the URI 1364 in the Request-URI is unknown to the server. 1366 6.5 Server Failure 5xx 1368 5xx responses are failure responses given when a server itself is 1369 having trouble. 1371 6.5.1 500 Server Internal Error 1373 The server encountered an unexpected condition that prevented it 1374 from fulfilling the request. The client MAY display the specific 1375 error condition and MAY retry the request after several seconds. 1377 6.5.2 501 Not Implemented 1379 The server does not support the functionality required to fulfill 1380 the request. This is the appropriate response when a Server does not 1381 recognize the request method and it is not capable of supporting it 1382 for any user. 1384 Note that a 405 (Method Not Allowed) is sent when the server 1385 recognizes the request method, but that method is not allowed or 1386 supported. 1388 6.5.3 503 Service Unavailable 1390 The server is temporarily unable to process the request due to a 1391 temporary overloading or maintenance of the server. The server MAY 1392 indicate when the client should retry the request in a Retry-After 1393 header field. If no Retry-After is given, the client MUST act as if 1394 it had received a 500 (Server Internal Error) response. 1396 A client receiving a 503 (Service Unavailable) SHOULD attempt to 1397 forward the request to an alternate server. It SHOULD NOT forward 1398 any other requests to that server for the duration specified in the 1399 Retry-After header field, if present. 1401 Servers MAY refuse the connection or drop the request instead of 1402 responding with 503 (Service Unavailable). 1404 6.5.4 504 Server Time-out 1406 The server did not receive a timely response from an external server 1407 it accessed in attempting to process the request. 1409 6.5.5 505 Version Not Supported 1411 The server does not support, or refuses to support, the Q4S protocol 1412 version that was used in the request. The server is indicating that 1413 it is unable or unwilling to complete the request using the same 1414 major version as the client, other than with this error message. 1416 6.5.6 513 Message Too Large 1418 The server was unable to process the request since the message 1419 length exceeded its capabilities. 1421 6.6 Global Failures 6xx 1423 6xx responses indicate that a server has definitive information 1424 about a particular policy not satisfied for processing the request. 1426 6.6.1 600 session does not exist 1428 The Session-Id is not valid 1430 6.6.2 601 quality level not allowed 1432 The QOS level requested is not allowed for the pair client/server 1434 6.6.3 603 Session not allowed 1436 The session is not allowed due to some policy (number of sessions 1437 allowed for the server is exceeded, or the time band of the Q4S- 1438 ALERT is not allowed for the pair client/server, etc.). 1440 6.6.4 604 authorization not allowed 1442 The policy server does not authorize the Q4S-ALERT quality session 1443 improvement operation due to an internal or external reason. 1445 7 Protocol 1447 This section describes the measurement procedures, the SDP structure 1448 of the Q4S messages, the different Q4S protocol phases and the 1449 messages exchanged in them. 1451 7.1 Protocol Phases 1453 All elements of the IP network contribute to the quality in terms 1454 of latency, jitter, bandwidth and packet loss. All these elements 1455 have their own quality policies in terms of priorities, traffic 1456 mode, etc. and each element has its own way to manage the quality. 1457 The purpose of a quality connection is to establish an end-to-end 1458 communication with enough quality for the application to function 1459 flawlessly. 1461 To monitor quality constraints of the application, four phases are 1462 defined and can be seen in the following figure: 1464 +---------------------------------------------------------------+ 1465 | | 1466 | | 1467 | Handshake ---> Negotiation -+--> Continuity ----> Termination | 1468 | A | (app start) | (app end) | 1469 | | | A | A | 1470 | | violated | violated | | 1471 | | constraints | constraints | | 1472 | | | | |_______| ____| | 1473 | | | | +-------+ | | 1474 | | | | | | 1475 | +------+ +---------------------+ | 1476 | | 1477 +---------------------------------------------------------------+ 1479 Figure 5 Session lifetime phases. 1481 o Handshake phase: in which the server is contacted by the client 1482 and in the answer message the quality constraints for the 1483 application is communicated embedded in an SDP. 1485 o Negotiation phase: in which the quality of the connection is 1486 measured in both directions (latency, jitter, bandwidth and 1487 packet loss), and Q4S messages may be sent in order to alert if 1488 the measured quality does not meet the constraints. This phase 1489 is iterative until quality constraints are reached, or the 1490 session is cancelled after a number of measurement cycles with 1491 consistent violation of the quality constraints. The number of 1492 measurement cycles executed depends on the qos-level which is 1493 incremented in each cycle until a maximum qos-level value is 1494 reached. Just after reaching the quality requirements, Q4S 1495 provides a simple optional mechanism using HTTP to start the 1496 application. 1498 o Continuity phase: in which quality is continuously measured. In 1499 this phase the measurements MUST avoid disturbing the 1500 application by consuming network resources. If quality 1501 constraints are not met, the server stack will notify the 1502 Actuator with an alert notification. If later the quality 1503 improves, the server stack will notify the Actuator, in this 1504 case with a recovery notification. After several alert 1505 notifications with no quality improvements, the Q4S stack 1506 SHOULD move to Termination phase. 1508 o Termination phase: in which the Q4S session is terminated. The 1509 application may be closed too or may not start. 1511 7.2 SDP Structure 1513 The original goal of SDP was to announce necessary information for 1514 the participants and multicast MBONE (Multicast Backbone) 1515 applications. Right now, its use has been extended to the 1516 announcement and the negotiation of multimedia sessions. The purpose 1517 of Q4S is not to establish media stream sessions, but to monitor a 1518 quality connection. This connection may be later used to establish 1519 any type of session including media sessions; Q4S does not impose 1520 any conditions on the type of communication requiring quality 1521 parameters. 1523 SDP will be used by Q4S to exchange quality constraints and will 1524 therefore always have all the media attributes ("m") set to zero. 1526 The SDP embedded in the messages is the container of the quality 1527 parameters. As these may vary depending on the direction of the 1528 communication (to and from the client) all quality parameters need 1529 to specify the uplink and downlink values: / . 1530 When one or both of these values are empty, it MUST be understood as 1531 needing no constraint on that parameter and/or that direction. 1533 The uplink direction MUST be considered as being the communication 1534 from the client to the server. The downlink direction MUST be 1535 considered as being the communication from the server to the client. 1537 The SDP information can comprise all or some of the following 1538 parameters shown in the example below. This is an example of an SDP 1539 message used by Q4S included in the 200 OK response to a Q4S BEGIN 1540 request. 1542 v=0 1543 o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33 1544 s=Q4S 1545 i=Q4S parameters 1546 t=0 0 1547 a=qos-level:0/0 1548 a=alerting-mode:Reactive 1549 a=alert-pause:5000 1550 a=public-address:client IP4 198.51.100.51 1551 a=public-address:server IP4 198.51.100.58 1552 a=measurement:procedure default(50/50,75/75,5000,40/80,100/256) 1553 a=latency:40 1554 a=jitter:10/10 1555 a=bandwidth:20/6000 1556 a=packetloss:0.50/0.50 1557 a=flow:app clientListeningPort TCP/10000-20000 1558 a=flow:app clientListeningPort UDP/15000-18000 1559 a=flow:app serverListeningPort TCP/56000 1560 a=flow:app serverListeningPort UDP/56000 1561 a=flow:q4s clientListeningPort UDP/55000 1562 a=flow:q4s clientListeningPort TCP/55001 1563 a=flow:q4s serverListeningPort UDP/56000 1564 a=flow:q4s serverListeningPort TCP/56001 1566 As quality constraints may be changed by applications at any time 1567 during the Q4S session lifetime, any Q4S 200 OK response sent by the 1568 server to the client in the Negotiation and Continuity phases could 1569 also include an SDP body with the new quality requirements stated by 1570 the applications from then on. Therefore, in response to any PING 1571 request sent by the client to the server, the server could send a 1572 Q4S 200 OK with an SDP message embedded that specifies new quality 1573 constraints requested by the application. 1575 7.2.1 "qos-level" attribute 1577 The "qos-level" attribute contains the QoS level for uplink and 1578 downlink. Default values are 0 for both directions. The meaning of 1579 each level is out of scope of Q4S, but a higher level SHOULD 1580 correspond to a better service quality. 1582 The "qos-level" attribute may be changed during the session lifetime 1583 raising or lowering the value as necessary following the network 1584 measurements and the application needs. 1586 7.2.2 "alerting-mode" attribute 1588 The "alerting-mode" attribute specifies the player in charge of 1589 triggering Q4S alerts in case of constraint violation. There are two 1590 possible values: 1592 a) Q4S-aware-network: Q4S ALERT messages are triggered by the server 1593 to the client. In this case the network is supposed to be Q4S 1594 aware, and reacts by itself to these alerts. 1596 b) Reactive: alert notifications are sent by the server stack to the 1597 Actuator. In this case the network is not Q4S aware and a 1598 specific node (Actuator) is in charge of triggering tuning 1599 mechanisms., either on the network or in the application. 1601 The "alerting-mode" attribute is optional and if not present 1602 Reactive alerting mode is assumed. 1604 7.2.3 "alert-pause" attribute 1606 In the Q4S-aware-network scenario, the "alert-pause" attribute 1607 specifies the amount of time (in milliseconds) the server waits 1608 between consecutive Q4S ALERT messages sent to the client. In the 1609 Reactive scenario, the "alert-pause" attribute specifies the amount 1610 of time (in milliseconds) the server stack waits between consecutive 1611 alert notifications sent to the Actuator. Measurements are not 1612 stopped in Negotiation or Continuity Phases during this period of 1613 time, but no Q4S ALERT messages or alert notifications are fired, 1614 even with violated quality constraints, allowing either network 1615 reconfigurations or application adjustments. 1617 7.2.4 "recovery-pause" attribute 1619 In the Q4S-aware-network scenario, the "recovery-pause" attribute 1620 specifies the amount of time (in milliseconds) the server waits for 1621 initiating the qos-level recovery process. Once the recovery process 1622 has started, the "recovery-pause" attribute also states the amount 1623 of time (in milliseconds) between consecutive Q4S-RECOVERY messages 1624 sent by the server to the client (in the Q4S-aware-network 1625 scenario), or between recovery notifications sent by the server 1626 stack to the Actuator (in the Reactive scenario). 1628 7.2.5 "public-address" attributes 1630 This attribute contains the public IP address of the client and the 1631 server. The server fills these attributes with his own public IP 1632 address and the public IP address of the first message received from 1633 the client in the handshake phase. 1635 The purpose of these attributes is to make available the addressing 1636 information to network policy server or other external entities in 1637 charge of processing Q4S-ALERT messages. 1639 7.2.6 "latency" attribute 1641 The maximum latency (considered equal for uplink and downlink) 1642 tolerance are specified in the "latency" attribute, expressed in 1643 milliseconds. In the Q4S-aware-network scenario, if the latency 1644 constraints are not met, a Q4S-ALERT method will be sent to the 1645 client. In the Reactive scenario, if the latency constraints are not 1646 met, an alert notification will be sent to the Actuator. If the 1647 "latency" attribute is not present or has a 0 value, no latency 1648 constraints need to be met and no measurements MAY be taken. 1650 7.2.7 "jitter" attribute 1652 The maximum uplink and downlink jitter tolerance are specified in 1653 the "jitter" attribute, expressed in milliseconds. In the Q4S-aware- 1654 network scenario, if the jitter constraints are not met, a Q4S-ALERT 1655 method will be sent to the client. In the Reactive scenario, if the 1656 latency constraints are not met, an alert notification will be sent 1657 to the Actuator. If "jitter" attribute is not present or has a 0 1658 value, no jitter constraints need to be met and no measurements MAY 1659 be taken. 1661 7.2.8 "bandwidth" attribute 1663 The minimum uplink and downlink bandwidth are specified in the 1664 "bandwidth" attribute, expressed in kbps. In the Q4S-aware-network 1665 scenario, if the bandwidth constraints are not met, a Q4S-ALERT 1666 method will be sent to the client. In the Reactive scenario, an 1667 alert notification will be sent to the Actuator. If "bandwidth" 1668 attribute is not present or has a 0 value, no bandwidth constraints 1669 need to be met and no measurements MAY be taken. 1671 7.2.9 "packetloss" attribute 1673 The maximum uplink and downlink packet loss tolerance are specified 1674 in the "packetloss" attribute expressed in percentage (two decimal 1675 accuracy). In the Q4S-aware-network scenario, if the packetloss 1676 constraints are not met, a Q4S-ALERT method will be sent to the 1677 client. In the Reactive scenario, an alert notification will be sent 1678 to the Actuator. If "packetloss" attribute is not present or has a 0 1679 value, no packetloss constraints need to be met and no measurements 1680 MAY be taken. 1682 7.2.10 "flow" attributes 1684 These attributes specify the flows (protocol, destination IP/ports) 1685 of data over TCP and UDP ports to be used in uplink and downlink 1686 communications. 1688 Several "flow" attributes can be defined. These flows identify the 1689 listening port (client or server), the protocol (TCP or UDP) (RFC 1690 793 [8] and RFC 768 [9]) with the range of ports that are going to 1691 be used by the application and, of course, by the Q4S protocol (for 1692 quality measurements). All defined flows (app and q4s) will be 1693 considered within the same quality profile, which is determined by 1694 the qos-level attribute in each direction. This allows to assume 1695 that measurements on q4s flows are the same experimented by the 1696 application which is using app flows. 1698 During negotiation and continuity phases the specified Q4S ports in 1699 the "flow:q4s" attributes of SDP will be used for Q4S messages. 1701 The Q4S flows comprise two UDP flows and two TCP flows (one uplink 1702 and one downlink for each one) whereas application traffic MAY 1703 consist of many flows, depending on its nature. The handshake phase 1704 takes place through the Q4S Contact URI, using the standard Q4S TCP 1705 port. However, the negotiation and continuity phases will take place 1706 on the specified Q4S ports (UDP and TCP) specified in the SDP. 1708 The "clientListeningPort" is a port in which the client listens for 1709 server requests and MUST be used as origin port of client responses. 1710 The "serverListeningPort" is a port in which server is listening for 1711 incoming messages from the client. The origin port of server 1712 responses may be different than "serverListeningPort" value. 1714 If "clientListeningPort" is zero (a=flow:q4s clientListeningPort 1715 TCP/0), the client MAY choose one randomly as per OS standard rules. 1716 Client ports inside the SDP must always be matched against actual 1717 received port values on the server side in order to deal with 1718 NAT/NATP devices. If zero value or incorrect value is present, 1719 server must set the value to the received origin port in the next 1720 message with SDP (200 OK, ALERT and CANCEL messages). 1722 7.2.11 "measurement" attributes 1724 These attributes contain the measurement procedure and the results 1725 of the quality measurements. 1727 Measurement parameters are included using the session attribute 1728 "measurement". The first measurement parameter is the procedure. Q4S 1729 provides a "default" procedure for measurements, but others like 1730 RTP/RTCP might be used and defined later. This draft will only 1731 define and explain the "default" procedure. 1733 In the initial client request a set of measurement procedures can be 1734 sent to the server for negotiation. One measurement procedure line 1735 MUST be included in the SDP message for each proposed method. The 1736 server MUST answer with only one line with the chosen procedure. 1738 For each procedure, a set of values of parameters separated by "," 1739 can be included in the same attribute line. The amount and type of 1740 parameters depends on the procedure type. 1742 In the following example the "default" procedure type is chosen: 1744 a=measurement:procedure default(50/50,75/75,5000,40/80,100/256) 1746 In the "default" procedure, the meaning of these parameters is: 1748 o The first parameter is the interval of time (in milliseconds) 1749 between PING requests during the negotiation phase. Uplink and 1750 downlink values from the client's point of view are separated 1751 by "/". This allows having different responsiveness values 1752 depending on the control resources used in each direction. 1754 o The second parameter is the time interval (in milliseconds) 1755 between PING requests during the continuity phase. Uplink and 1756 downlink values are separated by "/". This allows having two 1757 different responsiveness values depending on the control 1758 resources used in each direction. 1760 o The third parameter is the time interval to be used to measure 1761 bandwidth during the negotiation phase. 1763 o The fourth parameter indicates the window size for jitter and 1764 latency calculations. Uplink and downlink values are separated 1765 by "/". 1767 o The fifth parameter indicates the window size for packet loss 1768 calculations. Uplink and downlink values are separated by "/". 1770 There are four more measurement attributes: 1772 a=measurement:latency 45 1773 a=measurement:jitter 3/12 1774 a=measurement:bandwidth 200/9800 1775 a=measurement:packetloss 0.00/1.00 1777 The latency, jitter, bandwidth and packet-loss measurement 1778 attributes contain the values measured for each of these quality 1779 parameters in uplink and downlink directions. Notice that latency is 1780 considered equal for uplink and downlink directions. Quality 1781 parameter values in these measurement attributes provide a snapshot 1782 of the quality reached and MUST only be included in Q4S-ALERT 1783 messages in the SDP body such that they can be protected from 1784 malicious attacks as these alerts include a signature of the SDP 1785 body in the header. The rest of messages will include the measured 1786 values in the Measurements header. 1788 7.3 Measurements 1790 This section describes the way quality parameters are measured as 1791 defined by the "default" procedure. Measurements MUST be taken for 1792 any quality parameter with constraints, that is, specified in the 1793 SDP attributes with non-zero values. For non-present attributes 1794 measurements MAY be omitted. 1796 7.3.1 Latency 1798 Latency measurements will be performed if the latency attribute 1799 and/or the application latency attribute are present and with non- 1800 zero values. 1802 Q4S defines a PING method in order to exchange packets between the 1803 client and the server. Based on this PING exchange the client and 1804 the server are able to calculate the round-trip time (RTT). The RTT 1805 is the sum of downlink latency (normally named "reverse latency") 1806 and uplink latency (normally named "forward latency"). 1808 At least 255 samples of RTT MUST be taken by the client and server. 1809 As the forward and reverse latencies are impossible to measure, 1810 client and server will assume that both latencies are identical 1811 (symmetric network assumption). The latency will therefore be 1812 calculated as the statistical median value of all the RTT samples 1813 divided by 2. 1815 7.3.2 Jitter 1817 Jitter measurements will be performed if the jitter attribute and/or 1818 the application jitter attribute are present and with non-zero 1819 values. 1821 The jitter can be calculated independently by the client and by the 1822 server. The downlink jitter is calculated by the client taking into 1823 account the time interval between PING requests as defined by the 1824 measurement procedure attribute in the first or second parameter 1825 depending on the Q4S protocol phase. The client and the server MUST 1826 send these PING requests at the specified intervals. The client 1827 measures the downlink jitter whereas the server measures the uplink 1828 jitter. Note that PING responses are not taken into account when 1829 calculating jitter values. 1831 Every time a PING request message is received by an endpoint (either 1832 server or client), the corresponding jitter value is updated using 1833 the Statistical Jitter value calculated on the first 255 packets 1834 received using the arithmetic mean of the absolute values of elapsed 1835 times. 1837 Each endpoint sends a PING periodically with a fixed interval, each 1838 value of "elapsed time" (ET) should be very close to this interval. 1839 If a PING message is lost, the elapsed time value is doubled. 1840 Identifying lost PING messages, however, is not an issue because all 1841 PING messages are labeled with a Sequence-Number header. Therefore 1842 the receiver can discard this elapsed time value. 1844 In order to have the first jitter sample, the receiver MUST wait 1845 until it receives 3 PING requests, because each ET is the time 1846 between two PINGs and a Jitter needs at least two ET. 1848 The client measures the values of RTT and downlink jitter and the 1849 server measures RTT and uplink jitter, but all measurements are 1850 shared with the counterpart by means of "Measurements" header of 1851 PING message. 1853 7.3.3 Bandwidth 1855 Bandwidth measurements will be performed if the bandwidth attribute 1856 and/or the application bandwidth attribute is present and with non- 1857 zero values. 1859 In order to measure the available bandwidth, both the client and the 1860 server MUST start sending BWIDTH messages simultaneously using the 1861 UDP control ports exchanged during the handshake phase in the SDP 1862 message, at the needed rate to verify the availability of the 1863 bandwidth constraint in each direction using messages of 1 Kbyte or 1864 more in length. The messages are sent during the period of time 1865 defined in the third parameter of the SDP measurement default 1866 procedure attribute in millisecond units. 1868 a=measurement:procedure default(50/50,75/75,5000,256/256,256/256) 1869 +------------------------------------------------+ 1870 | Rate | 1871 | A | 1872 | | | 1873 |downlink rate-|-------------------+ <-- traffic | 1874 | | | sent by | 1875 | | | server | 1876 | | | | 1877 | | | | 1878 | | | | 1879 | | | | 1880 | | | | 1881 | | | | 1882 | | | | 1883 | | | | 1884 | | | | 1885 | | | | 1886 | | | | 1887 | | | | 1888 | uplink rate-|-------------------+ <-- traffic | 1889 | | | sent by | 1890 | | | client | 1891 | | | | 1892 | | | | 1893 | |---|---|---|---|---|----> time | 1894 | 0 1 2 3 4 5 (sec.) | 1895 | | 1896 +------------------------------------------------+ 1898 Figure 6 Bandwidth and packet loss measurements. 1900 The goal of these measurements is not to identify the available 1901 bandwidth of the communication path but to determine if the required 1902 bandwidth is available, meeting the application's constraints. 1903 Therefore, the requested bandwidth MUST be measured sending only the 1904 highest bit rate required by the bandwidth attribute. 1906 During bandwidth measurement time, ALERTS are not expected, but only 1907 at the end of the measurement time. 1909 When measuring bandwidth, all BWIDTH requests sent MUST be 1 1910 kilobyte in length (UDP payload length), and MUST include a 1911 Sequence-Number header with a sequential number starting at 0. The 1912 Sequence-Number MUST be incremented by 1 with each BWIDTH packet 1913 sent. If any measurement stage needs to be repeated, the sequence 1914 number MUST start at zero again. BWIDTH requests MUST NOT be 1915 answered. Examples: 1917 Client message: 1918 ========================= 1919 BWIDTH q4s://www.example.com Q4S/1.0 1920 User-Agent: q4s-ua-experimental-1.0 1921 Session-Id: 53655765 1922 Sequence-Number: 0 1923 Content-Type: text 1924 Content-Length: XXXX 1925 Measurements: l=22, j=10, pl=0.00, bw=3000 1927 aaaaaaaaaaaaa ( to complete 1024 bytes UDP payload length) 1928 ========================= 1930 The client MUST send BWIDTH packets to the server to allow the 1931 server to measure the uplink bandwidth. The server MUST send BWIDTH 1932 packets to the client to allow the client to measure the downlink 1933 bandwidth. 1935 Server message: 1936 ========================= 1937 BWIDTH q4s://www.example.com Q4S/1.0 1938 Session-Id: 53655765 1939 Sequence-Number: 0 1940 Content-Type: text 1941 Content-Length: XXXX 1942 Measurements: l=22, j=7, pl=0.00, bw=200 1944 aaaaaaaaaaaaa ( to complete 1024 bytes UDP payload length) 1945 ========================= 1947 7.3.4 Packet loss 1949 Packet loss and bandwidth are measured simultaneously using the 1950 BWIDTH packets sent by both the client and the server. Because the 1951 BWIDTH packets contain a Sequence-Number header incremented 1952 sequentially with each sent packet, lost packets can be easily 1953 identified. The lost packets MUST be counted during the measurement 1954 time. 1956 7.4 Handshake Phase 1958 The first phase consists of a Q4S BEGIN method issued from the 1959 client to the server. 1961 The first Q4S message MUST have a special URI (RFC 3986 [4]), which 1962 forces the use of the Q4S protocol if it is implemented in a 1963 standard web browser. 1965 This URI, named "Contact URI", is used to request the start of a 1966 session. Its scheme MUST be: 1968 "q4s:" "//" host [":" port] [path["?" query] 1970 Optionally, the client can send the desired quality parameters 1971 enclosed in the body of the message as an SDP document. The server 1972 MAY take them into account when building the answer message with the 1973 final values in the SDP body, following a request / response schema 1974 (RFC 3464 [5]). 1976 If the request is accepted, the server MUST answer it with a Q4S 200 1977 OK message, which MUST contain an SDP body (RFC 4566 [2]) with the 1978 assigned session id (embedded in the "o" SDP parameter), the IP 1979 addresses to be used, the flow ports to be used, the measurement 1980 procedure to be followed and information about the required quality 1981 constraints. Additionally, the alerting-mode and alert-pause time 1982 parameters may be included. Q4S responses should use the protocol 1983 designator "Q4S/1.0". 1985 After these two messages are exchanged, the first phase is 1986 completed. The quality parameter thresholds have been sent to the 1987 client. The next step is to measure the actual quality of the 1988 communication path between the client and the server and alert if 1989 the SLA is being violated. 1991 +------------------------------------------------+ 1992 | | 1993 | Client Server | 1994 | | 1995 | ------- Q4S BEGIN ------------> | 1996 | | 1997 | <------ Q4S 200 OK ------------ | 1998 | | 1999 | | 2000 +------------------------------------------------+ 2002 Figure 7 Handshake phase. 2004 Example of Client Request and Server Answer: 2006 Client Request: 2007 ========================= 2008 BEGIN q4s://www.example.com Q4S/1.0 2009 Content-Type: application/sdp 2010 User-Agent: q4s-ua-experimental-1.0 2011 Content-Length: 142 2013 (SDP not shown) 2014 ========================= 2016 Server Answer: 2017 ========================= 2018 Q4S/1.0 200 OK 2019 Date: Mon, 10 Jun 2010 10:00:01 GMT 2020 Content-Type: application/sdp 2021 Expires: 3000 2022 Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 2023 Content-Length: 131 2025 (SDP not shown) 2026 ========================= 2028 The headers used are explained in section 4.3. 2030 7.5 Negotiation phase 2032 The negotiation phase is in charge of measuring the quality 2033 parameters and verifying that the communication paths meet the 2034 required quality constraints on both directions as specified in the 2035 SDP body. 2037 The measured parameters will be compared with the quality 2038 constraints specified in the SDP body. If the quality session is 2039 compliant with all the quality constraints the application can 2040 start. 2042 o If the quality constraints are not met, a higher quality 2043 service level will be demanded. Depending on the scenario, this 2044 quality upgrade will be managed as follows: In the Q4S-aware- 2045 network scenario: a Q4S-ALERT method will be triggered by the 2046 server to the client and the client will answer with the same 2047 Q4S-ALERT method. After receiving the same Q4S-ALERT from the 2048 counterpart, no other alerts will be triggered by the server 2049 during the "alert-pause" period of time, in order to allow the 2050 network to react, but measurements will continue to be taken to 2051 achieve early detection of improved network quality conditions 2052 and a fast application start. 2054 o In the Reactive scenario: an alert notification will be sent by 2055 the server stack to the Actuator, and the Actuator will answer 2056 with an alert acknowledgement. After receiving the alert 2057 acknowledgement from the Actuator, the server stack will not 2058 send other alert notifications during the "alert-pause" period 2059 of time, in order to allow the Actuator to react and trigger 2060 actions on the application or on the policy server, but 2061 measurements will continue to be taken to achieve early 2062 detection of improved network quality conditions and a fast 2063 application start. 2065 In both scenarios stated above, if after several measurement cycles, 2066 the network constraints cannot be met the quality session is 2067 terminated. Concretely when under all possible actions taken by 2068 Actuator the quality remains below requirements, the session must be 2069 terminated. 2071 The steps to be taken in this phase depend on the measurement 2072 procedure exchanged during the handshake phase. This document only 2073 describes the "default" procedure, but others can be used, like 2074 RTP/RTCP (RFC 3550 [10]). 2076 Measurements of latency and jitter are done calculating the 2077 differences in arrival times of packets and can be achieved with 2078 little bandwidth consumption. The bandwidth measurement, on the 2079 other hand, involves higher bandwidth consumption in both directions 2080 (uplink and downlink). 2082 To avoid wasting unnecessary network resources these two types of 2083 measurements will be performed in two separate stages. If the 2084 required latencies and jitters cannot be reached, it makes no sense 2085 to waste network resources measuring bandwidth. In addition, if 2086 achieving the required latency and jitter thresholds implies 2087 upgrading the quality session level, the chance of obtaining 2088 compliant bandwidth measurements without retries is higher, saving 2089 network traffic again. Therefore, the default procedure, determines 2090 that the measurements are taken in two stages: 2092 o Stage 0: Measurement of latencies, jitters and packet loss 2094 o Stage 1: Measurement of bandwidths and packet loss 2096 Notice that packet loss can be measured in both stages, as all 2097 messages exchanged include a sequence-number header that allows for 2098 easy packet loss detection. 2100 The client starts the negotiation phase sending a READY request 2101 using the TCP Q4S ports defined in the SDP. This READY request 2102 includes a "Stage" header that indicates the measurement stage. 2104 If either jitter, latency or both are specified, the negotiation 2105 phase begins with the measurement of latencies and jitters (stage 2106 0). If none of those attributes are specified, stage 0 is skipped. 2108 7.5.1 Stage 0: Measurement of latencies and jitters 2110 The Stage 0 MUST start with a synchronization message exchange 2111 initiated with the client's READY message. 2113 Client request, READY message: 2114 ========================= 2115 READY q4s://www.example.com Q4S/1.0 2116 Stage: 0 2117 Session-Id: 53655765 2118 User-Agent: q4s-ua-experimental-1.0 2119 Content-Length: 0 2120 ========================= 2122 Server Response: 2123 ========================= 2124 Q4S/1.0 200 OK 2125 Session-Id: 53655765 2126 Stage:0 2127 Content-Length: 0 2128 ========================= 2129 This triggers the exchange of a sequence of PING requests and 2130 responses that will lead to the calculation of RTT (latency), jitter 2131 and packet loss. 2133 After receiving 200 OK, the client must send the first PING message 2134 and the server will wait to send PINGs until the reception of this 2135 first client PING. 2137 Client and server MUST send PING requests to each other. The 2138 Sequence-Number header of the first PING MUST be set to 0. Client 2139 and server will manage their own sequence numbers. 2141 +------------------------------------------------+ 2142 | | 2143 | Client Server | 2144 | | 2145 | --------- Q4S READY 0 ---------> | 2146 | <-------- Q4S 200 OK ----------- | 2147 | | 2148 | --------- Q4S PING ------------> | 2149 | <-------- Q4S 200 OK ----------- | 2150 | <-------- Q4S PING ------------- | 2151 | -------- Q4S 200 OK ----------> | 2152 | --------- Q4S PING ------------> | 2153 | <-------- Q4S PING ------------- | 2154 | --------- Q4S 200 OK ----------> | 2155 | <-------- Q4S 200 OK ----------- | 2156 | ... | 2157 | | 2158 +------------------------------------------------+ 2160 Figure 8 Simultaneous exchange of PING request and responses. 2162 This is an example of the PING request sent from the client and the 2163 server's response: 2165 Client Request: 2166 ========================= 2167 PING q4s://www.example.com Q4S/1.0 2168 Session-Id: 53655765 2169 Sequence-Number: 0 2170 User-Agent: q4s-ua-experimental-1.0 2171 Measurements: l=22, j=12, pl=0.20, bw= 2172 Content-Length: 0 2173 ========================= 2175 Server Response: 2176 ========================= 2177 Q4S/1.0 200 OK 2178 Session-Id: 53655765 2179 Sequence-Number: 0 2180 Content-Length: 0 2181 ========================= 2183 The function of the PING method is similar to the ICMP echo request 2184 message. The server MUST answer as soon as it receives the message. 2186 Both endpoints MUST send Q4S PING messages with the periodicity 2187 specified in the first parameter of SDP measurement procedure 2188 attribute, using always the same UDP ports and incrementing the 2189 Sequence-Number with each message. 2191 In the following example, the SDP measurement procedure attribute, 2192 this value is 50 milliseconds (from the client to the server) and 2193 60ms (from the server to the client). 2195 a=measurement:procedure default(50/60,50/50,5000,256/256,256/256) 2197 They MUST NOT wait for a response to send the next PING request. The 2198 "Sequence-Number" header value is incremented sequentially and MUST 2199 start at zero. If this stage is repeated, the initial Sequence- 2200 Number MUST start at zero again. 2202 All PING requests MUST contain a "Measurements" header, with the 2203 values of the latency, jitter and packet loss measured by each 2204 entity up to that moment. The client will send its measurements to 2205 the server and the server his measurements to the client. Example: 2207 Measurements: l=22, j=13, pl=0.10, bw= 2209 Where l stands for latency, j for jitter, pl for packetloss and bw 2210 for bandwidth. The bandwidth value is omitted, as it is not measured 2211 at this stage. 2213 Optionally the PING request can include a "Timestamp" header, with 2214 the time in which the message has been sent. In case the header is 2215 present, the server MUST include the header in the response without 2216 changing the value. 2218 A minimum number of PING messages MUST be exchanged in order to be 2219 able to measure latency, jitter and packet-loss with certain 2220 accuracy (at least 256 samples are recommended to get a accurate 2221 packet loss measurement). Both the client and the server calculate 2222 the respective measured parameter values. The mechanisms to 2223 calculate the different parameters are described in section 7.3. 2225 At the end of this stage 0, there are three possibilities: 2227 o The latency, jitter and packet loss constraints are reached in 2228 both directions 2230 o The latency, jitter and packet loss constraints are not reached 2231 in one or both directions 2233 In the first case, Stage 0 is finished. Client and server are ready 2234 for Stage 1: bandwidth and packet loss measurement. The client moves 2235 to stage 1 by sending a READY message including the header "Stage: 2236 1". 2238 If the bandwidth constraints are empty or with value zero, the 2239 negotiation phase MUST terminate and both client and server may 2240 initiate the Continuity Phase. In this case client moves to 2241 Continuity phase by sending a READY message including the header 2242 "Stage: 2". 2244 The second case, in which one or more quality constraints have not 2245 been met, is detailed in section 7.5.4. Quality constraints not 2246 reached. 2248 7.5.2 Stage 1: Measurement of bandwidth and packet loss 2250 This stage begins in a similar way to stage 0, sending a READY 2251 request over TCP. This READY message "Stage" header value is 1. The 2252 server answers with a Q4S 200 OK message to synchronize the 2253 initiation of the measurements. 2255 +------------------------------------------------+ 2256 | | 2257 | Client Server | 2258 | | 2259 | --------- Q4S READY 1 -----------> | 2260 | <-------- Q4S 200 OK ------------- | 2261 | | 2262 | --------- Q4S BWIDTH -----------> | 2263 | <-------- Q4S BWIDTH ------------ | 2264 | --------- Q4S BWIDTH -----------> | 2265 | <-------- Q4S BWIDTH ------------ | 2266 | ... | 2267 | | 2268 +------------------------------------------------+ 2269 Figure 9 Starting bandwidth and packet loss measurement 2271 Client Request: 2272 ========================= 2273 READY q4s://www.example.com Q4S/1.0 2274 User-Agent: q4s-ua-experimental-1.0 2275 Stage: 1 2276 Session-Id: 53655765 2277 Content-Length: 0 2279 ========================= 2281 Server Response: 2282 ========================= 2283 Q4S/1.0 200 OK 2284 Session-Id: 53655765 2285 Stage: 1 2286 Content-Length: 0 2288 ========================= 2290 Just after receiving the 200 OK, both the client and the server MUST 2291 start sending BWIDTH messages simultaneously using the UDP q4s 2292 ports. Section 7.3.3 describes the bandwidth measurement in detail. 2294 At the end of this stage 1, there are three possibilities: 2296 o The bandwidth and packet loss constraints are reached in both 2297 directions 2299 o The bandwidth and packet loss constraints are not reached in 2300 one both directions. 2302 In the first case, Stage 1 is finished. Client and server are ready 2303 for Continuity phase. The client moves to this phase by sending a 2304 READY message including the header "Stage: 2". The server answer 2305 MUST be 200 OK. 2307 +------------------------------------------------+ 2308 | | 2309 | Client Server | 2310 | | 2311 | --------- Q4S READY 2 --------------> | 2312 | <---- Q4S 200 OK with trigger URI----- | 2313 | | 2314 | --------- HTTP GET ----------------> | 2315 | | 2316 | (Application starts) | 2317 | | 2318 +------------------------------------------------+ 2320 Figure 10 Trigger the application using HTTP URI 2322 Client Request: 2323 ========================= 2324 READY q4s://www.example.com Q4S/1.0 2325 User-Agent: q4s-ua-experimental-1.0 2326 Stage: 2 2327 Session-Id: 53655765 2328 Content-Length: 0 2330 ========================= 2332 Server Answer: 2333 ========================= 2334 Q4S/1.0 200 OK 2335 Date: Mon, 10 Jun 2010 10:00:01 GMT 2336 Session-Id: 53655765 2337 Trigger-URI: http://www.example.com/app_start 2338 Expires: 3000 2339 Content-Type: application/sdp 2340 Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 2341 Content-Length: 131 2343 (SDP not shown) 2344 ========================= 2346 If the "Trigger-URI" header is present, the client SHOULD send an 2347 HTTP request to this URI. 2349 The second case, with violated network constraints is explained in 2350 7.5.4 Quality constraints not reached. 2352 7.5.3 Quality constraints not reached 2354 After finishing Stage 1 of the Negotiation phase, the client and the 2355 server have each other measured parameter values as these have been 2356 exchanged in the "Measurements" headers of the PING and BWIDTH 2357 messages. If there is one or more parameters that do not comply with 2358 the uplink or downlink application constraints required both the 2359 server and the client are aware of it. 2361 If there is any quality parameter that does not meet the uplink or 2362 downlink quality constraints specified in the SDP message, two 2363 scenarios are possible depending on the specified alerting-mode (if 2364 not present, default value is "Reactive" alerting mode): 2366 a) Q4S-aware-network alerting mode: the server MUST send a Q4S-ALERT 2367 message to the client including the digital signature header, and 2368 the client MUST answer with the same Q4S-ALERT message. The 2369 Signature header contains the signed hash value of the SDP body 2370 in order to protect all the SDP the data and therefore it MUST 2371 contain the measurement parameters in the body. 2373 Server request 2374 ========================= 2375 Q4S-ALERT q4s://www.example.com Q4S/1.0 2376 Host: www.example.com 2377 User-Agent: q4s-ua-experimental-1.0 2378 Session-Id: 53655765 2379 Content-Type: application/sdp 2380 Content-Length: 142 2382 v=0 2383 o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33 2384 s=Q4S 2385 i=Q4S parameters 2386 t=0 0 2387 a=qos-level:1/2 2388 a=alerting-mode: Q4S-aware-network 2389 a= alert-pause:5000 2390 a=public-address:client IP4 198.51.100.51 2391 a=public-address:server IP4 198.51.100.58 2392 a= latency:40 2393 a= jitter:10/10 2394 a= bandwidth:20/6000 2395 a= packetloss:0.50/0.50 2396 a=flow:app downlink TCP/10000-20000 2397 a=flow:app uplink TCP/56000 2398 a=flow:q4s downlink UDP/55000 2399 a=flow:q4s downlink TCP/55001 2400 a=flow:q4s uplink UDP/56000 2401 a=flow:q4s uplink TCP/56001 2402 a=measurement:procedure default(50/50,50/50,5000,256/256,256/256) 2403 a=measurement:latency 30 2404 a=measurement:jitter 6/4 2405 a=measurement:bandwidth 200/4000 2406 a=measurement:packetloss 0.20/0.33 2407 ========================= 2409 At this point, both client and server keep on measuring but without 2410 sending new Q4S ALERT messages during the "alert-pause" 2411 milliseconds. 2413 b) Reactive alerting mode: the server stack MUST send an alert 2414 notification to the Actuator, and the Actuator MUST answer with 2415 an acknowledgement to the received alert notification. The alert 2416 notification sent to the Actuator by the server stack doesn't 2417 follow Q4S message style but should have all the information the 2418 Actuator will need for the actions to be taken, which will be 2419 implementation dependent. 2421 At this point, during Negotiation phase, both client and server keep 2422 on measuring without sending new alert notifications to the Actuator 2423 during the "alert-pause" milliseconds specified in the SDP. This 2424 way, both client and server will detect any improvement in network 2425 conditions as soon as the network reacts. The application can start 2426 as soon as the number of measurements indicated in the measurement 2427 procedure attribute indicates that the quality parameters are met. 2429 Same applies to Continuity phase: the measurement dialog between 2430 client and server must not be interrupted by any possible ALERT 2431 message. 2433 7.5.3.1 Actuator role 2435 Actuator receives notifications of unmet requirements from Q4S 2436 server stack, and act over the application or over the network 2437 policy server, according with certain logic out of scope of this 2438 protocol. 2440 The Actuator logic activates mechanisms at application level or/and 2441 network level based on a quality level dictionary, in which each 2442 level meaning is implementation dependent and each level involve 2443 different actions based on rules to keep certain user experience 2444 quality. 2446 The type of actions that an actuator can take at application level 2447 are application dependent and MAY involve: 2449 o Reduction of application functionalities, such as limitation of 2450 application speed or application options. 2452 o Reduction of application resources usage, such as reduction of 2453 frames per second in a video app or any other parameter 2454 modification in order to adapt to network conditions. 2456 Apart from actuate at application level, the actuator MAY act at 2457 network level if a network policy server is available. 2459 7.5.3.2 Policy server role 2461 A network policy server may be part of the reactive scenario and it 2462 is in charge of managing network quality provision. Network policy 2463 server may implement all or some of these features (but not 2464 exclusive to): 2466 o Server validation in terms of quality constraints. 2468 o Authentication (Signature validation) and security (block 2469 malicious clients) 2471 o Policy rules (following rules are only examples): 2473 - Maximum quality level allowed for the ACP 2475 - Time bands allowed for providing quality sessions 2477 - Number of simultaneous quality sessions allowed 2479 - Maximum time used by allowed quality sessions 2481 - Etc. 2483 If any of the policy rules fail, a Q4S-ALERT message MUST be 2484 answered by a 6XX error, indicating the cause. 2486 7.5.4 QoS Level changes 2488 If any constraint was violated, client or server (depending on 2489 alerting mode) MAY trigger a Q4S-ALERT asking for higher qos-level 2490 attribute. The maximum qos-level allowed is 9, both uplink and 2491 downlink. 2493 If the qos-level has reached the maximum value for downlink or 2494 uplink without matching the constraints, then a CANCEL request MUST 2495 be sent by the client using the TCP port determined in the handshake 2496 phase in order to release the session. In reaction to the reception 2497 of the CANCEL request, the server MUST send a CANCEL request too. If 2498 no CANCEL request is received, the expiration time cancels the 2499 session at server side. 2501 Client Request: 2502 ========================= 2503 CANCEL q4s://www.example.com Q4S/1.0 2504 User-Agent: q4s-ua-experimental-1.0 2505 Session-Id: 53655765 2506 Content-Type: application/sdp 2507 Content-Length: 142 2509 (SDP not shown) 2510 ========================= 2512 Server Request in reaction to Client Request: 2513 ========================= 2514 CANCEL q4s://www.example.com Q4S/1.0 2515 Session-Id: 53655765 2516 Expires: 0 2517 Content-Type: application/sdp 2518 Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 2519 Content-Length: 131 2521 (SDP not shown) 2522 ========================= 2524 7.6 Continuity phase 2526 During the negotiation phase, latency, jitter, bandwidth and packet 2527 loss have been measured. During the continuity phase bandwidth will 2528 not be measured again because bandwidth measurements may disturb 2529 application performance. 2531 This phase is supposed to be executed at the same time as the real- 2532 time application is being used. 2534 This draft only covers the default procedure. The continuity 2535 operation with default procedure is based on a sliding window of 2536 samples. The number of samples involved in the sliding window may be 2537 different for jitter and latency than for packet-loss calculations 2538 according to the fifth and sixth parameters of the measurement 2539 procedure attribute. In this example, the jitter and latency sliding 2540 window comprises 40 samples whereas the size of the packet-loss 2541 sliding window is 100 samples: 2543 a=measurement:procedure default(50/50,75/75,5000,40/40,100/100) 2544 In addition, the sizes of these windows are configurable per 2545 direction: uplink and downlink values may differ. 2547 PING requests are sent continuously (in both directions) and when 2548 the Sequence-Number header reaches the maximum value, the client 2549 continues sending PING messages with the Sequence-Number header 2550 starting again at zero. When the server PING Sequence-Number header 2551 reaches the maximum value, it does the same, starting again from 2552 zero. 2554 On the client side, the measured values of downlink jitter, downlink 2555 packet loss and latency are calculated using the last samples, 2556 discarding older ones, in a sliding window schema. 2558 +--------------------------------------------------+ 2559 | | 2560 | 55 56 57 . . . 253 254 255 0 1 2 . . . 55 56 | 2561 | A A | 2562 | | | | 2563 | +-----------------------------------+ | 2564 | | 2565 +--------------------------------------------------+ 2567 Figure 11 Sliding samples window 2569 Only if the server detects that the measured values (downlink or 2570 uplink jitter, packet loss or latency) are not reaching the quality 2571 constraints, a Q4S ALERT is triggered and sent either to the client 2572 or to the Actuator, depending on the alerting mode, and the alert- 2573 pause timer is started. 2575 In Q4S-aware-network alerting mode, if the client receives a Q4S 2576 ALERT message, it MUST answer sending the Q4S ALERT request message 2577 back to the server including the SDP (with its corresponding digital 2578 signature). 2580 Both client and server will keep performing measurements but no 2581 other Q4S ALERT message MUST be sent during "alert-pause" 2582 milliseconds. The operations needed to act on the network and the 2583 agents in charge of them are out of scope of this draft. 2585 +------------------------------------------------+ 2586 | | 2587 | Client Server | 2588 | | 2589 | ... | 2590 | ----------- PING ----------> | 2591 | <--------- 200 OK ---------- | 2592 | <------- Q4S-ALERT --------- | 2593 | -------- Q4S-ALERT --------> | 2594 | <---------- PING ----------- | 2595 | ---------- 200 OK ---------> | 2596 | ----------- PING ----------> | 2597 | <--------- 200 OK ---------- | 2598 | <---------- PING ----------- | 2599 | ---------- 200 OK ---------> | 2600 | ... | 2601 | | 2602 +------------------------------------------------+ 2604 Figure 12 Continuity in Q4S-aware-network alerting mode 2606 In the Reactive scenario, if the server detects that the measured 2607 values (downlink or uplink jitter, packet loss or latency) are not 2608 reaching the quality constraints, an alert notification is triggered 2609 and sent to the Actuator. The Actuator MUST then answer to the 2610 server stack with an alert acknowledgement 2612 The measurement dialog between the client and the server MUST NOT be 2613 interrupted by any possible ALERT message. 2615 +------------------------------------------------+ 2616 | | 2617 | Client Server Actuator | 2618 | ... | 2619 | --- PING ----------> | 2620 | <-- 200 OK---------- | 2621 | <----- PING -------- | 2622 | <--- 200 OK -------- ---- alert | 2623 | notification --> | 2624 | | 2625 | --- PING ----------> <--- alert | 2626 | acknowledge --- | 2627 | <-- 200 OK---------- | 2628 | <----- PING -------- | 2629 | --- 200 OK --------> | 2630 | ... | 2631 | | 2632 +------------------------------------------------+ 2634 Figure 13 Continuity in Reactive alerting mode 2636 7.7 Termination Phase 2638 The Termination phase is end point for the established Q4S session 2639 that is reached in the following cases: 2641 . A CANCEL message has been received. The client sends a CANCEL 2642 message due to the impossibility of the network to meet the 2643 required quality constraints. The client and server application 2644 will be notified by the respective Q4S stack. 2646 . Session expires: if after the Expires time no client or server 2647 activity is detected, that end cancels the session. 2649 . A BEGIN message has been received by the server. The pre- 2650 existing Q4S quality session is cancelled and a new session 2651 will be initiated. 2653 The meaning of Termination phase in terms of release of resources or 2654 accounting is application dependent and out of scope of the Q4S 2655 protocol. 2657 In Reactive alerting mode, Q4S CANCEL messages received by the Q4S 2658 server must cause the sending of cancel notifications sent from the 2659 server stack to the Actuator in order to release possible assigned 2660 resources for the session. 2662 7.7.1. Sanity check of Quality sessions 2664 A session may finish due to several reasons (client shutdown, client 2665 CANCEL request, constraints not reached, etc), and any session 2666 finished MUST release the assigned resources. 2668 In order to release the assigned server resources for the session, 2669 the "Expires" header indicates the maximum interval of time without 2670 exchanging any Q4S message. 2672 7.8 Dynamic constraints and flows 2674 Depending on the nature of the application, the quality constraints 2675 to be reached may evolve, changing some or all quality constraint 2676 values in any direction. 2678 The client MUST be able to deal with this possibility. When the 2679 server sends an SDP document attached to a response (200 OK, or Q4S- 2680 ALERT, etc), the client MUST take all the new received values, 2681 overriding any previous value in use. 2683 The dynamic changes on the quality constraints can be as a result of 2684 two possibilities: 2686 o The application communicates to the Q4S server a change in the 2687 constraints. In this case the application requirements can 2688 evolve and the Q4S server will be aware of them. 2690 o The application uses TCP flows. In that case, in order to 2691 guarantee a constant throughput, the nature of TCP behavior 2692 forces the use of a composite constraint function, which 2693 depends on RTT, packet loss and window control mechanism 2694 implemented in each TCP stack. 2696 TCP throughput can be less than actual bandwidth if the 2697 Bandwidth-Delay Product (BDP) is large or if the network suffers 2698 from a high packet loss rate. In both cases, TCP congestion control 2699 algorithms may result in a suboptimal performance. 2701 Different TCP congestion control implementations like Reno [15], 2702 High Speed TCP (RFC 3649 [16]), CUBIC [17], Compound TCP (CTCP 2703 [18]), etc. reach different throughputs under the same network 2704 conditions of RTT and packet loss. In all cases, depending on the 2705 RTT measured value, the Q4S server could change dynamically the 2706 packetloss constraints (defined in SDP) in order to make possible to 2707 reach a required throughput or vice versa (use packetloss 2708 measurement to change dynamically latency constraints). 2710 A general guideline to calculate the packetloss constraint and RTT 2711 constraint consists in approximating the throughput using a 2712 simplified formula, which should take into account the TCP stack 2713 implementation of the receiver, in addition to RTT and packet loss: 2715 Th= Function( RTT, packet loss, ...) 2717 Then, depending on RTT measured values, set dynamically the 2718 packetloss constraint. 2720 It is possible to easily calculate a worst-case boundary for the 2721 Reno algorithm, which should ensure for all algorithms that the 2722 target throughput is actually achieved. Except that, high-speed 2723 algorithms will then have even a larger throughput, if more 2724 bandwidth is available. 2726 For the Reno algorithm, the Mathis' formula may be used [16] for the 2727 upper bound on the throughput: 2729 Th <= (MSS/RTT)*(1 / sqrt{p}) 2731 In absence of packet loss, a practical limit for the TCP throughput 2732 is the receiver_window_size divided by the round-trip time. However, 2733 if the TCP implementation uses a window scale option, this limit can 2734 reach the available bandwidth value. 2736 7.9 Qos-level upgrade and downgrade operation 2738 Each time the server detects violation of constraints, the alert 2739 mechanism is triggered, the alert-pause timer is started, and the 2740 qos-level is increased. When this happens repeatedly, and the qos- 2741 level reaches its maximum value (value 9), the session is cancelled. 2742 But when the violation of constraints stops before reaching qos- 2743 level maximum value, the recovery mechanism allows for the qos-level 2744 upgrade gradually. 2746 Following, this downgrade and upgrade of qos-level is explained with 2747 an example: 2749 1. A Q4S session is initiated successfully with qos-level=0. 2751 2. During the continuity phase, violation of constraints is 2752 detected; qos-level is increased to 1, a Q4S-ALERT is sent by 2753 the server to the client and alert-pause timer is started. 2755 3. Alert-pause timer expires and still violation of constraints 2756 is detected; qos-level is increased to 2, a Q4S-ALERT is sent 2757 by the server to the client and alert-pause timer is started. 2759 4. Alert-pause timer expires but violation of constraints has 2760 stopped; recovery-pause is started. 2762 5. Recovery-pause timer expires, and no violation of constraints 2763 has been detected meanwhile; qos-level is decreased to 1, a 2764 Q4S-RECOVERY is sent by the server to the client and recovery- 2765 pause timer is started again. 2767 6. Recovery-pause timer expires again and no violation of 2768 constraints has been detected meanwhile; qos-level is decreased 2769 to 0 and a Q4S-RECOVERY is sent by the server to the client; 2770 recovery-pause timer is not started this time as qos-level has 2771 reached its initial value. 2773 When the network configuration allows for the possibility of 2774 managing Q4S flows and application flows independently (either is a 2775 network-based QoS or a Q4S aware network), the qos-level downgrade 2776 process could be managed more efficiently using a strategy that 2777 allows for carrying out qos-level downgrades excluding app flows 2778 from SDP dynamically. The Q4S flows would be downgraded to allow for 2779 measurements on a lower quality level without interference of the 2780 application flows. A Q4S client MUST allow this kind of SDP 2781 modifications by the server. 2783 Periodically (every several minutes, depending on the 2784 implementation) a Q4S-ALERT could be triggered, in which the level 2785 is downgraded for Q4S flows, excluding application flows from the 2786 embedded SDP of that request. 2788 This mechanism allows to measure at lower levels of quality while 2789 application flows continue using a higher qos level value. 2791 o If the measurements in the lower level meet the quality 2792 constraints, then a Q4S-RECOVERY message to this lower qos- 2793 level may be triggered, in which the SDP includes the 2794 application flows in addition to Q4S flows. 2796 o If the measurements in the lower level do not meet the 2797 constraints, then a new Q4S-ALERT to the previous qos-level 2798 MUST be triggered, in which the SDP includes only the Q4S 2799 flows. 2801 +------------------------------------------------+ 2802 | | 2803 | qos-level | 2804 | A | 2805 | | | 2806 | 4| | 2807 | | | 2808 | 3| +------+ | 2809 | | | | | 2810 | 2| +----+ +----+ +--- | 2811 | | | | | | 2812 | 1| +----+ +-----+ | 2813 | | | | 2814 | 0+---+---------------------------------> time | 2815 | | 2816 +------------------------------------------------+ 2818 Figure 14 Possible evolution of qos-level 2820 This mechanism avoids the risk of disturbing the application, while 2821 the measurements are being run in lower levels. However, this 2822 optional optimization of resources MUST be used carefully. 2824 The chosen period to measure a lower qos level is implementation 2825 dependent. Therefore, it is not included as a measurement procedure 2826 parameter. It is RECOMMENDED to use a large value, such as 20 2827 minutes. 2829 8 General User Agent behavior 2831 8.1 Roles in peer to peer scenarios 2833 In order to allow peer to peer applications, a Q4S User Agent (UA) 2834 MUST be able to assume both client and server role. The role assumed 2835 depends on who sends the first message. 2837 In a communication between two UAs, the UA that sends the Q4S BEGIN 2838 request in the first place, for starting the handshake phase, shall 2839 assume the client role. 2841 If both UASs send the BEGIN request at the same time, they will wait 2842 for a random time to restart again. 2844 Otherwise, an UA may be configured to act only as server (e.g., 2845 content provider's side). 2847 +-----------------------------------------------+ 2848 | | 2849 | UA(Client) UA(Server) | 2850 | | 2851 | -------- Q4S BEGIN -------------> | 2852 | <------- Q4S BEGIN -------------- | 2853 | | 2854 | ------- Q4S BEGIN --------------> | 2855 | <------ Q4S 200 OK -------------- | 2856 | | 2857 | | 2858 +-----------------------------------------------+ 2860 Figure 15 P2P roles. 2862 8.2 Multiple Quality sessions in parallel 2864 A Q4S session is intended to be used for an application. It means 2865 that for using the application, the client MUST establish only one 2866 Q4S session against the server. Indeed, the relation between 2867 session-id and application is 1 to 1. 2869 If a user wants to participate in several independent Q4S sessions 2870 simultaneously against different servers (or against the same 2871 server) can execute different Q4S clients to establish separately 2872 different Q4S sessions but it is not recommended, because: 2874 o The establishment of a new Q4S session may affect other 2875 running applications over other Q4S sessions during bandwidth 2876 measurement. 2878 o If the negotiation phase is executed separately before running 2879 any application, the summation of bandwidth requirements could 2880 not be met when the applications are running in parallel. 2882 8.3 General client behavior 2884 A Q4S Client has different behaviors. We will use letters X,Y,Z to 2885 designate each different behavior (follow the letter bullets in the 2886 figure below). 2888 X) When it sends messages over TCP (methods BEGIN, READY, Q4S- 2889 ALERT, Q4S-RECOVERY and CANCEL) it behaves strictly like a state 2890 machine that sends requests and waits for responses. Depending on 2891 the response type it enters in a new state. 2893 When it sends UDP messages (methods PING and BWIDTH), a Q4S client 2894 is not strictly a state machine that sends messages and waits for 2895 responses because: 2897 Y) At latency, jitter and packet loss measurement, the PING 2898 requests are sent periodically, not after receiving the response 2899 to the previous request. In addition, the client MUST answer the 2900 PING requests coming from the server, therefore the client assumes 2901 temporarily the role of a server. 2903 Z) At bandwidth and packet loss measurement stage, the client does 2904 not expect to receive responses when sending BWIDTH requests to 2905 the server. In addition, it MUST receive and process all server 2906 messages in order to achieve the downlink measurement. 2908 The Q4S-ALERT and CANCEL may have a conventional answer if an error 2909 is produced, otherwise the corresponding answer is formatted as a 2910 request message. 2912 +-----------+------------------------+-----------+-----------+ 2913 | Handshake | Negotiation |Continuity |Termination| 2914 | Phase | Phase | Phase | Phase | 2915 | | | | | 2916 | X ---------> Y --> X --> Z --> X ---> Y --> X ---> X | 2917 | | A | A | | A | | | 2918 | | | | | | | | | | | 2919 | | +-----+ +-----+ | +-----+ | | 2920 | | | | | 2921 +------------------------------------------------+-----------+ 2923 Figure 16 Phases & client behaviors. 2925 8.3.1 Generating requests 2927 A valid Q4S request formulated by a Client MUST, at a minimum, 2928 contains the following header fields: 2930 o If no SDP is included: the header Session-Id and Sequence- 2931 Number are mandatory. 2933 o If SDP is included: Session-Id is embedded into SDP, therefore 2934 the inclusion of Session-Id header is optional but if present 2935 must have the same value. Measurements are embedded into the 2936 SDP only for Q4S-ALERT messages in order to be signed. 2938 At any time, if the server sends a new SDP with updated values, 2939 client MUST take it into account. 2941 8.4 General server behavior 2943 If a server does not understand a header field in a request (that 2944 is, the header field is not defined in this specification or in any 2945 supported extension), the server MUST ignore that header field and 2946 continue processing the message. 2948 The role of the server is changed at negotiation and continuity 2949 phases, in which server MUST send packets to measure jitter, latency 2950 and bandwidth. Therefore, the different behaviors of server are 2951 (follow the letter bullets in the figure below): 2953 R) When the client sends messages over TCP (methods BEGIN, READY 2954 Q4S-ALERT, Q4S-RECOVERY and CANCEL) it behaves strictly like a 2955 state machine that receives messages and sends responses. 2957 When the client begins to send UDP messages (methods PING and 2958 BWIDTH), a Q4S server is not strictly a state machine that receives 2959 messages and sends responses because: 2961 S) At latency, jitter and packet loss measurement, the PING 2962 requests are sent periodically by the client but also by the 2963 server. In this case the server behaves as a server answering 2964 client requests but also behaves temporarily as a client, sending 2965 PING requests toward the client and receiving responses. 2967 T) At bandwidth and packet loss measurement, the server sends 2968 BWIDTH requests to the client. In addition, it MUST receive and 2969 process client messages in order to achieve the uplink 2970 measurement. 2972 The Q4S-ALERT and CANCEL may have a conventional answer if an error 2973 is produced, otherwise the corresponding answer is formatted as a 2974 request message. 2976 +-----------+------------------------+-----------+-----------+ 2977 | Handshake | Negotiation |Continuity |Termination| 2978 | Phase | Phase | Phase | Phase | 2979 | | | | | 2980 | R ---------> S --> R --> T --> R ---> S --> R ---> R | 2981 | | A | A | | A | | | 2982 | | | | | | | | | | | 2983 | | +-----+ +-----+ | +-----+ | | 2984 | | | | | 2985 +------------------------------------------------+-----------+ 2987 Figure 17 Phases & server behaviours. 2989 9 Implementation Recommendations 2991 9.1 Default client constraints 2993 To provide a default configuration, it would be good that the client 2994 had a configurable set of Quality headers in the implementation 2995 settings menu. Otherwise these quality headers will not be present 2996 in the first message. 2998 Different business models (out of scope of this proposal) may be 2999 achieved: depending on who pays for the quality session, the server 3000 can accept certain Client parameters sent in the first message, or 3001 force billing parameters on the server side. 3003 9.2 Latency and Jitter measurements 3005 Different client and server implementations may send a different 3006 number of PING messages for measuring, although at least 255 3007 messages should be considered to perform the latency measurement. 3008 The Stage 0 measurements only may be considered ended when neither 3009 client nor server receive new PING messages after an implementation- 3010 dependent guard time. Only after, client can send a "READY 1" 3011 message. 3013 In execution systems, where the timers are not accurate, a 3014 recommended approach consists of including the optional header 3015 "Timestamp" in the PING request with the time in which the message 3016 has been sent. This allows an accurate measurement of the jitter 3017 even with no identical intervals of time between PINGs. 3019 9.3 Bandwidth measurements 3021 In programming languages or Operating Systems with limited timers or 3022 clock resolution, it is recommended to use an approach based on 3023 several intervals to send messages of 1KB (= 8000 bits), in order to 3024 reach the required bandwidth consumption using a rate as close as 3025 possible to a constant rate. 3027 For example, if the resolution is 1 millisecond, and the bandwidth 3028 to reach is 11Mbps, a good approach consists of sending: 3030 1 message of 1KB every 1 millisecond + 3032 1 message of 1KB every 3 milliseconds + 3034 1 message of 1KB every 23 milliseconds 3036 The number of intervals depends on required bandwidth and accuracy 3037 that the programmer wants to achieve. 3039 Considering messages of 1KB (= 8000 bits), a general approach to 3040 determine these intervals is 3042 1) Compute Target bandwidth / 8000 bits. In the example above is 3043 11Mbps/8000 = 1375 messages per second 3045 2) Divide the number of messages per second by 1000 to determine the 3046 number of messages per millisecond. 1375/1000 = 1'375 The integer 3047 value is the number of messages per millisecond (in this case, 3048 one). The pending bandwidth is now 375 messages per second 3050 3) To achieve the 375 messages per second, use a sub-multiple of 3051 1000 which must be less than 375 3053 1000/2 = 500 > 375 3055 1000/3 = 333 < 375 3057 In this case a message every 3 ms is suitable. The new pending 3058 target bandwidth is 375 -333 = 42 messages per second 3060 4) Repeat the same strategy as point 3, to reach the pending 3061 bandwidth. In this case, 23 ms is suitable because: 3063 1000/22 = 45 >42 3065 1000/23 = 43 >42 3067 1000 / 24 = 41.6 < 42 3069 We can choose 24 ms but then we need to cover additional 0.4 3070 messages per second (42-41.6=0.4) and 43 is a number higher than 42 3071 but very close to it. 3073 In execution systems where the timers are not accurate, a 3074 recommended approach consists of checking at each interval the 3075 number of packets that should have been sent at this timestamp since 3076 origin and send the needed number of packets in order to reach the 3077 required bandwidth. 3079 The shorter packets are used, the more constant is the rate of 3080 bandwidth measurement. However, this may stress the execution system 3081 in charge of receiving and processing packets. As a consequence, 3082 some packets may be lost because of stack overflows. To deal with 3083 this potential issue, a larger packet is recommended (2KB or more) 3084 taking into account the overhead produced by the chunks headers. 3086 9.4 Packet loss measurement resolution 3088 Depending on application nature and network conditions, a packet 3089 loss resolution less than 1% may be needed. In such case, there is 3090 no limit to the number of samples used for this calculation. A 3091 tradeoff between time and resolution should be reached in each case. 3092 For example, in order to have a resolution of 1/10000, the last 3093 10000 samples should be considered in the packetloss measured value. 3095 The problem of this approach is the reliability of old samples. If 3096 the interval used between PING messages is 50ms, then to have a 3097 resolution of 1/1000 it takes 50 seconds and a resolution of 1/10000 3098 takes 500 seconds (more than 8 minutes). The reliability of a packet 3099 loss calculation based on a sliding window of 8 minutes depends on 3100 how fast network conditions evolve. 3102 9.5 Measurements and reactions 3104 Q4S can be used as a mechanism for measure and trigger network 3105 tuning and application level actions (i.e. lowering video bit-rate, 3106 reduce multiplayer interaction speed, etc) in real-time in order to 3107 reach the application constraints, addressing measured possible 3108 network degradation. 3110 9.6 Instability treatments 3112 There are two scenarios in which Q4S can be affected by network 3113 problems: loss of Q4S packets and outlier samples 3115 9.6.1 Loss of control packets 3117 Lost UDP packets (PING or BWIDTH messages) don't cause any problems 3118 for the Q4S state machine, but if TCP packets are lost, some 3119 undesirable consequences could arise. 3121 Q4S does have protection mechanisms to overcome these situations. 3122 Examples: 3124 o If a BEGIN packet is lost or its corresponding answer, after a 3125 certain timeout, the client SHOULD resend another BEGIN packet, 3126 resetting the session 3128 o If a READY packet is lost, after a certain timeout, the client 3129 SHOULD resend another READY packet. 3131 o If a QOS ALERT request is lost or its corresponding answer, 3132 after a certain timeout, the originator SHOULD resend another 3133 Q4S-ALERT packet. 3135 o If CANCEL request is lost or its corresponding answer, after a 3136 certain timeout, the originator SHOULD resend another CANCEL 3137 packet. 3139 9.6.2 Outlier samples 3140 Outlier samples are those jitter or latency values far from the 3141 general/average values of most samples. 3143 Hence Q4S default measurement method uses the statistical median 3144 formula for latency calculation, the outlier samples are 3145 neutralized. This is a very common filtering for noise or errors on 3146 signal and image processing. 3148 9.7 Scenarios 3150 Q4S could be used in two scenarios: 3152 o client to ACP (Application content provider) 3154 o client to client (peer to peer scenario) 3156 9.7.1 Client to ACP 3158 One server: 3160 It is the common scenario in which client contact server to 3161 establish a Q4S session. 3163 N servers: 3165 In Content Delivery Networks and in general applications where 3166 delivery of contents can be achieved by different delivery nodes, 3167 two working mechanisms can be defined 3169 o Starting mode: End-user may run Q4S against several delivery 3170 nodes and after some seconds choose the best one to start the 3171 multimedia session 3173 o Prevention mode: During streaming session, user keeps several 3174 Q4S dialogs against different alternative delivery nodes. In 3175 case of congestion, end-user MAY change to the best alternative 3176 delivery node 3178 9.7.2 Client to client 3180 In order to solve the client to client scenario, a Q4S register 3181 function MUST be implemented. This allows clients contact each other 3182 for sending the BEGIN message. In this scenario, the Register server 3183 would be used by peers to publish their Q4S-Resource-Server header 3184 and their public IP address to make possible the assumption of 3185 server role. 3187 The register function is out of scope of this protocol version, 3188 because different HTTP mechanisms can be used and Q4S MUST NOT force 3189 any. 3191 10 Security Considerations 3193 10.1 Confidentiality Issues 3195 Hence Q4S does not transport any application data, Q4S does not 3196 jeopardize the security of application data. However, other certain 3197 considerations may take place, like identity impersonation and 3198 measurements privacy and integrity. 3200 10.2 Integrity of measurements and authentication 3202 Identity impersonation could potentially produce anomalous Q4S 3203 measurements. If this attack is based on spoofing of server IP 3204 address, it can be avoided using the digital signature mechanism, 3205 included in the SDP. The network can easily validate this digital 3206 signature using the public key of the server certificate. 3208 Integrity of Q4S measurements under any malicious manipulation (such 3209 as MITM attack) relay on the same mechanism, the SDP signature. 3211 The Signature header contains the signed hash value of the SDP body 3212 in order to protect all the SDP data, including the measurements. 3213 This signature not only protects the integrity of data but also 3214 authenticates the server. 3216 10.3 Privacy of measurements 3218 this protocol could be supported over IPSec. Q4S relays on UDP and 3219 TCP, and IPSec supports both. If Q4S is used for application-based 3220 QoS, then IPsec is operationally valid but if Q4S is used to trigger 3221 network-based actions, then measurements could be wrong, unless 3222 IPSec ports be considered at any potential action over the network 3223 (such as prioritization of certain application flows). 3225 10.4 Availability issues 3227 Any loss of connectivity may interrupt the availability of Q4S 3228 service, and results into higher packet-loss measurements, which is 3229 just the desired behavior in these situations. 3231 In order to mitigate availability issues caused by malicious attacks 3232 (such as DoS and DDoS), a good practice is to enable Q4S service 3233 only for authenticated users. Q4S can be launched after user is 3234 authenticated by the application. At this moment, his IP address is 3235 known and the Q4S service may be enabled for this IP address. 3236 Otherwise Q4S service should appear unreachable. 3238 10.5 Bandwidth occupancy issues 3240 Q4S bandwidth measurement is limited to the application needs. It 3241 means that all available bandwidth is not measured, but only the 3242 fraction required by the application. This allows other applications 3243 to use normally the rest of available bandwidth. 3245 However, a malicious Q4S client could re-starts Q4S sessions just 3246 after finishing the negotiation phase. The consequence would be to 3247 waste bandwidth for nothing. 3249 In order to mitigate this possible anomalous behavior, it is 3250 recommended to configure the server to reject sessions from the same 3251 end-point when this situation is detected. 3253 11 IANA Considerations 3255 11.1 Service Port 3257 IANA is requested to assign a specific port for Q4S TCP control flow 3258 mechanism: 3260 Service Name: Q4S 3262 Transport Protocol(s): TCP 3264 Assignee : 3266 Name : Jose Javier Garcia Aranda 3268 Email: jose_javier.garcia_aranda@nokia.com 3270 Contact : 3272 Name : Jose Javier Garcia Aranda 3274 Email: jose_javier.garcia_aranda@nokia.com 3276 Description : The service associated with this request is in charge 3277 of the establishment of new Q4S sessions, and during the session 3278 manages the pass to a new protocol stage (handshake, negotiation and 3279 continuity) as well as inform of alerts when measurements do not 3280 meet the requirements. 3282 Reference : this document. This service does not use IP-layer 3283 broadcast, multicast, or anycast communication. 3285 11.2 Protocol parameters 3287 IANA is requested to allocate the SDP parameters at "Foo-bar TLV 3288 Types" belonging to "The Foo Protocol Parameters" registry, from the 3289 range 0x42 to 0xfe. 3291 This is the list of attribute field names to register: 3293 Attribute name: qos-level 3294 Type of attribute: session level 3295 Subject to the charset attribute: NO 3296 Explanation of purpose: defines the current QoS profile in uplink 3297 and downlink for the communication between client and server. The 3298 exact meaning of each level is implementation dependent but in 3299 general, a higher qos-level value corresponds to a better quality 3300 network profile. 3301 Appropriate attribute values: [0..9] "/" [0..9] 3303 Attribute name: alerting-mode 3304 Type of attribute: session level 3305 Subject to the charset attribute: NO 3306 Explanation of purpose: defines the receiver of the Q4S alerts sent 3307 by the server. In Q4S-aware-network alerting mode, Q4S alerts are 3308 sent to the client. In this case the network is supposed to be Q4S 3309 aware, and reacts by itself to these alerts. In Reactive alerting 3310 mode, Q4S alerts sent to the network policy server. In this case the 3311 network is not Q4S aware and a specific node (policy server) is 3312 supposed to be in charge of achieving network tuning mechanisms. The 3313 "alerting-mode" attribute is optional, and its default value, when 3314 it is not present, is "Reactive". 3315 Appropriate attribute values: <"Q4S-aware-network"|"Reactive"> 3317 Attribute name: alert-pause 3318 Type of attribute: session level 3319 Subject to the charset attribute: NO 3320 Explanation of purpose: interval of time in milliseconds that the 3321 server must wait between Q4S-ALERT messages in order to allow 3322 network tuning operations. Measurements are not affected by this 3323 pause. 3324 Appropriate attribute values: [0..60000] 3326 Attribute name: public-address 3327 Type of attribute: session level 3328 Subject to the charset attribute: NO 3329 Explanation of purpose: contains the public IP address of the client 3330 or the server. 3331 Appropriate attribute values:<"client"|"server"><"IP4"|"IP6"> 3334 Attribute name: latency 3335 Type of attribute: session level 3336 Subject to the charset attribute: NO 3337 Explanation of purpose: defines the latency constraints in 3338 milliseconds for the communication between client and server. 3339 Appropriate attribute values: [0..9999] 3341 Attribute name: jitter 3342 Type of attribute: session level 3343 Subject to the charset attribute: NO 3344 Explanation of purpose: defines the jitter constraints in 3345 milliseconds in uplink and downlink for the communication between 3346 client and server. 3347 Appropriate attribute values: [0..9999] "/" [0..9999] 3349 Attribute name: bandwidth 3350 Type of attribute: session level 3351 Subject to the charset attribute: NO 3352 Explanation of purpose: define the bandwidth constraints in kbps in 3353 uplink and downlink for the communication between client and server. 3354 Appropriate attribute values: [0..99999] "/" [0..99999] 3356 Attribute name: packetloss 3357 Type of attribute: session level 3358 Subject to the charset attribute: NO 3359 Explanation of purpose: define the packet loss tolerance constraints 3360 in 100% in uplink and downlink for the communication between client 3361 and server. 3362 Appropriate attribute values: [0.00 ..100.00] "/"[0.00 ..100.00] 3364 Attribute name: application 3365 Type of attribute: session level 3366 Subject to the charset attribute: NO 3367 Explanation of purpose: define the quality parameter tolerance 3368 constraints with uplink and downlink values for the communication 3369 between the client and the server for four different parameters: 3370 latency, jitter, bandwidth and packetloss. 3371 Attribute values: 3372 <"latency:"> [0..9999] 3373 <"jitter:"|"bandwidth:"> [0..99999] "/" [0..99999]] 3374 <"packetloss:" [0.00 ..100.00] "/"[0.00 ..100.00]] 3376 Attribute name: flow 3377 Type of attribute: session level 3378 Subject to the charset attribute: NO 3379 Explanation of purpose: define a flow between a client and a server. 3380 The flow involves purpose (application or q4s -control-), 3381 destination port (server or client) protocol (UDP or TCP) and port 3382 or range or ports 3383 The "clientListeningPort" is a port in which the client listens for 3384 server requests and MUST be used as origin port of client responses. 3385 The "serverListeningPort" is a port in which server is listening for 3386 incoming messages from the client. The origin port of server 3387 responses may be different than "serverListeningPort" value. 3388 Attribute values: 3389 <"q4s"|"app"> <"serverListeningPort"|"clientListeningPort"> 3390 <"UDP"|"TCP"> <0..65535>[ "-" [0..65535]] 3392 Attribute name: measurement 3393 Type of attribute: session level 3394 Subject to the charset attribute: NO 3395 Explanation of purpose: define the procedure to measure the quality 3396 and the different values for each measurement 3397 Attribute values: "procedure/" | 3398 "latency "[0..9999] "/" [0..9999] | 3399 "jitter "[0..9999] "/" [0..9999] | 3400 "bandwidth "[0..99999] "/" [0..99999] | 3401 "packetloss "[0.00..100.00] "/" [0.00..100.00] 3403 If the attribute value is "procedure", the rest of the line MUST 3404 contain the name of the procedure and optional parameters, separated 3405 by ",". 3407 In the case of procedure "default", the valid values are: 3409 a=measurement:procedure default,[0..999]"/" [0..999] "," [0..999] 3410 "/" [0..999] "," [0..9999] "," [0..999]/[0..999] "," 3411 [0..999]/[0..999] 3413 where: 3415 o The first parameter is the interval of time (in milliseconds) 3416 between PING requests during the negotiation phase. Uplink and 3417 downlink values from the client's point of view are separated 3418 by "/". This allows having different responsiveness values 3419 depending on the control resources used in each direction. 3421 o The second parameter is the time interval (in milliseconds) 3422 between PING requests during the continuity phase. Uplink and 3423 downlink values are separated by "/". This allows having two 3424 different responsiveness values depending on the control 3425 resources used in each direction. 3427 o The third parameter is the time interval to be used to measure 3428 bandwidth during the negotiation phase. 3430 o The fourth parameter indicates the window size for jitter and 3431 latency calculations. Forward and reverse values are separated 3432 by "/". 3434 o The fifth parameter indicates the window size for packet loss 3435 calculations. Forward and reverse values are separated by "/". 3437 Other procedure names are allowed, but at least "default" procedure 3438 implementation is mandatory in client and servers. 3440 12 References 3442 12.1 Normative References 3444 [1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3445 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, 3446 June 2014. 3448 [2] Handley, M. and V. Jacobson, "SDP: Session Description 3449 Protocol", RFC 4566, July 2006. 3451 [3] Bradner, S., "Key words for use in RFCs to Indicate 3452 RequirementLevels", BCP 14, RFC 2119, March 1997. 3454 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 3455 Resource Identifiers (URI): Generic Syntax", RFC 3986, January 3456 2005. 3458 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 3459 with SDP", RFC 3264, June 2002. 3461 [6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3462 April 1992. 3464 [7] Moriarty, K., Johnsson, J., B. Kaliski, "Public-Key 3465 Cryptography Standards (PKCS) #1: RSA Cryptography 3466 Specifications version 2.2", RFC 8017, November 2016. 3468 [8] Defense Advanced Research Projects Agency, " Transmission 3469 Control Protocol", RFC 793, September 1981. 3471 [9] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3472 August 1980. 3474 [10] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V. 3475 "RTP: A Transport Protocol for Real-Time Applications", RFC 3476 3550, july 2003. 3478 [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 3479 RFC 3629, November 2003. 3481 [12] Resnick, P., "Internet Message Format", RFC 5322, October 2008 3483 [13] Leiba, S., "Ambiguity of Uppercase vs Lowercase in RFC 2119 3484 Key Words", RFC 8174, May 2007 3486 12.2 Informative References 3488 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A. 3489 Peterson, J., Sparks, R., Handley, M. and Schooler, E. , "SIP: 3490 Session Initiation Protocol", RFC 3261, June 2002. 3492 [15] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The 3493 Macroscopic Behavior of the TCP Congestion Avoidance 3494 Algorithm", Computer Communications Review, 27(3), July 1997. 3496 [16] Floyd, S., "HighSpeed TCP for a Large Congestion Windows", 3497 RFC 3649, December 2003. 3499 [17] Rhee, I., Xu, L., Ha, S., "CUBIC for Fast Long-Distance 3500 Networks", Internet-draft draft-rhee-tcpm-cubic-02, February 3501 2009. 3503 [18] Sridharan, M., Tan, K., Bansal, D., Thaler, D., "Compound 3504 TCP: A New TCP Congestion Control for High-Speed and Long 3505 Distance Networks", Internet-draft draft-sridharan-tcpm-ctcp- 3506 02, November, 2008. 3508 [19] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 3509 Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", 3510 RFC 4656, September 2006. 3512 [20] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 3513 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 3514 5357, October 2008. 3516 13 Acknowledgments 3518 Many people have made comments and suggestions contributing to this 3519 document. In particular, we would like to thank: 3521 Victor Villagra, Sonia Herranz, Clara Cubillo Pastor, Francisco 3522 Duran Pina, Michael Scharf, Jesus Soto Viso and Federico Guillen. 3524 Additionally, we want to thank the Spanish Centre for the 3525 Development of Industrial Technology (CDTI) as well as the Spanish 3526 Science and Tech Ministry which funds this initiative through their 3527 innovation programs. 3529 14 Contributors 3531 Jacobo Perez Lajo 3532 Nokia Spain 3533 Email: jacobo.perez@nokia.com 3535 Luis Miguel Diaz Vizcaino 3536 Nokia Spain 3537 Email: Luismi.Diaz@nokia.com 3539 Gonzalo Munoz Fernandez 3540 Nokia Spain 3541 Email: gonzalo.munoz_fernandez.ext@nokia.com 3543 Manuel Alarcon Granero 3544 Nokia Spain 3545 Email: manuel.alarcon_granero.ext@nokia.com 3547 Francisco Jose juan Quintanilla 3548 Nokia Spain 3549 Email: francisco_jose.juan_quintanilla.ext@nokia.com 3551 Carlos Barcenilla 3552 Universidad Politecnica de Madrid 3554 Juan Quemada 3555 Universidad Politecnica de Madrid 3556 Email: jquemada@dit.upm.es 3558 Ignacio Maestro 3559 Tecnalia Research & Innovation 3560 Email: ignacio.maestro@tecnalia.com 3562 Lara Fajardo Ibanez 3563 Optiva Media 3564 Email: lara.fajardo@optivamedia.com 3566 Pablo Lopez Zapico 3567 Optiva Media 3568 Email: Pablo.lopez@optivamedia.com 3570 15 Authors' Addresses 3572 Jose Javier Garcia Aranda 3573 Nokia 3574 C/Maria Tubau 9 3575 28050 Madrid 3576 Spain 3577 Phone: +34 91 330 4348 3578 Email: jose_javier.garcia_aranda@nokia.com 3580 Monica Cortes 3581 Universidad Politecnica de Madrid 3582 Avenida Complutense 30 3583 28040 Madrid 3584 Spain 3585 Email: cortesm@dit.upm.es 3587 Joaquin Salvachua 3588 Universidad Politecnica de Madrid 3589 Avenida Complutense 30 3590 28040 Madrid 3591 Spain 3592 Phone: +34 91 0672134 3593 Email: jsalvachua@dit.upm.es 3595 Maribel Narganes 3596 Tecnalia Research & Innovation 3597 Parque Cientifico y Tecnologico de Bizkaia 3598 Geldo Auzoa, Edificio 700 3599 E-48160 Derio (Bizkaia) 3600 Spain 3601 Phone: +34 946 430 850 3602 Email: maribel.narganes@tecnalia.com 3604 Inaki Martinez Sarriegui 3605 Optiva Media 3606 Edificio Europa II, 3607 Calle Musgo 2, 1G, 3608 28023 Madrid 3609 Spain 3610 Phone: +34 91 297 7271 3611 Email: inaki.martinez@optivamedia.com