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.¶

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.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.¶

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.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.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.5. Server Failure 5xx

5xx responses are failure responses given when a server itself is having trouble.¶

6.6. Global Failures 6xx

6xx responses indicate that a server has definitive information about a particular policy not satisfied for processing the request.¶

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 |        |
|                   |      |     |     |_______|   ____|        |
|                   |      |     |     +-------+       |        |
|                   |      |     |                     |        |
|                   +------+     +---------------------+        |
|                                                               |
+---------------------------------------------------------------+

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.¶

Attribute values:
   <"q4s"|"app"> <"serverListeningPort"|"clientListeningPort">
<"UDP"|"TCP"> <0..65535> [ "-" [0..65535]]

   a=measurement:procedure default(50/50,75/75,5000,40/80,100/256)

a=measurement:latency 45
a=measurement:jitter 3/12
a=measurement:bandwidth 200/9800
a=measurement:packetloss 0.00/1.00

a=measurement:procedure default,[0..999]"/" [0..999]  "," [0..999]
"/" [0..999] "," [0..9999] "," [0..999]/[0..999] ","
[0..999]/[0..999]

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.¶

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.)  |
        |                                                |
        +------------------------------------------------+

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)
=========================

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.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 ------------            |
        |                                                |
        |                                                |
        +------------------------------------------------+

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.¶

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
=========================

        +------------------------------------------------+
        |                                                |
        | 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 -----------          |
        |                     ...                        |
        |                                                |
        +------------------------------------------------+

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
=========================

a=measurement:procedure default(50/60,50/50,5000,256/256,256/256)

      Measurements: l=22, j=13, pl=0.10, bw=

        +------------------------------------------------+
        |                                                |
        | Client                                Server   |
        |                                                |
        |      --------- Q4S READY 1 ----------->        |
        |      <-------- Q4S 200 OK -------------        |
        |                                                |
        |      --------- Q4S BWIDTH  ----------->        |
        |      <-------- Q4S BWIDTH  ------------        |
        |      --------- Q4S BWIDTH  ----------->        |
        |      <-------- Q4S BWIDTH  ------------        |
        |                  ...                           |
        |                                                |
        +------------------------------------------------+

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

=========================

        +------------------------------------------------+
        |                                                |
        | Client                                Server   |
        |                                                |
        |     ---------  Q4S READY 2 -------------->     |
        |     <---- Q4S 200 OK with trigger URI-----     |
        |                                                |
        |     ---------   HTTP GET ---------------->     |
        |                                                |
        |            (Application starts)                |
        |                                                |
        +------------------------------------------------+

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)
=========================

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     |
       |        |                                   |     |
       |        +-----------------------------------+     |
       |                                                  |
       +--------------------------------------------------+

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 --------->                 |
        |        ...                                     |
        |                                                |
        +------------------------------------------------+

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 -------->                         |
        |        ...                                     |
        |                                                |
        +------------------------------------------------+

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.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 |
        |                                                |
        +------------------------------------------------+

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.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 --------------         |
        |                                               |
        |                                               |
        +-----------------------------------------------+

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     |  |           |
  |           |  |     |     |     |   |  |     |  |           |
  |           |  +-----+     +-----+   |  +-----+  |           |
  |           |                        |           |           |
  +------------------------------------------------+-----------+

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     |  |           |
  |           |  |     |     |     |   |  |     |  |           |
  |           |  +-----+     +-----+   |  +-----+  |           |
  |           |                        |           |           |
  +------------------------------------------------+-----------+

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.7. Scenarios

Q4S could be used in two scenarios:¶

• client to ACP¶
• client to client (peer-to-peer scenario)¶

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.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.¶