diff options
Diffstat (limited to 'doc/rfc/rfc8802.txt')
| -rw-r--r-- | doc/rfc/rfc8802.txt | 3691 |
1 files changed, 3691 insertions, 0 deletions
diff --git a/doc/rfc/rfc8802.txt b/doc/rfc/rfc8802.txt new file mode 100644 index 0000000..9cb0691 --- /dev/null +++ b/doc/rfc/rfc8802.txt @@ -0,0 +1,3691 @@ + + + + +Independent Submission J.J. Aranda +Request for Comments: 8802 M. Cortés +Category: Informational Nokia +ISSN: 2070-1721 J. Salvachúa + Univ. Politecnica de Madrid + M. Narganes + Tecnalia + I. Martínez-Sarriegui + Optiva Media + July 2020 + + + The Quality for Service (Q4S) Protocol + +Abstract + + This memo describes an application-level protocol for the + communication of end-to-end QoS compliance information based on the + HyperText Transfer Protocol (HTTP) and the Session Description + Protocol (SDP). The Quality for Service (Q4S) protocol provides a + mechanism to negotiate and monitor latency, jitter, bandwidth, and + packet loss, and to alert whenever one of the negotiated conditions + is violated. + + Implementation details on the actions to be triggered upon reception/ + detection of QoS alerts exchanged by the protocol are out of scope of + this document; it is either application dependent (e.g., act to + increase quality or reduce bit-rate) or network dependent (e.g., + change connection's quality profile). + + This protocol specification is the product of research conducted over + a number of years; it is presented here as a permanent record and to + offer a foundation for future similar work. It does not represent a + standard protocol and does not have IETF consensus. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8802. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 1.1. Scope + 1.2. Motivation + 1.3. Summary of Features + 1.4. Differences from OWAMP/TWAMP + 2. Terminology + 3. Overview of Operation + 4. Q4S Messages + 4.1. Requests + 4.2. Responses + 4.3. Header Fields + 4.3.1. Common Q4S Header Fields + 4.3.2. Specific Q4S Request Header Fields + 4.3.3. Specific Q4S Response Header Fields + 4.4. Bodies + 4.4.1. Encoding + 5. Q4S Method Definitions + 5.1. BEGIN + 5.2. READY + 5.3. PING + 5.4. BWIDTH + 5.5. Q4S-ALERT + 5.6. Q4S-RECOVERY + 5.7. CANCEL + 6. Response Codes + 6.1. 100 Trying + 6.2. Success 2xx + 6.2.1. 200 OK + 6.3. Redirection 3xx + 6.4. Request Failure 4xx + 6.4.1. 400 Bad Request + 6.4.2. 404 Not Found + 6.4.3. 405 Method Not Allowed + 6.4.4. 406 Not Acceptable + 6.4.5. 408 Request Timeout + 6.4.6. 413 Request Entity Too Large + 6.4.7. 414 Request-URI Too Long + 6.4.8. 415 Unsupported Media Type + 6.4.9. 416 Unsupported URI Scheme + 6.5. Server Failure 5xx + 6.5.1. 500 Server Internal Error + 6.5.2. 501 Not Implemented + 6.5.3. 503 Service Unavailable + 6.5.4. 504 Server Time-Out + 6.5.5. 505 Version Not Supported + 6.5.6. 513 Message Too Large + 6.6. Global Failures 6xx + 6.6.1. 600 Session Does Not Exist + 6.6.2. 601 Quality Level Not Allowed + 6.6.3. 603 Session Not Allowed + 6.6.4. 604 Authorization Not Allowed + 7. Protocol + 7.1. Protocol Phases + 7.2. SDP Structure + 7.2.1. "qos-level" Attribute + 7.2.2. "alerting-mode" Attribute + 7.2.3. "alert-pause" Attribute + 7.2.4. "recovery-pause" Attribute + 7.2.5. "public-address" Attributes + 7.2.6. "latency" Attribute + 7.2.7. "jitter" Attribute + 7.2.8. "bandwidth" Attribute + 7.2.9. "packetloss" Attribute + 7.2.10. "flow" Attributes + 7.2.11. "measurement" Attributes + 7.2.12. "max-content-length" Attribute + 7.3. Measurements + 7.3.1. Latency + 7.3.2. Jitter + 7.3.3. Bandwidth + 7.3.4. Packet Loss + 7.4. Handshake Phase + 7.5. Negotiation Phase + 7.5.1. Stage 0: Measurement of Latencies and Jitter + 7.5.2. Stage 1: Measurement of Bandwidth and Packet Loss + 7.5.3. Quality Constraints Not Reached + 7.5.3.1. Actuator Role + 7.5.3.2. Policy Server Role + 7.5.4. "qos-level" Changes + 7.6. Continuity Phase + 7.7. Termination Phase + 7.7.1. Sanity Check of Quality Sessions + 7.8. Dynamic Constraints and Flows + 7.9. "qos-level" Upgrade and Downgrade Operation + 8. General User Agent Behavior + 8.1. Roles in Peer-to-Peer Scenarios + 8.2. Multiple Quality Sessions in Parallel + 8.3. General Client Behavior + 8.3.1. Generating Requests + 8.4. General Server Behavior + 9. Implementation Recommendations + 9.1. Default Client Constraints + 9.2. Latency and Jitter Measurements + 9.3. Bandwidth Measurements + 9.4. Packet Loss Measurement Resolution + 9.5. Measurements and Reactions + 9.6. Instability Treatments + 9.6.1. Loss of Control Packets + 9.6.2. Outlier Samples + 9.7. Scenarios + 9.7.1. Client to ACP + 9.7.2. Client to Client + 10. Security Considerations + 10.1. Confidentiality Issues + 10.2. Integrity of Measurements and Authentication + 10.3. Privacy of Measurements + 10.4. Availability Issues + 10.5. Bandwidth Occupancy Issues + 11. Future Code Point Requirements + 11.1. Service Port + 12. IANA Considerations + 13. References + 13.1. Normative References + 13.2. Informative References + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + The World Wide Web (WWW) is a distributed hypermedia system that has + gained widespread acceptance among Internet users. Although WWW + browsers support other, preexisting Internet application protocols, + the primary protocol used between WWW clients and servers became the + HyperText Transfer Protocol (HTTP) ([RFC7230], [RFC7231], [RFC7232], + [RFC7233], [RFC7234], and [RFC7235]). Since then, HTTP over TLS + (known as HTTPS and described in [RFC2818]) has become an imperative + for providing secure and authenticated WWW access. The mechanisms + described in this document are equally applicable to HTTP and HTTPS. + + The ease of use of the Web has prompted its widespread employment as + a client/server architecture for many applications. Many of such + applications require the client and the server to be able to + communicate with each other and exchange information with certain + quality constraints. + + Quality in communications at the application level consists of four + measurable parameters: + + Latency: The time a message takes to travel from source to + destination. It may be approximated as RTT/2 (round-trip + time), assuming the networks are symmetrical. In this context, + we will consider the statistical median formula. + + Jitter: Latency variation. There are some formulas to calculate + jitter, and in this context, we will consider the arithmetic + mean formula. + + Bandwidth: Bit rate of communication. To ensure quality, a protocol + must ensure the availability of the bandwidth needed by the + application. + + Packet loss: The percentage of packet loss is closely related to + bandwidth and jitter. Packet loss affects bandwidth because a + high packet loss sometimes implies retransmissions that also + consumes extra bandwidth, other times the retransmissions are + not achieved (for example, in video streaming over UDP), and + the information received is less than the required bandwidth. + In terms of jitter, a packet loss sometimes is seen by the + destination as a larger time between arrivals, causing a jitter + growth. + + Any other communication parameter, such as throughput, is not a + network parameter because it depends on protocol window size and + other implementation-dependent aspects. + + The Q4S protocol provides a mechanism for quality monitoring based on + an HTTP syntax and the Session Description Protocol (SDP) in order to + be easily integrated in the WWW, but it may be used by any type of + application, not only those based on HTTP. Quality requirements may + be needed by any type of application that communicates using any kind + of protocol, especially those with real-time constraints. Depending + on the nature of each application, the constraints may be different, + leading to different parameter thresholds that need to be met. + + Q4S is an application-level client/server protocol that continuously + measures session quality for a given flow (or set of flows), end-to- + end (e2e) and in real time; raising alerts if quality parameters are + below a given negotiated threshold and sending recoveries when + quality parameters are restored. Q4S describes when these + notifications, alerts, and recoveries need to be sent and the entity + receiving them. The actions undertaken by the receiver of the alert + are out of scope of the protocol. + + Q4S is session-independent from the application flows to minimize the + impact on them. To perform the measurements, two control flows are + created on both communication paths (forward and reverse directions). + + This protocol specification is the product of research conducted over + a number of years and is presented here as a permanent record and to + offer a foundation for future similar work. It does not represent a + standard protocol and does not have IETF consensus. + +1.1. Scope + + The purpose of Q4S is to measure end-to-end network quality in real + time. Q4S does not transport any application data. This means that + Q4S is designed to be used jointly with other transport protocols + such as Real-time Transport Protocol (RTP) [RFC3550], Transmission + Control Protocol (TCP) [RFC0793], QUIC [QUIC], HTTP [RFC7230], etc. + + Some existent transport protocols are focused on real-time media + transport and certain connection metrics are available, which is the + case of RTP and RTP Control Protocol (RTCP) [RFC3550]. Other + protocols such as QUIC provide low connection latencies as well as + advanced congestion control. These protocols transport data + efficiently and provide a lot of functionalities. However, there are + currently no other quality measurement protocols offering the same + level of function as Q4S. See Section 1.4 for a discussion of the + IETF's quality measurement protocols, One-Way Active Measurement + Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP). + + Q4S enables applications to become reactive under e2e network quality + changes. To achieve it, an independent Q4S stack application must + run in parallel with the target application. Then, Q4S metrics may + be used to trigger actions on the target application, such as speed + adaptation to latency in multiuser games, bitrate control at + streaming services, intelligent commutation of delivery node at + Content Delivery Networks, and whatever the target application + allows. + +1.2. Motivation + + Monitoring quality of service (QoS) in computer networks is useful + for several reasons: + + * It enables real-time services and applications to verify whether + network resources achieve a certain QoS level. This helps real- + time services and applications to run over the Internet, allowing + the existence of Application Content Providers (ACPs), which offer + guaranteed real-time services to the end users. + + * Real-time monitoring allows applications to adapt themselves to + network conditions (application-based QoS) and/or request more + network quality from the Internet Service Provider (ISP) (if the + ISP offers this possibility). + + * Monitoring may also be required by peer-to-peer (P2P) real-time + applications for which Q4S can be used. + + * Monitoring enables ISPs to offer QoS to any ACP or end user + application in an accountable way. + + * Monitoring enables e2e negotiation of QoS parameters, + independently of the ISPs of both endpoints. + + A protocol to monitor QoS must address the following issues: + + * Must be ready to be used in conjunction with current standard + protocols and applications, without forcing a change on them. + + * Must have a formal and compact way to specify quality constraints + desired by the application to run. + + * Must have measurement mechanisms that avoid application disruption + and minimize network resources consumption. + + * Must have specific messages to alert about the violation of + quality constraints in different directions (forward and reverse) + because network routing may not be symmetrical, and of course, + quality constraints may not be symmetrical. + + * After having alerted about the violation of quality constraints, + must have specific messages to inform about the recovery of + quality constraints in corresponding directions (forward and + reverse). + + * Must protect the data (constraints, measurements, QoS levels + demanded from the network) in order to avoid the injection of + malicious data in the measurements. + +1.3. Summary of Features + + The Quality for Service (Q4S) protocol is a message-oriented + communication protocol that can be used in conjunction with any other + application-level protocol. Q4S is a measurement protocol. Any + action taken derived from its measurements are out of scope of the + protocol. These actions depend on the application provider and may + be application-level adaptive reactions, may involve requests to the + ISP, or whatever the application provider decides. + + The benefits in quality measurements provided by Q4S can be used by + any type of application that uses any type of protocol for data + transport. It provides a quality monitoring scheme for any + communication that takes place between the client and the server, not + only for the Q4S communication itself. + + Q4S does not establish multimedia sessions, and it does not transport + application data. It monitors the fulfillment of the quality + requirements of the communication between the client and the server; + therefore, it does not impose any restrictions on the type of + application, protocol, or usage of the monitored quality connection. + + Some applications may vary their quality requirements dynamically for + any given quality parameter. Q4S is able to adapt to the changing + application needs, modifying the parameter thresholds to the new + values and monitoring the network quality according to the new + quality constraints. It will raise alerts if the new constraints are + violated. + + The Q4S session lifetime is composed of four phases with different + purposes: Handshake, Negotiation, Continuity, and Termination. + Negotiation and Continuity phases perform network parameter + measurements per a negotiated measurement procedure. Different + measurement procedures could be used inside Q4S, although one default + measurement mechanism is needed for compatibility reasons and is the + one defined in this document. Basically, Q4S defines how to + transport application quality requirements and measurement results + between a client and server and how to provide monitoring and + alerting, too. + + Q4S must be executed just before starting a client-server application + that needs a quality connection in terms of latency, jitter, + bandwidth, and/or packet loss. Once the client and server have + succeeded in establishing communication under quality constraints, + the application can start, and Q4S continues measuring and alerting + if necessary. + + The quality parameters can be suggested by the client in the first + message of the Handshake phase, but it is the server that accepts + these parameter values or forces others. The server is in charge of + deciding the final values of quality connection. + +1.4. Differences from OWAMP/TWAMP + + OWAMP [RFC4656] and TWAMP [RFC5357] are two protocols to measure + network quality in terms of RTT, but they have a different goal than + Q4S. The main difference is the scope: Q4S is designed to assist + reactive applications, whereas OWAMP/TWAMP is designed to measure + just network delay. + + The differences can be summarized in the following points: + + * OWAMP and TWAMP are not intended for measuring availability of + resources (certain bandwidth availability, for example) but only + RTT. However, Q4S is intended for measuring required bandwidth, + packet loss, jitter, and latency in both directions. Available + bandwidth is not measured by Q4S, but bandwidth required for a + specific application is. + + * OWAMP and TWAMP do not have responsivity control (which defines + the speed of protocol reactions under network quality changes) + because these protocols are designed to measure network + performance, not to assist reactive applications, and do not + detect the fluctuations of quality within certain time intervals + to take reactive actions. However, responsivity control is a key + feature of Q4S. + + * OWAMP and TWAMP are not intended to run in parallel with reactive + applications, but the Q4S protocol's goal is to run in parallel + and assist reactive applications in making decisions based on Q4S- + ALERT packets, which may trigger actions. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Overview of Operation + + This section introduces the basic operation of Q4S using simple + examples. This section is of a tutorial nature and does not contain + any normative statements. + + The first example shows the basic functions of Q4S: communication + establishment between a client and a server, quality requirement + negotiations for the requested application, application start and + continuous quality parameter measurements, and finally communication + termination. + + The client triggers the establishment of the communication by + requesting a specific service or application from the server. This + first message must have a special URI [RFC3986], which may force the + use of the Q4S protocol if it is implemented in a standard web + browser. This message consists of a Q4S BEGIN method, which can + optionally include a proposal for the communication quality + requirements in an SDP body. This option gives the client a certain + negotiation capacity about quality requirements, but it will be the + server who finally decides the stated requirements. + + This request is answered by the server with a Q4S 200 OK response + letting the client know that it accepts the request. This response + message must contain an SDP body with the following: + + * The assigned Q4S sess-id. + + * The quality constraints required by the requested application. + + * The measurement procedure to use. + + * "alerting-mode" attribute: There are two different scenarios for + sending alerts that trigger actions either on the network or in + the application when measurements identify violated quality + constraints. In both cases, alerts are triggered by the server. + + (a) Q4S-aware-network scenario: The network is Q4S aware and + reacts by itself to these alerts. In this scenario, Q4S- + ALERT messages are sent by the server to the client, and + network elements inspect and process these alert messages. + The alerting mode in this scenario is called Q4S-aware- + network alerting mode. + + (b) Reactive scenario: As shown in Figure 1, the network is not + Q4S aware. In this scenario, alert notifications are sent to + a specific node, called an Actuator, which is in charge of + making decisions regarding what actions to trigger: either to + change application behavior to adapt it to network conditions + and/or invoke a network policy server in order to reconfigure + the network and request better quality for application flows. + + +------+ +-----------+ + | App |<----- app flows---------->|Application| + |Client| +-----------+ + +------+ A + | + +------+ +------+ +--------+ + | Q4S |<----Q4S---->| Q4S |<----->|Actuator| + |Client| |Server| +--------+ + +------+ +------+ | + V + +-------------+ + |policy server| + +-------------+ + + Figure 1: Reactive Scenario + + The format of messages exchanged between the server stack and + the Actuator doesn't follow Q4S codification rules; their + format will be implementation dependent. In this way, we + will call the messages sent from the server stack to the + Actuator "notifications" (e.g., alert notifications) and the + messages sent from the Actuator to the server stack in + response to notifications "acknowledges" (e.g., alert + acknowledges). + + * "alert-pause" attribute: The amount of time between consecutive + alerts. In the Q4S-aware-network scenario, the server has to wait + this period of time between Q4S-ALERT messages sent to the client. + In the Reactive scenario, the server stack has to wait this period + of time between alert notifications sent to the Actuator. + Measurements are not stopped in Negotiation or Continuity phases + during this period of time, but no alerts are sent, even with + violated network quality constraints, in order to leave time for + network reconfiguration or for application adjustments. + + * "recovery-pause" attribute: The amount of time the Q4S server + waits before trying to recover the initial "qos-level" + (Section 7.2.1). After having detected violation of quality + constraints several times, the "qos-level" will have been + increased accordingly. If this violation detection finally stops, + the server waits for a period of time (recovery time), and if the + situation persists, it tries to recover to previous "qos-level" + values gradually by sending Q4S-RECOVERY messages to the client in + the Q4S-aware-network scenario, or recovery notifications to the + Actuator in the Reactive scenario (Section 7.9). + + It is important to highlight that any Q4S 200 OK response sent by the + server to the client at any time during the life of a quality session + may contain an SDP body with new values of quality constraints + required by the application. Depending on the phase and the state of + the measurement procedure within the specific phase, the client will + react accordingly to take into account the new quality constraints in + the measurement procedure. + + Once the communication has been established (i.e., the Handshake + phase is finished), the protocol will verify that the communication + path between the client and the server meets the quality constraints + in both directions, from and to the server (Negotiation phase). This + Negotiation phase requires taking measurements of the quality + parameters: latencies, jitter, bandwidth, and packet loss. This + phase is initiated with a client message containing a Q4S READY + method, which will be answered by the server with a Q4S 200 OK + response. + + Negotiation measurements are achieved in two sequential stages: + + Stage 0: latency and jitter measurements + + Stage 1: bandwidth and packet loss measurements + + Stage 0 measurements are taken through Q4S PING messages sent from + both the client and the server. All Q4S PING requests will be + answered by Q4S 200 OK messages to allow for bidirectional + measurements. + + Different client and server implementations may send a different + number of PING messages for measuring, although at least 255 messages + should be considered to perform the latency measurement. The Stage 0 + measurements only may be considered ended when neither client nor + server receive new PING messages after an implementation-dependent + guard time. Only after Stage 0 has ended, can the client send a + "READY 1" message. + + After a pre-agreed number of measurements have been performed, + determined by the measurement procedure sent by the server, three + scenarios may be possible: + + (a) Measurements do not meet the requirements: in this case, the + stage 0 is repeated after sending an alert from the server to + the client or from the server stack to the Actuator, depending + on the alerting mode defined in the Handshake phase. Notice + that measurements continue to be taken but no alerts are sent + during the "alert-pause" time. In the Reactive scenario, the + Actuator will decide either to forward the alert notification to + the network policy server or to the application, depending on + where reconfiguration actions have to be taken. + + (b) Measurements do meet the requirements: in this case, client + moves to stage 1 by sending a new READY message. + + (c) At any time during the measurement procedure, the Q4S 200 OK + message sent by the server to the client, in response to a Q4S + PING message, contains an SDP body with new values of quality + constraints required by the application. This means the + application has varied their quality requirements dynamically; + therefore, quality thresholds used while monitoring quality + parameters have to be changed to the new constraints. In this + case, the client moves to the beginning of Stage 0 for + initiating the negotiation measurements again. + + Stage 1 is optional. Its purpose is to measure the availability of + application-needed bandwidth. If the "bandwidth" attribute is set to + zero kbps in the SDP, the client can skip stage 1 by sending a "READY + 2" message after completion of stage 0. Stage 1 measurements are + achieved through Q4S BWIDTH messages sent from both the client and + the server. Unlike PING messages, Q4S BWIDTH requests will not be + answered. + + If Stage 0 and 1 meet the application quality constraints, the + application may start. Q4S will enter the Continuity phase by + measuring the network quality parameters through the Q4S PING message + exchange on both connection paths and raising alerts in case of + violation. + + Once the client wants to terminate the quality session, it sends a + Q4S CANCEL message, which will be acknowledged by the server with + another Q4S CANCEL message. Termination of quality sessions are + always initiated by the client because Q4S TCP requests follow the + client/server schema. + + Figure 2 depicts the message exchange in a successful scenario. + + +-------------------------------------------+ + | | + | Client Server | + | | + Handshake | --------- Q4S BEGIN -----------> | + | <-------- Q4S 200 OK ----------- | + | | + Negotiation | | + (Stage 0) | --------- Q4S READY 0----------> | + | <-------- Q4S 200 OK ----------- | + | | + | --------- Q4S PING ------------> | + | <-------- Q4S 200 OK ----------- | + | <-------- Q4S PING ------------- | + | -------- Q4S 200 OK ----------> | + | --------- Q4S PING ------------> | + | <-------- Q4S PING ------------- | + | --------- Q4S 200 OK ----------> | + | <-------- Q4S 200 OK ----------- | + | ... | + Negotiation | | + (Stage 1) | --------- Q4S READY 1----------> | + | <-------- Q4S 200 OK ----------- | + | | + | --------- Q4S BWITDH ----------> | + | <-------- Q4S BWIDTH------------ | + | --------- Q4S BWITDH ----------> | + | <-------- Q4S BWIDTH------------ | + | ... | + Continuity | --------- Q4S READY 2 ---------> | + | <-------- Q4S 200 OK ----------- | app start + | | + | --------- Q4S PING ------------> | + | <-------- Q4S 200 OK ----------- | + | <-------- Q4S PING ------------- | + | -------- Q4S 200 OK ----------> | + | | + Termination | --------- Q4S CANCEL ----------> | app end + | <-------- Q4S CANCEL ----------- | + | | + +-------------------------------------------+ + + Figure 2: Successful Q4S Message Exchange + + Both client and server measurements are included in the PING and + BWIDTH messages, allowing both sides of the communication channel to + be aware of all measurements in both directions. + + The following two examples show the behavior of the Q4S protocol when + quality constraints are violated, and alerts are generated; and, + later on, when the violation of quality constraints stops leading to + the execution of the recovery process. The first example (Figure 3) + shows the Q4S-aware-network alerting mode scenario: + + +-------------------------------------------+ + | | + | Client Server | + | | + Handshake | --------- Q4S BEGIN -----------> | + | <-------- Q4S 200 OK ----------- | + | | + Negotiation | | + (Stage 0) | --------- Q4S READY 0----------> | + | <-------- Q4S 200 OK ----------- | + | | + | --------- Q4S PING ------------> | + | <-------- Q4S 200 OK ----------- | + | <-------- Q4S PING ------------- | + | -------- Q4S 200 OK ----------> | + | ... | + | | + | <-------- Q4S-ALERT ------------ | + | -------- Q4S-ALERT ------------> | + | (alert-pause start) | + Repetition | | + of Stage 0 | --------- Q4S READY 0----------> | + | <-------- Q4S 200 OK ----------- | + | | + | --------- Q4S PING ------------> | + | <-------- Q4S 200 OK ----------- | + | <-------- Q4S PING ------------- | + | ... | + Negotiation | | + (Stage 1) | --------- Q4S READY 1----------> | + | <-------- Q4S 200 OK ----------- | + | | + | --------- Q4S BWITDH ----------> | + | <-------- Q4S BWIDTH------------ | + | ... | + | | + Continuity | --------- Q4S READY 2 ---------> | + | <-------- Q4S 200 OK ----------- | app start + | | + | --------- Q4S PING ------------> | + | <-------- Q4S 200 OK ----------- | + | <-------- Q4S PING ------------- | + | -------- Q4S 200 OK ----------> | + | ... | + |(alert-pause expires & | + | violated constraints) | + | <-------- Q4S-ALERT ------------ | + | --------- Q4S-ALERT -----------> | + | | + | (alert-pause start) | + | --------- Q4S PING ------------> | + | <-------- Q4S 200 OK ----------- | + | <-------- Q4S PING ------------- | + | --------- Q4S 200 OK ----------> | + | ... | + |(alert-pause expires & | + | violated constraints) | + | <-------- Q4S-ALERT ------------ | + | --------- Q4S-ALERT -----------> | + | (alert-pause) | + | --------- Q4S PING ------------> | + | <-------- Q4S 200 OK ----------- | + | <-------- Q4S PING ------------- | + | -------- Q4S 200 OK ----------> | + | ... | + |(alert-pause expires & | + | Fulfilled constraints) | + | | + | (recovery-pause start) | + | | + | --------- Q4S PING ------------> | + | <-------- Q4S 200 OK ----------- | + | <-------- Q4S PING ------------- | + | -------- Q4S 200 OK ----------> | + | ... | + |(recovery-pause expires & | + | Fulfilled constraints) | + | <--------- Q4S-RECOVERY --------- | + | -------- Q4S-RECOVERY -----------> | + | | + | (recovery-pause start) | + | --------- Q4S PING ------------> | + | <-------- Q4S 200 OK ----------- | + | <-------- Q4S PING ------------- | + | -------- Q4S 200 OK ----------> | + | ... | + | | + Termination | --------- Q4S CANCEL ----------> | app end + | <-------- Q4S CANCEL ----------- | + | | + +-------------------------------------------+ + + Figure 3: Q4S-Aware-Network Alerting Mode + + In this Q4S-aware-network alerting mode scenario, the server may send + Q4S alerts to the client at any time upon detection of violated + quality constraints. This alerting exchange must not interrupt the + continuity quality parameter measurements between client and server. + + The second example depicted in Figure 4 represents the Reactive + scenario, in which alert notifications are sent from the server stack + to the Actuator, which is in charge of deciding to act over + application behavior and/or to invoke a network policy server. The + Actuator is an entity that has a defined set of different quality + levels and decides how to act depending on the actions stated for + each of these levels; it can take actions for making adjustments on + the application, or it can send a request to the policy server for + acting on the network. The policy server also has a defined set of + different quality levels previously agreed upon between the + Application Content Provider and the ISP. The Reactive alerting mode + is the default mode. + + +-------------------------------------------+ + | | + | Client Server Actuator | + Handshake | ----- Q4S BEGIN -----> | + | <---- Q4S 200 OK ----- | + | | + Negotiation | | + (Stage 0) | ----- Q4S READY 0----> | + | <---- Q4S 200 OK ----- | + | | + | ----- Q4S PING ------> | + | <---- Q4S 200 OK ----- | + | <---- Q4S PING ------- | + | ---- Q4S 200 OK ----> | + | ... | + | (alert-pause start) | + | --alert | + | notification--> | + | | + | <--alert | + | acknowledge--- | + | | + Repetition | | + of Stage 0 | ----- Q4S READY 0----> | + | <---- Q4S 200 OK ----- | + | | + | ----- Q4S PING ------> | + | <---- Q4S 200 OK ----- | + | <---- Q4S PING ------- | + | ... | + |(alert-pause expires & | + | violated constraints) | + | | + | --alert | + | notification--> | + | | + | <--alert | + | acknowledge--- | + | | + | ----- Q4S PING ------> | + | <---- Q4S 200 OK ----- | + | <---- Q4S PING ------- | + | ... | + Negotiation | | + (Stage 1) | ----- Q4S READY 1----> | + | <---- Q4S 200 OK ----- | + | | + | ----- Q4S BWITDH ----> | + | <---- Q4S BWIDTH------ | + | ... | + Continuity | ----- Q4S READY 2 ---> | + | <---- Q4S 200 OK ----- | app start + | | + |(alert-pause expires & | + | fulfilled constraints) | + | | + |(recovery-pause start) | + | ----- Q4S PING ------> | + | <---- Q4S 200 OK ----- | + | <---- Q4S PING ------- | + | ----- Q4S PING ------> | + | | + |(recovery-pause expires & | + | fulfilled constraints) | + | | + | --recovery | + | notification--> | + | | + | <--recovery | + | acknowledge--- | + | | + |(recovery-pause start) | + | <---- Q4S 200 OK ----- | + | <---- Q4S PING ------- | + | ----- Q4S 200 OK ----> | + | ----- Q4S PING ------> | + | ... | + | | + Termination | ----- Q4S CANCEL ----> | app end + | --cancel | + | notification--> | + | | + | <--cancel | + | acknowledge-- | + | <---- Q4S CANCEL ----- | + | | + +-------------------------------------------+ + + Figure 4: Reactive Alerting Mode + + At the end of any stage of the Negotiation phase, the server sends an + alert notification to the Actuator if quality constraints are + violated. During the period of time defined by the "alert-pause" + attribute, no further alert notifications are sent, but measurements + are not interrupted. This way, both the client and the server will + detect network improvements as soon as possible. In a similar way + during the Continuity phase, the server may send alert notifications + at any time to the Actuator upon detection of violated quality + constraints. This alerting exchange must not interrupt the + continuity measurements between client and server. + + Finally, in the Termination phase, Q4S CANCEL messages sent from the + client to the server must be forwarded from the server to the + Actuator in order to release possible assigned resources for the + session. + +4. Q4S Messages + + Q4S is a text-based protocol and uses the UTF-8 charset [RFC3629]. A + Q4S message is either a request or a response. + + Both request and response messages use the basic format of Internet + Message Format [RFC5322]. Both types of messages consist of a start- + line, one or more header fields, an empty line indicating the end of + the header fields, and an optional message-body. This document uses + ABNF notation [RFC5234] for the definitions of the syntax of + messages. + + The start-line, each message-header line, and the empty line MUST be + terminated by a carriage-return line-feed sequence (CRLF). Note that + the empty line MUST be present even if the message-body is not. + + generic-message = start-line CRLF + *message-header CRLF + CRLF + [ message-body ] + start-line = Request-Line / Status-Line + + Much of Q4S's messages and header field syntax are identical to + HTTP/1.1. However, Q4S is not an extension of HTTP. + +4.1. Requests + + Q4S requests are distinguished by having a Request-Line for a start- + line. A Request-Line contains a method name, a Request-URI, and the + protocol version separated by a single space (SP) character. + + The Request-Line ends with CRLF. No CR or LF are allowed except in + the end-of-line CRLF sequence. No linear whitespace (LWSP) is + allowed in any of the elements. + + Request-Line = Method SP Request-URI SP Q4S-Version CRLF + + Method: This specification defines seven methods: BEGIN for starting + and negotiating quality sessions, READY for synchronization of + measurements, PING and BWIDTH for quality measurements + purposes, CANCEL for terminating sessions, Q4S-ALERT for + reporting quality violations, and Q4S-RECOVERY for reporting + quality recovery. + + Request-URI: The Request-URI is a Q4S URI [RFC3986] as described in + Section 7.4. The Request-URI MUST NOT contain unescaped spaces + or control characters and MUST NOT be enclosed in "<>". + + Q4S-Version: Both request and response messages include the version + of Q4S in use. To be compliant with this specification, + applications sending Q4S messages MUST include a Q4S-Version of + "Q4S/1.0". The Q4S-Version string is case insensitive, but + implementations MUST send uppercase. Unlike HTTP/1.1, Q4S + treats the version number as a literal string. In practice, + this should make no difference. + +4.2. Responses + + Q4S responses are distinguished from requests by having a Status-Line + as their start-line. A Status-Line consists of the protocol version + followed by a numeric Status-Code and its associated textual phrase, + with each element separated by a single SP character. No CR or LF is + allowed except in the final CRLF sequence. + + Status-Line = Q4S-Version SP Status-Code SP Reason-Phrase CRLF + + The Status-Code is a 3-digit integer result code that indicates the + outcome of an attempt to understand and satisfy a request. The + Reason-Phrase is intended to give a short textual description of the + Status-Code. The Status-Code is intended for use by automata, + whereas the Reason-Phrase is intended for the human user. A client + is not required to examine or display the Reason-Phrase. + + While this specification suggests specific wording for the Reason- + Phrase, implementations MAY choose other text, for example, in the + language indicated in the Accept-Language header field of the + request. + + The first digit of the Status-Code defines the class of response. + The last two digits do not have any categorization role. For this + reason, any response with a status code between 100 and 199 is + referred to as a "1xx response", any response with a status code + between 200 and 299 as a "2xx response", and so on. Q4S/1.0 allows + following values for the first digit: + + 1xx: Provisional -- request received, continuing to process the + request; + + 2xx: Success -- the action was successfully received, understood, + and accepted; + + 3xx: Redirection -- further action needs to be taken in order to + complete the request; + + 4xx: Request Failure -- the request contains bad syntax or cannot be + fulfilled at this server; + + 5xx: Server Error -- the server failed to fulfill an apparently + valid request; + + 6xx: Global Failure -- the request cannot be fulfilled at any + server. + + The status codes are the same as described in HTTP [RFC7231]. In the + same way as HTTP, Q4S applications are not required to understand the + meaning of all registered status codes, though such understanding is + obviously desirable. However, applications MUST understand the class + of any status code, as indicated by the first digit, and treat any + unrecognized response as being equivalent to the x00 status code of + that class. + + The Q4S-ALERT, Q4S-RECOVERY, and CANCEL requests do not have to be + responded to. However, after receiving a Q4S-ALERT, Q4S-RECOVERY, or + CANCEL request, the server SHOULD send a Q4S-ALERT, Q4S-RECOVERY, or + CANCEL request to the client. + +4.3. Header Fields + + Q4S header fields are identical to HTTP header fields in both syntax + and semantics. + + Some header fields only make sense in requests or responses. These + are called request header fields and response header fields, + respectively. If a header field appears in a message that does not + match its category (such as a request header field in a response), it + MUST be ignored. + +4.3.1. Common Q4S Header Fields + + These fields may appear in request and response messages. + + Session-Id: the value for this header field is the same sess-id used + in SDP (embedded in the SDP "o=" line) and is assigned by the + server. The messages without SDP MUST include this header + field. If a message has an SDP body, this header field is + optional. The method of sess-id allocation is up to the + creating tool, but it is suggested that a UTC timestamp be used + to ensure uniqueness. + + Sequence-Number: sequential and cyclic positive integer number + assigned to PING and BWIDTH messages and acknowledged in 200 OK + responses. + + Timestamp: this optional header field contains the system time (with + the best possible accuracy). It indicates the time in which + the PING request was sent. If this header field is present in + PING messages, then the 200 OK response messages MUST include + this value. + + Stage: this is used in the client's READY requests and the server's + 200 OK responses during the Negotiation and Continuity phases + in order to synchronize the initiation of the measurements. + Example: Stage: 0 + +4.3.2. Specific Q4S Request Header Fields + + In addition to HTTP header fields, these are the specific Q4S request + header fields: + + User-Agent: this header field contains information about the + implementation of the user agent. This is for statistical + purposes, the tracing of protocol violations, and the automated + recognition of user agents for the sake of tailoring responses + to avoid particular user agent limitations. User agents SHOULD + include this field with requests. The field MAY contain + multiple product tokens and comments identifying the agent and + any sub-products that form a significant part of the user + agent. By convention, the product tokens are listed in order + of their significance for identifying the application. + + Signature: this header field contains a digital signature that can + be used by the network, Actuator, or policy server to validate + the SDP, preventing security attacks. The Signature is an + optional header field generated by the server according to the + pre-agreed security policies between the Application Content + Provider and the ISP. For example, a hash algorithm and + encryption method such as SHA256 [RFC6234] and RSA [RFC8017] + based on the server certificate could be used. This + certificate is supposed to be delivered by a Certification + Authority (CA) or policy owner to the server. The signature is + applied to the SDP body. + + Signature= RSA ( SHA256 (<sdp>), <certificate> ) + + If the Signature header field is not present, other validation + mechanisms MAY be implemented in order to provide assured + quality with security and control. + + Measurements: this header field carries the measurements of the + quality parameters in PING and BWIDTH requests. The format is: + + Measurements: "l=" " "|[0..9999] ", j=" " "|[0..9999] ", pl=" + " "|[0.00 .. 100.00] ", bw=" " "|[0..999999] + + Where "l" stands for latency followed by the measured value (in + milliseconds) or an empty space, "j" stands for jitter followed + by the measured value (in milliseconds) or an empty space, "pl" + stands for packet loss followed by the measured value (in + percentage with two decimals) or an empty space, and "bw" + stands for bandwidth followed by the measured value (in kbps) + or an empty space. + +4.3.3. Specific Q4S Response Header Fields + + Expires: its purpose is to provide a sanity check and allow the + server to close inactive sessions. If the client does not send + a new request before the expiration time, the server MAY close + the session. The value MUST be an integer, and the measurement + units are milliseconds. + + In order to keep the session open, the server MUST send a Q4S + alert before the session expiration (Expires header field), + with the same quality levels and an alert cause of "keep- + alive". The purpose of this alert is to avoid TCP sockets, + which were opened with READY message, from being closed, + specially in NAT scenarios. + +4.4. Bodies + + Requests, including new requests defined in extensions to this + specification, MAY contain message bodies unless otherwise noted. + The interpretation of the body depends on the request method. + + For response messages, the request method and the response status + code determine the type and interpretation of any message body. All + responses MAY include a body. + + The Internet media type of the message body MUST be given by the + Content-Type header field. + +4.4.1. Encoding + + The body MUST NOT be compressed. This mechanism is valid for other + protocols such as HTTP and SIP [RFC3261], but a compression/coding + scheme will limit the way the request is parsed to certain logical + implementations, thus making the protocol concept more implementation + dependent. In addition, the bandwidth calculation may not be valid + if compression is used. Therefore, the HTTP Accept-Encoding request + header field cannot be used in Q4S with values different from + "identity", and if it is present in a request, the server MUST ignore + it. In addition, the response header field Content-Encoding is + optional, but if present, the unique permitted value is "identity". + + The body length in bytes MUST be provided by the Content-Length + header field. The "chunked" transfer encoding of HTTP/1.1 MUST NOT + be used for Q4S. + + | Note: The chunked encoding modifies the body of a message in + | order to transfer it as a series of chunks, each one with its + | own size indicator. + +5. Q4S Method Definitions + + The Method token indicates the method to be performed on the resource + identified by the Request-URI. The method is case sensitive. + + Method = "BEGIN" | "READY" | "PING" | "BWIDTH" | + "Q4S-ALERT" | "Q4S-RECOVERY" | "CANCEL" | extension-method + + extension-method = token + + The list of methods allowed by a resource can be specified in an + Allow header field [RFC7231]. The return code of the response always + notifies the client when a method is currently allowed on a resource, + since the set of allowed methods can change dynamically. Any server + application SHOULD return the status code 405 (Method Not Allowed) if + the method is known, but not allowed for the requested resource, and + 501 (Not Implemented) if the method is unrecognized or not + implemented by the server. + +5.1. BEGIN + + The BEGIN method requests information from a resource identified by a + Q4S URI. The purpose of this method is to start the quality session. + + This method is used only during the Handshake phase to retrieve the + SDP containing the sess-id and all quality and operation parameters + for the desired application to run. + + When a BEGIN message is received by the server, any current quality + session MUST be canceled, and a new session should be created. + + The response to a Q4S BEGIN request is not cacheable. + +5.2. READY + + The READY method is used to synchronize the starting time for the + sending of PING and BWIDTH messages over UDP between clients and + servers. Including the Stage header field in this method is + mandatory. + + This message is used only in Negotiation and Continuity phases, and + only just before making a measurement. Otherwise (outside of this + context), the server MUST ignore this method. + +5.3. PING + + This message is used during the Negotiation and Continuity phases to + measure the RTT and jitter of a session. The message MUST be sent + only over UDP ports. + + The fundamental difference between the PING and BWIDTH requests is + reflected in the different measurements achieved with them. PING is + a short message, and it MUST be answered in order to measure RTT and + jitter, whereas BWIDTH is a long message and MUST NOT be answered. + + PING is a request method that can be originated by either the client + or the server. The client MUST also answer the server PING messages, + assuming a "server role" for these messages during the measurement + process. + + Including the Measurements header field in this method is mandatory, + and provides updated measurements values for latency, jitter, and + packet loss to the counterpart. + +5.4. BWIDTH + + This message is used only during the Negotiation phase to measure the + bandwidth and packet loss of a session. The message MUST be sent + only over UDP ports. + + BWIDTH is a request method that can be originated by either the + client or the server. Both client and server MUST NOT answer BWIDTH + messages. + + Including the Measurements header field in this method is mandatory + and provides updated measurements values for bandwidth and packet + loss to the counterpart. + +5.5. Q4S-ALERT + + This is the request message that Q4S generates when the measurements + indicate that quality constraints are being violated. It is used + during the Negotiation and Continuity phases. + + This informative message indicates that the user experience is being + degraded and includes the details of the problem (bandwidth, jitter, + packet loss measurements). The Q4S-ALERT message does not contain + any detail on the actions to be taken, which depend on the agreements + between all involved parties. + + Unless there is an error condition, an answer to a Q4S-ALERT request + is optional and is formatted as a request Q4S-ALERT message. If + there is an error condition, then a response message is sent. The + response to a Q4S-ALERT request is not cacheable. + + This method MUST be initiated by the server in both alerting modes. + In the Q4S-aware-network alerting mode, the Q4S-ALERT messages are + sent by the server to the client, advising the network to react by + itself. In the Reactive alerting mode, alert notifications are + triggered by the server stack and sent to the Actuator (see Figure 1, + "Reactive Scenario"). + + Client----q4s----SERVER STACK--->ACTUATOR-->APP OR POLICY SERVER + + The way in which the server stack notifies the Actuator is + implementation dependent, and the communication between the Actuator + and the network policy server is defined by the protocol and API that + the policy server implements. + +5.6. Q4S-RECOVERY + + This is the request message that Q4S generates when the measurements + indicate that quality constraints, which had been violated, have been + fulfilled during a period of time ("recovery-pause"). It is used + during the Negotiation and Continuity phases. + + This informative message indicates that the "qos-level" could be + increased gradually until the initial "qos-level" is recovered (the + "qos-level" established at the beginning of the session that was + decreased during violation of constraints. See Section 7.9). The + Q4S-RECOVERY message does not contain any detail on the actions to be + taken, which depends on the agreements between all involved parties. + + The answer to a Q4S-RECOVERY request is formatted as a request Q4S- + RECOVERY message. A Q4S-RECOVERY request MUST NOT be answered with a + response message unless there is an error condition. The response to + a Q4S-RECOVERY request is not cacheable. + + Like the Q4S-ALERT message, the Q4S-RECOVERY method is always + initiated by the server in both alerting modes. In the Q4S-aware- + network alerting mode, the Q4S-RECOVERY messages are sent by the + server to the client, advising the network to react by itself. In + the Reactive alerting mode, recovery notifications are triggered by + the server stack and sent to the Actuator (see Figure 1, "Reactive + Scenario"). + +5.7. CANCEL + + The purpose of the CANCEL message is the release of the Q4S Session- + Id and the possible resources assigned to the session. This message + could be triggered by the Q4S stack or by the application using the + stack (through an implementation-dependent API). + + In the same way as Q4S-ALERT, CANCEL must not be answered with a + response message, but with an answer formatted as a request Q4S- + CANCEL message. + + In the Reactive scenario, the server stack MUST react to the Q4S + CANCEL messages received from the client by forwarding a cancel + notification to the Actuator, in order to release possible assigned + resources for the session (at the application or at the policy + server). The Actuator MUST answer the cancel notification with a + cancel acknowledge towards the server stack, acknowledging the + reception. + +6. Response Codes + + Q4S response codes are used for TCP and UDP. However, in UDP, only + the response code 200 is used. + + The receiver of an unknown response code must take a generic action + for the received error group (1xx, 2xx, 3xx, 4xx, 5xx, 6xx). In case + of an unknown error group, the expected action should be the same as + with the 6xx error group. + +6.1. 100 Trying + + This response indicates that the request has been received by the + next-hop server and that some unspecified action is being taken on + behalf of this request (for example, a database is being consulted). + This response, like all other provisional responses, stops + retransmissions of a Q4S-ALERT during the "alert-pause" time. + +6.2. Success 2xx + + 2xx responses give information about the success of a request. + +6.2.1. 200 OK + + The request has succeeded. + +6.3. Redirection 3xx + + 3xx responses give information about the user's new location or about + alternative services that might be able to satisfy the request. + + The requesting client SHOULD retry the request at the new address(es) + given by the Location header field. + +6.4. Request Failure 4xx + + 4xx responses are definite failure responses from a particular + server. The client SHOULD NOT retry the same request without + modification (for example, adding appropriate header fields or SDP + values). However, the same request to a different server might be + successful. + +6.4.1. 400 Bad Request + + The request could not be understood due to malformed syntax. The + Reason-Phrase SHOULD identify the syntax problem in more detail, for + example, "Missing Sequence-Number header field". + +6.4.2. 404 Not Found + + The server has definitive information that the user does not exist at + the domain specified in the Request-URI. This status is also + returned if the domain in the Request-URI does not match any of the + domains handled by the recipient of the request. + +6.4.3. 405 Method Not Allowed + + The method specified in the Request-Line is understood, but not + allowed for the address identified by the Request-URI. + + The response MUST include an Allow header field containing a list of + valid methods for the indicated address. + +6.4.4. 406 Not Acceptable + + The resource identified by the request is only able to generate + response entities that have content characteristics that are not + acceptable according to the Accept header field sent in the request. + +6.4.5. 408 Request Timeout + + The server could not produce a response within a suitable amount of + time, and the client MAY repeat the request without modifications at + any later time. + +6.4.6. 413 Request Entity Too Large + + The server is refusing to process a request because the request + entity-body is larger than the one that the server is willing or able + to process. The server MAY close the connection to prevent the + client from continuing the request. + +6.4.7. 414 Request-URI Too Long + + The server is refusing to process the request because the Request-URI + is longer than the one that the server accepts. + +6.4.8. 415 Unsupported Media Type + + The server is refusing to process the request because the message + body of the request is in a format not supported by the server for + the requested method. The server MUST return a list of acceptable + formats using the Accept, Accept-Encoding, or Accept-Language header + field, depending on the specific problem with the content. + +6.4.9. 416 Unsupported URI Scheme + + The server cannot process the request because the scheme of the URI + in the Request-URI is unknown to the server. + +6.5. Server Failure 5xx + + 5xx responses are failure responses given when a server itself is + having trouble. + +6.5.1. 500 Server Internal Error + + The server encountered an unexpected condition that prevented it from + fulfilling the request. The client MAY display the specific error + condition and MAY retry the request after several seconds. + +6.5.2. 501 Not Implemented + + The server does not support the functionality required to fulfill the + request. This is the appropriate response when a server does not + recognize the request method, and it is not capable of supporting it + for any user. + + Note that a 405 (Method Not Allowed) is sent when the server + recognizes the request method, but that method is not allowed or + supported. + +6.5.3. 503 Service Unavailable + + The server is temporarily unable to process the request due to a + temporary overloading or maintenance of the server. The server MAY + indicate when the client should retry the request in a Retry-After + header field. If no Retry-After is given, the client MUST act as if + it had received a 500 (Server Internal Error) response. + + A client receiving a 503 (Service Unavailable) SHOULD attempt to + forward the request to an alternate server. It SHOULD NOT forward + any other requests to that server for the duration specified in the + Retry-After header field, if present. + + Servers MAY refuse the connection or drop the request instead of + responding with 503 (Service Unavailable). + +6.5.4. 504 Server Time-Out + + The server did not receive a timely response from an external server + it accessed in attempting to process the request. + +6.5.5. 505 Version Not Supported + + The server does not support, or refuses to support, the Q4S protocol + version that was used in the request. The server is indicating that + it is unable or unwilling to complete the request using the same + major version as the client, other than with this error message. + + In the case that the Q4S version is not supported, this error may be + sent by the server in the Handshake phase just after receiving the + first BEGIN message from client. + +6.5.6. 513 Message Too Large + + The server was unable to process the request because the message + length exceeded its capabilities. + +6.6. Global Failures 6xx + + 6xx responses indicate that a server has definitive information about + a particular policy not satisfied for processing the request. + +6.6.1. 600 Session Does Not Exist + + The Session-Id is not valid. + +6.6.2. 601 Quality Level Not Allowed + + The "qos-level" requested is not allowed for the client/server pair. + +6.6.3. 603 Session Not Allowed + + The session is not allowed due to some policy (the number of sessions + allowed for the server is exceeded, or the time band of the Q4S-ALERT + is not allowed for the client/server pair, etc.). + +6.6.4. 604 Authorization Not Allowed + + The policy server does not authorize the Q4S-ALERT quality session + improvement operation due to an internal or external reason. + +7. Protocol + + This section describes the measurement procedures, the SDP structure + of the Q4S messages, the different Q4S protocol phases, and the + messages exchanged in them. + +7.1. Protocol Phases + + All elements of the IP network contribute to quality in terms of + latency, jitter, bandwidth, and packet loss. All these elements have + their own quality policies in terms of priorities, traffic mode, + etc., and each element has its own way to manage the quality. The + purpose of a quality connection is to establish end-to-end + communication with enough quality for the application to function + flawlessly. + + To monitor quality constraints of the application, four phases are + defined and can be seen in Figure 5: + + +---------------------------------------------------------------+ + | | + | | + | Handshake ---> Negotiation -+--> Continuity ----> Termination | + | A | (app start) | (app end) | + | | V A V A | + | | violated | violated | | + | | constraints | constraints | | + | | | | |_______| ____| | + | | | | +-------+ | | + | | | | | | + | +------+ +---------------------+ | + | | + +---------------------------------------------------------------+ + + Figure 5: Session Lifetime Phases + + Handshake phase: in which the server is contacted by the client, and + in the answer message, the quality constraints for the application + are communicated in the embedded SDP. + + Negotiation phase: in which the quality of the connection is + measured in both directions (latency, jitter, bandwidth, and + packet loss), and Q4S messages may be sent in order to alert if + the measured quality does not meet the constraints. This phase is + iterative until quality constraints are reached, or the session is + canceled after a number of measurement cycles with consistent + violation of the quality constraints. The number of measurement + cycles executed depends on the "qos-level", which is incremented + in each cycle until a maximum "qos-level" value is reached. Just + after reaching the quality requirements, Q4S provides a simple + optional mechanism using HTTP to start the application. + + Continuity phase: in which quality is continuously measured. In + this phase, the measurements MUST avoid disturbing the application + by consuming network resources. If quality constraints are not + met, the server stack will notify the Actuator with an alert + notification. If later the quality improves, the server stack + will notify the Actuator, in this case with a recovery + notification. After several alert notifications with no quality + improvements, the Q4S stack SHOULD move to the Termination phase. + + Termination phase: in which the Q4S session is terminated. The + application may be closed also or may not start. + +7.2. SDP Structure + + The original goal of SDP was to announce necessary information for + the participants and multicast MBONE (Multicast Backbone) + applications. Right now, its use has been extended to the + announcement and the negotiation of multimedia sessions. The purpose + of Q4S is not to establish media stream sessions, but to monitor a + quality connection. This connection may be later used to establish + any type of session including media sessions; Q4S does not impose any + conditions on the type of communication requiring quality parameters. + + SDP will be used by Q4S to exchange quality constraints and will + therefore always have all the media descriptions ("m=") set to zero. + + The SDP embedded in the messages is the container of the quality + parameters. As these may vary depending on the direction of the + communication (to and from the client), all quality parameters need + to specify the uplink and downlink values: <uplink> / <downlink> (see + Section 7.5.3 for an example). When one or both of these values are + empty, it MUST be understood as needing no constraint on that + parameter and/or that direction. + + The uplink direction MUST be considered as being the communication + from the client to the server. The downlink direction MUST be + considered as being the communication from the server to the client. + + The SDP information can comprise all or some of the following + parameters shown in the example below. This is an example of an SDP + message used by Q4S included in the 200 OK response to a Q4S BEGIN + request. + + v=0 + o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33 + s=Q4S + i=Q4S parameters + t=0 0 + a=qos-level:0/0 + a=alerting-mode:Reactive + a=alert-pause:5000 + a=public-address:client IP4 198.51.100.51 + a=public-address:server IP4 198.51.100.58 + a=measurement:procedure default(50/50,75/75,5000,40/80,100/256) + a=latency:40 + a=jitter:10/10 + a=bandwidth:20/6000 + a=packetloss:0.50/0.50 + a=flow:app clientListeningPort TCP/10000-20000 + a=flow:app clientListeningPort UDP/15000-18000 + a=flow:app serverListeningPort TCP/56000 + a=flow:app serverListeningPort UDP/56000 + a=flow:q4s clientListeningPort UDP/55000 + a=flow:q4s clientListeningPort TCP/55001 + a=flow:q4s serverListeningPort UDP/56000 + a=flow:q4s serverListeningPort TCP/56001 + + As quality constraints may be changed by applications at any time + during the Q4S session lifetime, any Q4S 200 OK response sent by the + server to the client in the Negotiation and Continuity phases could + also include an SDP body with the new quality requirements stated by + the applications from then on. Therefore, in response to any PING + request sent by the client to the server, the server could send a Q4S + 200 OK with an embedded SDP message that specifies new quality + constraints requested by the application. + +7.2.1. "qos-level" Attribute + + The "qos-level" attribute contains the QoS level for uplink and + downlink. Default values are 0 for both directions. The meaning of + each level is out of scope of Q4S, but a higher level SHOULD + correspond to a better service quality. + + Appropriate attribute values: [0..9] "/" [0..9] + + The "qos-level" attribute may be changed during the session lifetime, + raising or lowering the value as necessary following the network + measurements and the application needs. + +7.2.2. "alerting-mode" Attribute + + The "alerting-mode" attribute specifies the player in charge of + triggering Q4S alerts in the case of constraint violation. There are + two possible values: + + Appropriate attribute values: <"Q4S-aware-network"|"Reactive"> + + Q4S-aware-network: Q4S-ALERT messages are triggered by the server to + the client. In this case, the network is supposed to be Q4S + aware, and reacts by itself to these alerts. + + Reactive: alert notifications are sent by the server stack to the + Actuator. In this case, the network is not Q4S aware, and a + specific node (Actuator) is in charge of triggering tuning + mechanisms, either on the network or in the application. + + The "alerting-mode" attribute is optional, and if not present, + Reactive alerting mode is assumed. + +7.2.3. "alert-pause" Attribute + + In the Q4S-aware-network scenario, the "alert-pause" attribute + specifies the amount of time (in milliseconds) the server waits + between consecutive Q4S-ALERT messages sent to the client. In the + Reactive scenario, the "alert-pause" attribute specifies the amount + of time (in milliseconds) the server stack waits between consecutive + alert notifications sent to the Actuator. Measurements are not + stopped in Negotiation or Continuity phases during this period of + time, but no Q4S-ALERT messages or alert notifications are fired, + even with violated quality constraints, allowing for either network + reconfigurations or application adjustments. + + Appropriate attribute values: [0..60000] + +7.2.4. "recovery-pause" Attribute + + In the Q4S-aware-network scenario, the "recovery-pause" attribute + specifies the amount of time (in milliseconds) the server waits for + initiating the "qos-level" recovery process. Once the recovery + process has started, the "recovery-pause" attribute also states the + amount of time (in milliseconds) between consecutive Q4S-RECOVERY + messages sent by the server to the client (in the Q4S-aware-network + scenario) or between recovery notifications sent by the server stack + to the Actuator (in the Reactive scenario). + + Appropriate attribute values: [0..60000] + +7.2.5. "public-address" Attributes + + This attribute contains the public IP address of the client and the + server. The server fills these attributes with its own public IP + address and the public IP address of the first message received from + the client in the Handshake phase. + + The purpose of these attributes is to make available the addressing + information to the network policy server or other external entities + in charge of processing Q4S-ALERT messages. + + Appropriate attribute values: <"client"|"server"> <"IP4"|"IP6"> + <value of IP address> + +7.2.6. "latency" Attribute + + The maximum latency (considered equal for uplink and downlink) + tolerance is specified in the "latency" attribute, expressed in + milliseconds. In the Q4S-aware-network scenario, if the latency + constraints are not met, a Q4S-ALERT method will be sent to the + client. In the Reactive scenario, if the latency constraints are not + met, an alert notification will be sent to the Actuator. If the + "latency" attribute is not present or has a 0 value, no latency + constraints need to be met, and no measurements MAY be taken. + + Appropriate attribute values: [0..9999] + +7.2.7. "jitter" Attribute + + The maximum uplink and downlink jitter tolerance is specified in the + "jitter" attribute, expressed in milliseconds. In the Q4S-aware- + network scenario, if the jitter constraints are not met, a Q4S-ALERT + method will be sent to the client. In the Reactive scenario, if the + latency constraints are not met, an alert notification will be sent + to the Actuator. If the "jitter" attribute is not present or has a 0 + value, no jitter constraints need to be met, and no measurements MAY + be taken. + + Appropriate attribute values: [0..9999] "/" [0..9999] + +7.2.8. "bandwidth" Attribute + + The minimum uplink and downlink bandwidth is specified in the + "bandwidth" attribute, expressed in kbps. In the Q4S-aware-network + scenario, if the bandwidth constraints are not met, a Q4S-ALERT + method will be sent to the client. In the Reactive scenario, an + alert notification will be sent to the Actuator. If the "bandwidth" + attribute is not present or has a 0 value, no bandwidth constraints + need to be met, and no measurements MAY be taken. + + Appropriate attribute values: [0..99999] "/" [0..99999] + +7.2.9. "packetloss" Attribute + + The maximum uplink and downlink packet loss tolerance is specified in + the "packetloss" attribute expressed in percentage (two decimal + accuracy). In the Q4S-aware-network scenario, if the packetloss + constraints are not met, a Q4S-ALERT method will be sent to the + client. In the Reactive scenario, an alert notification will be sent + to the Actuator. If the "packetloss" attribute is not present or has + a 0 value, no packet loss constraints need to be met, and no + measurements MAY be taken. + + Appropriate attribute values: [0.00 ..100.00] "/"[0.00 ..100.00] + +7.2.10. "flow" Attributes + + These attributes specify the flows (protocol, destination IP/ports) + of data over TCP and UDP ports to be used in uplink and downlink + communications. + + Several "flow" attributes can be defined. These flows identify the + listening port (client or server), the protocol (TCP [RFC0793] or UDP + [RFC0768]) with the range of ports that are going to be used by the + application and, of course, by the Q4S protocol (for quality + measurements). All defined flows ("app" and "q4s") will be + considered within the same quality profile, which is determined by + the "qos-level" attribute in each direction. This allows us to + assume that measurements on "q4s" flows are the same as experienced + by the application, which is using "app" flows. + + During Negotiation and Continuity phases, the specified Q4S ports in + the "flow:q4s" attributes of SDP will be used for Q4S messages. + + The Q4S flows comprise two UDP flows and two TCP flows (one uplink + and one downlink for each one), whereas application traffic MAY + consist of many flows, depending on its nature. The Handshake phase + takes place through the Q4S Contact URI, using the standard Q4S TCP + port. However, the Negotiation and Continuity phases will take place + on the Q4S ports (UDP and TCP) specified in the SDP. + + The "clientListeningPort" is a port on which the client listens for + server requests and MUST be used as the origin port of client + responses. The "serverListeningPort" is a port on which the server + is listening for incoming messages from the client. The origin port + of server responses may be different than the "serverListeningPort" + value. + + If "clientListeningPort" is zero ("a=flow:q4s clientListeningPort + TCP/0"), the client MAY choose one randomly per OS standard rules. + Client ports inside the SDP must always be matched against actual + received port values on the server side in order to deal with NAT/ + NAPT devices. If a zero value or incorrect value is present, the + server must set the value to the received origin port in the next + message with SDP (200 OK, ALERT, and CANCEL messages). + + Attribute values: + <"q4s"|"app"> <"serverListeningPort"|"clientListeningPort"> + <"UDP"|"TCP"> <0..65535> [ "-" [0..65535]] + +7.2.11. "measurement" Attributes + + These attributes contain the measurement procedure and the results of + the quality measurements. + + Measurement parameters are included using the session attribute + "measurement". The first measurement parameter is the procedure. + Q4S provides a "default" procedure for measurements, but others like + RTP/RTCP might be used and defined later. This document will only + define and explain the "default" procedure. + + In the initial client request, a set of measurement procedures can be + sent to the server for negotiation. One measurement procedure line + MUST be included in the SDP message for each proposed method. The + server MUST answer with only one line with the chosen procedure. + + For each procedure, a set of values of parameters separated by "," + can be included in the same attribute line. The amount and type of + parameters depends on the procedure type. + + In the following example, the "default" procedure type is chosen: + + a=measurement:procedure default(50/50,75/75,5000,40/80,100/256) + + In the "default" procedure, the meaning of these parameters is the + following: + + * The first parameter is the interval of time (in milliseconds) + between PING requests during the Negotiation phase. Uplink and + downlink values from the client's point of view are separated by + "/". This allows different responsiveness values depending on the + control resources used in each direction. + + * The second parameter is the time interval (in milliseconds) + between PING requests during the Continuity phase. Uplink and + downlink values are separated by "/". This allows two different + responsiveness values depending on the control resources used in + each direction. + + * The third parameter is the time interval to be used to measure + bandwidth during the Negotiation phase. + + * The fourth parameter indicates the window size for jitter and + latency calculations. Uplink and downlink values are separated by + "/". + + * The fifth parameter indicates the window size for packet loss + calculations. Uplink and downlink values are separated by "/". + + There are four more "measurement" attributes: + + a=measurement:latency 45 + a=measurement:jitter 3/12 + a=measurement:bandwidth 200/9800 + a=measurement:packetloss 0.00/1.00 + + The "measurement:latency", "measurement:jitter", + "measurement:bandwidth", and "measurement:packetloss" attributes + contain the values measured for each of these quality parameters in + uplink and downlink directions. Notice that latency is considered + equal for uplink and downlink directions. Quality parameter values + in these "measurement" attributes provide a snapshot of the quality + reached and MUST only be included in Q4S-ALERT messages in the SDP + body such that they can be protected from malicious attacks as these + alerts include a signature of the SDP body in the header. The rest + of the messages will include the measured values in the Measurements + header field. + + In the case of the "default" procedure, the valid values are as + follows: + + a=measurement:procedure default,[0..999]"/" [0..999] "," [0..999] + "/" [0..999] "," [0..9999] "," [0..999]/[0..999] "," + [0..999]/[0..999] + +7.2.12. "max-content-length" Attribute + + The adaptation of measurement traffic to approximate the actual data + streams' characteristics is convenient to accurately estimate the + expected QoS for applications. Particularly, packet size can have a + remarkable effect on bandwidth estimations. Moreover, this can + produce problems depending on the MTU of the end hosts and links + along the path. + + Therefore, the maximum content length MAY be set in an attribute + denoted as "max-content-length". Its value MUST be given in bytes + and MUST NOT include application, transport, network, or link layer + headers, i.e., size of the content length at the application layer. + If not set, the value MUST be 1000 bytes. + + Furthermore, this attribute MAY be used to communicate MTU limits in + endpoints, hence reducing possible bias as a result of network-layer + fragmentation. + + For instance: + + a=max-content-length:1300 + +7.3. Measurements + + This section describes the way quality parameters are measured as + defined by the "default" procedure. Measurements MUST be taken for + any quality parameter with constraints, that is, specified in the SDP + attributes with non-zero values. For absent attributes, measurements + MAY be omitted. + +7.3.1. Latency + + Latency measurements will be performed if the "latency" attribute + and/or the "a=measurement:latency" attribute are present and have + non-zero values. + + Q4S defines a PING method in order to exchange packets between the + client and the server. Based on this PING exchange, the client and + the server are able to calculate the round-trip time (RTT). The RTT + is the sum of downlink latency (normally named "reverse latency") and + uplink latency (normally named "forward latency"). + + At least 255 samples of RTT MUST be taken by the client and server. + As the forward and reverse latencies are impossible to measure, the + client and server will assume that both latencies are identical + (symmetric network assumption). The latency will therefore be + calculated as the statistical median value of all the RTT samples + divided by 2. + +7.3.2. Jitter + + Jitter measurements will be performed if the "jitter" attribute and/ + or the "a=measurement:jitter" attribute are present and have non-zero + values. + + The jitter can be calculated independently by the client and by the + server. The downlink jitter is calculated by the client taking into + account the time interval between PING requests as defined by the + "measurement:procedure" attribute in the first or second parameter + depending on the Q4S protocol phase. The client and the server MUST + send these PING requests at the specified intervals. The client + measures the downlink jitter, whereas the server measures the uplink + jitter. Note that PING responses are not taken into account when + calculating jitter values. + + Every time a PING request is received by an endpoint (either server + or client), the corresponding jitter value is updated with the + statistical jitter value, which is the arithmetic mean of the + absolute values of elapsed times calculated on the first 255 packets + received. + + Each endpoint sends a PING periodically with a fixed interval, and + each value of "elapsed time" (ET) should be very close to this + interval. If a PING message is lost, the ET value is doubled. + Identifying lost PING messages, however, is not an issue because all + PING messages are labeled with a Sequence-Number header field. + Therefore, the receiver can discard this ET value. + + In order to have the first jitter sample, the receiver MUST wait + until it receives 3 PING requests, because each ET is the time + between two PINGs, and a jitter measurement needs at least two ET. + + The client measures the values of RTT and downlink jitter, and the + server measures RTT and uplink jitter, but all measurements are + shared with the counterpart by means of the Measurements header field + of the PING message. + +7.3.3. Bandwidth + + Bandwidth measurements will be performed if the "bandwidth" attribute + and/or the "a=measurement:bandwidth" attribute is present and has + non-zero values. + + In order to measure the available bandwidth, both the client and the + server MUST start sending BWIDTH messages simultaneously using the + UDP control ports exchanged during the Handshake phase in the SDP + message at the needed rate to verify the availability of the + bandwidth constraint in each direction. The messages are sent during + the period of time defined in the third parameter of the SDP + "measurement:procedure default" attribute in milliseconds. + + a=measurement:procedure default(50/50,75/75,5000,256/256,256/256) + + +------------------------------------------------+ + | Rate | + | A | + | | | + |downlink rate-|-------------------+ <-- traffic | + | | | sent by | + | | | server | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | uplink rate-|-------------------+ <-- traffic | + | | | sent by | + | | | client | + | | | | + | | | | + | |---|---|---|---|---|----> time | + | 0 1 2 3 4 5 (sec.) | + | | + +------------------------------------------------+ + + Figure 6: Bandwidth and Packet Loss Measurements + + The goal of these measurements is not to identify the available + bandwidth of the communication path, but to determine if the required + bandwidth is available, meeting the application's constraints. + Therefore, the requested bandwidth MUST be measured sending only the + highest bitrate required by the bandwidth attribute. This is + illustrated in Figure 6. + + ALERTS are not expected during bandwidth measurement, but only at the + end of the measurement time. + + When measuring bandwidth, all BWIDTH requests sent MUST be 1 kilobyte + in length (UDP payload length by default), they MUST include a + Sequence-Number header field with a sequential number starting at 0, + and their content MUST consist of randomly generated values to + minimize the effect of compression elements along the path. The + Sequence-Number MUST be incremented by 1 with each BWIDTH packet + sent. If any measurement stage needs to be repeated, the sequence + number MUST start at zero again. BWIDTH requests MUST NOT be + answered. Examples: + + Client message: + ========================= + BWIDTH q4s://www.example.com Q4S/1.0 + User-Agent: q4s-ua-experimental-1.0 + Session-Id: 53655765 + Sequence-Number: 0 + Content-Type: text + Content-Length: XXXX + Measurements: l=22, j=10, pl=0.00, bw=3000 + + VkZaU1FrNVZNVlZSV0doT1ZrZ (to complete up to "max-content- + length" bytes UDP payload length) + ========================= + + The client MUST send BWIDTH packets to the server to allow the server + to measure the uplink bandwidth. The server MUST send BWIDTH packets + to the client to allow the client to measure the downlink bandwidth. + + Server message: + ========================= + BWIDTH q4s://www.example.com Q4S/1.0 + Session-Id: 53655765 + Sequence-Number: 0 + Content-Type: text + Content-Length: XXXX + Measurements: l=22, j=7, pl=0.00, bw=200 + + ZY0VaT1ZURlZVVmhyUFE9PQ (to complete up to max-content- + length UDP payload length) + ========================= + +7.3.4. Packet Loss + + Packet loss and bandwidth are measured simultaneously using the + BWIDTH packets sent by both the client and the server. Because the + BWIDTH packets contain a Sequence-Number header field incremented + sequentially with each sent packet, lost packets can be easily + identified. The lost packets MUST be counted during the measurement + time. + +7.4. Handshake Phase + + The first phase consists of a Q4S BEGIN method issued from the client + to the server as shown in Figure 7. + + The first Q4S message MUST have a special URI [RFC3986], which forces + the use of the Q4S protocol if it is implemented in a standard web + browser. + + This URI, named "Contact URI", is used to request the start of a + session. Its scheme MUST be: + + "q4s:" "//" host [":" port] [path["?" query] + + Optionally, the client can send the desired quality parameters + enclosed in the body of the message as an SDP document. The server + MAY take them into account when building the answer message with the + final values in the SDP body, following a request/response schema + [RFC3264]. + + If the request is accepted, the server MUST answer it with a Q4S 200 + OK message, which MUST contain an SDP body [RFC4566] with the + assigned sess-id (embedded in the SDP "o=" line), the IP addresses to + be used, the flow ports to be used, the measurement procedure to be + followed, and information about the required quality constraints. + Additionally, the "alerting-mode" and "alert-pause" time attributes + may be included. Q4S responses should use the protocol designator + "Q4S/1.0". + + After these two messages are exchanged, the first phase is completed. + The quality parameter thresholds have been sent to the client. The + next step is to measure the actual quality of the communication path + between the client and the server and alert if the Service Level + Agreement (SLA) is being violated. + + +------------------------------------------------+ + | | + | Client Server | + | | + | ------- Q4S BEGIN ------------> | + | | + | <------ Q4S 200 OK ------------ | + | | + | | + +------------------------------------------------+ + + Figure 7: Handshake Phase + + The following is an example of a client request and a server answer: + + Client Request: + ========================= + BEGIN q4s://www.example.com Q4S/1.0 + Content-Type: application/sdp + User-Agent: q4s-ua-experimental-1.0 + Content-Length: 142 + + (SDP not shown) + ========================= + + Server Answer: + ========================= + Q4S/1.0 200 OK + Date: Mon, 10 Jun 2010 10:00:01 GMT + Content-Type: application/sdp + Expires: 3000 + Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 + Content-Length: 131 + + (SDP not shown) + ========================= + + The header fields used are explained in Section 4.3. + +7.5. Negotiation Phase + + The Negotiation phase is in charge of measuring the quality + parameters and verifying that the communication paths meet the + required quality constraints in both directions as specified in the + SDP body. + + The measured parameters will be compared with the quality constraints + specified in the SDP body. If the quality session is compliant with + all the quality constraints, the application can start. + + If the quality constraints are not met, a higher quality service + level will be demanded. Depending on the scenario, this quality + upgrade will be managed as follows: + + In the Q4S-aware-network scenario: a Q4S-ALERT method will be + triggered by the server to the client, and the client will answer + with the same Q4S-ALERT method. After receiving the same Q4S- + ALERT from the counterpart, no other alerts will be triggered by + the server during the "alert-pause" period of time in order to + allow the network to react, but measurements will continue to be + taken to achieve early detection of improved network quality + conditions and a fast application start. + + In the Reactive scenario: an alert notification will be sent by the + server stack to the Actuator, and the Actuator will answer with an + alert acknowledgement. After receiving the alert acknowledgement + from the Actuator, the server stack will not send other alert + notifications during the "alert-pause" period of time in order to + allow the Actuator to react and trigger actions on the application + or on the policy server, but measurements will continue to be + taken to achieve early detection of improved network quality + conditions and a fast application start. + + In both scenarios stated above, if after several measurement cycles, + the network constraints cannot be met, the quality session is + terminated. Concretely when, under all possible actions taken by + Actuator, the quality remains below requirements, the session must be + terminated. + + The steps to be taken in this phase depend on the measurement + procedure exchanged during the Handshake phase. This document only + describes the "default" procedure, but others can be used, like RTP/ + RTCP [RFC3550]. + + Measurements of latency and jitter are made by calculating the + differences in the arrival times of packets and can be achieved with + little bandwidth consumption. The bandwidth measurement, on the + other hand, involves higher bandwidth consumption in both directions + (uplink and downlink). + + To avoid wasting unnecessary network resources, these two types of + measurements will be performed in two separate stages. If the + required latencies and jitters cannot be reached, it makes no sense + to waste network resources measuring bandwidth. In addition, if + achieving the required latency and jitter thresholds implies + upgrading the quality session level, the chance of obtaining + compliant bandwidth measurements without retries is higher, saving + network traffic again. Therefore, the "default" procedure determines + that the measurements are taken in two stages: + + Stage 0: Measurement of latencies, jitters, and packet loss + + Stage 1: Measurement of bandwidths and packet loss + + Notice that packet loss can be measured in both stages, as all + messages exchanged include a Sequence-Number header field that allows + for easy packet loss detection. + + The client starts the Negotiation phase by sending a READY request + using the TCP Q4S ports defined in the SDP. This READY request + includes a Stage header field that indicates the measurement stage. + + If either jitter, latency, or both are specified, the Negotiation + phase begins with the measurement of latencies and jitters (stage 0). + If none of those attributes is specified, stage 0 is skipped. + +7.5.1. Stage 0: Measurement of Latencies and Jitter + + The Stage 0 MUST start with a synchronization message exchange + initiated with the client's READY message. + + Client Request, READY message: + ========================= + READY q4s://www.example.com Q4S/1.0 + Stage: 0 + Session-Id: 53655765 + User-Agent: q4s-ua-experimental-1.0 + Content-Length: 0 + ========================= + + Server Response: + ========================= + Q4S/1.0 200 OK + Session-Id: 53655765 + Stage:0 + Content-Length: 0 + ========================= + + This triggers the exchange of a sequence of PING requests and + responses that will lead to the calculation of RTT (latency), jitter, + and packet loss. + + After receiving a 200 OK, the client must send the first PING + message, and the server will wait to send PINGs until the reception + of this first client PING. + + The client and server MUST send PING requests to each other. The + Sequence-Number header field of the first PING MUST be set to 0. The + client and server will manage their own sequence numbers. + + +------------------------------------------------+ + | | + | Client Server | + | | + | --------- Q4S READY 0 ---------> | + | <-------- Q4S 200 OK ----------- | + | | + | --------- Q4S PING ------------> | + | <-------- Q4S 200 OK ----------- | + | <-------- Q4S PING ------------- | + | -------- Q4S 200 OK ----------> | + | --------- Q4S PING ------------> | + | <-------- Q4S PING ------------- | + | --------- Q4S 200 OK ----------> | + | <-------- Q4S 200 OK ----------- | + | ... | + | | + +------------------------------------------------+ + + Figure 8: Simultaneous Exchange of PING Request and Responses + + The following is an example of the PING request sent from the client + and the server's response: + + Client Request: + ========================= + PING q4s://www.example.com Q4S/1.0 + Session-Id: 53655765 + Sequence-Number: 0 + User-Agent: q4s-ua-experimental-1.0 + Measurements: l=22, j=12, pl=0.20, bw= + Content-Length: 0 + ========================= + + Server Response: + ========================= + Q4S/1.0 200 OK + Session-Id: 53655765 + Sequence-Number: 0 + Content-Length: 0 + ========================= + + The function of the PING method is similar to the ICMP echo request + message [RFC0792]. The server MUST answer as soon as it receives the + message. + + Both endpoints MUST send Q4S PING messages with the periodicity + specified in the first parameter of SDP "measurement:procedure" + attribute, always using the same UDP ports and incrementing the + Sequence-Number with each message. + + In the following example, the value of the first parameter of the SDP + "measurement:procedure" attribute is 50 milliseconds (from the client + to the server) and 60 ms (from the server to the client): + + a=measurement:procedure default(50/60,50/50,5000,256/256,256/256) + + They MUST NOT wait for a response to send the next PING request. The + Sequence-Number header field value is incremented sequentially and + MUST start at zero. If this stage is repeated, the initial Sequence- + Number MUST start at zero again. + + All PING requests MUST contain a Measurements header field with the + values of the latency, jitter, and packet loss measured by each + entity up to that moment. The client will send its measurements to + the server, and the server will send its measurements to the client. + Example: + + Measurements: l=22, j=13, pl=0.10, bw= + + Where "l" stands for latency, "j" for jitter, "pl" for packet loss, + and "bw" for bandwidth. The bandwidth value is omitted, as it is not + measured at this stage. + + Optionally the PING request can include a Timestamp header field with + the time in which the message has been sent. In the case that the + header field is present, the server MUST include the header field in + the response without changing the value. + + A minimum number of PING messages MUST be exchanged in order to be + able to measure latency, jitter, and packet loss with certain + accuracy (at least 256 samples are RECOMMENDED to get an accurate + packet loss measurement). Both the client and the server calculate + the respective measured parameter values. The mechanisms to + calculate the different parameters are described in Section 7.3. + + At the end of this stage 0, there are three possibilities: + + * The latency, jitter, and packetloss constraints are reached in + both directions + + * The latency, jitter, and packetloss constraints are not reached in + one or both directions + + In the first case, Stage 0 is finished. The client and server are + ready for Stage 1: bandwidth and packet loss measurement. The client + moves to stage 1 by sending a READY message that includes the header + field, "Stage: 1". + + If the bandwidth constraints are either empty or have a value of + zero, the Negotiation phase MUST terminate, and both client and + server may initiate the Continuity phase. In this case, client moves + to the Continuity phase by sending a READY message that includes the + header field, "Stage: 2". + + The second case, in which one or more quality constraints have not + been met, is detailed in Section 7.5.4. + +7.5.2. Stage 1: Measurement of Bandwidth and Packet Loss + + This stage begins in a similar way to stage 0, sending a READY + request over TCP. The value of the READY message's Stage header + field is 1. The server answers with a Q4S 200 OK message to + synchronize the initiation of the measurements as shown in Figure 9. + + +------------------------------------------------+ + | | + | Client Server | + | | + | --------- Q4S READY 1 -----------> | + | <-------- Q4S 200 OK ------------- | + | | + | --------- Q4S BWIDTH -----------> | + | <-------- Q4S BWIDTH ------------ | + | --------- Q4S BWIDTH -----------> | + | <-------- Q4S BWIDTH ------------ | + | ... | + | | + +------------------------------------------------+ + + Figure 9: Starting Bandwidth and Packet Loss Measurement + + Client Request: + ========================= + READY q4s://www.example.com Q4S/1.0 + User-Agent: q4s-ua-experimental-1.0 + Stage: 1 + Session-Id: 53655765 + Content-Length: 0 + + ========================= + + Server Response: + ========================= + Q4S/1.0 200 OK + Session-Id: 53655765 + Stage: 1 + Content-Length: 0 + + ========================= + + Just after receiving the 200 OK, both the client and the server MUST + start sending BWIDTH messages simultaneously using the UDP "q4s" + ports. Section 7.3.3 describes the bandwidth measurement in detail. + + At the end of this stage 1, there are three possibilities: + + * The bandwidth and packetloss constraints are reached in both + directions. + + * The bandwidth and packetloss constraints are not reached in one or + both directions. + + In the first case, Stage 1 is finished. The client and server are + ready for the Continuity phase. The client moves to this phase by + sending a READY message that includes the header field, "Stage: 2". + The server answer MUST be 200 OK as shown in Figure 10. + + +------------------------------------------------+ + | | + | Client Server | + | | + | --------- Q4S READY 2 --------------> | + | <---- Q4S 200 OK with trigger URI----- | + | | + | --------- HTTP GET ----------------> | + | | + | (Application starts) | + | | + +------------------------------------------------+ + + Figure 10: Trigger the Application Using HTTP URI + + Client Request: + ========================= + READY q4s://www.example.com Q4S/1.0 + User-Agent: q4s-ua-experimental-1.0 + Stage: 2 + Session-Id: 53655765 + Content-Length: 0 + + ========================= + + Server Answer: + ========================= + Q4S/1.0 200 OK + Date: Mon, 10 Jun 2010 10:00:01 GMT + Session-Id: 53655765 + Trigger-URI: http://www.example.com/app_start + Expires: 3000 + Content-Type: application/sdp + Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 + Content-Length: 131 + + (SDP not shown) + ========================= + + If the Trigger-URI header field is present, the client SHOULD send an + HTTP request to this URI. + + The second case, with violated network constraints, is explained in + Section 7.5.4. + +7.5.3. Quality Constraints Not Reached + + After finishing Stage 1 of the Negotiation phase, the client and the + server have each other's measured parameter values as these have been + exchanged in the Measurements header fields of the PING and BWIDTH + messages. If there is one or more parameters that do not comply with + the uplink or downlink application constraints required, both the + server and the client are aware of it. + + If there is any quality parameter that does not meet the uplink or + downlink quality constraints specified in the SDP message, two + scenarios are possible depending on the specified alerting mode (if + not present, the default value is Reactive alerting mode): + + (a) Q4S-aware-network alerting mode: the server MUST send a Q4S- + ALERT message to the client including the digital Signature + header field, and the client MUST answer with the same Q4S-ALERT + message. The Signature header field contains the signed hash + value of the SDP body in order to protect all the SDP data, and + therefore it MUST contain the "measurement" parameters in the + body. + + Server request + ========================= + Q4S-ALERT q4s://www.example.com Q4S/1.0 + Host: www.example.com + User-Agent: q4s-ua-experimental-1.0 + Session-Id: 53655765 + Content-Type: application/sdp + Content-Length: 142 + + v=0 + o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33 + s=Q4S + i=Q4S parameters + t=0 0 + a=qos-level:1/2 + a=alerting-mode: Q4S-aware-network + a=alert-pause:5000 + a=public-address:client IP4 198.51.100.51 + a=public-address:server IP4 198.51.100.58 + a=latency:40 + a=jitter:10/10 + a=bandwidth:20/6000 + a=packetloss:0.50/0.50 + a=flow:app downlink TCP/10000-20000 + a=flow:app uplink TCP/56000 + a=flow:q4s downlink UDP/55000 + a=flow:q4s downlink TCP/55001 + a=flow:q4s uplink UDP/56000 + a=flow:q4s uplink TCP/56001 + a=measurement:procedure default(50/50,50/50,5000,256/256,256/256) + a=measurement:latency 30 + a=measurement:jitter 6/4 + a=measurement:bandwidth 200/4000 + a=measurement:packetloss 0.20/0.33 + ========================= + + At this point, both the client and server keep on measuring but + without sending new Q4S-ALERT messages during the "alert-pause" + milliseconds. + + (b) Reactive alerting mode: the server stack MUST send an alert + notification to the Actuator, and the Actuator MUST answer with + an acknowledgement to the received alert notification. The + alert notification sent to the Actuator by the server stack + doesn't follow Q4S message style but should have all the + information the Actuator will need for the actions to be taken, + which will be implementation dependent. + + At this point during Negotiation phase, both the client and server + keep on measuring without sending new alert notifications to the + Actuator during the "alert-pause" milliseconds specified in the SDP. + This way, both client and server will detect any improvement in + network conditions as soon as the network reacts. The application + can start as soon as the number of measurements indicated in the + "measurement:procedure" attribute indicates that the quality + parameters are met. + + The same applies to Continuity phase: the measurement dialog between + client and server must not be interrupted by any possible ALERT + message. + +7.5.3.1. Actuator Role + + The actuator receives notifications of unmet requirements from the + Q4S server stack and acts upon the application or the network policy + server, according to logic out of scope of this protocol. + + The Actuator logic activates mechanisms at the application level and/ + or the network level based on a quality level dictionary, in which + the meaning of each level is implementation dependent, and each level + involves different actions based on rules to keep a certain user + experience quality. + + The type of actions that an Actuator can take at the application + level are application dependent and MAY involve: + + * Reduction of application functionalities, such as limitation of + application speed or application options. + + * Reduction of application resources usage, such as reduction of + frames per second in a video application or any other parameter + modification in order to adapt to network conditions. + + Apart from actions at the application level, the Actuator MAY act at + the network level if a network policy server is available. + +7.5.3.2. Policy Server Role + + A network policy server may be part of the Reactive scenario, and it + is in charge of managing network quality provision. A network policy + server may implement all or some of these features (but + implementation is not exclusive to): + + * Server validation in terms of quality constraints + + * Authentication (Signature validation) and security (blocking of + malicious clients) + + * Policy rules (the following rules are only examples): + + - Maximum quality level allowed for the ACP + + - Time bands allowed for providing quality sessions + + - Number of simultaneous quality sessions allowed + + - Maximum time used by allowed quality sessions + + - Etc. + + If any of the policy rules fail, a Q4S-ALERT message MUST be answered + by a 6xx error indicating the cause. + +7.5.4. "qos-level" Changes + + If any constraint was violated, the server MAY trigger a Q4S-ALERT + asking for a higher "qos-level" attribute. The maximum "qos-level" + allowed is 9 for both uplink and downlink. + + If the "qos-level" has reached the maximum value for the downlink or + uplink without matching the constraints, then a CANCEL request MUST + be sent by the client using the TCP port determined in the Handshake + phase in order to release the session. In reaction to the reception + of the CANCEL request, the server MUST send a CANCEL request, too. + If no CANCEL request is received, the expiration time cancels the + session on the server side. + + Client Request: + ========================= + CANCEL q4s://www.example.com Q4S/1.0 + User-Agent: q4s-ua-experimental-1.0 + Session-Id: 53655765 + Content-Type: application/sdp + Content-Length: 142 + + (SDP not shown) + ========================= + + Server Request in reaction to Client Request: + ========================= + CANCEL q4s://www.example.com Q4S/1.0 + Session-Id: 53655765 + Expires: 0 + Content-Type: application/sdp + Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 + Content-Length: 131 + + (SDP not shown) + ========================= + +7.6. Continuity Phase + + During the Negotiation phase, latency, jitter, bandwidth, and packet + loss have been measured. During the Continuity phase, bandwidth will + not be measured again because bandwidth measurements may disturb + application performance. + + This phase is supposed to be executed at the same time as the real- + time application is being used. + + This document only covers the "default" procedure. The continuity + operation with the "default" procedure is based on a sliding window + of samples. The number of samples involved in the sliding window may + be different for jitter and latency than for packet loss calculations + according to the fifth and sixth parameters of the + "measurement:procedure" attribute. In the example, shown in + Figure 11, the jitter and latency sliding window comprises 40 + samples, whereas the size of the packet loss sliding window is 100 + samples: + + a=measurement:procedure default(50/50,75/75,5000,40/40,100/100) + + In addition, the sizes of these windows are configurable per + direction: uplink and downlink values may differ. + + PING requests are sent continuously (in both directions), and when + the Sequence-Number header field reaches the maximum value, the + client continues sending PING messages with the Sequence-Number + header field starting again at zero. When the server PING Sequence- + Number header field reaches the maximum value, it does the same, + starting again from zero. + + On the client side, the measured values of downlink jitter, downlink + packet loss, and latency are calculated using the last samples, + discarding older ones, in a sliding window schema. + + +--------------------------------------------------+ + | | + | 55 56 57 . . . 253 254 255 0 1 2 . . . 55 56 | + | A A | + | | | | + | +-----------------------------------+ | + | | + +--------------------------------------------------+ + + Figure 11: Sliding Samples Window + + Only if the server detects that the measured values (downlink or + uplink jitter, packet loss, or latency) are not reaching the quality + constraints, a Q4S-ALERT is triggered and sent either to the client + or to the Actuator, depending on the alerting mode, and the "alert- + pause" timer is started. + + In the Q4S-aware-network alerting mode shown in Figure 12, if the + client receives a Q4S-ALERT message, it MUST answer by sending the + Q4S-ALERT request message including the SDP (with its corresponding + digital signature) back to the server. + + Both client and server will keep performing measurements, but Q4S- + ALERT messages MUST NOT be sent during "alert-pause" milliseconds. + The operations needed to act on the network and the agents in charge + of them are out of scope of this document. + + +------------------------------------------------+ + | | + | Client Server | + | | + | ... | + | ----------- PING ----------> | + | <--------- 200 OK ---------- | + | <------- Q4S-ALERT --------- | + | -------- Q4S-ALERT --------> | + | <---------- PING ----------- | + | ---------- 200 OK ---------> | + | ----------- PING ----------> | + | <--------- 200 OK ---------- | + | <---------- PING ----------- | + | ---------- 200 OK ---------> | + | ... | + | | + +------------------------------------------------+ + + Figure 12: Continuity in Q4S-Aware-Network Alerting Mode + + In the Reactive scenario shown in Figure 13, if the server detects + that the measured values (downlink or uplink jitter, packet loss, or + latency) are not reaching the quality constraints, an alert + notification is triggered and sent to the Actuator. The Actuator + MUST then answer to the server stack with an alert acknowledgement. + + The measurement dialog between the client and the server MUST NOT be + interrupted by any possible ALERT message. + + +------------------------------------------------+ + | | + | Client Server Actuator | + | ... | + | --- PING ----------> | + | <-- 200 OK---------- | + | <----- PING -------- | + | <--- 200 OK -------- ---- alert | + | notification --> | + | | + | --- PING ----------> <--- alert | + | acknowledge --- | + | <-- 200 OK---------- | + | <----- PING -------- | + | --- 200 OK --------> | + | ... | + | | + +------------------------------------------------+ + + Figure 13: Continuity in Reactive Alerting Mode + +7.7. Termination Phase + + The Termination phase is the endpoint for the established Q4S session + that is reached in the following cases: + + * A CANCEL message has been received. The client sends a CANCEL + message due to the network's inability to meet the required + quality constraints. The client and server application will be + notified by their respective Q4S stacks. + + * Session expires: if after the Expires time, no client or server + activity is detected, that end cancels the session. + + * A BEGIN message has been received by the server. The pre-existing + Q4S quality session is canceled, and a new session will be + initiated. + + The meaning of the Termination phase in terms of the release of + resources or accounting is application dependent and out of scope of + the Q4S protocol. + + In the Reactive alerting mode, Q4S CANCEL messages received by the + Q4S server must cause the server stack to send cancel notifications + to the Actuator in order to release possible assigned resources for + the session. + +7.7.1. Sanity Check of Quality Sessions + + A session may finish due to several reasons (client shutdown, client + CANCEL request, constraints not reached, etc.), and any session + finished MUST release the assigned resources. + + In order to release the assigned server resources for the session, + the Expires header field indicates the maximum interval of time + without exchanging any Q4S message. + +7.8. Dynamic Constraints and Flows + + Depending on the nature of the application, the quality constraints + to be reached may evolve, changing some or all quality constraint + values in any direction. + + The client MUST be able to deal with this possibility. When the + server sends an SDP document attached to a response (200 OK or Q4S- + ALERT, etc.), the client MUST take all the new received values, + overriding any previous value in use. + + The dynamic changes on the quality constraints can be a result of two + possibilities: + + * The application communicates to the Q4S server a change in the + constraints. In this case, the application requirements can + evolve, and the Q4S server will be aware of them. + + * The application uses TCP flows. In that case, in order to + guarantee a constant throughput, the nature of TCP behavior forces + the use of a composite constraint function, which depends on RTT, + packet loss, and a window control mechanism implemented in each + TCP stack. + + TCP throughput can be less than actual bandwidth if the Bandwidth- + Delay Product (BDP) is large, or if the network suffers from a high + packet loss rate. In both cases, TCP congestion control algorithms + may result in a suboptimal performance. + + Different TCP congestion control implementations like Reno [RENO], + High Speed TCP [RFC3649], CUBIC [CUBIC], Compound TCP (CTCP) [CTCP], + etc., reach different throughputs under the same network conditions + of RTT and packet loss. In all cases, depending on the RTT-measured + value, the Q4S server could dynamically change the packetloss + constraints (defined in the SDP) in order to make it possible to + reach a required throughput or vice versa (using + "measurement:packetloss" to change dynamically the latency + constraints). + + A general guideline for calculating the packet loss constraint and + the RTT constraint consists of approximating the throughput by using + a simplified formula, which should take into account the TCP stack + implementation of the receiver, in addition to the RTT and packet + loss: + + Th= Function( RTT, packet loss, ...) + + Then, depending on RTT-measured values, set dynamically the packet + loss constraint. + + It is possible to easily calculate a worst-case boundary for the Reno + algorithm, which should ensure for all algorithms that the target + throughput is actually achieved, except that high-speed algorithms + will then have even larger throughput if more bandwidth is available. + + For the Reno algorithm, the Mathis formula may be used [RENO] for the + upper bound on the throughput: + + Th <= (MSS/RTT)*(1 / sqrt{p}) + + In the absence of packet loss, a practical limit for the TCP + throughput is the receiver_window_size divided by the RTT. However, + if the TCP implementation uses a window scale option, this limit can + reach the available bandwidth value. + +7.9. "qos-level" Upgrade and Downgrade Operation + + Each time the server detects a violation of constraints, the alert + mechanism is triggered, the "alert-pause" timer is started, and the + "qos-level" is increased. When this happens repeatedly, and the + "qos-level" reaches its maximum value (value 9), the session is + canceled. But when the violation of constraints stops before + reaching "qos-level" maximum value, the recovery mechanism allows for + the "qos-level" upgrade gradually. + + This downgrade and upgrade of "qos-level" is explained with the + following example: + + 1. A Q4S session is initiated successfully with "qos-level=0". + + 2. During the Continuity phase, violation of constraints is + detected; the "qos-level" is increased to 1, a Q4S-ALERT is sent + by the server to the client, and an "alert-pause" timer is + started. + + 3. The "alert-pause" timer expires, and still a violation of + constraints is detected; the "qos-level" is increased to 2, a + Q4S-ALERT is sent by the server to the client, and an "alert- + pause" timer is started. + + 4. The "alert-pause" timer expires, but the violation of constraints + has stopped; the "recovery-pause" timer is started. + + 5. The "recovery-pause" timer expires, and no violation of + constraints has been detected. Meanwhile, the "qos-level" is + decreased to 1, a Q4S-RECOVERY is sent by the server to the + client, and the "recovery-pause" timer is started again. + + 6. The "recovery-pause" timer expires again, and no violation of + constraints has been detected. Meanwhile, the "qos-level" is + decreased to 0, and a Q4S-RECOVERY is sent by the server to the + client. The "recovery-pause" timer is not started this time as + the "qos-level" has reached its initial value. + + When the network configuration allows for the possibility of managing + Q4S flows and application flows independently (either is a network- + based QoS or a Q4S-aware network), the "qos-level" downgrade process + could be managed more efficiently using a strategy that allows for + carrying out "qos-level" downgrades excluding application flows from + SDP dynamically. The Q4S flows would be downgraded to allow for + measurements on a lower quality level without interference of the + application flows. A Q4S client MUST allow this kind of SDP + modification by the server. + + Periodically (every several minutes, depending on the implementation) + a Q4S-ALERT could be triggered, in which the level is downgraded for + Q4S flows, excluding application flows from the embedded SDP of that + request. + + This mechanism allows the measurement at lower levels of quality + while application flows continue using a higher "qos-level" value. + + * If the measurements in the lower level meet the quality + constraints, then a Q4S-RECOVERY message to this lower "qos-level" + may be triggered, in which the SDP includes the application flows + in addition to the Q4S flows. + + * If the measurements in the lower level do not meet the + constraints, then a new Q4S-ALERT to the previous "qos-level" MUST + be triggered, in which the SDP includes only the Q4S flows. + + +------------------------------------------------+ + | | + | qos-level | + | A | + | | | + | 4| | + | | | + | 3| +------+ | + | | | | | + | 2| +----+ +----+ +--- | + | | | | | | + | 1| +----+ +-----+ | + | | | | + | 0+---+---------------------------------> time | + | | + +------------------------------------------------+ + + Figure 14: Possible Evolution of "qos-level" + + This mechanism, illustrated in Figure 14, avoids the risk of + disturbing the application while the measurements are being run in + lower levels. However, this optional optimization of resources MUST + be used carefully. + + The chosen period to measure a lower "qos-level" is implementation + dependent. Therefore, it is not included as a + "measurement:procedure" parameter. It is RECOMMENDED to use a large + value, such as 20 minutes. + +8. General User Agent Behavior + +8.1. Roles in Peer-to-Peer Scenarios + + In order to allow peer-to-peer applications, a Q4S User Agent (UA) + MUST be able to assume both the client and server role. The role + assumed depends on who sends the first message. + + In a communication between two UAs, the UA that first sends the Q4S + BEGIN request to start the Handshake phase shall assume the client + role. + + If both UAs send the BEGIN request at the same time, they will wait + for a random time to restart again as shown in Figure 15. + + Otherwise, an UA may be configured to act only as server (e.g., + content provider's side). + + +-----------------------------------------------+ + | | + | UA(Client) UA(Server) | + | | + | -------- Q4S BEGIN -------------> | + | <------- Q4S BEGIN -------------- | + | | + | ------- Q4S BEGIN --------------> | + | <------ Q4S 200 OK -------------- | + | | + | | + +-----------------------------------------------+ + + Figure 15: P2P Roles + +8.2. Multiple Quality Sessions in Parallel + + A Q4S session is intended to be used for an application. This means + that for using the application, the client MUST establish only one + Q4S session against the server. Indeed, the relation between the + Session-Id and the application is 1 to 1. + + If a user wants to participate in several independent Q4S sessions + simultaneously against different servers (or against the same + server), it can execute different Q4S clients to establish separately + different Q4S sessions, but it is NOT RECOMMENDED because: + + * The establishment of a new Q4S session may affect other running + applications over other Q4S sessions during bandwidth measurement. + + * If the Negotiation phase is executed separately before running any + application, the summation of bandwidth requirements could not be + met when the applications are running in parallel. + +8.3. General Client Behavior + + A Q4S client has different behaviors. We will use letters X, Y, and + Z to designate each different behavior (follow the letters in + Figure 16 and their descriptions below). + + X) When it sends messages over TCP (methods BEGIN, READY, Q4S-ALERT, + Q4S-RECOVERY, and CANCEL), it behaves strictly like a state + machine that sends requests and waits for responses. Depending + on the response type, it enters into a new state. + + When it sends UDP messages (methods PING and BWIDTH), a Q4S client is + not strictly a state machine that sends messages and waits for + responses because of the following: + + Y) During the measurement of latency, jitter, and packet loss, the + PING requests are sent periodically, not just after receiving the + response to the previous request. In addition, the client MUST + answer the PING requests coming from the server, therefore the + client assumes temporarily the role of a server. + + Z) During the bandwidth and packet loss measurement stage, the + client does not expect to receive responses when sending BWIDTH + requests to the server. In addition, it MUST receive and process + all server messages in order to achieve the downlink measurement. + + The Q4S-ALERT and CANCEL may have a conventional answer if an error + is produced, otherwise the corresponding answer is formatted as a + request message. + + +-----------+------------------------+-----------+-----------+ + | Handshake | Negotiation |Continuity |Termination| + | Phase | Phase | Phase | Phase | + | | | | | + | X ---------> Y --> X --> Z --> X ---> Y --> X ---> X | + | | A | A | | A | | | + | | | | | | | | | | | + | | +-----+ +-----+ | +-----+ | | + | | | | | + +------------------------------------------------+-----------+ + + Figure 16: Phases and Client Behaviors + +8.3.1. Generating Requests + + A valid Q4S request formulated by a client MUST, at a minimum, + contain the following header fields: + + If no SDP is included: the header fields Session-Id and Sequence- + Number are mandatory. + + If SDP is included: the Session-Id is embedded into the SDP, + therefore the inclusion of the Session-Id header field is + optional, but if present, must have the same value. Measurements + are embedded into the SDP only for Q4S-ALERT messages in order to + be signed. + + At any time, if the server sends new SDP with updated values, the + client MUST take it into account. + +8.4. General Server Behavior + + If a server does not understand a header field in a request (that is, + the header field is not defined in this specification or in any + supported extension), the server MUST ignore that header field and + continue processing the message. + + The role of the server is changed at Negotiation and Continuity + phases, in which the server MUST send packets to measure jitter, + latency, and bandwidth. Therefore, the different behaviors of the + server are (follow the letters in Figure 17 and their descriptions + below): + + R) When the client sends messages over TCP (methods BEGIN, READY + Q4S-ALERT, Q4S-RECOVERY, and CANCEL), it behaves strictly like a + state machine that receives messages and sends responses. + + When the client begins to send UDP messages (methods PING and + BWIDTH), a Q4S server is not strictly a state machine that receives + messages and sends responses because of the following: + + S) During the measurement of latency, jitter, and packet loss, the + PING requests are sent periodically by the client and also by the + server. In this case, the server behaves as a server answering + client requests but also behaves temporarily as a client, sending + PING requests toward the client and receiving responses. + + T) During bandwidth and packet loss measurement, the server sends + BWIDTH requests to the client. In addition, it MUST receive and + process client messages in order to achieve the uplink + measurement. + + The Q4S-ALERT and CANCEL may have a conventional answer if an error + is produced, otherwise the corresponding answer is formatted as a + request message. + + +-----------+------------------------+-----------+-----------+ + | Handshake | Negotiation |Continuity |Termination| + | Phase | Phase | Phase | Phase | + | | | | | + | R ---------> S --> R --> T --> R ---> S --> R ---> R | + | | A | A | | A | | | + | | | | | | | | | | | + | | +-----+ +-----+ | +-----+ | | + | | | | | + +------------------------------------------------+-----------+ + + Figure 17: Phases and Server Behaviors + +9. Implementation Recommendations + +9.1. Default Client Constraints + + To provide a default configuration, it would be good if the client + had a configurable set of quality headers in the implementation + settings menu. Otherwise, these quality headers will not be present + in the first message. + + Different business models (out of scope of this proposal) may be + achieved: depending on who pays for the quality session, the server + can accept certain client parameters sent in the first message, or + force billing parameters on the server side. + +9.2. Latency and Jitter Measurements + + Different client and server implementations may send a different + number of PING messages for measuring, although at least 255 messages + should be considered to perform the latency measurement. The Stage 0 + measurements may be considered ended only when neither the client nor + server receive new PING messages after an implementation-dependent + guard time. Only after, the client can send a "READY 1" message. + + In execution systems, where the timers are not accurate, a + recommended approach consists of including the optional Timestamp + header field in the PING request with the time in which the message + has been sent. This allows an accurate measurement of the jitter + even with no identical intervals of time between PINGs. + +9.3. Bandwidth Measurements + + In programming languages or operating systems with limited timers or + clock resolution, it is recommended to use an approach based on + several intervals to send messages of 1KB (= 8000 bits) in order to + reach the required bandwidth consumption, using a rate as close as + possible to a constant rate. + + For example, if the resolution is 1 millisecond, and the bandwidth to + reach is 11 Mbps, a good approach consists of sending: + + 1 message of 1KB every 1 millisecond + + + 1 message of 1KB every 3 milliseconds + + + 1 message of 1KB every 23 milliseconds + + The number of intervals depends on the required bandwidth and + accuracy that the programmer wants to achieve. + + Considering messages of 1KB (= 8000 bits), a general approach to + determine these intervals is the following: + + (1) Compute target bandwidth / 8000 bits. In the example above, it + is 11 Mbps / 8000 = 1375 messages per second. + + (2) Divide the number of messages per second by 1000 to determine + the number of messages per millisecond: 1375 / 1000 = 1.375. + The integer value is the number of messages per millisecond (in + this case, one). The pending bandwidth is now 375 messages per + second. + + (3) To achieve the 375 messages per second, use a submultiple of + 1000, which must be less than 375: + + 1000 / 2 = 500 > 375 + + 1000 / 3 = 333 < 375 + + In this case, a message every 3 ms is suitable. The new pending + target bandwidth is 375 - 333 = 42 messages per second. + + (4) Repeat the same strategy as point 3 to reach the pending + bandwidth. In this case, 23 ms is suitable because of the + following: + + 1000 / 22 = 45 > 42 + + 1000 / 23 = 43 > 42 + + 1000 / 24 = 41.6 < 42 + + We can choose 24 ms, but then we need to cover an additional 0.4 + messages per second (42 - 41.6 = 0.4), and 43 is a number higher than + 42 but very close to it. + + In execution systems where the timers are not accurate, a recommended + approach consists of checking at each interval the number of packets + that should have been sent at this timestamp since origin and send + the needed number of packets in order to reach the required + bandwidth. + + The shorter the packets used, the more constant the rate of bandwidth + measurement. However, this may stress the execution system in charge + of receiving and processing packets. As a consequence, some packets + may be lost because of stack overflows. To deal with this potential + issue, a larger packet is RECOMMENDED (2KB or more), taking into + account the overhead produced by the chunks' headers. + +9.4. Packet Loss Measurement Resolution + + Depending on the application nature and network conditions, a packet + loss resolution less than 1% may be needed. In such cases, there is + no limit to the number of samples used for this calculation. A + trade-off between time and resolution should be reached in each case. + For example, in order to have a resolution of 1/10000, the last 10000 + samples should be considered in the packet loss measured value. + + The problem of this approach is the reliability of old samples. If + the interval used between PING messages is 50 ms, then to have a + resolution of 1/1000, it takes 50 seconds, and a resolution of + 1/10000 takes 500 seconds (more than 8 minutes). The reliability of + a packet loss calculation based on a sliding window of 8 minutes + depends on how fast network conditions evolve. + +9.5. Measurements and Reactions + + Q4S can be used as a mechanism to measure and trigger network tuning + and application-level actions (i.e. lowering video bit-rate, reducing + multiplayer interaction speed, etc.) in real time in order to reach + the application constraints, addressing measured possible network + degradation. + +9.6. Instability Treatments + + There are two scenarios in which Q4S can be affected by network + problems: loss of Q4S packets and outlier samples. + +9.6.1. Loss of Control Packets + + Lost UDP packets (PING or BWIDTH messages) don't cause any problems + for the Q4S state machine, but if TCP packets are delivered too late + (which we will consider as "lost"), some undesirable consequences + could arise. + + Q4S does have protection mechanisms to overcome these situations. + Examples: + + * If a BEGIN packet or its corresponding answer is lost, after a + certain timeout, the client SHOULD resend another BEGIN packet, + resetting the session + + * If a READY packet is lost, after a certain timeout, the client + SHOULD resend another READY packet. + + * If a Q4S-ALERT request or its corresponding answer is lost, after + a certain timeout, the originator SHOULD resend another Q4S-ALERT + packet. + + * If a CANCEL request or its corresponding answer is lost, after a + certain timeout, the originator SHOULD resend another CANCEL + packet. + +9.6.2. Outlier Samples + + Outlier samples are those jitter or latency values far from the + general/average values of most samples. + + Hence, the Q4S default measurement method uses the statistical median + formula for latency calculation, and the outlier samples are + neutralized. This is a very common filter for noise or errors on + signal and image processing. + +9.7. Scenarios + + Q4S could be used in two scenarios: + + * client to ACP + + * client to client (peer-to-peer scenario) + +9.7.1. Client to ACP + + One server: + + It is the common scenario in which the client contacts the server to + establish a Q4S session. + + N servers: + + In Content Delivery Networks and in general applications where + delivery of contents can be achieved by different delivery nodes, two + working mechanisms can be defined: + + Starting mode: the end user may run Q4S against several delivery + nodes and after some seconds choose the best one to start the + multimedia session. + + Prevention mode: during a streaming session, the user keeps several + Q4S dialogs against different alternative delivery nodes. In case + of congestion, the end user MAY change to the best alternative + delivery node. + +9.7.2. Client to Client + + In order to solve the client-to-client scenario, a Q4S register + function MUST be implemented. This allows clients to contact each + other for sending the BEGIN message. In this scenario, the Register + server would be used by peers to publish their Q4S-Resource-Server + header and their public IP address to enable the assumption of the + server role. + + The register function is out of scope of this protocol version + because different HTTP mechanisms can be used, and Q4S MUST NOT force + any. + +10. Security Considerations + +10.1. Confidentiality Issues + + Because Q4S does not transport any application data, Q4S does not + jeopardize the security of application data. However, other certain + considerations may take place, like identity impersonation and + measurements privacy and integrity. + +10.2. Integrity of Measurements and Authentication + + Identity impersonation could potentially produce anomalous Q4S + measurements. If this attack is based on spoofing of the server IP + address, it can be avoided using the digital signature mechanism + included in the SDP. The network can easily validate this digital + signature using the public key of the server certificate. + + Integrity of Q4S measurements under any malicious manipulation (such + as a Man-in-the-Middle (MITM) attack) relies on the same mechanism, + the SDP signature. + + The Signature header field contains the signed hash value of the SDP + body in order to protect all the SDP data, including the + measurements. This signature not only protects the integrity of data + but also authenticates the server. + +10.3. Privacy of Measurements + + This protocol could be supported over IPsec. Q4S relies on UDP and + TCP, and IPsec supports both. If Q4S is used for application-based + QoS, then IPsec is operationally valid; however, if Q4S is used to + trigger network-based actions, then measurements could be incorrect + unless the IPsec ports can be a target of potential action over the + network (such as prioritizing IPsec flows to measure the new, + upgraded state of certain application flows). + +10.4. Availability Issues + + Any loss of connectivity may interrupt the availability of the Q4S + service and may result in higher packet loss measurements, which is + just the desired behavior in these situations. + + In order to mitigate availability issues caused by malicious attacks + (such as DoS and DDoS), a good practice is to enable the Q4S service + only for authenticated users. Q4S can be launched after the user is + authenticated by the application. At this moment, the user's IP + address is known, and the Q4S service may be enabled for this IP + address. Otherwise, the Q4S service should appear unreachable. + +10.5. Bandwidth Occupancy Issues + + Q4S bandwidth measurement is limited to the application needs. It + means that all available bandwidth is not measured, but only the + fraction required by the application. This allows other applications + to use the rest of available bandwidth normally. + + However, a malicious Q4S client could restart Q4S sessions just after + finishing the Negotiation phase. The consequence would be to waste + bandwidth for nothing. + + In order to mitigate this possible anomalous behavior, it is + RECOMMENDED to configure the server to reject sessions from the same + endpoint when this situation is detected. + +11. Future Code Point Requirements + + If the ideas described in this document are pursued to become a + protocol specification, then the code points described in this + document will need to be assigned by IANA. + +11.1. Service Port + + An assigned port would make possible a future Q4S-aware network + capable of reacting by itself to Q4S alerts. A specific port would + simplify the identification of the protocol by network elements in + charge of making possible reactive decisions. Therefore, the need + for a port assignment by IANA may be postponed until there is the + need for a future Q4S-aware network. + + Service Name: Q4S + + Transport Protocol(s): TCP + + Assignee: + Name: Jose Javier Garcia Aranda + + Email: jose_javier.garcia_aranda@nokia.com + + Contact: + Name: Jose Javier Garcia Aranda + + Email: jose_javier.garcia_aranda@nokia.com + + Description: The service associated with this request is in charge + of the establishment of new Q4S sessions, and during the + session, manages the handoff to a new protocol phase + (Handshake, Negotiation and Continuity) as well as sends alerts + when measurements do not meet the requirements. + + Reference: This document. This service does not use IP-layer + broadcast, multicast, or anycast communication. + +12. IANA Considerations + + This document has no IANA actions. + +13. References + +13.1. Normative References + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + <https://www.rfc-editor.org/info/rfc7230>. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, + <https://www.rfc-editor.org/info/rfc7231>. + + [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Conditional Requests", RFC 7232, + DOI 10.17487/RFC7232, June 2014, + <https://www.rfc-editor.org/info/rfc7232>. + + [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., + "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", + RFC 7233, DOI 10.17487/RFC7233, June 2014, + <https://www.rfc-editor.org/info/rfc7233>. + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, DOI 10.17487/RFC7234, June 2014, + <https://www.rfc-editor.org/info/rfc7234>. + + [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Authentication", RFC 7235, + DOI 10.17487/RFC7235, June 2014, + <https://www.rfc-editor.org/info/rfc7235>. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + <https://www.rfc-editor.org/info/rfc2818>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <https://www.rfc-editor.org/info/rfc3986>. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, <https://www.rfc-editor.org/info/rfc3629>. + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + <https://www.rfc-editor.org/info/rfc5322>. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <https://www.rfc-editor.org/info/rfc5234>. + + [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and SHA-based HMAC and HKDF)", RFC 6234, + DOI 10.17487/RFC6234, May 2011, + <https://www.rfc-editor.org/info/rfc6234>. + + [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, + "PKCS #1: RSA Cryptography Specifications Version 2.2", + RFC 8017, DOI 10.17487/RFC8017, November 2016, + <https://www.rfc-editor.org/info/rfc8017>. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + <https://www.rfc-editor.org/info/rfc3264>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <https://www.rfc-editor.org/info/rfc4566>. + +13.2. Informative References + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, <https://www.rfc-editor.org/info/rfc3550>. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, DOI 10.17487/RFC0793, September 1981, + <https://www.rfc-editor.org/info/rfc793>. + + [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, DOI 10.17487/RFC0792, September 1981, + <https://www.rfc-editor.org/info/rfc792>. + + [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed + and Secure Transport", Work in Progress, Internet-Draft, + draft-ietf-quic-transport-29, 9 June 2020, + <https://tools.ietf.org/html/draft-ietf-quic-transport- + 29>. + + [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. + Zekauskas, "A One-way Active Measurement Protocol + (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, + <https://www.rfc-editor.org/info/rfc4656>. + + [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. + Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", + RFC 5357, DOI 10.17487/RFC5357, October 2008, + <https://www.rfc-editor.org/info/rfc5357>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + DOI 10.17487/RFC0768, August 1980, + <https://www.rfc-editor.org/info/rfc768>. + + [RENO] Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The + Macroscopic Behavior of the TCP Congestion Avoidance + Algorithm", ACM SIGCOMM Computer Communication Review, pp. + 67-82, DOI 10.1145/263932.264023, July 1997, + <https://doi.org/10.1145/263932.264023>. + + [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", + RFC 3649, DOI 10.17487/RFC3649, December 2003, + <https://www.rfc-editor.org/info/rfc3649>. + + [CUBIC] Rhee, I., Xu, L., and S. Ha, "CUBIC for Fast Long-Distance + Networks", Work in Progress, Internet-Draft, draft-rhee- + tcpm-cubic-02, 26 August 2008, + <https://tools.ietf.org/html/draft-rhee-tcpm-cubic-02>. + + [CTCP] Sridharan, M., Tan, K., Bansal, D., and D. Thaler, + "Compound TCP: A New TCP Congestion Control for High-Speed + and Long Distance Networks", Work in Progress, Internet- + Draft, draft-sridharan-tcpm-ctcp-02, 11 November 2008, + <https://tools.ietf.org/html/draft-sridharan-tcpm-ctcp- + 02>. + +Acknowledgements + + Many people have made comments and suggestions contributing to this + document. In particular, we would like to thank: + + Victor Villagra, Sonia Herranz, Clara Cubillo Pastor, Francisco Duran + Pina, Michael Scharf, Jesus Soto Viso, and Federico Guillen. + + Additionally, we want to thank the Spanish Centre for the Development + of Industrial Technology (CDTI) as well as the Spanish Science and + Tech Ministry, which funds this initiative through their innovation + programs. + +Contributors + + Jacobo Perez Lajo + Nokia Spain + + Email: jacobo.perez@nokia.com + + + Luis Miguel Diaz Vizcaino + Nokia Spain + + Email: Luismi.Diaz@nokia.com + + + Gonzalo Munoz Fernandez + Nokia Spain + + Email: gonzalo.munoz_fernandez.ext@nokia.com + + + Manuel Alarcon Granero + Nokia Spain + + Email: manuel.alarcon_granero.ext@nokia.com + + + Francisco Jose Juan Quintanilla + Nokia Spain + + Email: francisco_jose.juan_quintanilla.ext@nokia.com + + + Carlos Barcenilla + Universidad Politecnica de Madrid + + + Juan Quemada + Universidad Politecnica de Madrid + + Email: jquemada@dit.upm.es + + + Ignacio Maestro + Tecnalia Research & Innovation + + Email: ignacio.maestro@tecnalia.com + + + Lara Fajardo Ibañez + Optiva Media + + Email: lara.fajardo@optivamedia.com + + + Pablo López Zapico + Optiva Media + + Email: Pablo.lopez@optivamedia.com + + + David Muelas Recuenco + Universidad Autonoma de Madrid + + Email: dav.muelas@uam.es + + + Jesus Molina Merchan + Universidad Autonoma de Madrid + + Email: jesus.molina@uam.es + + + Jorge E. Lopez de Vergara Mendez + Universidad Autonoma de Madrid + + Email: jorge.lopez_vergara@uam.es + + + Victor Manuel Maroto Ortega + Optiva Media + + Email: victor.maroto@optivamedia.com + + +Authors' Addresses + + Jose Javier Garcia Aranda + Nokia + María Tubau 9 + 28050 Madrid + Spain + + Phone: +34 91 330 4348 + Email: jose_javier.garcia_aranda@nokia.com + + + Mónica Cortés + Nokia + María Tubau 9 + 28050 Madrid + Spain + + Email: monica.cortes_sack@nokia.com + + + Joaquín Salvachúa + Universidad Politecnica de Madrid + Avenida Complutense 30 + 28040 Madrid + Spain + + Phone: +34 91 0672134 + Email: Joaquin.salvachua@upm.es + + + Maribel Narganes + Tecnalia Research & Innovation + Parque Científico y Tecnológico de Bizkaia + Astondo Bidea, Edificio 700 + E-48160 Derio Bizkaia + Spain + + Phone: +34 946 430 850 + Email: maribel.narganes@tecnalia.com + + + Iñaki Martínez-Sarriegui + Optiva Media + Edificio Europa II, + Calle Musgo 2, 1G, + 28023 Madrid + Spain + + Phone: +34 91 297 7271 + Email: inaki.martinez@optivamedia.com |