The Q4S protocol provides a light, real-time quality measurement of end-to-end connections that is independent of the transport protocol. It enables applications to take reactive measures when network quality drops, such as reducing encoding quality for video or adjusting gameplay for online games. The Q4S protocol involves three phases - handshake to set thresholds, negotiation to check quality before launching an application, and continuity to monitor quality during a session and trigger alerts. It has advantages like being agnostic to the transport protocol and allowing easy application-level decisions. Potential use cases involve cloud gaming, multiplayer music creation, and network monitoring.

1. Q4S protocol
The real-time quality measurement protocol

2. Motivation
 For any adaptive mechanisms it is desirable to have a standard and light measurement
protocol, independent of the type of protocol used in the application. A protocol applicable
to measure the end-to end quality, agnostic to the type of transport protocol used ( HTTP,
FTP, RTP, any proprietary protocol, etc.)
 These Q4S measurements enables applications to become “reactive”
Any transport protocol
Q4S measurement protocol ServerClient

3. Problem description
 The problem of network transmission on the Internet (latency, jitter and
packet burst, bandwidth and packet-loss) affects strongly “new age”
services like interactive video applications, virtualized games, or low latency e-
auction. The user experience of these new services are damaged by network
quality problems
 In addition, the transmission problems evolve during session time, and
therefore a quality measurement mechanism such as Q4S is needed to know
the quality status of the transmission and apply reactively different palliative
mechanisms

4. Q4S measures.
You take real-time decisions
Q4S measures and sends alerts when any initial quality threshold is violated. Afterwards,
you can trigger any application level action or network level action:
The actions you may take under alerts:
 Application level Adaptive mechanisms: Actions can be sent to applications (reduce
speed game under latency grew) or middleware (“adaptive encoding” for interactive
video services, in which codec could run faster (doing less compression effort) when
network latency increases, or compress more strongly when packet loss is detected)
 Network level Adaptive mechanisms: asking for more quality (bandwidth or priority) to
network provider when transmission problems are detected and cannot be solved
successfully by application-level adaptive mechanisms. This approach could open a new
possibility for network operators: to sell dynamic quality on demand

5. Practical implementation
“Actuator” is the user
of Q4S stack. The
actuator take the
decisions at
application-level or
netwok-level
actuator
Logic of “Actuator” is
out of scope of Q4S
stack
Q4S Q4S

6. Q4S session lifetime
3 phases:
 Handshake: set quality
thresholds
 Negotiation: check if
connection is good enough
before launching application or
game
 Continuity: measures during
game/app session and
launches alerts when quality
thresholds are violated

7. Advantages
 Agnostic to transport protocol
 Allows taking decissions easily at application-level (at encoding or at game/app
logic). Applications become reactive
 Adjustable responsivity
 Low resources usage (bandwidth and CPU)

8. Use cases
Cloud gaming and online gaming
• Latency, jitter, packet loss evolves and
damage user experience
• Multi-user games suffer different user
quality connections
• Use Q4S to Trigger actions over codec
speed , spatial and temporal resolution
• Use Q4S to Trigger actions over game
logic, maximizing gameplay
• Use Q4S to equalize user experience at
multi-user games

9. Use cases
Multi musician creations
 Different musicians
connected to internet, and
different latencies and jitter
make difficult to play
together
 Use Q4S to Trigger actions
over metronome at real-
time, adjusting metronome
according with latency

10. Use cases
Network monitoring
 Monitor network connections is not
only a question of connectivity
 Use Q4S probes to monitor quality
of connections and assist traffic
engineering decissions

11. References
Q4S protocol can be found at IETF website
 https://datatracker.ietf.org/doc/draft-aranda-dispatch-q4s/
Q4S portal ( FAQ, implementations, contact, etc.) at
 https://q4sprotocol.wordpress.com