Where is located the Q4S protocol specification?
Q4S protocol can be found at IETF website
How does Q4S perform measurement and how accurate is it?
Q4S can use any measurement procedure. The measurement procedure “default” is defined in the protocol specification and it is designed to be simple and interoperable, even in low performance equipments (Mobile, STB, …). The “default” procedure measures both directions (forward and reverse) using a control flow independent from application own flows in order to avoid disturbance. The measurement is achieved using a sliding time window containing the last samples. This “default” measurement procedure may be replaced by any custom procedure.
The accuracy of “default” procedure depends on the resources used in the control flow. For example, in our lab a 15kbps control flow provides a reaction time of 1 second when network parameters (latency, jitter or packet loss) degrades a 5%, and a accuracy of 10^-3 in packet loss using a window of 50 seconds or 10^-2 using a window of 5 seconds.
To achieve better accuracy or reaction time, control flow resources may be increased. A 150kbps allows a reaction time of 100ms and a precision of 10^-3 for packet loss in 5 seconds window.
On startup the server sends to the client the control flow resources to be used and in consequence the reaction time and time window is set.
The Q4S bandwidth consumption configuration is very flexible (from 1kbps to hundreds of kbps and can be different in downlink and uplink), allowing different sensitiveness. This allows adapt Q4S to different environments (3G, 4G, LTE, wireline, etc).
What is the meaning of “QoS-ALERT” message?
This is the message that Q4S generates when the measurements indicate that quality SLA is being violated. It is an informative message which indicates that the user’s experience is being degraded and includes the details of the problem (bandwidth, jitter, packet loss measurements and the SLA) and direction affected. The ALERT message does not contain the actions to take, which are completely free.
The type of actions that could be taken under ALERT, could be reduction of bitrate or reduce functionalities, or reduce frames per second, or intensity of compression, or even ask to the network provider for higher traffic prioritization. These “adaptative solutions” are not defined by Q4S
Is Q4S able to measure the TCP throughput?
TCP throughput is not considered a single parameter but a lineal combination of different net parameters. It depends on net bandwidth, net delay, and it depends on the stack TCP/IP implementation of the Operating System too.
TCP Th= Function( RTT, packet loss, stack implementation)
Default measurement procedure of Q4S is able to provide an estimated value of TCP throughput, and depending on this result, the chance to dynamically modify the input values (RTT and packet loss) is open, in order to get a constant TCP throughput.
Who is the user of Q4S?
The user of Q4S should be a piece of software called “actuator”, which is in charge of launch the Q4S stack, receive the alerts and invoke actions over the application ( a video game, a video conference collaborative tool, etc. ) and/or over the network provider
The actuator may be an independent piece of software, but must communicate with Q4S stack, in order to receive alerts.
What is “QoS-level dictionary”?
The QoS-level dictionary deals with the implementation of the different qos-levels used in Q4S. However, the definition of the dictionary is out of scope of Q4S.
For example, in a cloud gaming scenario, the level 0 could be “best effort”, level 1 could be “act over the videogame reducing its speed“, level 2 could be “ act over the video encoder reducing quality”, level 3 could be “ act over the video encoder reducing frames per second”, level 4 could be “act over the network asking for more priority”, etc.
The set of available actions depends on the application possibilities and network possibilities.
Why network reservation is less efficient than statistical multiplexing?
The added value by Q4S to current QoS management models (e.g. single measurement – or no measurement at all – and resource reservation at the beginning of the data exchange) is that enables dynamic measurement and reactive actions, including the possibility of network resource allocation
This is a key feature for many applications which are highly dynamic in terms of bandwidth consumption: a connection may work perfectly right without extra effort (BE), in that case the resource reservation is an unnecessary waste. Due to the fact that the bandwidth used by a connection is not constant, statistical multiplexing offers great advantages, only if not doing the static reservation in the peak (allows two simultaneous Best Effort users instead of one full reserved user).
Does Q4S break the Internet neutrality?
Regarding the Internet end2end principle:
“The end2end principle states that, whenever possible, communications protocol operations should be defined to occur at the end-points of a communications system, or as close as possible to the resource being controlled. According to the end-to-end principle, protocol features are only justified in the lower layers of a system if they are a performance optimization”
First of all, Q4S works at application level, not at network level. Q4S helps applications to adapt themselves to network conditions. If the application adaptation capacity is not able to overcome the network problems, and the network provider offers an interface to ask for more network quality on demand, then Q4S may help to decide when we have reach this situation.
In that cases the mechanism to guarantee the quality constraints for the service could be something “diffserv or reservation on demand”, and Diffserv is standardized in IETF.
Q4S only measures quality of connection, it does not provide mechanisms to act over the network. These mechanisms must be at network provder side.
Therefore, Q4S goes not against IETF philosophy.
Why is positive to standardize the Q4S protocol?
In environments with no standardized Q4S protocol, each service provider may develop its own measurement protocol solution. Q4S offers a tested reliable protocol, with adjustable responsivity, low bandwidth consumption and standard to be able to interoperate among different implementations