rfc8802xml2.original.xml   rfc8802.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- [rfced] updated by Chris /09/04/19 -->
<!ENTITY RFC7230 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7230.xml">
<!ENTITY RFC7231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7231.xml">
<!ENTITY RFC7232 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7232.xml">
<!ENTITY RFC7233 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7233.xml">
<!ENTITY RFC7234 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7234.xml">
<!ENTITY RFC7235 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7235.xml">
<!ENTITY RFC3550 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3550.xml">
<!ENTITY RFC4566 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4566.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC3986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3986.xml">
<!ENTITY RFC3264 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3264.xml">
<!ENTITY RFC4634 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4634.xml">
<!ENTITY RFC8017 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8017.xml">
<!ENTITY RFC0793 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.0793.xml">
<!ENTITY RFC0768 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.0768.xml">
<!ENTITY RFC3550 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3550.xml">
<!ENTITY RFC3629 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3629.xml">
<!ENTITY RFC5322 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5322.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC3261 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3261.xml">
<!ENTITY RFC3649 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3649.xml">
<!ENTITY RFC4656 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4656.xml">
<!ENTITY RFC5357 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5357.xml">
]>
<rfc submissionType="independent" category="info" number="XXXX" ipr="trust200902
">
<!-- Generated by id2xml 1.4.4 on 2019-08-20T02:21:18Z -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="oo*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="no"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front>
<title>The Quality for Service Protocol</title>
<author fullname="Jose Javier Garcia Aranda" initials="J." surname="Arand
a">
<organization>Nokia</organization>
<address><postal><street>C/Maria Tubau 9</street>
<street>28050 Madrid</street>
<street>Spain</street>
</postal>
<phone>+34 91 330 4348</phone>
<email>jose_javier.garcia_aranda@nokia.com</email>
</address>
</author>
<author fullname="Monica Cortes" initials="M." surname="Cortes">
<organization abbrev="Univ. Politecnica de Madrid">Universidad Politecnic
a de Madrid</organization>
<address><postal><street>Avenida Complutense 30</street>
<street>28040 Madrid</street>
<street>Spain</street>
</postal>
<email>cortesm@dit.upm.es</email>
</address>
</author>
<author fullname="Joaquin Salvachua" initials="J." surname="Salvachua">
<organization abbrev="Univ. Politecnica de Madrid">Universidad Politecnic
a de Madrid</organization>
<address><postal><street>Avenida Complutense 30</street>
<street>28040 Madrid</street>
<street>Spain</street>
</postal>
<phone>+34 91 0672134</phone>
<email>jsalvachua@dit.upm.es</email>
</address>
</author>
<author fullname="Maribel Narganes" initials="M." surname="Narganes">
<organization abbrev="Tecnalia">Tecnalia Research &amp; Innovation</organ
ization>
<address><postal><street>Parque Cientifico y Tecnologico de Bizkaia</stre
et>
<street>Geldo Auzoa, Edificio 700</street>
<street>E-48160 Derio (Bizkaia)</street>
<street>Spain</street>
</postal>
<phone>+34 946 430 850</phone>
<email>maribel.narganes@tecnalia.com</email>
</address>
</author>
<author fullname="Inaki Martinez Sarriegui" initials="I." surname="Sarrie
gui">
<organization>Optiva Media</organization>
<address><postal><street>Edificio Europa II,</street>
<street>Calle Musgo 2, 1G,</street>
<street>28023 Madrid</street>
<street>Spain</street>
</postal>
<phone>+34 91 297 7271</phone>
<email>inaki.martinez@optivamedia.com</email>
</address>
</author>
<date month="September" year="2019"/>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
submissionType="independent"
category="info"
number="8802"
docName="draft-aranda-dispatch-q4s-10"
ipr="trust200902"
obsoletes=""
updates=""
xml:lang="en"
sortRefs="false"
symRefs="true"
tocDepth="4"
tocInclude="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.40.1 -->
<!-- Generated by id2xml 1.4.4 on 2019-08-20T02:21:18Z -->
<front>
<abstract><t> <title>The Quality for Service (Q4S) Protocol</title>
This memo describes an application level protocol for the <seriesInfo name="RFC" value="8802"/>
<author fullname="Jose Javier Garcia Aranda" initials="J.J." surname="Aranda
">
<organization>Nokia</organization>
<address>
<postal>
<street>María Tubau 9</street>
<code>28050</code>
<city>Madrid</city>
<country>Spain</country>
</postal>
<phone>+34 91 330 4348</phone>
<email>jose_javier.garcia_aranda@nokia.com</email>
</address>
</author>
<author fullname="Mónica Cortés" initials="M." surname="Cortés">
<organization>Nokia</organization>
<address>
<postal>
<street>María Tubau 9</street>
<code>28050</code>
<city>Madrid</city>
<country>Spain</country>
</postal>
<email>monica.cortes_sack@nokia.com</email>
</address>
</author>
<author fullname="Joaquín Salvachúa" initials="J." surname="Salvachúa">
<organization abbrev="Univ. Politecnica de Madrid">Universidad Politecnica
de Madrid</organization>
<address>
<postal>
<street>Avenida Complutense 30</street>
<code>28040</code>
<city>Madrid</city>
<country>Spain</country>
</postal>
<phone>+34 91 0672134</phone>
<email>Joaquin.salvachua@upm.es</email>
</address>
</author>
<author fullname="Maribel Narganes" initials="M." surname="Narganes">
<organization abbrev="Tecnalia">Tecnalia Research &amp; Innovation</organi
zation>
<address>
<postal>
<extaddr>Parque Científico y Tecnológico de Bizkaia</extaddr>
<street>Astondo Bidea, Edificio 700</street>
<code>E-48160</code>
<city>Derio</city>
<region>Bizkaia</region>
<country>Spain</country>
</postal>
<phone>+34 946 430 850</phone>
<email>maribel.narganes@tecnalia.com</email>
</address>
</author>
<author fullname="Iñaki Martínez-Sarriegui" initials="I." surname="Martínez-
Sarriegui">
<organization>Optiva Media</organization>
<address>
<postal>
<street>Edificio Europa II,</street>
<street>Calle Musgo 2, 1G,</street>
<street>28023 Madrid</street>
<street>Spain</street>
</postal>
<phone>+34 91 297 7271</phone>
<email>inaki.martinez@optivamedia.com</email>
</address>
</author>
<date month="July" year="2020"/>
<keyword>quality measurement</keyword>
<keyword>measurement protocol</keyword>
<keyword>latency</keyword>
<keyword>jitter</keyword>
<keyword>bandwidth</keyword>
<keyword>packet-loss</keyword>
<abstract>
<t>
This memo describes an application-level protocol for the
communication of end-to-end QoS compliance information based on communication of end-to-end QoS compliance information based on
the Hypertext Transfer Protocol (HTTP) and the Session the HyperText Transfer Protocol (HTTP) and the Session
Description Protocol (SDP). The Quality for Service Protocol Description Protocol (SDP). The Quality for Service
(Q4S) provides a mechanism to negotiate and monitor latency, (Q4S) protocol provides a mechanism to negotiate and monitor latency,
jitter, bandwidth, and packet, and to alert whenever one of the jitter, bandwidth, and packet loss, and to alert whenever one of the
negotiated conditions is violated.</t> negotiated conditions is violated.</t>
<t>
<t>
Implementation details on the actions to be triggered upon Implementation details on the actions to be triggered upon
reception/detection of QoS alerts exchanged by the protocol are reception/detection of QoS alerts exchanged by the protocol are
out of scope of this document, it is application dependent (e.g., out of scope of this document; it is either application dependent (e.g.,
act to increase quality or reduce bit-rate) or network dependent act to increase quality or reduce bit-rate) or network dependent
(e.g., change connection's quality profile).</t> (e.g., change connection's quality profile).</t>
<t>
<t>
This protocol specification is the product of research conducted This protocol specification is the product of research conducted
over a number of years, and is presented here as a permanent over a number of years; it is presented here as a permanent
record and to offer a foundation for future similar work. It does record and to offer a foundation for future similar work. It does
not represent a standard protocol and does not have IETF not represent a standard protocol and does not have IETF
consensus.</t> consensus.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sec-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="section-1"><t> <t>
The World Wide Web (WWW) is a distributed hypermedia system The World Wide Web (WWW) is a distributed hypermedia system
which has gained widespread acceptance among Internet users. that has gained widespread acceptance among Internet users.
Although WWW browsers support other, preexisting Internet Although WWW browsers support other, preexisting Internet
application protocols, the primary protocol used between WWW application protocols, the primary protocol used between WWW
clients and servers became the HyperText Transfer Protocol (HTTP) clients and servers became the HyperText Transfer Protocol (HTTP)
(RFC 7230 <xref target="ref-1"/>, RFC 7231 <xref target="ref-2"/>, RFC 7232 < (<xref target="RFC7230" format="default"/>, <xref target="RFC7231" format="de
xref target="ref-3"/>, RFC 7233 <xref target="ref-4"/>, RFC 7234 fault"/>,
<xref target="ref-5"/>, and RFC 7235 <xref target="ref-6"/>). Since then, HT <xref target="RFC7232" format="default"/>, <xref target="RFC7233" format="de
TP over TLS (known as HTTPS fault"/>,
and described in RFC 2818 [7]) has become an imperative for <xref target="RFC7234" format="default"/>, and <xref target="RFC7235" format
="default"/>).
Since then, HTTP over TLS (known as HTTPS
and described in <xref target="RFC2818" format="default"/>) has become an imp
erative for
providing secure and authenticated WWW access. The mechanisms providing secure and authenticated WWW access. The mechanisms
described in this document are equally applicable to HTTP and described in this document are equally applicable to HTTP and
HTTPS.</t> HTTPS.</t>
<t>
<t>
The ease of use of the Web has prompted its widespread employment The ease of use of the Web has prompted its widespread employment
as a client/server architecture for many applications. Many of as a client/server architecture for many applications. Many of
such applications require the client and the server to be able to such applications require the client and the server to be able to
communicate each other and exchange information with certain communicate with each other and exchange information with certain
quality constraints.</t> quality constraints.</t>
<t>
<t>
Quality in communications at the application level consists of Quality in communications at the application level consists of
four measurable parameters: four measurable parameters:
<list style="hanging" hangIndent="6"> </t>
<t hangText="Latency:">The time a message takes to travel from source to <dl newline="false" spacing="normal" indent="6">
destination. It may be approximated to RTT/2 (Round trip <dt>Latency:</dt>
time), assuming the networks are symmetrical. In this context <dd>The time a message takes to travel from source to
we will consider the statistical median formula.</t> destination. It may be approximated as RTT/2 (round-trip
time), assuming the networks are symmetrical. In this context,
<t hangText="Jitter:">latency variation. There are some formulas to we will consider the statistical median formula.</dd>
calculate Jitter, and in this context we will consider the <dt>Jitter:</dt>
arithmetic mean formula.</t> <dd>Latency variation. There are some formulas to
calculate jitter, and in this context, we will consider the
<t hangText="Bandwidth:">bit rate of communication. To assure quality, a arithmetic mean formula.</dd>
protocol must assure the availability of the bandwidth needed
by the application.</t>
<t hangText="Packet loss:">The percentage of packet loss is closely relat <dt>Bandwidth:</dt>
ed <dd>Bit rate of communication. To ensure quality, a
to bandwidth and jitter. Affects bandwidth because a high protocol must ensure the availability of the bandwidth needed
packet loss implies sometimes retransmissions that also by the application.</dd>
<dt>Packet loss:</dt>
<dd>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 consumes extra bandwidth, other times the retransmissions are
not achieved (for example in video streaming over UDP) and not achieved (for example, in video streaming over UDP), and
the information received is less than the required bandwidth. the information received is less than the required bandwidth.
In terms of jitter, a packet loss sometimes is seen by the In terms of jitter, a packet loss sometimes is seen by the
destination like a larger time between arrivals, causing a destination as a larger time between arrivals, causing a
jitter growth.</t> jitter growth.</dd>
</dl>
</list> <t>
</t> Any other communication parameter, such as throughput, is not a
<t>
Any other communication parameter such as throughput, is not a
network parameter because it depends on protocol window size and network parameter because it depends on protocol window size and
other implementation-dependent aspects.</t> other implementation-dependent aspects.</t>
<t>
<t> The Q4S protocol provides a mechanism for
The Quality for Service Protocol (Q4S) provides a mechanism for
quality monitoring based on an HTTP syntax and the Session quality monitoring based on an HTTP syntax and the Session
Description protocol (SDP) in order to be easily integrated in 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 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 based on HTTP. Quality requirements may be needed by any type of
application that communicates using any kind of protocol, application that communicates using any kind of protocol,
especially those with real-time constraints. Depending on the especially those with real-time constraints. Depending on the
nature of each application the constraints may be different nature of each application, the constraints may be different,
leading to different parameter thresholds that need to be met.</t> leading to different parameter thresholds that need to be met.</t>
<t>
<t> Q4S is an application-level client/server protocol that
Q4S is an application level Client/Server protocol that
continuously measures session quality for a given flow (or set of continuously measures session quality for a given flow (or set of
flows), end-to-end (e2e) and in real-time; raising alerts if flows), end-to-end (e2e) and in real time; raising alerts if
quality parameters are below a given pre-negotiated threshold and quality parameters are below a given negotiated threshold and
sending recoveries when quality parameters are restored. Q4S sending recoveries when quality parameters are restored. Q4S
describes when these notifications, alerts and recoveries, need to describes when these notifications, alerts, and recoveries need to
be sent and the entity receiving them. The actions undertaken by be sent and the entity receiving them. The actions undertaken by
the receiver of the alert are out of scope of the protocol.</t> the receiver of the alert are out of scope of the protocol.</t>
<t>
<t> Q4S is session-independent from the application flows to minimize
Q4S is session-independent from the application flows, to minimize
the impact on them. To perform the measurements, two control flows the impact on them. To perform the measurements, two control flows
are created on both communication paths (forward and reverse are created on both communication paths (forward and reverse
directions).</t> directions).</t>
<t>
<t>
This protocol specification is the product of research conducted This protocol specification is the product of research conducted
over a number of years, and is presented here as a permanent over a number of years and is presented here as a permanent
record and to offer a foundation for future similar work. It does record and to offer a foundation for future similar work. It does
not represent a standard protocol and does not have IETF not represent a standard protocol and does not have IETF
consensus.</t> consensus.</t>
<section anchor="sec-1.1" numbered="true" toc="default">
<section title="Scope" anchor="section-1.1"><t> <name>Scope</name>
<t>
The purpose of Q4S is to measure end-to-end network quality in The purpose of Q4S is to measure end-to-end network quality in
real-time. Q4S does not transport any application data. It means real time. Q4S does not transport any application data. This means
that Q4S is designed to be used jointly with other transport that Q4S is designed to be used jointly with other transport
protocols such as Real Time Protocol (RTP)(RFC 3550 <xref target="ref-8"/>), protocols such as Real-time Transport Protocol (RTP) <xref target="RFC3550" f
Transmission Control Protocol (TCP) (RFC 793 <xref target="ref-16"/>), Quick ormat="default"/>,
UDP Transmission Control Protocol (TCP) <xref target="RFC0793" format="default"/>
Internet Connections (QUIC)<xref target="ref-9"/> , HTTP <xref target="ref-1" ,
/>, etc.</t> QUIC <xref target="I-D.ietf-quic-transport" format="default"/>,
HTTP <xref target="RFC7230" format="default"/>, etc.</t>
<t> <t>
Some existent transport protocols are focused in real-time media Some existent transport protocols are focused on real-time media
transport and certain connection metrics are available, which is transport and certain connection metrics are available, which is
the case of RTP and Real Time Control Protocol (RTCP)<xref target="ref-8"/>. Other the case of RTP and RTP Control Protocol (RTCP) <xref target="RFC3550" format ="default"/>. Other
protocols such as QUIC provide low connection latencies as well as protocols such as QUIC provide low connection latencies as well as
advanced congestion control. These protocols transport data advanced congestion control. These protocols transport data
efficiently and provide lot of functionalities. However, there are efficiently and provide a lot of functionalities. However, there are
currently no other quality measurement protocols offering the same currently no other quality measurement protocols offering the same
level of function as Q4S. See <xref target="section-1.4"/> for a discussion level of function as Q4S. See <xref target="sec-1.4" format="default"/> for
of the a discussion of the
IETF's OWAMP and TWAMP quality measurement protocols.</t> IETF's quality measurement protocols, One-Way Active Measurement Protocol (OW
AMP) and
<t> Two-Way Active Measurement Protocol (TWAMP).</t>
Q4S enable applications to become reactive under e2e network <t>
Q4S enables applications to become reactive under e2e network
quality changes. To achieve it, an independent Q4S stack quality changes. To achieve it, an independent Q4S stack
application must run in parallel to target application. Then, Q4S application must run in parallel with the target application. Then, Q4S
metrics may be used to trigger actions on target application such metrics may be used to trigger actions on the target application, such
as speed adaptation to latency in multiuser games, bitrate control as speed adaptation to latency in multiuser games, bitrate control
at streaming services, intelligent commutation of delivery node at at streaming services, intelligent commutation of delivery node at
Content Delivery Networks, and whatever target application allow.</t> Content Delivery Networks, and whatever the target application allows.</t>
</section>
</section> <section anchor="sec-1.2" numbered="true" toc="default">
<name>Motivation</name>
<section title="Motivation" anchor="section-1.2"><t> <t>
Monitoring quality of service (QoS) in computer networks is useful Monitoring quality of service (QoS) in computer networks is useful
for several reasons:</t> for several reasons:</t>
<ul spacing="normal">
<t><list style="symbols"><t>Enable real-time services and applications to <li>It enables real-time services and applications to verify whether
verify whether
network resources achieve a certain QoS level. This helps network resources achieve a certain QoS level. This helps
real-time services and applications to run through the real-time services and applications to run over the
Internet, allowing the existence of Application Content Internet, allowing the existence of Application Content
Providers (ACPs) which offer guaranteed real-time services to Providers (ACPs), which offer guaranteed real-time services to
the final users.</t> the end users.</li>
<li>Real-time monitoring allows applications to adapt themselves
<t>Real-time monitoring allows applications to adapt themselves to network conditions (application-based QoS) and/or request
to network conditions (Application-based QoS) and/or request more network quality from the Internet Service Provider (ISP)
more network quality to the Internet Service Provider (ISP) (if the ISP offers this possibility).</li>
(if the ISP offers this possibility).</t> <li>Monitoring may also be required by peer-to-peer (P2P) real-time
applications for which Q4S can be used.</li>
<t>Monitoring may also be required by Peer to Peer (P2P) real-time <li>Monitoring enables ISPs to offer QoS to any ACP or end user applic
applications for which Q4S can be used</t> ation
in an accountable way.</li>
<t>Enable ISPs to offer QoS to any ACP or final user application <li>
in an accountable way</t> <t>Monitoring enables e2e negotiation of QoS parameters, independent
ly of
<t>Enable e2e negotiation of QoS parameters, independently of the ISPs of both endpoints.</t>
the ISPs of both endpoints.<vspace blankLines="1"/> </li>
</ul>
<t>
A protocol to monitor QoS must address the following issues: A protocol to monitor QoS must address the following issues:
</t> </t>
<ul spacing="normal">
<t>Must be ready to be used in conjunction with current standard <li>Must be ready to be used in conjunction with current standard
protocols and applications, without forcing a change on them.</t> protocols and applications, without forcing a change on them.</li>
<li>Must have a formal and compact way to specify quality
<t>Must have a formal and compact way to specify quality constraints desired by the application to run.</li>
constraints desired by the application to run.</t> <li>Must have measurement mechanisms that avoid application
disruption and minimize network resources consumption.</li>
<t>Must have measurement mechanisms avoiding application <li>Must have specific messages to alert about the violation of
disruption and minimizing network resources consumption.</t>
<t>Must have specific messages to alert about the violation of
quality constraints in different directions (forward and quality constraints in different directions (forward and
reverse), because network routing may not be symmetrical, and reverse) because network routing may not be symmetrical, and
of course, quality constraints may not be symmetrical.</t> of course, quality constraints may not be symmetrical.</li>
<li>After having alerted about the violation of quality
<t>After having alerted about the violation of quality
constraints, must have specific messages to inform about constraints, must have specific messages to inform about
recovery of quality constraints in corresponding directions the recovery of quality constraints in corresponding directions
(forward and reverse).</t> (forward and reverse).</li>
<li>Must protect the data (constraints, measurements, QoS levels
<t>Must protect the data (constrains, measurements, QoS levels
demanded from the network) in order to avoid the injection of demanded from the network) in order to avoid the injection of
malicious data in the measurements.</t> malicious data in the measurements.</li>
</ul>
</list> </section>
</t> <section anchor="sec-1.3" numbered="true" toc="default">
<name>Summary of Features</name>
</section> <t>
The Quality for Service (Q4S) protocol is a message-oriented
<section title="Summary of Features" anchor="section-1.3"><t>
The Quality for Service Protocol (Q4S) is a message-oriented
communication protocol that can be used in conjunction with any communication protocol that can be used in conjunction with any
other application-level protocol. Q4S is a measurement protocol. other application-level protocol. Q4S is a measurement protocol.
Any action taken derived from its measurements are out of scope of Any action taken derived from its measurements are out of scope of
the protocol. These actions depend on application provider and may the protocol. These actions depend on the application provider and may
be application-level adaptive reactions, may involve requests to be application-level adaptive reactions, may involve requests to
ISP, or whatever application provider decide.</t> the ISP, or whatever the application provider decides.</t>
<t>
<t>
The benefits in quality measurements provided by Q4S can be used The benefits in quality measurements provided by Q4S can be used
by any type of application that uses any type of protocol for data by any type of application that uses any type of protocol for data
transport. It provides a quality monitoring scheme for any transport. It provides a quality monitoring scheme for any
communication that takes place between the client and the server, communication that takes place between the client and the server,
not only for the Q4S communication itself.</t> not only for the Q4S communication itself.</t>
<t>
<t> Q4S does not establish multimedia sessions, and it does not
Q4S does not establish multimedia sessions and it does not
transport application data. It monitors the fulfillment of the transport application data. It monitors the fulfillment of the
quality requirements of the communication between the client and quality requirements of the communication between the client and
the server, and therefore does not impose any restrictions on the the server; therefore, it does not impose any restrictions on the
type of application, protocol or the type of usage of the type of application, protocol, or usage of the
monitored quality connection.</t> monitored quality connection.</t>
<t>
<t>
Some applications may vary their quality requirements dynamically Some applications may vary their quality requirements dynamically
for any given quality parameter. Q4S is able to adapt to the for any given quality parameter. Q4S is able to adapt to the
changing application needs modifying the parameter thresholds to changing application needs, modifying the parameter thresholds to
the new values and monitoring the network quality according to the the new values and monitoring the network quality according to the
new quality constraints. It will raise alerts if the new new quality constraints. It will raise alerts if the new
constraints are violated.</t> constraints are violated.</t>
<t>
<t> The Q4S session lifetime is composed of four phases with different
Q4S session lifetime is composed of four phases with different purposes: Handshake, Negotiation, Continuity, and Termination.
purposes: Handshake, Negotiation, Continuity and Termination.
Negotiation and Continuity phases perform network parameter Negotiation and Continuity phases perform network parameter
measurements as per a negotiated measurement procedure. Different measurements per a negotiated measurement procedure. Different
measurement procedures could be used inside Q4S, although one measurement procedures could be used inside Q4S, although one
default measurement mechanism is needed for compatibility reasons default measurement mechanism is needed for compatibility reasons
and is the one defined in this document. Basically, Q4S defines and is the one defined in this document. Basically, Q4S defines
how to transport application quality requirements and measurement how to transport application quality requirements and measurement
results between client and server and providing monitoring and results between a client and server and how to provide monitoring and
alerting too.</t> alerting, too.</t>
<t>
<t>
Q4S must be executed just before starting a client-server Q4S must be executed just before starting a client-server
application which needs a quality connection in terms of latency, application that needs a quality connection in terms of latency,
jitter, bandwidth and/or packet loss. Once client and server have jitter, bandwidth, and/or packet loss. Once the client and server have
succeeded in establishing communication under quality constraints, succeeded in establishing communication under quality constraints,
the application can start, and Q4S continues measuring and the application can start, and Q4S continues measuring and
alerting if necessary.</t> alerting if necessary.</t>
<t>
<t>
The quality parameters can be suggested by the client in the first The quality parameters can be suggested by the client in the first
message of the handshake phase, but it's the server that accepts message of the Handshake phase, but it is the server that accepts
these parameter values or forces others. The server is in charge these parameter values or forces others. The server is in charge
of deciding the final values of quality connection.</t> of deciding the final values of quality connection.</t>
</section>
</section> <section anchor="sec-1.4" numbered="true" toc="default">
<name>Differences from OWAMP/TWAMP</name>
<section title="Differences with OWAMP/TWAMP" anchor="section-1.4"><t> <t>
OWAMP (RFC 4656) <xref target="ref-27"/> and TWAMP (RFC 5357) <xref target="r OWAMP <xref target="RFC4656" format="default"/> and
ef-28"/> are two protocols TWAMP <xref target="RFC5357" format="default"/> are two protocols
to measure network quality in terms of RTT, but has a different 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 goal than Q4S. The main difference is the scope: Q4S is designed
to assist reactive applications, while OWAMP/TWAMP is designed to assist reactive applications, whereas OWAMP/TWAMP is designed
just to measure network delay.</t> to measure just network delay.</t>
<t>
<t> The differences can be summarized in the following points:</t>
Differences can be summarized in the following points:</t> <ul spacing="normal">
<li>OWAMP and TWAMP are not intended for measuring availability of
<t><list style="symbols"><t>OWAMP/TWAMP is not intended for measuring ava resources (certain bandwidth availability, for example) but
ilability of
resources (certain Bandwidth availability for example) but
only RTT. However, Q4S is intended for measuring required only RTT. However, Q4S is intended for measuring required
bandwidth, packet-loss, jitter and latency in both bandwidth, packet loss, jitter, and latency in both
directions. Available bandwidth is not measured by Q4S, but directions. Available bandwidth is not measured by Q4S, but
required bandwidth for specific application.</t> bandwidth required for a specific application is.</li>
<li>OWAMP and TWAMP do not have responsivity control (which
<t>OWAMP/TWAMP does not have responsivity control (which
defines the speed of protocol reactions under network quality defines the speed of protocol reactions under network quality
changes), because this protocol is designed to measure changes) because these protocols are designed to measure
network performance, not to assist reactive applications and network performance, not to assist reactive applications, and
does not detect the fluctuations of quality in certain time do not detect the fluctuations of quality within certain time
intervals to take reactive actions. However, responsivity intervals to take reactive actions. However, responsivity
control is a key feature of Q4S.</t> control is a key feature of Q4S.</li>
<li>OWAMP and TWAMP are not intended to run in parallel with reactive
<t>OWAMP/TWAMP is not intended to run in parallel with reactive applications, but the Q4S protocol's goal is to run in parallel and assist
applications, but Q4S' goal is to run in parallel and assist reactive applications in making decisions based on Q4S-ALERT
reactive applications to take decisions based on Q4S ALERT packets, which may trigger actions.</li>
packets which may trigger actions.</t> </ul>
</section>
</list> </section>
</t> <section anchor="sec-2" numbered="true" toc="default">
<name>Terminology</name>
</section> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
</section> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
<section title="Terminology" anchor="section-2"><t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
"MAY", and "OPTIONAL" in this document are to be interpreted as be
described in BCP 14 RFC 2119 <xref target="ref-11"/> RFC 8174 <xref target=" interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
ref-21"/> when, and only target="RFC8174"/> when, and only when, they appear in all capitals, as
when, they appear in all capitals, as shown here.</t> shown here.
</t>
</section> </section>
<section anchor="sec-3" numbered="true" toc="default">
<section title="Overview of Operation" anchor="section-3"><t> <name>Overview of Operation</name>
<t>
This section introduces the basic operation of Q4S using simple This section introduces the basic operation of Q4S using simple
examples. This section is of tutorial nature and does not contain examples. This section is of a tutorial nature and does not contain
any normative statements.</t> any normative statements.</t>
<t>
<t> The first example shows the basic functions of Q4S:
The first example shows the basic functions of a Q4S:
communication establishment between a client and a server, quality communication establishment between a client and a server, quality
requirement negotiations for the requested application, requirement negotiations for the requested application,
application start and continuous quality parameter measurements, application start and continuous quality parameter measurements,
and finally communication termination.</t> and finally communication termination.</t>
<t>
<t> The client triggers the establishment of the communication by
The client triggers the establishment of the communication
requesting a specific service or application from the server. This requesting a specific service or application from the server. This
first message must have a special URI (RFC 3986)<xref target="ref-12"/>, whic h may first message must have a special URI <xref target="RFC3986" format="default" />, which may
force the use of the Q4S protocol if it is implemented in a force the use of the Q4S protocol if it is implemented in a
standard web browser. This message consists of a Q4S BEGIN method, standard web browser. This message consists of a Q4S BEGIN method,
which can optionally include a proposal for the communication which can optionally include a proposal for the communication
quality requirements in an SDP body. This option gives the client quality requirements in an SDP body. This option gives the client
a certain negotiation capacity about quality requirements, but it a certain negotiation capacity about quality requirements, but it
will be the server who finally decides about the stated will be the server who finally decides the stated
requirements.</t> requirements.</t>
<t>
<t>
This request is answered by the server with a Q4S 200 OK response This request is answered by the server with a Q4S 200 OK response
letting the client know that it accepts the request. This response letting the client know that it accepts the request. This response
message must contain an SDP body with:</t> message must contain an SDP body with the following:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The assigned Q4S session id.</t> <li>The assigned Q4S sess-id.</li>
<li>The quality constraints required by the requested application.</li>
<t>The quality constraints required by the requested <li>The measurement procedure to use.</li>
application.</t> <li>
<t>"alerting-mode" attribute: There are two different scenarios for
<t>The measurement procedure to use.</t>
<t>The alerting mode: there are two different scenarios for
sending alerts that trigger actions either on the network or sending alerts that trigger actions either on the network or
in the application when measurements identify violated in the application when measurements identify violated
quality constraints. In both cases, alerts are triggered by quality constraints. In both cases, alerts are triggered by
the server. the server.
</t>
<list style="format (%c)"> <ol spacing="normal" type="(%c)">
<t> Q4S-aware-network scenario: the network is Q4S aware, <li>
and reacts by itself to these alerts. In this scenario <t>Q4S-aware-network scenario: The network is Q4S aware
Q4S ALERT messages are sent by the server to the client, 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 and network elements inspect and process these alert
messages. The alerting mode in this scenario is called messages. The alerting mode in this scenario is called
Q4S-aware-network alerting mode.</t> Q4S-aware-network alerting mode.</t>
</li>
<t>Reactive scenario: As shown in Figure 1, the network <li>
is not Q4S aware. In this scenario alert notifications <t>Reactive scenario: As shown in
<xref target="ref-reactive-scenario" format="default"/>, the network
is not Q4S aware. In this scenario, alert notifications
are sent to a specific node, called an Actuator, which is are sent to a specific node, called an Actuator, which is
in charge of taking decisions regarding what actions to in charge of making decisions regarding what actions to
trigger: either to change application behavior to adapt trigger: either to change application behavior to adapt
it to network conditions and/or invoke a network policy it to network conditions and/or invoke a network policy
server in order to reconfigure the network and request server in order to reconfigure the network and request
more quality for application flows.</t> better quality for application flows.</t>
<figure anchor="ref-reactive-scenario">
</list> <name>Reactive Scenario</name>
</t> <artwork name="" type="" align="left" alt=""><![CDATA[
</list>
</t>
<figure title="Reactive scenario" anchor="ref-reactive-scenario"><artwork
><![CDATA[
+------+ +-----------+ +------+ +-----------+
| App |<----- app flows---------->|Application| | App |<----- app flows---------->|Application|
|Client| +-----------+ |Client| +-----------+
+------+ A +------+ A
| |
+------+ +------+ +--------+ +------+ +------+ +--------+
| Q4S |<----Q4S---->| Q4S |<----->|Actuator| | Q4S |<----Q4S---->| Q4S |<----->|Actuator|
|Client| |Server| +--------+ |Client| |Server| +--------+
+------+ +------+ | +------+ +------+ |
V V
+-------------+ +-------------+
|policy server| |policy server|
+-------------+ +-------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="symbols"><t>The format of messages exchanged between the <t>The format of messages exchanged between the server stack and
server stack and the Actuator doesn't follow Q4S codification rules;
the Actuator, doesn't follow Q4S codification rules, but
their format will be implementation dependent. In this way, their format will be implementation dependent. In this way,
we will call the messages sent from the server stack to the we will call the messages sent from the server stack to the
Actuator "notifications" (e.g., alert notifications), and the Actuator "notifications" (e.g., alert notifications) and the
messages sent from the Actuator to the server stack in messages sent from the Actuator to the server stack in
response to notifications "acknowledges" (e.g., alert response to notifications "acknowledges" (e.g., alert
acknowledges).</t> acknowledges).</t>
</li>
<t>alert-pause: The amount of time between consecutive alerts. </ol></li>
</ul>
<ul spacing="normal">
<li>"alert-pause" attribute: The amount of time between consecutive aler
ts.
In the Q4S-aware-network scenario, the server has to wait In the Q4S-aware-network scenario, the server has to wait
this period of time between Q4S ALERT messages sent to the this period of time between Q4S-ALERT messages sent to the
client. In the Reactive scenario, the server stack has to client. In the Reactive scenario, the server stack has to
wait this period of time between alert notifications sent to wait this period of time between alert notifications sent to
the Actuator. Measurements are not stopped in Negotiation or the Actuator. Measurements are not stopped in Negotiation or
Continuity Phases during this period of time, but no alerts Continuity phases during this period of time, but no alerts
are sent even with violated network quality constraints in are sent, even with violated network quality constraints, in
order to leave time for network reconfiguration or for order to leave time for network reconfiguration or for
application adjustments.</t> application adjustments.</li>
<li>"recovery-pause" attribute: The amount of time the Q4S server waits
<t>recovery-pause: The amount of time the Q4S server waits before trying to recover the initial "qos-level" (<xref target="sec-7.2.1"
before trying to recover the initial qos-level. After having format="default"/>).
After having
detected violation of quality constraints several times, the detected violation of quality constraints several times, the
qos-level will have been increased accordingly. If this "qos-level" will have been increased accordingly. If this
violation detection finally stops, the server waits for a violation detection finally stops, the server waits for a
period of time (recovery time) and if the situation persists, period of time (recovery time), and if the situation persists,
it tries to recover to previous qos-level values gradually by it tries to recover to previous "qos-level" values gradually by
sending Q4S RECOVERY messages to the client, in the Q4S-aware-network scen sending Q4S-RECOVERY messages to the client in the Q4S-aware-network scena
ario, or recovery notifications to the rio, or recovery notifications to the
Actuator, in the Reactive scenario.</t> Actuator in the Reactive scenario (<xref target="sec-7.9" format="default"
/>).</li>
</list> </ul>
</t> <t>
<t>
It is important to highlight that any Q4S 200 OK response sent by 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 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 session may contain an SDP body with new values of quality
constraints required by the application. Depending on the phase constraints required by the application. Depending on the phase
and the state of the measurement procedure within the specific and the state of the measurement procedure within the specific
phase, the client will react accordingly so as to take into phase, the client will react accordingly to take into
account the new quality constraints in the measurement procedure.</t> account the new quality constraints in the measurement procedure.</t>
<t>
<t> Once the communication has been established (i.e., the Handshake phase is
Once the communication has been established (handshake phase is
finished), the protocol will verify that the communication path finished), the protocol will verify that the communication path
between the client and the server meets the quality constraints on between the client and the server meets the quality constraints in
both directions, from and to the server (negotiation phase). This both directions, from and to the server (Negotiation phase). This
negotiation phase requires taking measurements of the quality Negotiation phase requires taking measurements of the quality
parameters: latencies, jitter, bandwidth and packet loss. This parameters: latencies, jitter, bandwidth, and packet loss. This
phase is initiated with a client message containing a Q4S READY phase is initiated with a client message containing a Q4S READY
method, which will be answered by the server with a Q4S 200 OK method, which will be answered by the server with a Q4S 200 OK
response.</t> response.</t>
<t>
<t>
Negotiation measurements are achieved in two sequential stages: Negotiation measurements are achieved in two sequential stages:
</t>
<list style="hanging" hangIndent="6"> <dl newline="false" spacing="normal" indent="6">
<dt>Stage 0:</dt>
<t hangText="Stage 0:"> latency and jitter measurements</t> <dd> latency and jitter measurements</dd>
<dt>Stage 1:</dt>
<t hangText="Stage 1:"> bandwidth and packet loss measurements</t> <dd> bandwidth and packet loss measurements</dd>
</dl>
</list> <t>
</t> Stage 0 measurements are taken through Q4S PING messages
sent from both the client and the server. All Q4S PING
<t>
Stage 0 measurements are being taken through Q4S PING messages
sent both from both the client and the server. All Q4S PING
requests will be answered by Q4S 200 OK messages to allow for requests will be answered by Q4S 200 OK messages to allow for
bidirectional measurements.</t> bidirectional measurements.</t>
<t>
<t>
Different client and server implementations may send a different Different client and server implementations may send a different
number of PING messages for measuring, although at least 255 number of PING messages for measuring, although at least 255
messages should be considered to perform the latency measurement. messages should be considered to perform the latency measurement.
The Stage 0 measurements only may be considered ended when neither The Stage 0 measurements only may be considered ended when neither
client nor server receive new PING messages after an client nor server receive new PING messages after an
implementation-dependent guard time. Only after, client can send a implementation-dependent guard time. Only after Stage 0 has ended, can the cl ient send a
"READY 1" message.</t> "READY 1" message.</t>
<t>
<t>
After a pre-agreed number of measurements have been performed, After a pre-agreed number of measurements have been performed,
determined by the measurement procedure sent by the server, three determined by the measurement procedure sent by the server, three
scenarios may be possible: scenarios may be possible:
</t>
<list style="format (%c)"> <t> Measurements do not meet the <ol spacing="normal" type="(%c)">
requirements: in this case the <li> Measurements do not meet the
requirements: in this case, the
stage 0 is repeated after sending an alert from the server to stage 0 is repeated after sending an alert from the server to
the client or from the server stack to the Actuator, depending the client or from the server stack to the Actuator, depending
on the alerting mode defined in the Handshake phase. Notice on the alerting mode defined in the Handshake phase. Notice
that measurements continue to be taken but no alerts are sent that measurements continue to be taken but no alerts are sent
during the alert-pause time. In the Reactive scenario, the during the "alert-pause" time. In the Reactive scenario, the
Actuator will decide either to forward the alert notification Actuator will decide either to forward the alert notification
to the network policy server or to the application, depending to the network policy server or to the application, depending
on where reconfiguration actions have to be taken. on where reconfiguration actions have to be taken.
</t> </li>
<li> Measurements do meet the requirements: in this case, client
<t> Measurements do meet the requirements: in this case client moves to stage 1 by sending a new READY message.
moves to stage 1 sending a new READY message. </li>
</t> <li> At any time during the measurement procedure, the Q4S 200 OK
<t> At any time during the measurement procedure, the Q4S 200 OK
message sent by the server to the client, in response to a Q4S message sent by the server to the client, in response to a Q4S
PING message, contains an SDP body with new values of quality PING message, contains an SDP body with new values of quality
constraints required by the application; this means the constraints required by the application. This means the
application has varied their quality requirements dynamically application has varied their quality requirements dynamically;
and therefore quality thresholds used while monitoring quality therefore, quality thresholds used while monitoring quality
parameters have to be changed to the new constraints. In this parameters have to be changed to the new constraints. In this
case the client moves to the beginning of the Stage 0 for case, the client moves to the beginning of Stage 0 for
initiating the negotiation measurements again. initiating the negotiation measurements again.
</t> </li>
</list> </ol>
</t> <t>
<t>
Stage 1 is optional. Its purpose is to measure the availability of Stage 1 is optional. Its purpose is to measure the availability of
application needed bandwidth. This stage can be skipped by client application-needed bandwidth. If the "bandwidth" attribute is
sending a "READY 2" message after completion of stage 0 when set to zero kbps in the SDP, the client can skip stage 1 by
bandwidth requirements is set to cero kbps in the SDP. Stage 1 sending a "READY 2" message after completion of stage 0. Stage 1
measurements are achieved through Q4S BWIDTH messages sent both measurements are achieved through Q4S BWIDTH messages sent
from the client and the server. Unlike PING messages, Q4S BWIDTH from both the client and the server. Unlike PING messages, Q4S BWIDTH
requests will not be answered.</t> requests will not be answered.</t>
<t>
<t>
If Stage 0 and 1 meet the application quality constraints, the If Stage 0 and 1 meet the application quality constraints, the
application may start. Q4S will enter the continuity phase application may start. Q4S will enter the Continuity phase
measuring the network quality parameters through the Q4S PING by measuring the network quality parameters through the Q4S PING
message exchange on both connection paths, and raising alerts in message exchange on both connection paths and raising alerts in
case of violation.</t> case of violation.</t>
<t>
<t> Once the client wants to terminate the quality session, it sends a
Once the client wants to terminate the quality session it sends a
Q4S CANCEL message, which will be acknowledged by the server with Q4S CANCEL message, which will be acknowledged by the server with
another Q4S CANCEL message. Termination of quality sessions are another Q4S CANCEL message. Termination of quality sessions are
always initiated by the client because Q4S TCP requests follow the always initiated by the client because Q4S TCP requests follow the
client server schema.</t> client/server schema.</t>
<t><xref target="ref-successful-q4s-message-exchange" format="default"/>
<t><list style="hanging" hangIndent="-1"><t hangText="Figure 2 depicts th depicts the message exchange in a successful scenario.</t>
e message exchange in a successful scenario."> <figure anchor="ref-successful-q4s-message-exchange">
<vspace blankLines="0"/> <name>Successful Q4S Message Exchange</name>
</t> <artwork name="" type="" align="left" alt=""><![CDATA[
</list>
</t>
<figure title="Successful Q4S message exchange" anchor="ref-successful-q4
s-message-exchange"><artwork><![CDATA[
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Client Server | | Client Server |
| | | |
Handshake | --------- Q4S BEGIN -----------> | Handshake | --------- Q4S BEGIN -----------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| | | |
Negotiation | | Negotiation | |
(Stage 0) | --------- Q4S READY 0----------> | (Stage 0) | --------- Q4S READY 0----------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
skipping to change at line 673 skipping to change at line 621
Negotiation | | Negotiation | |
(Stage 1) | --------- Q4S READY 1----------> | (Stage 1) | --------- Q4S READY 1----------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| | | |
| --------- Q4S BWITDH ----------> | | --------- Q4S BWITDH ----------> |
| <-------- Q4S BWIDTH------------ | | <-------- Q4S BWIDTH------------ |
| --------- Q4S BWITDH ----------> | | --------- Q4S BWITDH ----------> |
| <-------- Q4S BWIDTH------------ | | <-------- Q4S BWIDTH------------ |
| ... | | ... |
Continuity | --------- Q4S READY 2 ---------> | Continuity | --------- Q4S READY 2 ---------> |
| <-------- Q4S 200 OK ----------- | app | <-------- Q4S 200 OK ----------- | app start
start
| | | |
| --------- Q4S PING ------------> | | --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- | | <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> | | -------- Q4S 200 OK ----------> |
| | | |
Termination | --------- Q4S CANCEL ----------> | app end Termination | --------- Q4S CANCEL ----------> | app end
| <-------- Q4S CANCEL ----------- | | <-------- Q4S CANCEL ----------- |
| | | |
+-------------------------------------------+ +-------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Client and server measurements are included into PING and BWIDTH Both client and server measurements are included in the PING and BWIDTH
messages, allowing both sides of the communication to be are aware messages, allowing both sides of the communication channel to be aware
of all measurements in both directions.</t> of all measurements in both directions.</t>
<t>
<t>
The following two examples show the behavior of the Q4S protocol The following two examples show the behavior of the Q4S protocol
when: quality constraints are violated, alerts are generated; and, when quality constraints are violated, and alerts are generated; and,
later on, violation of quality constraints stops leading to the later on, when the violation of quality constraints stops leading to the
execution of the recovery process. The first example (Figure 3) execution of the recovery process. The first example
(<xref target="ref-q4s-aware-network-alerting-mode" format="default"/>)
shows the Q4S-aware-network alerting mode scenario:</t> shows the Q4S-aware-network alerting mode scenario:</t>
<figure anchor="ref-q4s-aware-network-alerting-mode">
<figure title="Q4S-aware-network alerting mode" anchor="ref-q4s-aware-net <name>Q4S-Aware-Network Alerting Mode</name>
work-alerting-mode"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Client Server | | Client Server |
| | | |
Handshake | --------- Q4S BEGIN -----------> | Handshake | --------- Q4S BEGIN -----------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| | | |
Negotiation | | Negotiation | |
(Stage 0) | --------- Q4S READY 0----------> | (Stage 0) | --------- Q4S READY 0----------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| | | |
| --------- Q4S PING ------------> | | --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- | | <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> | | -------- Q4S 200 OK ----------> |
| ... | | ... |
| | | |
| <-------- Q4S ALERT ------------ | | <-------- Q4S-ALERT ------------ |
| -------- Q4S ALERT ------------> | | -------- Q4S-ALERT ------------> |
| (alert-pause start) | | (alert-pause start) |
Repetition | | Repetition | |
of Stage 0 | --------- Q4S READY 0----------> | of Stage 0 | --------- Q4S READY 0----------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| | | |
| --------- Q4S PING ------------> | | --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- | | <-------- Q4S PING ------------- |
| ... | | ... |
Negotiation | | Negotiation | |
(Stage 1) | --------- Q4S READY 1----------> | (Stage 1) | --------- Q4S READY 1----------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| | | |
| --------- Q4S BWITDH ----------> | | --------- Q4S BWITDH ----------> |
| <-------- Q4S BWIDTH------------ | | <-------- Q4S BWIDTH------------ |
| ... | | ... |
| | | |
Continuity | --------- Q4S READY 2 ---------> | Continuity | --------- Q4S READY 2 ---------> |
| <-------- Q4S 200 OK ----------- | app | <-------- Q4S 200 OK ----------- | app start
start
| | | |
| --------- Q4S PING ------------> | | --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- | | <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> | | -------- Q4S 200 OK ----------> |
| ... | | ... |
|(alert-pause expires & | |(alert-pause expires & |
| violated constraints) | | violated constraints) |
| <-------- Q4S ALERT ------------ | | <-------- Q4S-ALERT ------------ |
| --------- Q4S ALERT -----------> | | --------- Q4S-ALERT -----------> |
| | | |
| (alert-pause start) | | (alert-pause start) |
| --------- Q4S PING ------------> | | --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- | | <-------- Q4S PING ------------- |
| --------- Q4S 200 OK ----------> | | --------- Q4S 200 OK ----------> |
| ... | | ... |
|(alert-pause expires & | |(alert-pause expires & |
| violated constraints) | | violated constraints) |
| <-------- Q4S ALERT ------------ | | <-------- Q4S-ALERT ------------ |
| --------- Q4S ALERT -----------> | | --------- Q4S-ALERT -----------> |
| (alert-pause) | | (alert-pause) |
| --------- Q4S PING ------------> | | --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- | | <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> | | -------- Q4S 200 OK ----------> |
| ... | | ... |
|(alert-pause expires & | |(alert-pause expires & |
| Fullfilled constraints) | | Fulfilled constraints) |
| | | |
| (recovery-pause start) | | (recovery-pause start) |
| | | |
| --------- Q4S PING ------------> | | --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- | | <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> | | -------- Q4S 200 OK ----------> |
| ... | | ... |
|(recovery-pause expires & | |(recovery-pause expires & |
| Fullfilled constraints) | | Fulfilled constraints) |
| <--------- Q4S RECOVERY --------- | | <--------- Q4S-RECOVERY --------- |
| -------- Q4S RECOVERY -----------> | | -------- Q4S-RECOVERY -----------> |
| | | |
| (recovery-pause start) | | (recovery-pause start) |
| --------- Q4S PING ------------> | | --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- | | <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> | | -------- Q4S 200 OK ----------> |
| ... | | ... |
| | | |
Termination | --------- Q4S CANCEL ----------> | app end Termination | --------- Q4S CANCEL ----------> | app end
| <-------- Q4S CANCEL ----------- | | <-------- Q4S CANCEL ----------- |
| | | |
+-------------------------------------------+ +-------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In this Q4S-aware-network alerting mode scenario, the server may In this Q4S-aware-network alerting mode scenario, the server may
send Q4S alerts to the client at any time on detection of violated send Q4S alerts to the client at any time upon detection of violated
quality constraints. This alerting exchange must not interrupt the quality constraints. This alerting exchange must not interrupt the
continuity quality parameter measurements between client and continuity quality parameter measurements between client and
server.</t> server.</t>
<t>
<t> The second example depicted in <xref target="ref-reactive-alerting-mode" form
The second example depicted in the figure 4 represents the at="default"/> represents the
Reactive scenario, in which alert notifications are sent from the Reactive scenario, in which alert notifications are sent from the
server stack to the Actuator which is in charge of deciding either server stack to the Actuator, which is in charge of deciding
to act over application behavior and/or invoke a network policy to act over application behavior and/or to invoke a network policy
server. The Actuator is an entity that has a pre-defined set of server. The Actuator is an entity that has a defined set of
different quality levels and decides how to act depending on the different quality levels and decides how to act depending on the
actions stated for each of these levels; it can take actions for actions stated for each of these levels; it can take actions for
making adjustments on the application or it can send a request to making adjustments on the application, or it can send a request to
the policy server for acting on the network. The policy server the policy server for acting on the network. The policy server
also has a pre-defined set of different quality levels pre-agreed also has a defined set of different quality levels previously agreed
upon between the Application Content Provider and the ISP. The upon between the Application Content Provider and the ISP. The
Reactive alerting mode is the default mode.</t> Reactive alerting mode is the default mode.</t>
<figure anchor="ref-reactive-alerting-mode">
<figure title="Reactive alerting mode" anchor="ref-reactive-alerting-mode <name>Reactive Alerting Mode</name>
"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Client Server Actuator | | Client Server Actuator |
Handshake | ----- Q4S BEGIN -----> | Handshake | ----- Q4S BEGIN -----> |
| <---- Q4S 200 OK ----- | | <---- Q4S 200 OK ----- |
| | | |
Negotiation | | Negotiation | |
(Stage 0) | ----- Q4S READY 0----> | (Stage 0) | ----- Q4S READY 0----> |
| <---- Q4S 200 OK ----- | | <---- Q4S 200 OK ----- |
| | | |
skipping to change at line 867 skipping to change at line 814
| <---- Q4S PING ------- | | <---- Q4S PING ------- |
| ... | | ... |
Negotiation | | Negotiation | |
(Stage 1) | ----- Q4S READY 1----> | (Stage 1) | ----- Q4S READY 1----> |
| <---- Q4S 200 OK ----- | | <---- Q4S 200 OK ----- |
| | | |
| ----- Q4S BWITDH ----> | | ----- Q4S BWITDH ----> |
| <---- Q4S BWIDTH------ | | <---- Q4S BWIDTH------ |
| ... | | ... |
Continuity | ----- Q4S READY 2 ---> | Continuity | ----- Q4S READY 2 ---> |
| <---- Q4S 200 OK ----- | app | <---- Q4S 200 OK ----- | app start
start
| | | |
|(alert-pause expires & | |(alert-pause expires & |
| fulfilled constraints) | | fulfilled constraints) |
| | | |
|(recovery-pause start) | |(recovery-pause start) |
| ----- Q4S PING ------> | | ----- Q4S PING ------> |
| <---- Q4S 200 OK ----- | | <---- Q4S 200 OK ----- |
| <---- Q4S PING ------- | | <---- Q4S PING ------- |
| ----- Q4S PING ------> | | ----- Q4S PING ------> |
| | | |
skipping to change at line 905 skipping to change at line 851
Termination | ----- Q4S CANCEL ----> | app end Termination | ----- Q4S CANCEL ----> | app end
| --cancel | | --cancel |
| notification--> | | notification--> |
| | | |
| <--cancel | | <--cancel |
| acknowledge-- | | acknowledge-- |
| <---- Q4S CANCEL ----- | | <---- Q4S CANCEL ----- |
| | | |
+-------------------------------------------+ +-------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
At the end of any Negotiation phase stage, the server sends an At the end of any stage of the Negotiation phase, the server sends an
alert notification to the Actuator if quality constraints are alert notification to the Actuator if quality constraints are
violated. During the period of time defined by the alert-pause violated. During the period of time defined by the "alert-pause"
parameter, no further alert notifications are sent, but attribute, no further alert notifications are sent, but
measurements are not interrupted. This way, both the client and measurements are not interrupted. This way, both the client and
the server will detect network improvements as soon as possible. the server will detect network improvements as soon as possible.
In a similar way, during the continuity phase, the server may send In a similar way during the Continuity phase, the server may send
alert notifications at any time to the Actuator on detection of alert notifications at any time to the Actuator upon detection of
violated quality constraints. This alerting exchange must not violated quality constraints. This alerting exchange must not
interrupt the continuity measurements between client and server.</t> interrupt the continuity measurements between client and server.</t>
<t>
<t>
Finally, in the Termination phase, Q4S CANCEL messages sent from Finally, in the Termination phase, Q4S CANCEL messages sent from
the client to the server must be forwarded from the server to the the client to the server must be forwarded from the server to the
Actuator in order to release possible assigned resources for the Actuator in order to release possible assigned resources for the
session.</t> session.</t>
</section>
</section> <section anchor="sec-4" numbered="true" toc="default">
<name>Q4S Messages</name>
<section title="Q4S Messages" anchor="section-4"><t> <t>
Q4S is a text-based protocol and uses the UTF-8 charset (RFC 3629 Q4S is a text-based protocol and uses the UTF-8 charset
<xref target="ref-19"/>). A Q4S message is either a request or a response.</t <xref target="RFC3629" format="default"/>. A Q4S message is either a request
> or a response.</t>
<t>
<t> Both request and response messages use the basic format of
Both Request and Response messages use the basic format of Internet Message Format <xref target="RFC5322" format="default"/>. Both types
Internet Message Format (RFC 5322 <xref target="ref-20"/>). Both types of mes of messages
sages
consist of a start-line, one or more header fields, an empty line 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.</t> indicating the end of the header fields, and an optional message-body.
This document uses ABNF notation <xref target="RFC5234" format="default"/>
<t> for the definitions of the syntax of messages.</t>
The start-line, each message-header line, and the empty line MUST <t>
The start-line, each message-header line, and the empty line <bcp14>MUST</bcp
14>
be terminated by a carriage-return line-feed sequence (CRLF). be terminated by a carriage-return line-feed sequence (CRLF).
Note that the empty line MUST be present even if the message-body Note that the empty line <bcp14>MUST</bcp14> be present even if the message-b ody
is not.</t> is not.</t>
<sourcecode type="abnf"><![CDATA[
<figure><artwork><![CDATA[
generic-message = start-line CRLF generic-message = start-line CRLF
*message-header CRLF *message-header CRLF
CRLF CRLF
[ message-body ] [ message-body ]
start-line = Request-Line / Status-Line start-line = Request-Line / Status-Line
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
Much of Q4S's messages and header field syntax are identical to Much of Q4S's messages and header field syntax are identical to
HTTP/1.1. However, Q4S is not an extension of HTTP.</t> HTTP/1.1. However, Q4S is not an extension of HTTP.</t>
<section anchor="sec-4.1" numbered="true" toc="default">
<section title="Requests" anchor="section-4.1"><t> <name>Requests</name>
<t>
Q4S requests are distinguished by having a Request-Line for a Q4S requests are distinguished by having a Request-Line for a
start-line. A Request-Line contains a method name, a Request-URI, start-line. A Request-Line contains a method name, a Request-URI,
and the protocol version separated by a single space (SP) and the protocol version separated by a single space (SP)
character.</t> character.</t>
<t>
<t>
The Request-Line ends with CRLF. No CR or LF are allowed except in The Request-Line ends with CRLF. No CR or LF are allowed except in
the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed the end-of-line CRLF sequence. No linear whitespace (LWSP) is allowed
in any of the elements.</t> in any of the elements.</t>
<sourcecode type="abnf"><![CDATA[
<t> Request-Line = Method SP Request-URI SP Q4S-Version CRLF
Request-Line = Method SP Request-URI SP Q4S-Version CRLF </t> ]]></sourcecode>
<dl newline="false" spacing="normal" indent="6">
<t><list style="hanging" hangIndent="6"> <dt>Method:</dt>
<dd>
<t hangText="Method:">
This specification defines seven methods: BEGIN for This specification defines seven methods: BEGIN for
starting and negotiate quality sessions, READY for starting and negotiating quality sessions, READY for
synchronization of measurements, PING and BWIDTH for synchronization of measurements, PING and BWIDTH for
quality measurements purpose, CANCEL for terminating quality measurements purposes, CANCEL for terminating
sessions, Q4S-ALERT for quality violations reporting, and sessions, Q4S-ALERT for reporting quality violations, and
Q4S-RECOVERY for quality recovery reporting. Q4S-RECOVERY for reporting quality recovery.
</t> </dd>
<dt>Request-URI:</dt>
<t hangText="Request-URI:"> <dd>
The Request-URI is a Q4S URI (RFC 2396) as described The Request-URI is a Q4S URI <xref target="RFC3986" format="default"/> as
in 7.4. The Request-URI MUST NOT contain unescaped spaces described
or control characters and MUST NOT be enclosed in "&lt;&gt;". in <xref target="sec-7.4" format="default"/>. The Request-URI <bcp14>MUST
</t> NOT</bcp14> contain unescaped spaces
or control characters and <bcp14>MUST NOT</bcp14> be enclosed in "&lt;&gt;
<t hangText="Q4S-Version:"> ".
</dd>
<dt>Q4S-Version:</dt>
<dd>
Both request and response messages include the Both request and response messages include the
version of Q4S in use. To be compliant with this version of Q4S in use. To be compliant with this
specification, applications sending Q4S messages MUST specification, applications sending Q4S messages <bcp14>MUST</bcp14>
include a Q4S-Version of "Q4S/1.0". The Q4S-Version string include a Q4S-Version of "Q4S/1.0". The Q4S-Version string
is case-insensitive, but implementations MUST send upper-case. Unlike HTTP is case insensitive, but implementations <bcp14>MUST</bcp14>
/1.1, Q4S treats the version number as a send uppercase. Unlike HTTP/1.1, Q4S treats the version number as a
literal string. In practice, this should make no difference. literal string. In practice, this should make no difference.
</t> </dd>
</dl>
</list> </section>
</t> <section anchor="sec-4.2" numbered="true" toc="default">
<name>Responses</name>
</section> <t>
<section title="Responses" anchor="section-4.2"><t>
Q4S responses are distinguished from requests by having a Status-Line as thei r start-line. A Status-Line consists of the protocol Q4S responses are distinguished from requests by having a Status-Line as thei r start-line. A Status-Line consists of the protocol
version followed by a numeric Status-Code and its associated version followed by a numeric Status-Code and its associated
textual phrase, with each element separated by a single SP textual phrase, with each element separated by a single SP
character. No CR or LF is allowed except in the final CRLF character. No CR or LF is allowed except in the final CRLF
sequence.</t> sequence.</t>
<sourcecode type="abnf"><![CDATA[
<t> Status-Line = Q4S-Version SP Status-Code SP Reason-Phrase CRLF
Status-Line = Q4S-Version SP Status-Code SP Reason-Phrase CRLF </t> ]]></sourcecode>
<t>
<t>
The Status-Code is a 3-digit integer result code that indicates The Status-Code is a 3-digit integer result code that indicates
the outcome of an attempt to understand and satisfy a request. The the outcome of an attempt to understand and satisfy a request. The
Reason-Phrase is intended to give a short textual description of Reason-Phrase is intended to give a short textual description of
the Status-Code. The Status-Code is intended for use by automata, the Status-Code. The Status-Code is intended for use by automata,
whereas the Reason-Phrase is intended for the human user. A client whereas the Reason-Phrase is intended for the human user. A client
is not required to examine or display the Reason-Phrase.</t> is not required to examine or display the Reason-Phrase.</t>
<t>
<t> While this specification suggests specific wording for the
While this specification suggests specific wording for the reason Reason-Phrase, implementations <bcp14>MAY</bcp14> choose other text, for exam
phrase, implementations MAY choose other text, for example, in the ple, in the
language indicated in the Accept-Language header field of the language indicated in the Accept-Language header field of the
request.</t> request.</t>
<t>
<t>
The first digit of the Status-Code defines the class of response. The first digit of the Status-Code defines the class of response.
The last two digits do not have any categorization role. For this The last two digits do not have any categorization role. For this
reason, any response with a status code between 100 and 199 is reason, any response with a status code between 100 and 199 is
referred to as a "1xx response", any response with a status code 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 between 200 and 299 as a "2xx response", and so on. Q4S/1.0
allows following values for the first digit: allows following values for the first digit:
<list style="hanging" hangIndent="6"> </t>
<t hangText="1xx:"> <dl newline="false" spacing="normal" indent="6">
<dt>1xx:</dt>
<dd>
Provisional -- request received, continuing to process the request; Provisional -- request received, continuing to process the request;
</t> </dd>
<dt>2xx:</dt>
<t hangText="2xx:"> <dd>
Success -- the action was successfully received, understood, and accepted ; Success -- the action was successfully received, understood, and accepted ;
</t> </dd>
<dt>3xx:</dt>
<t hangText="3xx:"> <dd>
Redirection -- further action needs to be taken in order to complete the request; Redirection -- further action needs to be taken in order to complete the request;
</t> </dd>
<dt>4xx:</dt>
<t hangText="4xx:"> <dd>
Request Failure -- the request contains bad syntax or cannot be fulfilled at this server; Request Failure -- the request contains bad syntax or cannot be fulfilled at this server;
</t> </dd>
<dt>5xx:</dt>
<t hangText="5xx:"> <dd>
Server Error -- the server failed to fulfill an apparently valid request Server Error -- the server failed to fulfill an apparently valid request
" ;
</t> </dd>
<dt>6xx:</dt>
<t hangText="6xx:"> <dd>
Global Failure -- the request cannot be fulfilled at any server" Global Failure -- the request cannot be fulfilled at any server.
</t> </dd>
</list></t> </dl>
<t>
<t> The status codes are the same as described in HTTP <xref target="RFC7231" for
The status codes are the same described in HTTP (RFC 7231 <xref target="ref-2 mat="default"/>. In
"/>). In
the same way as HTTP, Q4S applications are not required to the same way as HTTP, Q4S applications are not required to
understand the meaning of all registered status codes, though such understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications <bcp14>MUST</bcp1 4>
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to digit, and treat any unrecognized response as being equivalent to
the x00 status code of that class.</t> the x00 status code of that class.</t>
<t>
<t> The Q4S-ALERT, Q4S-RECOVERY, and CANCEL requests do not have to be
The Q4S-ALERT, Q4S-RECOVERY and CANCEL requests do not have to be responded to. However, after receiving a Q4S-ALERT, Q4S-RECOVERY, or
responded. However, after receiving a Q4S-ALERT, Q4S-RECOVERY or CANCEL request, the server <bcp14>SHOULD</bcp14> send a Q4S-ALERT, Q4S-RECOVE
CANCEL request, the server SHOULD send a Q4S-ALERT, Q4S-RECOVERY RY,
or CANCEL request to the client</t> or CANCEL request to the client.</t>
</section>
</section> <section anchor="sec-4.3" numbered="true" toc="default">
<name>Header Fields</name>
<section title="Header Fields" anchor="section-4.3"><t> <t>
Q4S header fields are identical to HTTP header fields in both Q4S header fields are identical to HTTP header fields in both
syntax and semantics.</t> syntax and semantics.</t>
<t>
<t>
Some header fields only make sense in requests or responses. These Some header fields only make sense in requests or responses. These
are called request header fields and response header fields, are called request header fields and response header fields,
respectively. If a header field appears in a message not matching 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 its category (such as a request header field in a response), it
MUST be ignored.</t> <bcp14>MUST</bcp14> be ignored.</t>
<section anchor="sec-4.3.1" numbered="true" toc="default">
<section title="Common Q4S Header Fields" anchor="section-4.3.1"> <name>Common Q4S Header Fields</name>
<t> These fields may appear in request and response messages.
<t> These fields may appear in Request and Response messages. </t>
<dl newline="false" spacing="normal" indent="6">
<list style="hanging" hangIndent="6"> <dt>Session-Id:</dt>
<t hangText="Session-Id:">the value for this header is the same session id <dd>the value for this header field is the same sess-id
used in SDP (embedded in "o" SDP parameter) and is assigned used in SDP (embedded in the SDP "o=" line) and is assigned
by the server. The messages without SDP MUST include this by the server. The messages without SDP <bcp14>MUST</bcp14> include this
header. If a message has and SDP body, this header is header field. If a message has an SDP body, this header field is
optional. The method of &lt;session id&gt; allocation is up to the optional. The method of sess-id allocation is up to the
creating tool, but it is suggested that a UTC timestamp be creating tool, but it is suggested that a UTC timestamp be
used to ensure uniqueness.</t> used to ensure uniqueness.</dd>
<dt>Sequence-Number:</dt>
<t hangText="Sequence-Number:">sequential and cyclic positive integer <dd>sequential and cyclic positive integer
number assigned to PING and BWIDTH messages, and acknowledged number assigned to PING and BWIDTH messages and acknowledged
in 200 OK responses.</t> in 200 OK responses.</dd>
<dt>Timestamp:</dt>
<t hangText="Timestamp:">this optional header contains the system time <dd>this optional header field contains the system time
(with the best possible accuracy). It indicates the time in (with the best possible accuracy). It indicates the time in
which the PING request was sent. If this header is present in which the PING request was sent. If this header field is present in
PING messages, then the 200 OK response messages MUST include PING messages, then the 200 OK response messages <bcp14>MUST</bcp14> inclu
this value.</t> de
this value.</dd>
<t hangText="Stage:">this is used in client's READY requests and server's <dt>Stage:</dt>
<dd>this is used in the client's READY requests and the server's
200 OK responses during the Negotiation and Continuity phases 200 OK responses during the Negotiation and Continuity phases
in order to synchronize the initiation of the measurements. in order to synchronize the initiation of the measurements.
Example: Stage: 0</t> Example: Stage: 0</dd>
</dl>
</list> </section>
</t> <section anchor="sec-4.3.2" numbered="true" toc="default">
<name>Specific Q4S Request Header Fields</name>
</section> <t>
<section title="Specific Q4S Request Header Fields" anchor="section-4.3.2
"><t>
In addition to HTTP header fields, these are the specific Q4S In addition to HTTP header fields, these are the specific Q4S
request header fields</t> request header fields:</t>
<dl newline="false" spacing="normal" indent="6">
<t><list style="symbols"><t>User-Agent: this header contains information <dt>User-Agent:</dt>
about the <dd>this header field contains information about the
implementation of the user agent. This is for statistical implementation of the user agent. This is for statistical
purposes, the tracing of protocol violations, and the purposes, the tracing of protocol violations, and the
automated recognition of user agents for the sake of automated recognition of user agents for the sake of
tailoring responses to avoid particular user agent tailoring responses to avoid particular user agent
limitations. User agents SHOULD include this field with limitations. User agents <bcp14>SHOULD</bcp14> include this field with
requests. The field MAY contain multiple product tokens and requests. The field <bcp14>MAY</bcp14> contain multiple product tokens and
comments identifying the agent and any sub-products which comments identifying the agent and any sub-products that
form a significant part of the user agent. By convention, the form a significant part of the user agent. By convention, the
product tokens are listed in order of their significance for product tokens are listed in order of their significance for
identifying the application.</t> identifying the application.</dd>
<dt>Signature:</dt>
<t>Signature: this header contains a digital signature that can <dd><t>this header field contains a digital signature that can
be used by the network, actuator or policy server to validate be used by the network, Actuator, or policy server to validate
the SDP, preventing security attacks. The signature is an the SDP, preventing security attacks. The Signature is an
optional header generated by the server according to the pre-agreed securi optional header field generated by the server according to the
ty policies between the Application Content pre-agreed security policies between the Application Content
Provider and the ISP. For example, a hash algorithm and Provider and the ISP. For example, a hash algorithm and
encryption method such as SHA256 (RFC 4634 <xref target="ref-14"/>) and RS encryption method such as SHA256 <xref target="RFC6234" format="default"/>
A (RFC and RSA <xref target="RFC8017" format="default"/> based on the server cert
8017 <xref target="ref-15"/>) based on the server certificate could be use ificate could be used.
d.
This certificate is supposed to be delivered by a This certificate is supposed to be delivered by a
Certification Authority (CA) or policy owner to the server. Certification Authority (CA) or policy owner to the server.
The signature is applied to the SDP body. The signature is applied to the SDP body.</t>
<sourcecode type="abnf"><![CDATA[
<figure><artwork><![CDATA[
Signature= RSA ( SHA256 (<sdp>), <certificate> ) Signature= RSA ( SHA256 (<sdp>), <certificate> )
]]></artwork> ]]></sourcecode>
</figure> <t>If the Signature header field is not present, other validation
mechanisms
If the signature is not present, other validation mechanism <bcp14>MAY</bcp14> be implemented in order to provide assured quality with
MAY be implemented in order to provide assured quality with
security and control. security and control.
</t> </t>
</dd>
<t>Measurements: this header carries the measurements of the <dt>Measurements:</dt>
<dd><t>this header field carries the measurements of the
quality parameters in PING and BWIDTH requests. The format quality parameters in PING and BWIDTH requests. The format
is: is: </t>
<sourcecode type="abnf"><![CDATA[
<figure><artwork><![CDATA[ Measurements: "l=" " "|[0..9999] ", j=" " "|[0..9999] ", pl="
Measurements: "l=" " "|[0..9999] ", j=" " "|[0..9999] ", pl=" " "|[0.00 .. 100.00] ", bw=" " "|[0..999999]
" "|[0.00 .. 100.00] ", bw=" " "|[0..999999] ]]></sourcecode>
]]></artwork> <t>
</figure>
Where "l" stands for latency followed by the measured value Where "l" stands for latency followed by the measured value
(in milliseconds)or an empty space, "j" stands for jitter (in milliseconds) or an empty space, "j" stands for jitter
followed by the measured value (in milliseconds) or an empty followed by the measured value (in milliseconds) or an empty
space, "pl" stands for packetloss followed by the measured space, "pl" stands for packet loss followed by the measured
value (in percentage with two decimals) or an empty space value (in percentage with two decimals) or an empty space,
and "bw" stands for bandwidth followed by the measured value and "bw" stands for bandwidth followed by the measured value
(in kbps) or an empty space.</t> (in kbps) or an empty space.</t>
</dd>
</list> </dl>
</t> </section>
<section anchor="sec-4.3.3" numbered="true" toc="default">
</section> <name>Specific Q4S Response Header Fields</name>
<dl newline="false" spacing="normal" indent="6">
<section title="Specific Q4S Response Header Fields" anchor="section-4.3. <dt>Expires:</dt>
3"><t><list style="symbols"><t>Expires: its purpose is to provide a sanity check <dd><t>its purpose is to provide a sanity check and allow
and allow
the server to close inactive sessions. If the client does not the server to close inactive sessions. If the client does not
send a new request before the expiration time, the server MAY send a new request before the expiration time, the server <bcp14>MAY</bcp1
close the session. The value MUST be an integer and the 4>
measurement units are milliseconds.<vspace blankLines="1"/> close the session. The value <bcp14>MUST</bcp14> be an integer, and the
In order to keep the session open the server MUST send a Q4S measurement units are milliseconds.</t>
alert before the session expiration (Expires header), with <t>
In order to keep the session open, the server <bcp14>MUST</bcp14> send a
Q4S
alert before the session expiration (Expires header field), with
the same quality levels and an alert cause of "keep-alive". the same quality levels and an alert cause of "keep-alive".
The purpose of this alert is to avoid TCP sockets (which were The purpose of this alert is to avoid TCP sockets, which were
opened with READY message) from being closed, specially in opened with READY message, from being closed, specially in
NAT scenarios. NAT scenarios.</t>
</t> </dd>
</dl>
</list> </section>
</t> </section>
<section anchor="sec-4.4" numbered="true" toc="default">
</section> <name>Bodies</name>
<t>
</section>
<section title="Bodies" anchor="section-4.4"><t>
Requests, including new requests defined in extensions to this Requests, including new requests defined in extensions to this
specification, MAY contain message bodies unless otherwise noted. specification, <bcp14>MAY</bcp14> contain message bodies unless otherwise not ed.
The interpretation of the body depends on the request method.</t> The interpretation of the body depends on the request method.</t>
<t>
<t>
For response messages, the request method and the response status For response messages, the request method and the response status
code determine the type and interpretation of any message body. code determine the type and interpretation of any message body.
All responses MAY include a body.</t> All responses <bcp14>MAY</bcp14> include a body.</t>
<t>
<t> The Internet media type of the message body <bcp14>MUST</bcp14> be given by t
The Internet media type of the message body MUST be given by the he
Content-Type header field.</t> Content-Type header field.</t>
<section anchor="sec-4.4.1" numbered="true" toc="default">
<section title="Encoding" anchor="section-4.4.1"><t> <name>Encoding</name>
The body MUST NOT be compressed. This mechanism is valid for <t>
other protocols such as HTTP and SIP (RFC 3261 <xref target="ref-22"/>), but The body <bcp14>MUST NOT</bcp14> be compressed. This mechanism is valid for
a compression/coding scheme will limit certain logical other protocols such as HTTP and SIP <xref target="RFC3261" format="default"/
implementations of the way the request is parsed, thus, making the >,
protocol concept more implementation dependent. In addition, 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. bandwidth calculation may not be valid if compression is used.
Therefore, the HTTP request header "Accept-Encoding" cannot be Therefore, the HTTP Accept-Encoding request header field cannot be
used in Q4S with different values than "identity" and if it is used in Q4S with values different from "identity", and if it is
present in a request, the server MUST ignore it. In addition, the present in a request, the server <bcp14>MUST</bcp14> ignore it. In addition,
response header "Content-Encoding" is optional, but if present, the
response header field Content-Encoding is optional, but if present,
the unique permitted value is "identity".</t> the unique permitted value is "identity".</t>
<t>
<t> The body length in bytes <bcp14>MUST</bcp14> be provided by the Content-Lengt
The body length in bytes MUST be provided by the Content-Length h
header field. The "chunked" transfer encoding of HTTP/1.1 MUST NOT header field. The "chunked" transfer encoding of HTTP/1.1 <bcp14>MUST NOT</bc
be used for Q4S (Note: The chunked encoding modifies the body of a p14>
be used for Q4S.</t>
<aside><t>Note: The chunked encoding modifies the body of a
message in order to transfer it as a series of chunks, each one message in order to transfer it as a series of chunks, each one
with its own size indicator.)</t> with its own size indicator.</t></aside>
</section>
</section> </section>
</section>
</section> <section anchor="sec-5" numbered="true" toc="default">
<name>Q4S Method Definitions</name>
</section> <t>
<section title="Q4S Method Definitions" anchor="section-5"><t>
The Method token indicates the method to be performed on the The Method token indicates the method to be performed on the
resource identified by the Request-URI. The method is case-sensitive.</t> resource identified by the Request-URI. The method is case sensitive.</t>
<sourcecode type="abnf"><![CDATA[
<figure><artwork><![CDATA[ Method = "BEGIN" | "READY" | "PING" | "BWIDTH" |
Method = "BEGIN" | "READY" | "PING" | "BWIDTH" | "Q4S-ALERT" | "Q4S-RECOVERY" | "CANCEL" | extension-method
"Q4S-ALERT" | "Q4S-RECOVERY" | "CANCEL" |
extension-method
extension-method = token extension-method = token
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
The list of methods allowed by a resource can be specified in an The list of methods allowed by a resource can be specified in an
"Allow" header field (RFC 7231 <xref target="ref-2"/>). The return code of th e Allow header field <xref target="RFC7231" format="default"/>. The return code of the
response always notifies the client when a method is currently response always notifies the client when a method is currently
allowed on a resource, since the set of allowed methods can change allowed on a resource, since the set of allowed methods can change
dynamically. Any server application SHOULD return the status code dynamically. Any server application <bcp14>SHOULD</bcp14> return the status c ode
405 (Method Not Allowed) if the method is known, but not allowed 405 (Method Not Allowed) if the method is known, but not allowed
for the requested resource, and 501 (Not Implemented) if the for the requested resource, and 501 (Not Implemented) if the
method is unrecognized or not implemented by the server.</t> method is unrecognized or not implemented by the server.</t>
<section anchor="sec-5.1" numbered="true" toc="default">
<section title="BEGIN" anchor="section-5.1"><t> <name>BEGIN</name>
<t>
The BEGIN method requests information from a resource identified The BEGIN method requests information from a resource identified
by a Q4S URI. The semantics of this method is the starting of a by a Q4S URI. The purpose of this method is to start the
quality session.</t> quality session.</t>
<t>
<t> This method is used only during the Handshake phase to retrieve
This method is only used during the handshake phase to retrieve the SDP containing the sess-id and all quality and operation
the SDP containing session id and all quality and operation
parameters for the desired application to run.</t> parameters for the desired application to run.</t>
<t>
<t>
When a BEGIN message is received by the server, any current When a BEGIN message is received by the server, any current
quality session MUST be cancelled, and a new session should be quality session <bcp14>MUST</bcp14> be canceled, and a new session should be
created.</t> created.</t>
<t>
<t>
The response to a Q4S BEGIN request is not cacheable.</t> The response to a Q4S BEGIN request is not cacheable.</t>
</section>
</section> <section anchor="sec-5.2" numbered="true" toc="default">
<name>READY</name>
<section title="READY" anchor="section-5.2"><t> <t>
The READY method is used to synchronize the starting time for The READY method is used to synchronize the starting time for the
sending of PING and BWIDTH messages over UDP between clients and sending of PING and BWIDTH messages over UDP between clients and
servers. The stage header included in this method is mandatory.</t> servers. Including the Stage header field in this method is mandatory.</t>
<t>
<t> This message is used only in Negotiation and Continuity phases,
This message is only used in negotiation and continuity phases, and only just before making a measurement. Otherwise (outside of this
and only just before making a measurement. Otherwise (out of this context), the server <bcp14>MUST</bcp14> ignore this method.</t>
context), the server MUST ignore this method.</t> </section>
<section anchor="sec-5.3" numbered="true" toc="default">
</section> <name>PING</name>
<t>
<section title="PING" anchor="section-5.3"><t> This message is used during the Negotiation and Continuity phases
This message is used during the negotiation and continuity phases to measure the RTT and jitter of a session. The message <bcp14>MUST</bcp14> b
to measure the RTT and jitter of a session. The message MUST be e
sent only over UDP ports.</t> sent only over UDP ports.</t>
<t>
<t>
The fundamental difference between the PING and BWIDTH requests is The fundamental difference between the PING and BWIDTH requests is
reflected in the different measurements achieved with them. PING reflected in the different measurements achieved with them. PING
is a short message, and MUST be answered in order to measure RTT is a short message, and it <bcp14>MUST</bcp14> be answered in order to measur
and jitter, whereas BWIDTH is a long message and MUST NOT be e RTT
and jitter, whereas BWIDTH is a long message and <bcp14>MUST NOT</bcp14> be
answered.</t> answered.</t>
<t>
<t> PING is a request method that can be originated by either the client or
PING is a request method that can be originated by client but also the server. The client <bcp14>MUST</bcp14> also answer the server PING messag
by server. Client MUST also answer the server PING messages, es,
assuming a "server role" for these messages during measurement assuming a "server role" for these messages during the measurement
process.</t> process.</t>
<t>
<t> Including the Measurements header field in this method is mandatory, and
The Measurements header included in this method is mandatory, and provides updated measurements values for latency, jitter, and
provides updated measurements values for latency, jitter and
packet loss to the counterpart.</t> packet loss to the counterpart.</t>
</section>
</section> <section anchor="sec-5.4" numbered="true" toc="default">
<name>BWIDTH</name>
<section title="BWIDTH" anchor="section-5.4"><t> <t>
This message is used only during the Negotiation phase to measure This message is used only during the Negotiation phase to measure
the bandwidth and packet loss of a session. The message MUST be the bandwidth and packet loss of a session. The message <bcp14>MUST</bcp14> b e
sent only over UDP ports.</t> sent only over UDP ports.</t>
<t>
<t> BWIDTH is a request method that can be originated by either the client
BWIDTH is a request method that can be originated by the client or the server. Both client and server <bcp14>MUST NOT</bcp14> answer
but also by server. Both (client and server) MUST NOT answer
BWIDTH messages.</t> BWIDTH messages.</t>
<t>
<t> Including the Measurements header field in this method is mandatory and
The Measurements header included in this method is mandatory and
provides updated measurements values for bandwidth and packet loss provides updated measurements values for bandwidth and packet loss
to the counterpart.</t> to the counterpart.</t>
</section>
</section> <section anchor="sec-5.5" numbered="true" toc="default">
<name>Q4S-ALERT</name>
<section title="Q4S-ALERT" anchor="section-5.5"><t> <t>
This is the request message that Q4S generates when the This is the request message that Q4S generates when the
measurements indicate that quality constraints are being violated. measurements indicate that quality constraints are being violated.
It is used during the negotiation and continuity phases.</t> It is used during the Negotiation and Continuity phases.</t>
<t>
<t>
This informative message indicates that the user experience is This informative message indicates that the user experience is
being degraded and includes the details of the problem (bandwidth, being degraded and includes the details of the problem (bandwidth,
jitter, packet loss measurements). The Q4S-ALERT message does not jitter, packet loss measurements). The Q4S-ALERT message does not
contain any detail on the actions to be taken, which depends on contain any detail on the actions to be taken, which depend on
the agreements between all involved parties.</t> the agreements between all involved parties.</t>
<t>
<t> Unless there is an error condition, an answer to a Q4S-ALERT
Q4S-ALERT request does not have to be answered with a response request is optional and is formatted as a request Q4S-ALERT message.
message unless there is an error condition, but with an answer If there is an error condition, then a response message is sent.
formatted as a request Q4S-ALERT message. The response to a Q4S-ALERT request The response to a Q4S-ALERT request is not cacheable.</t>
is not cacheable.</t> <t>
This method <bcp14>MUST</bcp14> be initiated by the server in both alerting
<t> modes. In the Q4S-aware-network alerting mode, the Q4S-ALERT messages
This method MUST be initiated by the server in both alerting are sent by the server to the client, advising the
modes. In Q4S-aware-network alerting mode, the Q4S-ALERT messages network to react by itself. In the Reactive alerting mode, alert
are fired by the server and sent to the client, advising the
network to react by itself. In Reactive alerting mode, alert
notifications are triggered by the server stack and sent to the notifications are triggered by the server stack and sent to the
Actuator(see Figure1 "Reactive Scenario").</t> Actuator (see <xref target="ref-reactive-scenario" format="default"/>, "React
ive Scenario").</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Client----q4s----SERVER STACK--->ACTUATOR-->APP OR POLICY SERVER Client----q4s----SERVER STACK--->ACTUATOR-->APP OR POLICY SERVER
]]></artwork> ]]></artwork>
</figure> <t>
<t>
The way in which the server stack notifies the Actuator is The way in which the server stack notifies the Actuator is
implementation dependent, and the communication between the implementation dependent, and the communication between the
Actuator and the network policy server is defined by the protocol Actuator and the network policy server is defined by the protocol
and API that the policy server implements.</t> and API that the policy server implements.</t>
</section>
</section> <section anchor="sec-5.6" numbered="true" toc="default">
<name>Q4S-RECOVERY</name>
<section title="Q4S-RECOVERY" anchor="section-5.6"><t> <t>
This is the request message that Q4S generates when the This is the request message that Q4S generates when the
measurements indicate that quality constraints were being violated measurements indicate that quality constraints, which had been violated,
but they have been fulfilled during a period of time already have been fulfilled during a period of time
(recovery pause). It is used during the negotiation and continuity ("recovery-pause"). It is used during the Negotiation and Continuity
phases.</t> phases.</t>
<t>
<t> This informative message indicates that the "qos-level" could be
This informative message indicates that the qos-level could be increased gradually until the initial "qos-level" is recovered (the
increased gradually until the initial qos-level is recovered (the "qos-level" established at the beginning of the session that was
qos-level established at the beginning os the session of that was decreased during violation of constraints. See <xref target="sec-7.9" format=
decreased during violation of constraints). The Q4S-RECOVERY "default"/>).
The Q4S-RECOVERY
message does not contain any detail on the actions to be taken, message does not contain any detail on the actions to be taken,
which depends on the agreements between all involved parties.</t> which depends on the agreements between all involved parties.</t>
<t>
<t> The answer to a Q4S-RECOVERY request is formatted as a request
Q4S-RECOVERY request MUST NOT be answered with a response message Q4S-RECOVERY message. A Q4S-RECOVERY request <bcp14>MUST NOT</bcp14> be answe
unless there is an error condition, but with an answer formatted red
as a request Q4S-RECOVERY message. The response to a Q4S-RECOVERY with a response message unless there is an error condition.
request is not cacheable.</t> The response to a Q4S-RECOVERY request is not cacheable.</t>
<t>
<t> Like the Q4S-ALERT message, the Q4S-RECOVERY method is always
As for the Q4S-ALERT message, the Q4S-RECOVERY method is always initiated by the server in both alerting modes. In the
initiated by the server in both alerting modes. In Q4S-aware-network alerting Q4S-aware-network alerting mode, the Q4S-RECOVERY messages are sent by the
mode, the Q4S-RECOVERY messages are fired by the server to the client, advising the network to react by
server and sent to the client, advising the network to react by itself. In the Reactive alerting mode, recovery notifications are
itself. In Reactive alerting mode, recovery notifications are triggered by the server stack and sent to the Actuator (see <xref target="ref
triggered by the server stack and sent to the Actuator(see Figure1 -reactive-scenario" format="default"/>,
"Reactive Scenario").</t> "Reactive Scenario").</t>
</section>
</section> <section anchor="sec-5.7" numbered="true" toc="default">
<name>CANCEL</name>
<section title="CANCEL" anchor="section-5.7"><t> <t>
The semantics of CANCEL message is the release of the Q4S session The purpose of the CANCEL message is the release of the Q4S
id and the possible resources assigned to the session. This Session-Id and the possible resources assigned to the session. This
message could be triggered by Q4S stack or by the application message could be triggered by the Q4S stack or by the application
using the stack (through an implementation dependent API).</t> using the stack (through an implementation-dependent API).</t>
<t>
<t>
In the same way as Q4S-ALERT, CANCEL must not be answered with a 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 messag e.</t> response message, but with an answer formatted as a request Q4S-CANCEL messag e.</t>
<t>
<t> In the Reactive scenario, the server stack <bcp14>MUST</bcp14> react to the Q
In the Reactive scenario, the server stack MUST react to the Q4S 4S
CANCEL messages received from the client by forwarding a cancel CANCEL messages received from the client by forwarding a cancel
notification to the Actuator, in order to release possible notification to the Actuator, in order to release possible
assigned resources for the session (at application or at policy assigned resources for the session (at the application or at the policy
server). The Actuator MUST answer the cancel notification with a server). The Actuator <bcp14>MUST</bcp14> answer the cancel notification with
a
cancel acknowledge towards the server stack, acknowledging the cancel acknowledge towards the server stack, acknowledging the
reception.</t> reception.</t>
</section>
</section> </section>
<section anchor="sec-6" numbered="true" toc="default">
</section> <name>Response Codes</name>
<t>
<section title="Response Codes" anchor="section-6"><t> Q4S response codes are used for TCP and UDP. However, in UDP, only
Q4S response codes are used for TCP and UDP. However, in UDP only
the response code 200 is used.</t> the response code 200 is used.</t>
<t>
<t>
The receiver of an unknown response code must take a generic The receiver of an unknown response code must take a generic
action for the received error group (1XX, 2XX, 3XX, 4XX, 5XX, action for the received error group (1xx, 2xx, 3xx, 4xx, 5xx,
6XX). In case of unknown error group, the expected action should 6xx). In case of an unknown error group, the expected action should
be the same as with 6XX error group.</t> be the same as with the 6xx error group.</t>
<section anchor="sec-6.1" numbered="true" toc="default">
<section title="100 Trying" anchor="section-6.1"><t> <name>100 Trying</name>
<t>
This response indicates that the request has been received by the This response indicates that the request has been received by the
next-hop server and that some unspecified action is being taken on next-hop server and that some unspecified action is being taken on
behalf of this request (for example, a database is being behalf of this request (for example, a database is being
consulted). This response, like all other provisional responses, consulted). This response, like all other provisional responses,
stops retransmissions of a Q4S-ALERT during the alert-pause time.</t> stops retransmissions of a Q4S-ALERT during the "alert-pause" time.</t>
</section>
</section> <section anchor="sec-6.2" numbered="true" toc="default">
<name>Success 2xx</name>
<section title="Success 2xx" anchor="section-6.2"><t> <t>
2xx responses give information about success of a request.</t> 2xx responses give information about the success of a request.</t>
<section anchor="sec-6.2.1" numbered="true" toc="default">
<section title="200 OK" anchor="section-6.2.1"><t> <name>200 OK</name>
<t>
The request has succeeded.</t> The request has succeeded.</t>
</section>
</section> </section>
<section anchor="sec-6.3" numbered="true" toc="default">
</section> <name>Redirection 3xx</name>
<t>
<section title="Redirection 3xx" anchor="section-6.3"><t> 3xx responses give information about the user's new location or
3xx responses give information about the user's new location, or
about alternative services that might be able to satisfy the about alternative services that might be able to satisfy the
request.</t> request.</t>
<t>
<t> The requesting client <bcp14>SHOULD</bcp14> retry the request at the new
The requesting client SHOULD retry the request at the new
address(es) given by the Location header field.</t> address(es) given by the Location header field.</t>
</section>
</section> <section anchor="sec-6.4" numbered="true" toc="default">
<name>Request Failure 4xx</name>
<section title="Request Failure 4xx" anchor="section-6.4"><t> <t>
4xx responses are definite failure responses from a particular 4xx responses are definite failure responses from a particular
server. The client SHOULD NOT retry the same request without server. The client <bcp14>SHOULD NOT</bcp14> retry the same request without
modification (for example, adding appropriate headers or SDP modification (for example, adding appropriate header fields or SDP
values). However, the same request to a different server might be values). However, the same request to a different server might be
successful.</t> successful.</t>
<section anchor="sec-6.4.1" numbered="true" toc="default">
<section title="400 Bad Request" anchor="section-6.4.1"><t> <name>400 Bad Request</name>
<t>
The request could not be understood due to malformed syntax. The The request could not be understood due to malformed syntax. The
Reason-Phrase SHOULD identify the syntax problem in more detail, Reason-Phrase <bcp14>SHOULD</bcp14> identify the syntax problem in more detai l,
for example, "Missing Sequence-Number header field".</t> for example, "Missing Sequence-Number header field".</t>
</section>
</section> <section anchor="sec-6.4.2" numbered="true" toc="default">
<name>404 Not Found</name>
<section title="404 Not Found" anchor="section-6.4.2"><t> <t>
The server has definitive information that the user does not exist The server has definitive information that the user does not exist
at the domain specified in the Request-URI. This status is also 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 returned if the domain in the Request-URI does not match any of
the domains handled by the recipient of the request.</t> the domains handled by the recipient of the request.</t>
</section>
</section> <section anchor="sec-6.4.3" numbered="true" toc="default">
<name>405 Method Not Allowed</name>
<section title="405 Method Not Allowed" anchor="section-6.4.3"><t> <t>
The method specified in the Request-Line is understood, but not The method specified in the Request-Line is understood, but not
allowed for the address identified by the Request-URI.</t> allowed for the address identified by the Request-URI.</t>
<t>
<t> The response <bcp14>MUST</bcp14> include an Allow header field containing a l
The response MUST include an Allow header field containing a list ist
of valid methods for the indicated address.</t> of valid methods for the indicated address.</t>
</section>
</section> <section anchor="sec-6.4.4" numbered="true" toc="default">
<name>406 Not Acceptable</name>
<section title="406 Not Acceptable" anchor="section-6.4.4"><t> <t>
The resource identified by the request is only able of generating The resource identified by the request is only able to generate
response entities that have content characteristics not acceptable response entities that have content characteristics that are not acceptable
according to the Accept header field sent in the request.</t> according to the Accept header field sent in the request.</t>
</section>
</section> <section anchor="sec-6.4.5" numbered="true" toc="default">
<name>408 Request Timeout</name>
<section title="408 Request Timeout" anchor="section-6.4.5"><t> <t>
The server could not produce a response within a suitable amount The server could not produce a response within a suitable amount
of time, and the client MAY repeat the request without of time, and the client <bcp14>MAY</bcp14> repeat the request without
modifications at any later time</t> modifications at any later time.</t>
</section>
</section> <section anchor="sec-6.4.6" numbered="true" toc="default">
<name>413 Request Entity Too Large</name>
<section title="413 Request Entity Too Large" anchor="section-6.4.6"><t> <t>
The server is refusing to process a request because the request The server is refusing to process a request because the request
entity-body is larger than the one that the server is willing or entity-body is larger than the one that the server is willing or
able to process. The server MAY close the connection to prevent able to process. The server <bcp14>MAY</bcp14> close the connection to preven t
the client from continuing the request.</t> the client from continuing the request.</t>
</section>
</section> <section anchor="sec-6.4.7" numbered="true" toc="default">
<name>414 Request-URI Too Long</name>
<section title="414 Request-URI Too Long" anchor="section-6.4.7"><t> <t>
The server is refusing to process the request because the Request-URI is long er than the one that the server accepts.</t> The server is refusing to process the request because the Request-URI is long er than the one that the server accepts.</t>
</section>
</section> <section anchor="sec-6.4.8" numbered="true" toc="default">
<name>415 Unsupported Media Type</name>
<section title="415 Unsupported Media Type" anchor="section-6.4.8"><t> <t>
The server is refusing to process the request because the message 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 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 the requested method. The server <bcp14>MUST</bcp14> return a list of accepta ble
formats using the Accept, Accept-Encoding, or Accept-Language formats using the Accept, Accept-Encoding, or Accept-Language
header field, depending on the specific problem with the content.</t> header field, depending on the specific problem with the content.</t>
</section>
</section> <section anchor="sec-6.4.9" numbered="true" toc="default">
<name>416 Unsupported URI Scheme</name>
<section title="416 Unsupported URI Scheme" anchor="section-6.4.9"><t> <t>
The server cannot process the request because the scheme of the The server cannot process the request because the scheme of the
URI in the Request-URI is unknown to the server.</t> URI in the Request-URI is unknown to the server.</t>
</section>
</section> </section>
<section anchor="sec-6.5" numbered="true" toc="default">
</section> <name>Server Failure 5xx</name>
<t>
<section title="Server Failure 5xx" anchor="section-6.5"><t>
5xx responses are failure responses given when a server itself is 5xx responses are failure responses given when a server itself is
having trouble.</t> having trouble.</t>
<section anchor="sec-6.5.1" numbered="true" toc="default">
<section title="500 Server Internal Error" anchor="section-6.5.1"><t> <name>500 Server Internal Error</name>
<t>
The server encountered an unexpected condition that prevented it The server encountered an unexpected condition that prevented it
from fulfilling the request. The client MAY display the specific from fulfilling the request. The client <bcp14>MAY</bcp14> display the specif
error condition and MAY retry the request after several seconds.</t> ic
error condition and <bcp14>MAY</bcp14> retry the request after several second
</section> s.</t>
</section>
<section title="501 Not Implemented" anchor="section-6.5.2"><t> <section anchor="sec-6.5.2" numbered="true" toc="default">
<name>501 Not Implemented</name>
<t>
The server does not support the functionality required to fulfill The server does not support the functionality required to fulfill
the request. This is the appropriate response when a Server does the request. This is the appropriate response when a server does
not recognize the request method and it is not capable of not recognize the request method, and it is not capable of
supporting it for any user.</t> supporting it for any user.</t>
<t>
<t>
Note that a 405 (Method Not Allowed) is sent when the server Note that a 405 (Method Not Allowed) is sent when the server
recognizes the request method, but that method is not allowed or recognizes the request method, but that method is not allowed or
supported.</t> supported.</t>
</section>
</section> <section anchor="sec-6.5.3" numbered="true" toc="default">
<name>503 Service Unavailable</name>
<section title="503 Service Unavailable" anchor="section-6.5.3"><t> <t>
The server is temporarily unable to process the request due to a The server is temporarily unable to process the request due to a
temporary overloading or maintenance of the server. The server MAY temporary overloading or maintenance of the server. The server <bcp14>MAY</bc p14>
indicate when the client should retry the request in a Retry-After 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 header field. If no Retry-After is given, the client <bcp14>MUST</bcp14> act as
if it had received a 500 (Server Internal Error) response.</t> if it had received a 500 (Server Internal Error) response.</t>
<t>
<t> A client receiving a 503 (Service Unavailable) <bcp14>SHOULD</bcp14> attempt
A client receiving a 503 (Service Unavailable) SHOULD attempt to to
forward the request to an alternate server. It SHOULD NOT forward forward the request to an alternate server. It <bcp14>SHOULD NOT</bcp14> forw
ard
any other requests to that server for the duration specified in any other requests to that server for the duration specified in
the Retry-After header field, if present.</t> the Retry-After header field, if present.</t>
<t>
<t> Servers <bcp14>MAY</bcp14> refuse the connection or drop the request instead
Servers MAY refuse the connection or drop the request instead of of
responding with 503 (Service Unavailable).</t> responding with 503 (Service Unavailable).</t>
</section>
</section> <section anchor="sec-6.5.4" numbered="true" toc="default">
<name>504 Server Time-Out</name>
<section title="504 Server Time-out" anchor="section-6.5.4"><t> <t>
The server did not receive a timely response from an external The server did not receive a timely response from an external
server it accessed in attempting to process the request.</t> server it accessed in attempting to process the request.</t>
</section>
</section> <section anchor="sec-6.5.5" numbered="true" toc="default">
<name>505 Version Not Supported</name>
<section title="505 Version Not Supported" anchor="section-6.5.5"><t> <t>
The server does not support, or refuses to support, the Q4S The server does not support, or refuses to support, the Q4S
protocol version that was used in the request. The server is protocol version that was used in the request. The server is
indicating that it is unable or unwilling to complete the request indicating that it is unable or unwilling to complete the request
using the same major version as the client, other than with this using the same major version as the client, other than with this
error message.</t> error message.</t>
<t>
<t> In the case that the Q4S version is not supported, this error may be
In the case that Q4S version is not supported, this error may be sent by the server in the Handshake phase just after receiving the
sent by the server in handshake phase just after receiving the
first BEGIN message from client.</t> first BEGIN message from client.</t>
</section>
</section> <section anchor="sec-6.5.6" numbered="true" toc="default">
<name>513 Message Too Large</name>
<section title="513 Message Too Large" anchor="section-6.5.6"><t> <t>
The server was unable to process the request since the message The server was unable to process the request because the message
length exceeded its capabilities.</t> length exceeded its capabilities.</t>
</section>
</section> </section>
<section anchor="sec-6.6" numbered="true" toc="default">
</section> <name>Global Failures 6xx</name>
<t>
<section title="Global Failures 6xx" anchor="section-6.6"><t>
6xx responses indicate that a server has definitive information 6xx responses indicate that a server has definitive information
about a particular policy not satisfied for processing the about a particular policy not satisfied for processing the
request.</t> request.</t>
<section anchor="sec-6.6.1" numbered="true" toc="default">
<section title="600 session does not exist" anchor="section-6.6.1"><t> <name>600 Session Does Not Exist</name>
The Session-Id is not valid</t> <t>
The Session-Id is not valid.</t>
</section> </section>
<section anchor="sec-6.6.2" numbered="true" toc="default">
<section title="601 quality level not allowed" anchor="section-6.6.2"><t> <name>601 Quality Level Not Allowed</name>
The QOS level requested is not allowed for the pair client/server</t> <t>
The "qos-level" requested is not allowed for the client/server pair.</t>
</section> </section>
<section anchor="sec-6.6.3" numbered="true" toc="default">
<section title="603 Session not allowed" anchor="section-6.6.3"><t> <name>603 Session Not Allowed</name>
The session is not allowed due to some policy (number of sessions <t>
allowed for the server is exceeded, or the time band of the Q4S-ALERT is not The session is not allowed due to some policy (the number of sessions
allowed for the pair client/server, etc.).</t> allowed for the server is exceeded, or the time band of the Q4S-ALERT
is not allowed for the client/server pair, etc.).</t>
</section> </section>
<section anchor="sec-6.6.4" numbered="true" toc="default">
<section title="604 authorization not allowed" anchor="section-6.6.4"><t> <name>604 Authorization Not Allowed</name>
<t>
The policy server does not authorize the Q4S-ALERT quality session The policy server does not authorize the Q4S-ALERT quality session
improvement operation due to an internal or external reason.</t> improvement operation due to an internal or external reason.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sec-7" numbered="true" toc="default">
<name>Protocol</name>
</section> <t>
<section title="Protocol" anchor="section-7"><t>
This section describes the measurement procedures, the SDP This section describes the measurement procedures, the SDP
structure of the Q4S messages, the different Q4S protocol phases structure of the Q4S messages, the different Q4S protocol phases,
and the messages exchanged in them.</t> and the messages exchanged in them.</t>
<section anchor="sec-7.1" numbered="true" toc="default">
<section title="Protocol Phases" anchor="section-7.1"><t> <name>Protocol Phases</name>
All elements of the IP network contribute to the quality in <t>
terms of latency, jitter, bandwidth and packet loss. All these 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, elements have their own quality policies in terms of priorities,
traffic mode, etc. and each element has its own way to manage the traffic mode, etc., and each element has its own way to manage the
quality. The purpose of a quality connection is to establish an quality. The purpose of a quality connection is to establish
end-to-end communication with enough quality for the application end-to-end communication with enough quality for the application
to function flawlessly.</t> to function flawlessly.</t>
<t>
<t>
To monitor quality constraints of the application, four phases are To monitor quality constraints of the application, four phases are
defined and can be seen in figure 5:</t> defined and can be seen in <xref target="ref-session-lifetime-phases" format=
"default"/>:</t>
<figure title="Session lifetime phases" anchor="ref-session-lifetime-phas <figure anchor="ref-session-lifetime-phases">
es"><artwork><![CDATA[ <name>Session Lifetime Phases</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| | | |
| | | |
| Handshake ---> Negotiation -+--> Continuity ----> Termination | | Handshake ---> Negotiation -+--> Continuity ----> Termination |
| A | (app start) | (app end) | | A | (app start) | (app end) |
| | V A V A | | | V A V A |
| | violated | violated | | | | violated | violated | |
| | constraints | constraints | | | | constraints | constraints | |
| | | | |_______| ____| | | | | | |_______| ____| |
| | | | +-------+ | | | | | | +-------+ | |
| | | | | | | | | | | |
| +------+ +---------------------+ | | +------+ +---------------------+ |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="symbols"><t>Handshake phase: in which the server is conta <dl spacing="normal">
cted by the <dt>Handshake phase:</dt><dd>in which the server is contacted by the
client and in the answer message the quality constraints for client, and in the answer message, the quality constraints for
the application is communicated embedded in an SDP.</t> the application are communicated in the embedded SDP.</dd>
<dt>Negotiation phase:</dt><dd>in which the quality of the connection
<t>Negotiation phase: in which the quality of the connection is is
measured in both directions (latency, jitter, bandwidth and measured in both directions (latency, jitter, bandwidth, and
packet loss), and Q4S messages may be sent in order to alert packet loss), and Q4S messages may be sent in order to alert
if the measured quality does not meet the constraints. This if the measured quality does not meet the constraints. This
phase is iterative until quality constraints are reached, or phase is iterative until quality constraints are reached, or
the session is cancelled after a number of measurement cycles the session is canceled after a number of measurement cycles
with consistent violation of the quality constraints. The with consistent violation of the quality constraints. The
number of measurement cycles executed depends on the qos-level which is in number of measurement cycles executed depends on the "qos-level",
cremented in each cycle until a maximum qos-level value is reached. Just after r which is incremented in each cycle until a maximum "qos-level" value
eaching the quality is reached. Just after reaching the quality
requirements, Q4S provides a simple optional mechanism using requirements, Q4S provides a simple optional mechanism using
HTTP to start the application.</t> HTTP to start the application.</dd>
<dt>Continuity phase:</dt><dd>in which quality is continuously measure
<t>Continuity phase: in which quality is continuously measured. d.
In this phase the measurements MUST avoid disturbing the In this phase, the measurements <bcp14>MUST</bcp14> avoid disturbing the
application by consuming network resources. If quality application by consuming network resources. If quality
constraints are not met, the server stack will notify the constraints are not met, the server stack will notify the
Actuator with an alert notification. If later the quality Actuator with an alert notification. If later the quality
improves, the server stack will notify the Actuator, in this improves, the server stack will notify the Actuator, in this
case with a recovery notification. After several alert case with a recovery notification. After several alert
notifications with no quality improvements, the Q4S stack notifications with no quality improvements, the Q4S stack
SHOULD move to Termination phase.</t> <bcp14>SHOULD</bcp14> move to the Termination phase.</dd>
<dt>Termination phase:</dt><dd>in which the Q4S session is terminated.
<t>Termination phase: in which the Q4S session is terminated. The application may be closed also or may not start.</dd>
The application may be closed too or may not start.</t> </dl>
</section>
</list> <section anchor="sec-7.2" numbered="true" toc="default">
</t> <name>SDP Structure</name>
<t>
</section>
<section title="SDP Structure" anchor="section-7.2"><t>
The original goal of SDP was to announce necessary information for The original goal of SDP was to announce necessary information for
the participants and multicast MBONE (Multicast Backbone) the participants and multicast MBONE (Multicast Backbone)
applications. Right now, its use has been extended to the applications. Right now, its use has been extended to the
announcement and the negotiation of multimedia sessions. The announcement and the negotiation of multimedia sessions. The
purpose of Q4S is not to establish media stream sessions, but to purpose of Q4S is not to establish media stream sessions, but to
monitor a quality connection. This connection may be later used to monitor a quality connection. This connection may be later used to
establish any type of session including media sessions; Q4S does establish any type of session including media sessions; Q4S does
not impose any conditions on the type of communication requiring not impose any conditions on the type of communication requiring
quality parameters.</t> quality parameters.</t>
<t>
<t>
SDP will be used by Q4S to exchange quality constraints and will SDP will be used by Q4S to exchange quality constraints and will
therefore always have all the media attributes ("m") set to zero.</t> therefore always have all the media descriptions ("m=") set to zero.</t>
<t>
<t>
The SDP embedded in the messages is the container of the quality The SDP embedded in the messages is the container of the quality
parameters. As these may vary depending on the direction of the parameters. As these may vary depending on the direction of the
communication (to and from the client) all quality parameters need communication (to and from the client), all quality parameters need
to specify the uplink and downlink values: &lt;uplink&gt; / &lt;downlink&gt;. to specify the uplink and downlink values: &lt;uplink&gt; / &lt;downlink&gt;
When one or both of these values are empty, it MUST be understood (see <xref target="sec-7.5.3" format="default"/> for an example).
When one or both of these values are empty, it <bcp14>MUST</bcp14> be underst
ood
as needing no constraint on that parameter and/or that direction.</t> as needing no constraint on that parameter and/or that direction.</t>
<t>
<t> The uplink direction <bcp14>MUST</bcp14> be considered as being the communica
The uplink direction MUST be considered as being the communication tion
from the client to the server. The downlink direction MUST be from the client to the server. The downlink direction <bcp14>MUST</bcp14> be
considered as being the communication from the server to the considered as being the communication from the server to the
client.</t> client.</t>
<t>
<t>
The SDP information can comprise all or some of the following The SDP information can comprise all or some of the following
parameters shown in the example below. This is an example of an 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 SDP message used by Q4S included in the 200 OK response to a Q4S
BEGIN request.</t> BEGIN request.</t>
<sourcecode type="sdp"><![CDATA[
<figure><artwork><![CDATA[
v=0 v=0
o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33 o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33
s=Q4S s=Q4S
i=Q4S parameters i=Q4S parameters
t=0 0 t=0 0
a=qos-level:0/0 a=qos-level:0/0
a=alerting-mode:Reactive a=alerting-mode:Reactive
a=alert-pause:5000 a=alert-pause:5000
a=public-address:client IP4 198.51.100.51 a=public-address:client IP4 198.51.100.51
a=public-address:server IP4 198.51.100.58 a=public-address:server IP4 198.51.100.58
skipping to change at line 1770 skipping to change at line 1669
a=bandwidth:20/6000 a=bandwidth:20/6000
a=packetloss:0.50/0.50 a=packetloss:0.50/0.50
a=flow:app clientListeningPort TCP/10000-20000 a=flow:app clientListeningPort TCP/10000-20000
a=flow:app clientListeningPort UDP/15000-18000 a=flow:app clientListeningPort UDP/15000-18000
a=flow:app serverListeningPort TCP/56000 a=flow:app serverListeningPort TCP/56000
a=flow:app serverListeningPort UDP/56000 a=flow:app serverListeningPort UDP/56000
a=flow:q4s clientListeningPort UDP/55000 a=flow:q4s clientListeningPort UDP/55000
a=flow:q4s clientListeningPort TCP/55001 a=flow:q4s clientListeningPort TCP/55001
a=flow:q4s serverListeningPort UDP/56000 a=flow:q4s serverListeningPort UDP/56000
a=flow:q4s serverListeningPort TCP/56001 a=flow:q4s serverListeningPort TCP/56001
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
As quality constraints may be changed by applications at any time As quality constraints may be changed by applications at any time
during the Q4S session lifetime, any Q4S 200 OK response sent by during the Q4S session lifetime, any Q4S 200 OK response sent by
the server to the client in the Negotiation and Continuity phases the server to the client in the Negotiation and Continuity phases
could also include an SDP body with the new quality requirements could also include an SDP body with the new quality requirements
stated by the applications from then on. Therefore, in response to stated by the applications from then on. Therefore, in response to
any PING request sent by the client to the server, the server any PING request sent by the client to the server, the server
could send a Q4S 200 OK with an SDP message embedded that could send a Q4S 200 OK with an embedded SDP message that
specifies new quality constraints requested by the application.</t> specifies new quality constraints requested by the application.</t>
<section anchor="sec-7.2.1" numbered="true" toc="default">
<section title="&quot;qos-level&quot; attribute" anchor="section-7.2.1">< <name>"qos-level" Attribute</name>
t> <t>
The "qos-level" attribute contains the QoS level for uplink and The "qos-level" attribute contains the QoS level for uplink and
downlink. Default values are 0 for both directions. The meaning of downlink. Default values are 0 for both directions. The meaning of
each level is out of scope of Q4S, but a higher level SHOULD each level is out of scope of Q4S, but a higher level <bcp14>SHOULD</bcp14>
correspond to a better service quality.</t> correspond to a better service quality.</t>
<t>
<t>
Appropriate attribute values: [0..9] "/" [0..9]</t> Appropriate attribute values: [0..9] "/" [0..9]</t>
<t>
<t>
The "qos-level" attribute may be changed during the session The "qos-level" attribute may be changed during the session
lifetime raising or lowering the value as necessary following the lifetime, raising or lowering the value as necessary following the
network measurements and the application needs.</t> network measurements and the application needs.</t>
</section>
</section> <section anchor="sec-7.2.2" numbered="true" toc="default">
<name>"alerting-mode" Attribute</name>
<section title="&quot;alerting-mode&quot; attribute" anchor="section-7.2. <t>
2"><t>
The "alerting-mode" attribute specifies the player in charge of The "alerting-mode" attribute specifies the player in charge of
triggering Q4S alerts in case of constraint violation. There are triggering Q4S alerts in the case of constraint violation. There are
two possible values:</t> two possible values:</t>
<t>
<t>
Appropriate attribute values: &lt;"Q4S-aware-network"|"Reactive"&gt;</t> Appropriate attribute values: &lt;"Q4S-aware-network"|"Reactive"&gt;</t>
<dl newline="false" spacing="normal" indent="6">
<t><list style="format (%c)"> <dt>Q4S-aware-network:</dt> <dd>Q4S-ALERT messages are triggered by
<t>Q4S-aware-network: Q4S ALERT messages are triggered by the the
server to the client. In this case the network is supposed to server to the client. In this case, the network is supposed to
be Q4S aware, and reacts by itself to these alerts. be Q4S aware, and reacts by itself to these alerts.</dd>
</t> <dt> Reactive:</dt> <dd>alert notifications are sent by the server s
tack to
<t> Reactive: alert notifications are sent by the server stack to the Actuator. In this case, the network is not Q4S aware, and a
the Actuator. In this case the network is not Q4S aware and a
specific node (Actuator) is in charge of triggering tuning specific node (Actuator) is in charge of triggering tuning
mechanisms., either on the network or in the application. mechanisms, either on the network or in the application.
</t> </dd>
</dl>
</list> <t>
</t> The "alerting-mode" attribute is optional, and if not present,
<t>
The "alerting-mode" attribute is optional and if not present
Reactive alerting mode is assumed.</t> Reactive alerting mode is assumed.</t>
</section>
</section> <section anchor="sec-7.2.3" numbered="true" toc="default">
<name>"alert-pause" Attribute</name>
<section title="&quot;alert-pause&quot; attribute" anchor="section-7.2.3" <t>
><t>
In the Q4S-aware-network scenario, the "alert-pause" attribute In the Q4S-aware-network scenario, the "alert-pause" attribute
specifies the amount of time (in milliseconds) the server waits specifies the amount of time (in milliseconds) the server waits
between consecutive Q4S ALERT messages sent to the client. In the between consecutive Q4S-ALERT messages sent to the client. In the
Reactive scenario, the "alert-pause" attribute specifies the Reactive scenario, the "alert-pause" attribute specifies the
amount of time (in milliseconds) the server stack waits between amount of time (in milliseconds) the server stack waits between
consecutive alert notifications sent to the Actuator. Measurements consecutive alert notifications sent to the Actuator. Measurements
are not stopped in Negotiation or Continuity Phases during this are not stopped in Negotiation or Continuity phases during this
period of time, but no Q4S ALERT messages or alert notifications period of time, but no Q4S-ALERT messages or alert notifications
are fired, even with violated quality constraints, allowing either are fired, even with violated quality constraints, allowing for either
network reconfigurations or application adjustments.</t> network reconfigurations or application adjustments.</t>
<t>
<t>
Appropriate attribute values: [0..60000]</t> Appropriate attribute values: [0..60000]</t>
</section>
</section> <section anchor="sec-7.2.4" numbered="true" toc="default">
<name>"recovery-pause" Attribute</name>
<section title="&quot;recovery-pause&quot; attribute" anchor="section-7.2 <t>
.4"><t>
In the Q4S-aware-network scenario, the "recovery-pause" attribute In the Q4S-aware-network scenario, the "recovery-pause" attribute
specifies the amount of time (in milliseconds) the server waits specifies the amount of time (in milliseconds) the server waits
for initiating the qos-level recovery process. Once the recovery for initiating the "qos-level" recovery process. Once the recovery
process has started, the "recovery-pause" attribute also states process has started, the "recovery-pause" attribute also states
the amount of time (in milliseconds) between consecutive Q4S-RECOVERY message the amount of time (in milliseconds) between consecutive Q4S-RECOVERY
s sent by the server to the client (in the Q4S-aware-network scenario), or betwe messages sent by the server to the client (in the Q4S-aware-network scenario)
en recovery notifications sent by or between recovery notifications sent by
the server stack to the Actuator (in the Reactive scenario).</t> the server stack to the Actuator (in the Reactive scenario).</t>
<t>
<t>
Appropriate attribute values: [0..60000]</t> Appropriate attribute values: [0..60000]</t>
</section>
</section> <section anchor="sec-7.2.5" numbered="true" toc="default">
<name>"public-address" Attributes</name>
<section title="&quot;public-address&quot; attributes" anchor="section-7. <t>
2.5"><t>
This attribute contains the public IP address of the client and This attribute contains the public IP address of the client and
the server. The server fills these attributes with his own public the server. The server fills these attributes with its own public
IP address and the public IP address of the first message received IP address and the public IP address of the first message received
from the client in the handshake phase.</t> from the client in the Handshake phase.</t>
<t>
<t>
The purpose of these attributes is to make available the The purpose of these attributes is to make available the
addressing information to network policy server or other external addressing information to the network policy server or other external
entities in charge of processing Q4S-ALERT messages.</t> entities in charge of processing Q4S-ALERT messages.</t>
<t>
<t> Appropriate attribute values: &lt;"client"|"server"&gt; &lt;"IP4"|"IP6"&gt;
Appropriate attribute values:&lt;"client"|"server"&gt;&lt;"IP4"|"IP6"&gt;
&lt;value of IP address&gt;</t> &lt;value of IP address&gt;</t>
</section>
</section> <section anchor="sec-7.2.6" numbered="true" toc="default">
<name>"latency" Attribute</name>
<section title="&quot;latency&quot; attribute" anchor="section-7.2.6"><t> <t>
The maximum latency (considered equal for uplink and downlink) The maximum latency (considered equal for uplink and downlink)
tolerance are specified in the "latency" attribute, expressed in tolerance is specified in the "latency" attribute, expressed in
milliseconds. In the Q4S-aware-network scenario, if the latency milliseconds. In the Q4S-aware-network scenario, if the latency
constraints are not met, a Q4S-ALERT method will be sent to the constraints are not met, a Q4S-ALERT method will be sent to the
client. In the Reactive scenario, if the latency constraints are client. In the Reactive scenario, if the latency constraints are
not met, an alert notification will be sent to the Actuator. If not met, an alert notification will be sent to the Actuator. If
the "latency" attribute is not present or has a 0 value, no the "latency" attribute is not present or has a 0 value, no
latency constraints need to be met and no measurements MAY be latency constraints need to be met, and no measurements <bcp14>MAY</bcp14> be
taken.</t> taken.</t>
<t>
<t>
Appropriate attribute values: [0..9999]</t> Appropriate attribute values: [0..9999]</t>
</section>
</section> <section anchor="sec-7.2.7" numbered="true" toc="default">
<name>"jitter" Attribute</name>
<section title="&quot;jitter&quot; attribute" anchor="section-7.2.7"><t> <t>
The maximum uplink and downlink jitter tolerance are specified in The maximum uplink and downlink jitter tolerance is specified in
the "jitter" attribute, expressed in milliseconds. In the Q4S-aware-network s cenario, if the jitter constraints are not met, a the "jitter" attribute, expressed in milliseconds. In the Q4S-aware-network s cenario, if the jitter constraints are not met, a
Q4S-ALERT method will be sent to the client. In the Reactive Q4S-ALERT method will be sent to the client. In the Reactive
scenario, if the latency constraints are not met, an alert scenario, if the latency constraints are not met, an alert
notification will be sent to the Actuator. If "jitter" attribute 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 is not present or has a 0 value, no jitter constraints need to be
met and no measurements MAY be taken.</t> met, and no measurements <bcp14>MAY</bcp14> be taken.</t>
<t>
<t>
Appropriate attribute values: [0..9999] "/" [0..9999]</t> Appropriate attribute values: [0..9999] "/" [0..9999]</t>
</section>
</section> <section anchor="sec-7.2.8" numbered="true" toc="default">
<name>"bandwidth" Attribute</name>
<section title="&quot;bandwidth&quot; attribute" anchor="section-7.2.8">< <t>
t> The minimum uplink and downlink bandwidth is specified in the
The minimum uplink and downlink bandwidth are specified in the
"bandwidth" attribute, expressed in kbps. In the Q4S-aware-network "bandwidth" attribute, expressed in kbps. In the Q4S-aware-network
scenario, if the bandwidth constraints are not met, a Q4S-ALERT scenario, if the bandwidth constraints are not met, a Q4S-ALERT
method will be sent to the client. In the Reactive scenario, an method will be sent to the client. In the Reactive scenario, an
alert notification will be sent to the Actuator. If "bandwidth" alert notification will be sent to the Actuator. If the "bandwidth"
attribute is not present or has a 0 value, no bandwidth attribute is not present or has a 0 value, no bandwidth
constraints need to be met and no measurements MAY be taken.</t> constraints need to be met, and no measurements <bcp14>MAY</bcp14> be taken.<
/t>
<t> <t>
Appropriate attribute values: [0..99999] "/" [0..99999]</t> Appropriate attribute values: [0..99999] "/" [0..99999]</t>
</section>
</section> <section anchor="sec-7.2.9" numbered="true" toc="default">
<name>"packetloss" Attribute</name>
<section title="&quot;packetloss&quot; attribute" anchor="section-7.2.9"> <t>
<t> The maximum uplink and downlink packet loss tolerance is
The maximum uplink and downlink packet loss tolerance are
specified in the "packetloss" attribute expressed in percentage specified in the "packetloss" attribute expressed in percentage
(two decimal accuracy). In the Q4S-aware-network scenario, if the (two decimal accuracy). In the Q4S-aware-network scenario, if the
packetloss constraints are not met, a Q4S-ALERT method will be packetloss constraints are not met, a Q4S-ALERT method will be
sent to the client. In the Reactive scenario, an alert sent to the client. In the Reactive scenario, an alert
notification will be sent to the Actuator. If "packetloss" notification will be sent to the Actuator. If the "packetloss"
attribute is not present or has a 0 value, no packetloss attribute is not present or has a 0 value, no packet loss
constraints need to be met and no measurements MAY be taken.</t> constraints need to be met, and no measurements <bcp14>MAY</bcp14> be taken.<
/t>
<t> <t>
Appropriate attribute values: [0.00 ..100.00] "/"[0.00 ..100.00]</t> Appropriate attribute values: [0.00 ..100.00] "/"[0.00 ..100.00]</t>
</section>
</section> <section anchor="sec-7.2.10" numbered="true" toc="default">
<name>"flow" Attributes</name>
<section title="&quot;flow&quot; attributes" anchor="section-7.2.10"><t> <t>
These attributes specify the flows (protocol, destination These attributes specify the flows (protocol, destination
IP/ports) of data over TCP and UDP ports to be used in uplink and IP/ports) of data over TCP and UDP ports to be used in uplink and
downlink communications.</t> downlink communications.</t>
<t>
<t>
Several "flow" attributes can be defined. These flows identify the Several "flow" attributes can be defined. These flows identify the
listening port (client or server), the protocol (TCP or UDP) (RFC listening port (client or server), the protocol (TCP <xref target="RFC0793" f
793 <xref target="ref-16"/> and RFC 768 <xref target="ref-17"/>) with the ran ormat="default"/>
ge of ports that are going or UDP <xref target="RFC0768" format="default"/>)
with the range of ports that are going
to be used by the application and, of course, by the Q4S protocol to be used by the application and, of course, by the Q4S protocol
(for quality measurements). All defined flows (app and q4s) will (for quality measurements). All defined flows ("app" and "q4s") will
be considered within the same quality profile, which is determined be considered within the same quality profile, which is determined
by the qos-level attribute in each direction. This allows to by the "qos-level" attribute in each direction. This allows us to
assume that measurements on q4s flows are the same experimented by assume that measurements on "q4s" flows are the same as experienced by
the application which is using app flows.</t> the application, which is using "app" flows.</t>
<t>
<t> During Negotiation and Continuity phases, the specified Q4S ports
During negotiation and continuity phases the specified Q4S ports
in the "flow:q4s" attributes of SDP will be used for Q4S messages.</t> in the "flow:q4s" attributes of SDP will be used for Q4S messages.</t>
<t>
<t>
The Q4S flows comprise two UDP flows and two TCP flows (one uplink The Q4S flows comprise two UDP flows and two TCP flows (one uplink
and one downlink for each one) whereas application traffic MAY and one downlink for each one), whereas application traffic <bcp14>MAY</bcp14
consist of many flows, depending on its nature. The handshake >
consist of many flows, depending on its nature. The Handshake
phase takes place through the Q4S Contact URI, using the standard phase takes place through the Q4S Contact URI, using the standard
Q4S TCP port. However, the negotiation and continuity phases will Q4S TCP port. However, the Negotiation and Continuity phases will
take place on the specified Q4S ports (UDP and TCP) specified in take place on the Q4S ports (UDP and TCP) specified in
the SDP.</t> the SDP.</t>
<t>
<t> The "clientListeningPort" is a port on which the client listens
The "clientListeningPort" is a port in which the client listens for server requests and <bcp14>MUST</bcp14> be used as the origin port of cli
for server requests and MUST be used as origin port of client ent
responses. The "serverListeningPort" is a port in which server is responses. The "serverListeningPort" is a port on which the server is
listening for incoming messages from the client. The origin port listening for incoming messages from the client. The origin port
of server responses may be different than "serverListeningPort" of server responses may be different than the "serverListeningPort"
value.</t> value.</t>
<t>
<t> If "clientListeningPort" is zero ("a=flow:q4s clientListeningPort
If "clientListeningPort" is zero (a=flow:q4s clientListeningPort TCP/0"), the client <bcp14>MAY</bcp14> choose one randomly per OS standard
TCP/0), the client MAY choose one randomly as per OS standard
rules. Client ports inside the SDP must always be matched against rules. Client ports inside the SDP must always be matched against
actual received port values on the server side in order to deal actual received port values on the server side in order to deal
with NAT/NATP devices. If zero value or incorrect value is with NAT/NAPT devices. If a zero value or incorrect value is
present, server must set the value to the received origin port in present, the server must set the value to the received origin port in
the next message with SDP (200 OK, ALERT and CANCEL messages).</t> the next message with SDP (200 OK, ALERT, and CANCEL messages).</t>
<sourcecode type="abnf"><![CDATA[
<figure><artwork><![CDATA[
Attribute values: Attribute values:
<"q4s"|"app"> <"serverListeningPort"|"clientListeningPort"> <"q4s"|"app"> <"serverListeningPort"|"clientListeningPort">
<"UDP"|"TCP"> <0..65535>[ "-" [0..65535]] <"UDP"|"TCP"> <0..65535> [ "-" [0..65535]]
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sec-7.2.11" numbered="true" toc="default">
<name>"measurement" Attributes</name>
<section title="&quot;measurement&quot; attributes" anchor="section-7.2.1 <t>
1"><t>
These attributes contain the measurement procedure and the results These attributes contain the measurement procedure and the results
of the quality measurements.</t> of the quality measurements.</t>
<t>
<t>
Measurement parameters are included using the session attribute Measurement parameters are included using the session attribute
"measurement". The first measurement parameter is the procedure. "measurement". The first measurement parameter is the procedure.
Q4S provides a "default" procedure for measurements, but others Q4S provides a "default" procedure for measurements, but others
like RTP/RTCP might be used and defined later. This document will like RTP/RTCP might be used and defined later. This document will
only define and explain the "default" procedure.</t> only define and explain the "default" procedure.</t>
<t>
<t> In the initial client request, a set of measurement procedures can
In the initial client request a set of measurement procedures can
be sent to the server for negotiation. One measurement procedure be sent to the server for negotiation. One measurement procedure
line MUST be included in the SDP message for each proposed method. line <bcp14>MUST</bcp14> be included in the SDP message for each proposed met
The server MUST answer with only one line with the chosen hod.
The server <bcp14>MUST</bcp14> answer with only one line with the chosen
procedure.</t> procedure.</t>
<t>
<t>
For each procedure, a set of values of parameters separated by "," For each procedure, a set of values of parameters separated by ","
can be included in the same attribute line. The amount and type of can be included in the same attribute line. The amount and type of
parameters depends on the procedure type.</t> parameters depends on the procedure type.</t>
<t>
<t> In the following example, the "default" procedure type is chosen:</t>
In the following example the "default" procedure type is chosen:</t> <sourcecode type="sdp"><![CDATA[
<figure><artwork><![CDATA[
a=measurement:procedure default(50/50,75/75,5000,40/80,100/256) a=measurement:procedure default(50/50,75/75,5000,40/80,100/256)
]]></artwork></figure> ]]></sourcecode>
<t>
<t> In the "default" procedure, the meaning of these parameters is
In the "default" procedure, the meaning of these parameters is:</t> the following:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The first parameter is the interval of time ( <li>The first parameter is the interval of time (in milliseconds)
in milliseconds) between PING requests during the Negotiation phase. Uplink
between PING requests during the negotiation phase. Uplink
and downlink values from the client's point of view are and downlink values from the client's point of view are
separated by "/". This allows having different responsiveness separated by "/". This allows different responsiveness
values depending on the control resources used in each values depending on the control resources used in each
direction.</t> direction.</li>
<li>The second parameter is the time interval (in milliseconds)
<t>The second parameter is the time interval (in milliseconds) between PING requests during the Continuity phase. Uplink and
between PING requests during the continuity phase. Uplink and downlink values are separated by "/". This allows two
downlink values are separated by "/". This allows having two
different responsiveness values depending on the control different responsiveness values depending on the control
resources used in each direction.</t> resources used in each direction.</li>
<li>The third parameter is the time interval to be used to
<t>The third parameter is the time interval to be used to measure bandwidth during the Negotiation phase.</li>
measure bandwidth during the negotiation phase.</t> <li>The fourth parameter indicates the window size for jitter and
<t>The fourth parameter indicates the window size for jitter and
latency calculations. Uplink and downlink values are latency calculations. Uplink and downlink values are
separated by "/".</t> separated by "/".</li>
<li>The fifth parameter indicates the window size for packet loss
<t>The fifth parameter indicates the window size for packet loss
calculations. Uplink and downlink values are separated by calculations. Uplink and downlink values are separated by
"/".</t> "/".</li>
</ul>
</list> <t>
</t> There are four more "measurement" attributes:</t>
<sourcecode type="sdp"><![CDATA[
<t>
There are four more measurement attributes:</t>
<figure><artwork><![CDATA[
a=measurement:latency 45 a=measurement:latency 45
a=measurement:jitter 3/12 a=measurement:jitter 3/12
a=measurement:bandwidth 200/9800 a=measurement:bandwidth 200/9800
a=measurement:packetloss 0.00/1.00 a=measurement:packetloss 0.00/1.00
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> The "measurement:latency", "measurement:jitter", "measurement:bandwidth", and
The latency, jitter, bandwidth and packet-loss measurement "measurement:packetloss"
attributes contain the values measured for each of these quality attributes contain the values measured for each of these quality
parameters in uplink and downlink directions. Notice that latency parameters in uplink and downlink directions. Notice that latency
is considered equal for uplink and downlink directions. Quality is considered equal for uplink and downlink directions. Quality
parameter values in these measurement attributes provide a parameter values in these "measurement" attributes provide a
snapshot of the quality reached and MUST only be included in Q4S-ALERT messag snapshot of the quality reached and <bcp14>MUST</bcp14> only be
es in the SDP body such that they can be protected included in Q4S-ALERT messages in the SDP body such that they can be protecte
d
from malicious attacks as these alerts include a signature of the from malicious attacks as these alerts include a signature of the
SDP body in the header. The rest of messages will include the SDP body in the header. The rest of the messages will include the
measured values in the Measurements header.</t> measured values in the Measurements header field.</t>
<t>
<t> In the case of the "default" procedure, the valid values are as follows:</t>
In the case of procedure "default", the valid values are:</t> <sourcecode type="abnf"><![CDATA[
<figure><artwork><![CDATA[
a=measurement:procedure default,[0..999]"/" [0..999] "," [0..999] a=measurement:procedure default,[0..999]"/" [0..999] "," [0..999]
"/" [0..999] "," [0..9999] "," [0..999]/[0..999] "," "/" [0..999] "," [0..9999] "," [0..999]/[0..999] ","
[0..999]/[0..999] [0..999]/[0..999]
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sec-7.2.12" numbered="true" toc="default">
<name>"max-content-length" Attribute</name>
<section title="&quot;max-content-length&quot; attribute" anchor="section <t>
-7.2.12"><t>
The adaptation of measurement traffic to approximate the actual The adaptation of measurement traffic to approximate the actual
data streams' characteristics is convenient to accurately estimate data streams' characteristics is convenient to accurately estimate
the expected QoS for applications. Particularly, packet size can the expected QoS for applications. Particularly, packet size can
have a remarkable effect on bandwidth estimations. Moreover, this have a remarkable effect on bandwidth estimations. Moreover, this
can produce problems depending on the MTU of the end hosts and can produce problems depending on the MTU of the end hosts and
links along the path.</t> links along the path.</t>
<t>
<t> Therefore, the maximum content length <bcp14>MAY</bcp14> be set in an attribu
Therefore, the maximum content length MAY be set in an attribute te
denoted as "max-content-length". Its value MUST be given in bytes denoted as "max-content-length". Its value <bcp14>MUST</bcp14> be given in by
and MUST NOT include application, transport, network or link layer tes
and <bcp14>MUST NOT</bcp14> include application, transport, network, or link
layer
headers, i.e., size of the content length at the application headers, i.e., size of the content length at the application
layer. If not set, the value MUST be 1000 bytes.</t> layer. If not set, the value <bcp14>MUST</bcp14> be 1000 bytes.</t>
<t>
<t> Furthermore, this attribute <bcp14>MAY</bcp14> be used to communicate MTU lim
Furthermore, this attribute MAY be used to inform about MTU limits its
in end points, hence reducing possible bias as a result of in endpoints, hence reducing possible bias as a result of
network-layer fragmentation.</t> network-layer fragmentation.</t>
<t>
<t>
For instance:</t> For instance:</t>
<t>
<t>
a=max-content-length:1300</t> a=max-content-length:1300</t>
</section>
</section> </section>
<section anchor="sec-7.3" numbered="true" toc="default">
</section> <name>Measurements</name>
<t>
<section title="Measurements" anchor="section-7.3"><t>
This section describes the way quality parameters are measured as This section describes the way quality parameters are measured as
defined by the "default" procedure. Measurements MUST be taken for defined by the "default" procedure. Measurements <bcp14>MUST</bcp14> be taken for
any quality parameter with constraints, that is, specified in the any quality parameter with constraints, that is, specified in the
SDP attributes with non-zero values. For non-present attributes SDP attributes with non-zero values. For absent attributes,
measurements MAY be omitted.</t> measurements <bcp14>MAY</bcp14> be omitted.</t>
<section anchor="sec-7.3.1" numbered="true" toc="default">
<section title="Latency" anchor="section-7.3.1"><t> <name>Latency</name>
Latency measurements will be performed if the latency attribute <t>
and/or the application latency attribute are present and with non-zero values Latency measurements will be performed if the "latency" attribute
.</t> and/or the "a=measurement:latency" attribute are present and have non-zero va
lues.</t>
<t> <t>
Q4S defines a PING method in order to exchange packets between the Q4S defines a PING method in order to exchange packets between the
client and the server. Based on this PING exchange the client and client and the server. Based on this PING exchange, the client and
the server are able to calculate the round-trip time (RTT). The the server are able to calculate the round-trip time (RTT). The
RTT is the sum of downlink latency (normally named "reverse latency") and upl ink latency (normally named "forward latency").</t> RTT is the sum of downlink latency (normally named "reverse latency") and upl ink latency (normally named "forward latency").</t>
<t>
<t> At least 255 samples of RTT <bcp14>MUST</bcp14> be taken by the client and
At least 255 samples of RTT MUST be taken by the client and
server. As the forward and reverse latencies are impossible to server. As the forward and reverse latencies are impossible to
measure, client and server will assume that both latencies are measure, the client and server will assume that both latencies are
identical (symmetric network assumption). The latency will identical (symmetric network assumption). The latency will
therefore be calculated as the statistical median value of all the therefore be calculated as the statistical median value of all the
RTT samples divided by 2.</t> RTT samples divided by 2.</t>
</section>
</section> <section anchor="sec-7.3.2" numbered="true" toc="default">
<name>Jitter</name>
<section title="Jitter" anchor="section-7.3.2"><t> <t>
Jitter measurements will be performed if the jitter attribute Jitter measurements will be performed if the "jitter" attribute
and/or the application jitter attribute are present and with non-zero values. and/or the "a=measurement:jitter" attribute are present and have non-zero val
</t> ues.</t>
<t>
<t>
The jitter can be calculated independently by the client and by The jitter can be calculated independently by the client and by
the server. The downlink jitter is calculated by the client taking the server. The downlink jitter is calculated by the client taking
into account the time interval between PING requests as defined by into account the time interval between PING requests as defined by
the measurement procedure attribute in the first or second the "measurement:procedure" attribute in the first or second
parameter depending on the Q4S protocol phase. The client and the parameter depending on the Q4S protocol phase. The client and the
server MUST send these PING requests at the specified intervals. server <bcp14>MUST</bcp14> send these PING requests at the specified interval
The client measures the downlink jitter whereas the server s.
The client measures the downlink jitter, whereas the server
measures the uplink jitter. Note that PING responses are not taken measures the uplink jitter. Note that PING responses are not taken
into account when calculating jitter values.</t> into account when calculating jitter values.</t>
<t>
<t> Every time a PING request is received by an endpoint
Every time a PING request message is received by an endpoint
(either server or client), the corresponding jitter value is (either server or client), the corresponding jitter value is
updated using the Statistical Jitter value calculated on the first updated with the statistical jitter value, which is
255 packets received using the arithmetic mean of the absolute the arithmetic mean of the absolute values of elapsed times
values of elapsed times.</t> calculated on the first 255 packets received.
</t>
<t> <t>
Each endpoint sends a PING periodically with a fixed interval, Each endpoint sends a PING periodically with a fixed interval,
each value of "elapsed time" (ET) should be very close to this and each value of "elapsed time" (ET) should be very close to this
interval. If a PING message is lost, the elapsed time value is interval. If a PING message is lost, the ET value is
doubled. Identifying lost PING messages, however, is not an issue doubled. Identifying lost PING messages, however, is not an issue
because all PING messages are labeled with a Sequence-Number because all PING messages are labeled with a Sequence-Number
header. Therefore the receiver can discard this elapsed time header field. Therefore, the receiver can discard this ET
value.</t> value.</t>
<t>
<t> In order to have the first jitter sample, the receiver <bcp14>MUST</bcp14> wa
In order to have the first jitter sample, the receiver MUST wait it
until it receives 3 PING requests, because each ET is the time until it receives 3 PING requests, because each ET is the time
between two PINGs and a Jitter needs at least two ET.</t> between two PINGs, and a jitter measurement needs at least two ET.</t>
<t>
<t> The client measures the values of RTT and downlink jitter, and the
The client measures the values of RTT and downlink jitter and the
server measures RTT and uplink jitter, but all measurements are server measures RTT and uplink jitter, but all measurements are
shared with the counterpart by means of "Measurements" header of shared with the counterpart by means of the Measurements header field of
PING message.</t> the PING message.</t>
</section>
</section> <section anchor="sec-7.3.3" numbered="true" toc="default">
<name>Bandwidth</name>
<section title="Bandwidth" anchor="section-7.3.3"><t> <t>
Bandwidth measurements will be performed if the bandwidth Bandwidth measurements will be performed if the "bandwidth"
attribute and/or the application bandwidth attribute is present attribute and/or the "a=measurement:bandwidth" attribute is present
and with non-zero values.</t> and has non-zero values.</t>
<t>
<t>
In order to measure the available bandwidth, both the client and In order to measure the available bandwidth, both the client and
the server MUST start sending BWIDTH messages simultaneously using the server <bcp14>MUST</bcp14> start sending BWIDTH messages simultaneously u
the UDP control ports exchanged during the handshake phase in the sing
SDP message, at the needed rate to verify the availability of the 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 bandwidth constraint in each direction. The messages are sent
during the period of time defined in the third parameter of the during the period of time defined in the third parameter of the
SDP measurement default procedure attribute in millisecond units.</t> SDP "measurement:procedure default" attribute in milliseconds.</t>
<figure anchor="ref-bandwidth-and-packet-loss-measurements">
<figure title="Bandwidth and packet loss measurements" anchor="ref-bandwi <name>Bandwidth and Packet Loss Measurements</name>
dth-and-packet-loss-measurements"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
a=measurement:procedure default(50/50,75/75,5000,256/256,256/256) a=measurement:procedure default(50/50,75/75,5000,256/256,256/256)
+------------------------------------------------+ +------------------------------------------------+
| Rate | | Rate |
| A | | A |
| | | | | |
|downlink rate-|-------------------+ <-- traffic | |downlink rate-|-------------------+ <-- traffic |
| | | sent by | | | | sent by |
| | | server | | | | server |
| | | | | | | |
skipping to change at line 2226 skipping to change at line 2079
| uplink rate-|-------------------+ <-- traffic | | uplink rate-|-------------------+ <-- traffic |
| | | sent by | | | | sent by |
| | | client | | | | client |
| | | | | | | |
| | | | | | | |
| |---|---|---|---|---|----> time | | |---|---|---|---|---|----> time |
| 0 1 2 3 4 5 (sec.) | | 0 1 2 3 4 5 (sec.) |
| | | |
+------------------------------------------------+ +------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The goal of these measurements is not to identify the available The goal of these measurements is not to identify the available
bandwidth of the communication path but to determine if the bandwidth of the communication path, but to determine if the
required bandwidth is available, meeting the application's required bandwidth is available, meeting the application's
constraints. Therefore, the requested bandwidth MUST be measured constraints. Therefore, the requested bandwidth <bcp14>MUST</bcp14> be measur
sending only the highest bit rate required by the bandwidth ed
attribute. This is illustrated in Figure 6.</t> sending only the highest bitrate required by the bandwidth
attribute. This is illustrated in <xref target="ref-bandwidth-and-packet-loss
<t> -measurements" format="default"/>.</t>
During bandwidth measurement time, ALERTS are not expected, but <t>
ALERTS are not expected during bandwidth measurement, but
only at the end of the measurement time.</t> only at the end of the measurement time.</t>
<t>
<t> When measuring bandwidth, all BWIDTH requests sent <bcp14>MUST</bcp14> be 1
When measuring bandwidth, all BWIDTH requests sent MUST be 1 kilobyte in length (UDP payload length by default), they <bcp14>MUST</bcp14>
kilobyte in length (UDP payload length by default), and MUST include a Sequence-Number header field with a sequential number starting
include a Sequence-Number header with a sequential number starting at 0, and their content <bcp14>MUST</bcp14> consist of randomly generated val
at 0, and their content MUST consist of randomly generated values ues
to minimize the effect of compression elements along the path. The to minimize the effect of compression elements along the path. The
Sequence-Number MUST be incremented by 1 with each BWIDTH packet Sequence-Number <bcp14>MUST</bcp14> be incremented by 1 with each BWIDTH pack et
sent. If any measurement stage needs to be repeated, the sequence sent. If any measurement stage needs to be repeated, the sequence
number MUST start at zero again. BWIDTH requests MUST NOT be number <bcp14>MUST</bcp14> start at zero again. BWIDTH requests <bcp14>MUST N OT</bcp14> be
answered. Examples:</t> answered. Examples:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
Client message: Client message:
========================= =========================
BWIDTH q4s://www.example.com Q4S/1.0 BWIDTH q4s://www.example.com Q4S/1.0
User-Agent: q4s-ua-experimental-1.0 User-Agent: q4s-ua-experimental-1.0
Session-Id: 53655765 Session-Id: 53655765
Sequence-Number: 0 Sequence-Number: 0
Content-Type: text Content-Type: text
Content-Length: XXXX Content-Length: XXXX
Measurements: l=22, j=10, pl=0.00, bw=3000 Measurements: l=22, j=10, pl=0.00, bw=3000
VkZaU1FrNVZNVlZSV0doT1ZrZ (to complete up to "max-content- VkZaU1FrNVZNVlZSV0doT1ZrZ (to complete up to "max-content-
length" bytes UDP payload length) length" bytes UDP payload length)
========================= =========================
]]></artwork> ]]></artwork>
</figure> <t>
<t> The client <bcp14>MUST</bcp14> send BWIDTH packets to the server to allow the
The client MUST send BWIDTH packets to the server to allow the server to measure the uplink bandwidth. The server <bcp14>MUST</bcp14> send
server to measure the uplink bandwidth. The server MUST send
BWIDTH packets to the client to allow the client to measure the BWIDTH packets to the client to allow the client to measure the
downlink bandwidth.</t> downlink bandwidth.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
Server message: Server message:
========================= =========================
BWIDTH q4s://www.example.com Q4S/1.0 BWIDTH q4s://www.example.com Q4S/1.0
Session-Id: 53655765 Session-Id: 53655765
Sequence-Number: 0 Sequence-Number: 0
Content-Type: text Content-Type: text
Content-Length: XXXX Content-Length: XXXX
Measurements: l=22, j=7, pl=0.00, bw=200 Measurements: l=22, j=7, pl=0.00, bw=200
ZY0VaT1ZURlZVVmhyUFE9PQ (to complete up to max-content- ZY0VaT1ZURlZVVmhyUFE9PQ (to complete up to max-content-
length length UDP payload length)
UDP payload length)
========================= =========================
]]></artwork> ]]></artwork>
</figure> </section>
</section> <section anchor="sec-7.3.4" numbered="true" toc="default">
<name>Packet Loss</name>
<section title="Packet loss" anchor="section-7.3.4"><t> <t>
Packet loss and bandwidth are measured simultaneously using the Packet loss and bandwidth are measured simultaneously using the
BWIDTH packets sent by both the client and the server. Because the BWIDTH packets sent by both the client and the server. Because the
BWIDTH packets contain a Sequence-Number header incremented BWIDTH packets contain a Sequence-Number header field incremented
sequentially with each sent packet, lost packets can be easily sequentially with each sent packet, lost packets can be easily
identified. The lost packets MUST be counted during the identified. The lost packets <bcp14>MUST</bcp14> be counted during the
measurement time.</t> measurement time.</t>
</section>
</section> </section>
<section anchor="sec-7.4" numbered="true" toc="default">
</section> <name>Handshake Phase</name>
<t>
<section title="Handshake Phase" anchor="section-7.4"><t>
The first phase consists of a Q4S BEGIN method issued from the The first phase consists of a Q4S BEGIN method issued from the
client to the server as shown in Figure 7.</t> client to the server as shown in <xref target="ref-handshake-phase" format="d
efault"/>.</t>
<t> <t>
The first Q4S message MUST have a special URI (RFC 3986 <xref target="ref-12" The first Q4S message <bcp14>MUST</bcp14> have a special URI <xref target="RF
/>), C3986" format="default"/>,
which forces the use of the Q4S protocol if it is implemented in a which forces the use of the Q4S protocol if it is implemented in a
standard web browser.</t> standard web browser.</t>
<t>
<t>
This URI, named "Contact URI", is used to request the start of a This URI, named "Contact URI", is used to request the start of a
session. Its scheme MUST be:</t> session. Its scheme <bcp14>MUST</bcp14> be:</t>
<sourcecode type="abnf"><![CDATA[
<figure><artwork><![CDATA[
"q4s:" "//" host [":" port] [path["?" query] "q4s:" "//" host [":" port] [path["?" query]
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
Optionally, the client can send the desired quality parameters Optionally, the client can send the desired quality parameters
enclosed in the body of the message as an SDP document. The server enclosed in the body of the message as an SDP document. The server
MAY take them into account when building the answer message with <bcp14>MAY</bcp14> take them into account when building the answer message wi
the final values in the SDP body, following a request / response th
schema (RFC 3264 <xref target="ref-13"/>).</t> the final values in the SDP body, following a request/response
schema <xref target="RFC3264" format="default"/>.</t>
<t> <t>
If the request is accepted, the server MUST answer it with a Q4S If the request is accepted, the server <bcp14>MUST</bcp14> answer it with a Q
200 OK message, which MUST contain an SDP body (RFC 4566 <xref target="ref-10 4S
"/>) 200 OK message, which <bcp14>MUST</bcp14> contain an SDP body <xref target="R
with the assigned session id (embedded in the "o" SDP parameter), FC4566" format="default"/>
with the assigned sess-id (embedded in the SDP "o=" line),
the IP addresses to be used, the flow ports to be used, the the IP addresses to be used, the flow ports to be used, the
measurement procedure to be followed and information about the measurement procedure to be followed, and information about the
required quality constraints. Additionally, the alerting-mode and required quality constraints. Additionally, the "alerting-mode" and
alert-pause time parameters may be included. Q4S responses should "alert-pause" time attributes may be included. Q4S responses should
use the protocol designator "Q4S/1.0".</t> use the protocol designator "Q4S/1.0".</t>
<t>
<t>
After these two messages are exchanged, the first phase is After these two messages are exchanged, the first phase is
completed. The quality parameter thresholds have been sent to the completed. The quality parameter thresholds have been sent to the
client. The next step is to measure the actual quality of the client. The next step is to measure the actual quality of the
communication path between the client and the server and alert if communication path between the client and the server and alert if
the Service Level Agreement (SLA) is being violated.</t> the Service Level Agreement (SLA) is being violated.</t>
<figure anchor="ref-handshake-phase">
<figure title="Handshake phase" anchor="ref-handshake-phase"><artwork><![ <name>Handshake Phase</name>
CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------------------------------+ +------------------------------------------------+
| | | |
| Client Server | | Client Server |
| | | |
| ------- Q4S BEGIN ------------> | | ------- Q4S BEGIN ------------> |
| | | |
| <------ Q4S 200 OK ------------ | | <------ Q4S 200 OK ------------ |
| | | |
| | | |
+------------------------------------------------+ +------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Example of Client Request and Server Answer:</t> The following is an example of a client request and a server answer:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
Client Request: Client Request:
========================= =========================
BEGIN q4s://www.example.com Q4S/1.0 BEGIN q4s://www.example.com Q4S/1.0
Content-Type: application/sdp Content-Type: application/sdp
User-Agent: q4s-ua-experimental-1.0 User-Agent: q4s-ua-experimental-1.0
Content-Length: 142 Content-Length: 142
(SDP not shown) (SDP not shown)
========================= =========================
skipping to change at line 2381 skipping to change at line 2221
========================= =========================
Q4S/1.0 200 OK Q4S/1.0 200 OK
Date: Mon, 10 Jun 2010 10:00:01 GMT Date: Mon, 10 Jun 2010 10:00:01 GMT
Content-Type: application/sdp Content-Type: application/sdp
Expires: 3000 Expires: 3000
Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4
Content-Length: 131 Content-Length: 131
(SDP not shown) (SDP not shown)
========================= =========================
The headers used are explained in section 4.3.
]]></artwork> ]]></artwork>
</figure> <t>The header fields used are explained in <xref target="sec-4.3" format="defaul
</section> t"/>.</t>
</section>
<section title="Negotiation Phase" anchor="section-7.5"><t> <section anchor="sec-7.5" numbered="true" toc="default">
The negotiation phase is in charge of measuring the quality <name>Negotiation Phase</name>
<t>
The Negotiation phase is in charge of measuring the quality
parameters and verifying that the communication paths meet the parameters and verifying that the communication paths meet the
required quality constraints on both directions as specified in required quality constraints in both directions as specified in
the SDP body.</t> the SDP body.</t>
<t>
<t>
The measured parameters will be compared with the quality The measured parameters will be compared with the quality
constraints specified in the SDP body. If the quality session is constraints specified in the SDP body. If the quality session is
compliant with all the quality constraints the application can compliant with all the quality constraints, the application can
start.</t> start.</t>
<t>If the quality constraints are not met, a higher quality
<t><list style="symbols"><t>If the quality constraints are not met, a hig
her quality
service level will be demanded. Depending on the scenario, service level will be demanded. Depending on the scenario,
this quality upgrade will be managed as follows: In the Q4S-aware-network this quality upgrade will be managed as follows: </t>
scenario: a Q4S-ALERT method will be triggered
by the server to the client and the client will answer with <dl>
<dt>In the Q4S-aware-network scenario:</dt><dd>a Q4S-ALERT method will be t
riggered
by the server to the client, and the client will answer with
the same Q4S-ALERT method. After receiving the same Q4S-ALERT the same Q4S-ALERT method. After receiving the same Q4S-ALERT
from the counterpart, no other alerts will be triggered by from the counterpart, no other alerts will be triggered by
the server during the "alert-pause" period of time, in order the server during the "alert-pause" period of time in order
to allow the network to react, but measurements will continue to allow the network to react, but measurements will continue
to be taken to achieve early detection of improved network to be taken to achieve early detection of improved network
quality conditions and a fast application start.</t> quality conditions and a fast application start.</dd>
<dt>In the Reactive scenario:</dt><dd>an alert notification will be se
<t>In the Reactive scenario: an alert notification will be sent nt
by the server stack to the Actuator, and the Actuator will by the server stack to the Actuator, and the Actuator will
answer with an alert acknowledgement. After receiving the answer with an alert acknowledgement. After receiving the
alert acknowledgement from the Actuator, the server stack alert acknowledgement from the Actuator, the server stack
will not send other alert notifications during the "alert-pause" period of will not send other alert notifications during the "alert-pause"
time, in order to allow the Actuator to period of time in order to allow the Actuator to
react and trigger actions on the application or on the policy react and trigger actions on the application or on the policy
server, but measurements will continue to be taken to achieve server, but measurements will continue to be taken to achieve
early detection of improved network quality conditions and a early detection of improved network quality conditions and a
fast application start.</t> fast application start.</dd>
</dl>
</list> <t>
</t>
<t>
In both scenarios stated above, if after several measurement In both scenarios stated above, if after several measurement
cycles, the network constraints cannot be met the quality session cycles, the network constraints cannot be met, the quality session
is terminated. Concretely when under all possible actions taken by is terminated. Concretely when, under all possible actions taken by
Actuator the quality remains below requirements, the session must Actuator, the quality remains below requirements, the session must
be terminated.</t> be terminated.</t>
<t>
<t>
The steps to be taken in this phase depend on the measurement The steps to be taken in this phase depend on the measurement
procedure exchanged during the handshake phase. This document only procedure exchanged during the Handshake phase. This document only
describes the "default" procedure, but others can be used, like describes the "default" procedure, but others can be used, like
RTP/RTCP (RFC 3550 <xref target="ref-18"/>).</t> RTP/RTCP <xref target="RFC3550" format="default"/>.</t>
<t>
<t> Measurements of latency and jitter are made by calculating the
Measurements of latency and jitter are done calculating the differences in the arrival times of packets and can be achieved with
differences in arrival times of packets and can be achieved with
little bandwidth consumption. The bandwidth measurement, on the little bandwidth consumption. The bandwidth measurement, on the
other hand, involves higher bandwidth consumption in both other hand, involves higher bandwidth consumption in both
directions (uplink and downlink).</t> directions (uplink and downlink).</t>
<t>
<t> To avoid wasting unnecessary network resources, these two types of
To avoid wasting unnecessary network resources these two types of
measurements will be performed in two separate stages. If the measurements will be performed in two separate stages. If the
required latencies and jitters cannot be reached, it makes no required latencies and jitters cannot be reached, it makes no
sense to waste network resources measuring bandwidth. In addition, sense to waste network resources measuring bandwidth. In addition,
if achieving the required latency and jitter thresholds implies if achieving the required latency and jitter thresholds implies
upgrading the quality session level, the chance of obtaining upgrading the quality session level, the chance of obtaining
compliant bandwidth measurements without retries is higher, saving compliant bandwidth measurements without retries is higher, saving
network traffic again. Therefore, the default procedure, network traffic again. Therefore, the "default" procedure
determines that the measurements are taken in two stages: determines that the measurements are taken in two stages:
<list style="hanging" hangIndent="6">
<t hangText="Stage 0:"> Measurement of latencies, jitters and packet los
s</t>
<t hangText="Stage 1:"> Measurement of bandwidths and packet loss</t>
</list>
</t> </t>
<dl newline="false" spacing="normal" indent="6">
<t> <dt>Stage 0:</dt>
<dd> Measurement of latencies, jitters, and packet loss</dd>
<dt>Stage 1:</dt>
<dd> Measurement of bandwidths and packet loss</dd>
</dl>
<t>
Notice that packet loss can be measured in both stages, as all Notice that packet loss can be measured in both stages, as all
messages exchanged include a sequence-number header that allows messages exchanged include a Sequence-Number header field that allows
for easy packet loss detection.</t> for easy packet loss detection.</t>
<t>
<t> The client starts the Negotiation phase by sending a READY request
The client starts the negotiation phase sending a READY request
using the TCP Q4S ports defined in the SDP. This READY request using the TCP Q4S ports defined in the SDP. This READY request
includes a "Stage" header that indicates the measurement stage.</t> includes a Stage header field that indicates the measurement stage.</t>
<t>
<t> If either jitter, latency, or both are specified, the Negotiation
If either jitter, latency or both are specified, the negotiation
phase begins with the measurement of latencies and jitters (stage phase begins with the measurement of latencies and jitters (stage
0). If none of those attributes are specified, stage 0 is skipped.</t> 0). If none of those attributes is specified, stage 0 is skipped.</t>
<section anchor="sec-7.5.1" numbered="true" toc="default">
<section title="Stage 0: Measurement of Latencies and Jitter" anchor="sec <name>Stage 0: Measurement of Latencies and Jitter</name>
tion-7.5.1"><t> <t>
The Stage 0 MUST start with a synchronization message exchange The Stage 0 <bcp14>MUST</bcp14> start with a synchronization message exchange
initiated with the client's READY message.</t> initiated with the client's READY message.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[ Client Request, READY message:
Client request, READY message:
========================= =========================
READY q4s://www.example.com Q4S/1.0 READY q4s://www.example.com Q4S/1.0
Stage: 0 Stage: 0
Session-Id: 53655765 Session-Id: 53655765
User-Agent: q4s-ua-experimental-1.0 User-Agent: q4s-ua-experimental-1.0
Content-Length: 0 Content-Length: 0
========================= =========================
Server Response: Server Response:
========================= =========================
Q4S/1.0 200 OK Q4S/1.0 200 OK
Session-Id: 53655765 Session-Id: 53655765
Stage:0 Stage:0
Content-Length: 0 Content-Length: 0
========================= =========================
]]></artwork> ]]></artwork>
</figure> <t>
<t>
This triggers the exchange of a sequence of PING requests and This triggers the exchange of a sequence of PING requests and
responses that will lead to the calculation of RTT (latency), responses that will lead to the calculation of RTT (latency),
jitter and packet loss.</t> jitter, and packet loss.</t>
<t>
<t> After receiving a 200 OK, the client must send the first PING
After receiving 200 OK, the client must send the first PING message, and the server will wait to send PINGs until the reception
message and the server will wait to send PINGs until the reception
of this first client PING.</t> of this first client PING.</t>
<t>
<t> The client and server <bcp14>MUST</bcp14> send PING requests to each other. T
Client and server MUST send PING requests to each other. The he
Sequence-Number header of the first PING MUST be set to 0. Client Sequence-Number header field of the first PING <bcp14>MUST</bcp14> be set to
0. The client
and server will manage their own sequence numbers.</t> and server will manage their own sequence numbers.</t>
<figure anchor="ref-simultaneous-exchange-of-ping-request-and-response
<figure title="Simultaneous exchange of PING request and responses" ancho s">
r="ref-simultaneous-exchange-of-ping-request-and-responses"><artwork><![CDATA[ <name>Simultaneous Exchange of PING Request and Responses</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------------------------------+ +------------------------------------------------+
| | | |
| Client Server | | Client Server |
| | | |
| --------- Q4S READY 0 ---------> | | --------- Q4S READY 0 ---------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| | | |
| --------- Q4S PING ------------> | | --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- | | <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> | | -------- Q4S 200 OK ----------> |
| --------- Q4S PING ------------> | | --------- Q4S PING ------------> |
| <-------- Q4S PING ------------- | | <-------- Q4S PING ------------- |
| --------- Q4S 200 OK ----------> | | --------- Q4S 200 OK ----------> |
| <-------- Q4S 200 OK ----------- | | <-------- Q4S 200 OK ----------- |
| ... | | ... |
| | | |
+------------------------------------------------+ +------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Figure 8 shows an example of the PING request sent from the client The following is
an example of the PING request sent from the client
and the server's response:</t> and the server's response:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
Client Request: Client Request:
========================= =========================
PING q4s://www.example.com Q4S/1.0 PING q4s://www.example.com Q4S/1.0
Session-Id: 53655765 Session-Id: 53655765
Sequence-Number: 0 Sequence-Number: 0
User-Agent: q4s-ua-experimental-1.0 User-Agent: q4s-ua-experimental-1.0
Measurements: l=22, j=12, pl=0.20, bw= Measurements: l=22, j=12, pl=0.20, bw=
Content-Length: 0 Content-Length: 0
========================= =========================
Server Response: Server Response:
========================= =========================
Q4S/1.0 200 OK Q4S/1.0 200 OK
Session-Id: 53655765 Session-Id: 53655765
Sequence-Number: 0 Sequence-Number: 0
Content-Length: 0 Content-Length: 0
========================= =========================
]]></artwork> ]]></artwork>
</figure> <t>
<t>
The function of the PING method is similar to the ICMP echo The function of the PING method is similar to the ICMP echo
request message. The server MUST answer as soon as it receives the request message <xref target="RFC0792" format="default"/>.
The server <bcp14>MUST</bcp14> answer as soon as it receives the
message.</t> message.</t>
<t>
<t> Both endpoints <bcp14>MUST</bcp14> send Q4S PING messages with the periodicit
Both endpoints MUST send Q4S PING messages with the periodicity y
specified in the first parameter of SDP measurement procedure specified in the first parameter of SDP "measurement:procedure"
attribute, using always the same UDP ports and incrementing the attribute, always using the same UDP ports and incrementing the
Sequence-Number with each message.</t> Sequence-Number with each message.</t>
<t>
<t> In the following example, the value of the first parameter of the SDP "measur
In the following example, the SDP measurement procedure attribute, ement:procedure" attribute
this value is 50 milliseconds (from the client to the server) and is 50 milliseconds (from the client to the server) and
60ms (from the server to the client).</t> 60 ms (from the server to the client):</t>
<sourcecode type="sdp"><![CDATA[
<figure><artwork><![CDATA[
a=measurement:procedure default(50/60,50/50,5000,256/256,256/256) a=measurement:procedure default(50/60,50/50,5000,256/256,256/256)
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> They <bcp14>MUST NOT</bcp14> wait for a response to send the next PING reques
They MUST NOT wait for a response to send the next PING request. t.
The "Sequence-Number" header value is incremented sequentially and The Sequence-Number header field value is incremented sequentially and
MUST start at zero. If this stage is repeated, the initial <bcp14>MUST</bcp14> start at zero. If this stage is repeated, the initial
Sequence-Number MUST start at zero again.</t> Sequence-Number <bcp14>MUST</bcp14> start at zero again.</t>
<t>
<t> All PING requests <bcp14>MUST</bcp14> contain a Measurements header field wit
All PING requests MUST contain a "Measurements" header, with the h the
values of the latency, jitter and packet loss measured by each values of the latency, jitter, and packet loss measured by each
entity up to that moment. The client will send its measurements to entity up to that moment. The client will send its measurements to
the server and the server his measurements to the client. Example:</t> the server, and the server will send its measurements to the client. Example:
</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Measurements: l=22, j=13, pl=0.10, bw=</t> Measurements: l=22, j=13, pl=0.10, bw=
]]></artwork> ]]></artwork>
</figure> <t>
Where "l" stands for latency, "j" for jitter, "pl" for packet loss, and "bw"
<t>
Where l stands for latency, j for jitter, pl for packetloss and bw
for bandwidth. The bandwidth value is omitted, as it is not for bandwidth. The bandwidth value is omitted, as it is not
measured at this stage.</t> measured at this stage.</t>
<t>
<t> Optionally the PING request can include a Timestamp header field with
Optionally the PING request can include a "Timestamp" header, with the time in which the message has been sent. In the case that the header fiel
the time in which the message has been sent. In case the header is d is
present, the server MUST include the header in the response present, the server <bcp14>MUST</bcp14> include the header field in the respo
nse
without changing the value.</t> without changing the value.</t>
<t>
<t> A minimum number of PING messages <bcp14>MUST</bcp14> be exchanged in order t
A minimum number of PING messages MUST be exchanged in order to be o be
able to measure latency, jitter and packet-loss with certain able to measure latency, jitter, and packet loss with certain
accuracy (at least 256 samples are RECOMMENDED to get a accurate accuracy (at least 256 samples are <bcp14>RECOMMENDED</bcp14> to get an accur
ate
packet loss measurement). Both the client and the server calculate packet loss measurement). Both the client and the server calculate
the respective measured parameter values. The mechanisms to the respective measured parameter values. The mechanisms to
calculate the different parameters are described in section 7.3.</t> calculate the different parameters are described in <xref target="sec-7.3" fo rmat="default"/>.</t>
<t> <t>
At the end of this stage 0, there are three possibilities:</t> At the end of this stage 0, there are three possibilities:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The latency, jitter and packet loss constrain <li>The latency, jitter, and packetloss constraints are reached
ts are reached in both directions</li>
in both directions</t> <li>The latency, jitter, and packetloss constraints are not
reached in one or both directions</li>
<t>The latency, jitter and packet loss constraints are not </ul>
reached in one or both directions</t> <t>
In the first case, Stage 0 is finished. The client and server are
</list>
</t>
<t>
In the first case, Stage 0 is finished. Client and server are
ready for Stage 1: bandwidth and packet loss measurement. The ready for Stage 1: bandwidth and packet loss measurement. The
client moves to stage 1 by sending a READY message including the client moves to stage 1 by sending a READY message that includes the
header "Stage: 1".</t> header field, "Stage: 1".</t>
<t>
<t> If the bandwidth constraints are either empty or have a value of zero, the
If the bandwidth constraints are empty or with value zero, the Negotiation phase <bcp14>MUST</bcp14> terminate, and both client and server m
negotiation phase MUST terminate and both client and server may ay
initiate the Continuity Phase. In this case client moves to initiate the Continuity phase. In this case, client moves to the
Continuity phase by sending a READY message including the header Continuity phase by sending a READY message that includes the header field,
"Stage: 2".</t> "Stage: 2".</t>
<t>
<t>
The second case, in which one or more quality constraints have not The second case, in which one or more quality constraints have not
been met, is detailed in section 7.5.4.</t> been met, is detailed in <xref target="sec-7.5.4" format="default"/>.</t>
</section>
</section> <section anchor="sec-7.5.2" numbered="true" toc="default">
<name>Stage 1: Measurement of Bandwidth and Packet Loss</name>
<section title="Stage 1: Measurement of Bandwidth and Packet Loss" anchor <t>
="section-7.5.2"><t>
This stage begins in a similar way to stage 0, sending a READY This stage begins in a similar way to stage 0, sending a READY
request over TCP. This READY message "Stage" header value is 1. 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 The server answers with a Q4S 200 OK message to synchronize the
initiation of the measurements as shown in Figure 9.</t> initiation of the measurements as shown in
<xref target="ref-starting-bandwidth-and-packet-loss-measurement" format="def
<figure title="Starting bandwidth and packet loss measurement" anchor="re ault"/>.</t>
f-starting-bandwidth-and-packet-loss-measurement"><artwork><![CDATA[ <figure anchor="ref-starting-bandwidth-and-packet-loss-measurement">
<name>Starting Bandwidth and Packet Loss Measurement</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------------------------------+ +------------------------------------------------+
| | | |
| Client Server | | Client Server |
| | | |
| --------- Q4S READY 1 -----------> | | --------- Q4S READY 1 -----------> |
| <-------- Q4S 200 OK ------------- | | <-------- Q4S 200 OK ------------- |
| | | |
| --------- Q4S BWIDTH -----------> | | --------- Q4S BWIDTH -----------> |
| <-------- Q4S BWIDTH ------------ | | <-------- Q4S BWIDTH ------------ |
| --------- Q4S BWIDTH -----------> | | --------- Q4S BWIDTH -----------> |
| <-------- Q4S BWIDTH ------------ | | <-------- Q4S BWIDTH ------------ |
| ... | | ... |
| | | |
+------------------------------------------------+ +------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Client Request: Client Request:
========================= =========================
READY q4s://www.example.com Q4S/1.0 READY q4s://www.example.com Q4S/1.0
User-Agent: q4s-ua-experimental-1.0 User-Agent: q4s-ua-experimental-1.0
Stage: 1 Stage: 1
Session-Id: 53655765 Session-Id: 53655765
Content-Length: 0 Content-Length: 0
========================= =========================
Server Response: Server Response:
========================= =========================
Q4S/1.0 200 OK Q4S/1.0 200 OK
Session-Id: 53655765 Session-Id: 53655765
Stage: 1 Stage: 1
Content-Length: 0 Content-Length: 0
========================= =========================
]]></artwork> ]]></artwork>
</figure> <t>
<t>
Just after receiving the 200 OK, both the client and the server Just after receiving the 200 OK, both the client and the server
MUST start sending BWIDTH messages simultaneously using the UDP <bcp14>MUST</bcp14> start sending BWIDTH messages simultaneously using the UD
q4s ports. <xref target="section-7.3.3"/> describes the bandwidth measurement P
in "q4s" ports. <xref target="sec-7.3.3" format="default"/> describes the bandwi
dth measurement in
detail.</t> detail.</t>
<t>
<t>
At the end of this stage 1, there are three possibilities:</t> At the end of this stage 1, there are three possibilities:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The bandwidth and packet loss constraints are <li>The bandwidth and packetloss constraints are reached in both
reached in both directions.</li>
directions</t> <li>The bandwidth and packetloss constraints are not reached in
one or both directions.</li>
<t>The bandwidth and packet loss constraints are not reached in </ul>
one both directions.</t> <t>
In the first case, Stage 1 is finished. The client and server are
</list> ready for the Continuity phase. The client moves to this phase by
</t> sending a READY message that includes the header field, "Stage: 2". The
server answer <bcp14>MUST</bcp14> be 200 OK as shown in
<t> <xref target="ref-trigger-the-application-using-http-uri" format="default"/>.
In the first case, Stage 1 is finished. Client and server are </t>
ready for Continuity phase. The client moves to this phase by <figure anchor="ref-trigger-the-application-using-http-uri">
sending a READY message including the header "Stage: 2". The <name>Trigger the Application Using HTTP URI</name>
server answer MUST be 200 OK as shown in Figure 10.</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="Trigger the application using HTTP URI" anchor="ref-trigge
r-the-application-using-http-uri"><artwork><![CDATA[
+------------------------------------------------+ +------------------------------------------------+
| | | |
| Client Server | | Client Server |
| | | |
| --------- Q4S READY 2 --------------> | | --------- Q4S READY 2 --------------> |
| <---- Q4S 200 OK with trigger URI----- | | <---- Q4S 200 OK with trigger URI----- |
| | | |
| --------- HTTP GET ----------------> | | --------- HTTP GET ----------------> |
| | | |
| (Application starts) | | (Application starts) |
| | | |
+------------------------------------------------+ +------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Client Request: Client Request:
========================= =========================
READY q4s://www.example.com Q4S/1.0 READY q4s://www.example.com Q4S/1.0
User-Agent: q4s-ua-experimental-1.0 User-Agent: q4s-ua-experimental-1.0
Stage: 2 Stage: 2
Session-Id: 53655765 Session-Id: 53655765
Content-Length: 0 Content-Length: 0
========================= =========================
skipping to change at line 2757 skipping to change at line 2565
Session-Id: 53655765 Session-Id: 53655765
Trigger-URI: http://www.example.com/app_start Trigger-URI: http://www.example.com/app_start
Expires: 3000 Expires: 3000
Content-Type: application/sdp Content-Type: application/sdp
Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4
Content-Length: 131 Content-Length: 131
(SDP not shown) (SDP not shown)
========================= =========================
]]></artwork> ]]></artwork>
</figure> <t>
<t> If the Trigger-URI header field is present, the client <bcp14>SHOULD</bcp14>
If the "Trigger-URI" header is present, the client SHOULD send an send an
HTTP request to this URI.</t> HTTP request to this URI.</t>
<t>
<t> The second case, with violated network constraints, is explained in
The second case, with violated network constraints is explained in <xref target="sec-7.5.4" format="default"/>.</t>
7.5.4.</t> </section>
<section anchor="sec-7.5.3" numbered="true" toc="default">
</section> <name>Quality Constraints Not Reached</name>
<t>
<section title="Quality Constraints Not Reached" anchor="section-7.5.3"><
t>
After finishing Stage 1 of the Negotiation phase, the client and After finishing Stage 1 of the Negotiation phase, the client and
the server have each other measured parameter values as these have the server have each other's measured parameter values as these have
been exchanged in the "Measurements" headers of the PING and been exchanged in the Measurements header fields of the PING and
BWIDTH messages. If there is one or more parameters that do not BWIDTH messages. If there is one or more parameters that do not
comply with the uplink or downlink application constraints comply with the uplink or downlink application constraints
required both the server and the client are aware of it.</t> required, both the server and the client are aware of it.</t>
<t>
<t>
If there is any quality parameter that does not meet the uplink or If there is any quality parameter that does not meet the uplink or
downlink quality constraints specified in the SDP message, two downlink quality constraints specified in the SDP message, two
scenarios are possible depending on the specified alerting-mode scenarios are possible depending on the specified alerting mode
(if not present, default value is "Reactive" alerting mode): (if not present, the default value is Reactive alerting mode):
<list style="format (%c)"> </t>
<t> Q4S-aware-network alerting mode:"> the server MUST send a <ol spacing="normal" type="(%c)">
Q4S-ALERT message to the client including the digital signature <li>
header, and the client MUST answer with the same Q4S-ALERT <t> Q4S-aware-network alerting mode: the server <bcp14>MUST</bcp14
message. The Signature header contains the signed hash value of > send a
the SDP body in order to protect all the SDP the data and Q4S-ALERT message to the client including the digital Signature
therefore it MUST contain the measurement parameters in the header field, and the client <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> contain the "measurement" parameters in t
he
body. body.
</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Server request Server request
========================= =========================
Q4S-ALERT q4s://www.example.com Q4S/1.0 Q4S-ALERT q4s://www.example.com Q4S/1.0
Host: www.example.com Host: www.example.com
User-Agent: q4s-ua-experimental-1.0 User-Agent: q4s-ua-experimental-1.0
Session-Id: 53655765 Session-Id: 53655765
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
v=0 v=0
skipping to change at line 2828 skipping to change at line 2635
a=flow:q4s downlink TCP/55001 a=flow:q4s downlink TCP/55001
a=flow:q4s uplink UDP/56000 a=flow:q4s uplink UDP/56000
a=flow:q4s uplink TCP/56001 a=flow:q4s uplink TCP/56001
a=measurement:procedure default(50/50,50/50,5000,256/256,256/256) a=measurement:procedure default(50/50,50/50,5000,256/256,256/256)
a=measurement:latency 30 a=measurement:latency 30
a=measurement:jitter 6/4 a=measurement:jitter 6/4
a=measurement:bandwidth 200/4000 a=measurement:bandwidth 200/4000
a=measurement:packetloss 0.20/0.33 a=measurement:packetloss 0.20/0.33
========================= =========================
]]></artwork> ]]></artwork>
</figure> <t>
At this point, both the client and server keep on measuring but
At this point, both client and server keep on measuring but without sending new Q4S-ALERT messages during the "alert-pause"
without sending new Q4S ALERT messages during the "alert-pause"
milliseconds. </t> milliseconds. </t>
</li>
<t> Reactive alerting mode:"> the server stack MUST send an alert <li> Reactive alerting mode: the server stack <bcp14>MUST</bcp14> s
notification to the Actuator, and the Actuator MUST answer with end an alert
notification to the Actuator, and the Actuator <bcp14>MUST</bcp14> answer
with
an acknowledgement to the received alert notification. The an acknowledgement to the received alert notification. The
alert notification sent to the Actuator by the server stack alert notification sent to the Actuator by the server stack
doesn't follow Q4S message style but should have all the doesn't follow Q4S message style but should have all the
information the Actuator will need for the actions to be taken, information the Actuator will need for the actions to be taken,
which will be implementation dependent. which will be implementation dependent.
</t> </li>
</ol>
</list> <t>
</t> At this point during Negotiation phase, both the client and server
<t>
At this point, during Negotiation phase, both client and server
keep on measuring without sending new alert notifications to the keep on measuring without sending new alert notifications to the
Actuator during the "alert-pause" milliseconds specified in the Actuator during the "alert-pause" milliseconds specified in the
SDP. This way, both client and server will detect any improvement SDP. This way, both client and server will detect any improvement
in network conditions as soon as the network reacts. The in network conditions as soon as the network reacts. The
application can start as soon as the number of measurements application can start as soon as the number of measurements
indicated in the measurement procedure attribute indicates that indicated in the "measurement:procedure" attribute indicates that
the quality parameters are met.</t> the quality parameters are met.</t>
<t>
<t> The same applies to Continuity phase: the measurement dialog between
Same applies to Continuity phase: the measurement dialog between
client and server must not be interrupted by any possible ALERT client and server must not be interrupted by any possible ALERT
message.</t> message.</t>
<section anchor="sec-7.5.3.1" numbered="true" toc="default">
<section title="Actuator Role" anchor="section-7.5.3.1"><t> <name>Actuator Role</name>
Actuator receives notifications of unmet requirements from the Q4S <t>
server stack, and act upon the application or the network policy 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.</t> server, according to logic out of scope of this protocol.</t>
<t>
<t> The Actuator logic activates mechanisms at the application level
The Actuator logic activates mechanisms at application level and/or the network level based on a quality level dictionary, in which
or/and network level based on a quality level dictionary, in which the meaning of each level is implementation dependent, and each level
each level meaning is implementation dependent and each level involves different actions based on rules to keep a certain user
involve different actions based on rules to keep certain user
experience quality.</t> experience quality.</t>
<t>
<t> The type of actions that an Actuator can take at the application level
The type of actions that an Actuator can take at application level are application dependent and <bcp14>MAY</bcp14> involve:</t>
are application dependent and MAY involve:</t> <ul spacing="normal">
<li>Reduction of application functionalities, such as limitation
<t><list style="symbols"><t>Reduction of application functionalities, suc of application speed or application options.</li>
h as limitation <li>Reduction of application resources usage, such as reduction
of application speed or application options.</t> of frames per second in a video application or any other parameter
modification in order to adapt to network conditions.</li>
<t>Reduction of application resources usage, such as reduction </ul>
of frames per second in a video app or any other parameter <t>
modification in order to adapt to network conditions.</t> Apart from actions at the application level, the Actuator <bcp14>MAY</bcp14>
act at
</list> the network level if a network policy server is available.</t>
</t> </section>
<section anchor="sec-7.5.3.2" numbered="true" toc="default">
<t> <name>Policy Server Role</name>
Apart from actions at application level, the Actuator MAY act at <t>
network level if a network policy server is available.</t> A network policy server may be part of the Reactive scenario, and
it is in charge of managing network quality provision. A network
</section> policy server may implement all or some of these features (but implementation
is not
<section title="Policy Server Role" anchor="section-7.5.3.2"><t>
A network policy server may be part of the reactive scenario and
it is in charge of managing network quality provision. Network
policy server may implement all or some of these features (but not
exclusive to):</t> exclusive to):</t>
<ul spacing="normal">
<t><list style="symbols"><t>Server validation in terms of quality constra <li>Server validation in terms of quality constraints</li>
ints.</t> <li>Authentication (Signature validation) and security (blocking o
f
<t>Authentication (Signature validation) and security (block malicious clients)</li>
malicious clients)</t> <li>
<t>Policy rules (the following rules are only examples):</t>
<t>Policy rules (following rules are only examples):<list style="symbols" <ul spacing="normal">
><t>Maximum quality level allowed for the ACP</t> <li>Maximum quality level allowed for the ACP</li>
<li>Time bands allowed for providing quality sessions</li>
<t>Time bands allowed for providing quality sessions</t> <li>Number of simultaneous quality sessions allowed</li>
<li>Maximum time used by allowed quality sessions</li>
<t>Number of simultaneous quality sessions allowed</t> <li>Etc.</li>
</ul>
<t>Maximum time used by allowed quality sessions</t> </li>
</ul>
<t>Etc.</t> <t>
If any of the policy rules fail, a Q4S-ALERT message <bcp14>MUST</bcp14> be
</list> answered by a 6xx error indicating the cause.</t>
</t> </section>
</section>
</list> <section anchor="sec-7.5.4" numbered="true" toc="default">
</t> <name>"qos-level" Changes</name>
<t>
<t> If any constraint was violated, the server <bcp14>MAY</bcp14> trigger a Q4S-A
If any of the policy rules fail, a Q4S-ALERT message MUST be LERT
answered by a 6XX error, indicating the cause.</t> asking for a higher "qos-level" attribute. The maximum "qos-level"
allowed is 9 for both uplink and downlink.</t>
</section> <t>
If the "qos-level" has reached the maximum value for the downlink or
</section>
<section title="QoS Level Changes" anchor="section-7.5.4"><t>
If any constraint was violated, server MAY trigger a Q4S-ALERT
asking for higher qos-level attribute. The maximum qos-level
allowed is 9, both uplink and downlink.</t>
<t>
If the qos-level has reached the maximum value for downlink or
uplink without matching the constraints, then a CANCEL request uplink without matching the constraints, then a CANCEL request
MUST be sent by the client using the TCP port determined in the <bcp14>MUST</bcp14> be sent by the client using the TCP port determined in th
handshake phase in order to release the session. In reaction to e
the reception of the CANCEL request, the server MUST send a CANCEL Handshake phase in order to release the session. In reaction to
request too. If no CANCEL request is received, the expiration time the reception of the CANCEL request, the server <bcp14>MUST</bcp14> send a CA
cancels the session at server side.</t> NCEL
request, too. If no CANCEL request is received, the expiration time
<figure><artwork><![CDATA[ cancels the session on the server side.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Client Request: Client Request:
========================= =========================
CANCEL q4s://www.example.com Q4S/1.0 CANCEL q4s://www.example.com Q4S/1.0
User-Agent: q4s-ua-experimental-1.0 User-Agent: q4s-ua-experimental-1.0
Session-Id: 53655765 Session-Id: 53655765
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
(SDP not shown) (SDP not shown)
========================= =========================
skipping to change at line 2966 skipping to change at line 2753
CANCEL q4s://www.example.com Q4S/1.0 CANCEL q4s://www.example.com Q4S/1.0
Session-Id: 53655765 Session-Id: 53655765
Expires: 0 Expires: 0
Content-Type: application/sdp Content-Type: application/sdp
Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4
Content-Length: 131 Content-Length: 131
(SDP not shown) (SDP not shown)
========================= =========================
]]></artwork> ]]></artwork>
</figure> </section>
</section> </section>
<section anchor="sec-7.6" numbered="true" toc="default">
</section> <name>Continuity Phase</name>
<t>
<section title="Continuity Phase" anchor="section-7.6"><t> During the Negotiation phase, latency, jitter, bandwidth, and
During the negotiation phase, latency, jitter, bandwidth and packet loss have been measured. During the Continuity phase,
packet loss have been measured. During the continuity phase
bandwidth will not be measured again because bandwidth bandwidth will not be measured again because bandwidth
measurements may disturb application performance.</t> measurements may disturb application performance.</t>
<t>
<t>
This phase is supposed to be executed at the same time as the This phase is supposed to be executed at the same time as the
real-time application is being used.</t> real-time application is being used.</t>
<t>
<t> This document only covers the "default" procedure. The continuity
This document only covers the default procedure. The continuity operation with the "default" procedure is based on a sliding window of
operation with default procedure is based on a sliding window of
samples. The number of samples involved in the sliding window may samples. The number of samples involved in the sliding window may
be different for jitter and latency than for packet-loss be different for jitter and latency than for packet loss
calculations according to the fifth and sixth parameters of the calculations according to the fifth and sixth parameters of the
measurement procedure attribute. In the example, shown in Figure "measurement:procedure" attribute. In the example, shown in
11, the jitter and latency sliding window comprises 40 samples <xref target="ref-sliding-samples-window" format="default"/>,
whereas the size of the packet-loss sliding window is 100 samples:</t> the jitter and latency sliding window comprises 40 samples,
whereas the size of the packet loss sliding window is 100 samples:</t>
<figure><artwork><![CDATA[ <sourcecode type="sdp"><![CDATA[
a=measurement:procedure default(50/50,75/75,5000,40/40,100/100) a=measurement:procedure default(50/50,75/75,5000,40/40,100/100)
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
In addition, the sizes of these windows are configurable per In addition, the sizes of these windows are configurable per
direction: uplink and downlink values may differ.</t> direction: uplink and downlink values may differ.</t>
<t>
<t> PING requests are sent continuously (in both directions), and when
PING requests are sent continuously (in both directions) and when the Sequence-Number header field reaches the maximum value, the client
the Sequence-Number header reaches the maximum value, the client continues sending PING messages with the Sequence-Number header field
continues sending PING messages with the Sequence-Number header
starting again at zero. When the server PING Sequence-Number starting again at zero. When the server PING Sequence-Number
header reaches the maximum value, it does the same, starting again header field reaches the maximum value, it does the same, starting again
from zero.</t> from zero.</t>
<t>
<t>
On the client side, the measured values of downlink jitter, On the client side, the measured values of downlink jitter,
downlink packet loss and latency are calculated using the last downlink packet loss, and latency are calculated using the last
samples, discarding older ones, in a sliding window schema.</t> samples, discarding older ones, in a sliding window schema.</t>
<figure anchor="ref-sliding-samples-window">
<figure title="Sliding samples window" anchor="ref-sliding-samples-window <name>Sliding Samples Window</name>
"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------------------------------------------------+ +--------------------------------------------------+
| | | |
| 55 56 57 . . . 253 254 255 0 1 2 . . . 55 56 | | 55 56 57 . . . 253 254 255 0 1 2 . . . 55 56 |
| A A | | A A |
| | | | | | | |
| +-----------------------------------+ | | +-----------------------------------+ |
| | | |
+--------------------------------------------------+ +--------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Only if the server detects that the measured values (downlink or Only if the server detects that the measured values (downlink or
uplink jitter, packet loss or latency) are not reaching the uplink jitter, packet loss, or latency) are not reaching the
quality constraints, a Q4S ALERT is triggered and sent either to quality constraints, a Q4S-ALERT is triggered and sent either to
the client or to the Actuator, depending on the alerting mode, and the client or to the Actuator, depending on the alerting mode, and
the alert-pause timer is started.</t> the "alert-pause" timer is started.</t>
<t>
<t> In the Q4S-aware-network alerting mode shown in
In Q4S-aware-network alerting mode shown in Figure 12, if the <xref target="ref-continuity-in-q4s-aware-network-alerting-mode" format="defa
client receives a Q4S ALERT message, it MUST answer sending the ult"/>,
Q4S ALERT request message back to the server including the SDP if the
(with its corresponding digital signature).</t> client receives a Q4S-ALERT message, it <bcp14>MUST</bcp14> answer by sending
the
<t> Q4S-ALERT request message including the SDP
Both client and server will keep performing measurements but no (with its corresponding digital signature) back to the server.</t>
other Q4S ALERT message MUST be sent during "alert-pause" <t>
milliseconds. The operations needed to act on the network and the Both client and server will keep performing measurements,
agents in charge of them are out of scope of this draft.</t> but Q4S-ALERT messages <bcp14>MUST NOT</bcp14> be sent during
"alert-pause" milliseconds.
<figure title="Continuity in Q4S-aware-network alerting mode" anchor="ref The operations needed to act on the network and the
-continuity-in-q4s-aware-network-alerting-mode"><artwork><![CDATA[ agents in charge of them are out of scope of this document.</t>
<figure anchor="ref-continuity-in-q4s-aware-network-alerting-mode">
<name>Continuity in Q4S-Aware-Network Alerting Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------------------------------+ +------------------------------------------------+
| | | |
| Client Server | | Client Server |
| | | |
| ... | | ... |
| ----------- PING ----------> | | ----------- PING ----------> |
| <--------- 200 OK ---------- | | <--------- 200 OK ---------- |
| <------- Q4S-ALERT --------- | | <------- Q4S-ALERT --------- |
| -------- Q4S-ALERT --------> | | -------- Q4S-ALERT --------> |
| <---------- PING ----------- | | <---------- PING ----------- |
| ---------- 200 OK ---------> | | ---------- 200 OK ---------> |
| ----------- PING ----------> | | ----------- PING ----------> |
| <--------- 200 OK ---------- | | <--------- 200 OK ---------- |
| <---------- PING ----------- | | <---------- PING ----------- |
| ---------- 200 OK ---------> | | ---------- 200 OK ---------> |
| ... | | ... |
| | | |
+------------------------------------------------+ +------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In the Reactive scenario shown in Figure 13, if the server detects In the Reactive scenario shown in <xref target="ref-continuity-in-reactive-al
that the measured values (downlink or uplink jitter, packet loss erting-mode" format="default"/>,
if the server detects
that the measured values (downlink or uplink jitter, packet loss,
or latency) are not reaching the quality constraints, an alert or latency) are not reaching the quality constraints, an alert
notification is triggered and sent to the Actuator. The Actuator notification is triggered and sent to the Actuator. The Actuator
MUST then answer to the server stack with an alert acknowledgement</t> <bcp14>MUST</bcp14> then answer to the server stack with an alert acknowledge
ment.</t>
<t> <t>
The measurement dialog between the client and the server MUST NOT The measurement dialog between the client and the server <bcp14>MUST NOT</bcp
14>
be interrupted by any possible ALERT message.</t> be interrupted by any possible ALERT message.</t>
<figure anchor="ref-continuity-in-reactive-alerting-mode">
<figure title="Continuity in Reactive alerting mode" anchor="ref-continui <name>Continuity in Reactive Alerting Mode</name>
ty-in-reactive-alerting-mode"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------------------------------+ +------------------------------------------------+
| | | |
| Client Server Actuator | | Client Server Actuator |
| ... | | ... |
| --- PING ----------> | | --- PING ----------> |
| <-- 200 OK---------- | | <-- 200 OK---------- |
| <----- PING -------- | | <----- PING -------- |
| <--- 200 OK -------- ---- alert | | <--- 200 OK -------- ---- alert |
| notification --> | | notification --> |
| | | |
| --- PING ----------> <--- alert | | --- PING ----------> <--- alert |
| acknowledge --- | | acknowledge --- |
| <-- 200 OK---------- | | <-- 200 OK---------- |
| <----- PING -------- | | <----- PING -------- |
| --- 200 OK --------> | | --- 200 OK --------> |
| ... | | ... |
| | | |
+------------------------------------------------+ +------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="sec-7.7" numbered="true" toc="default">
<section title="Termination Phase" anchor="section-7.7"><t> <name>Termination Phase</name>
The Termination phase is the end point for the established Q4S <t>
The Termination phase is the endpoint for the established Q4S
session that is reached in the following cases:</t> session that is reached in the following cases:</t>
<ul spacing="normal">
<t><list style="symbols"><t>A CANCEL message has been received. The clien <li>A CANCEL message has been received. The client sends a
t sends a CANCEL message due to the network's inability to
CANCEL message due to the impossibility of the network to
meet the required quality constraints. The client and server meet the required quality constraints. The client and server
application will be notified by the respective Q4S stack.</t> application will be notified by their respective Q4S stacks.</li>
<li>Session expires: if after the Expires time, no client or
<t>Session expires: if after the Expires time no client or server activity is detected, that end cancels the session.</li>
server activity is detected, that end cancels the session.</t> <li>A BEGIN message has been received by the server.
The pre-existing Q4S quality session is canceled, and a new session
<t>A BEGIN message has been received by the server. The pre-existing Q4S will be initiated.</li>
quality session is cancelled and a new session </ul>
will be initiated.</t> <t>
The meaning of the Termination phase in terms of the release of resources
</list>
</t>
<t>
The meaning of Termination phase in terms of release of resources
or accounting is application dependent and out of scope of the Q4S or accounting is application dependent and out of scope of the Q4S
protocol.</t> protocol.</t>
<t>
<t> In the Reactive alerting mode, Q4S CANCEL messages received by the Q4S
In Reactive alerting mode, Q4S CANCEL messages received by the Q4S server must cause the server stack to send cancel notifications
server must cause the sending of cancel notifications sent from to the Actuator in order to release possible
the server stack to the Actuator in order to release possible
assigned resources for the session.</t> assigned resources for the session.</t>
<section anchor="sec-7.7.1" numbered="true" toc="default">
<section title="Sanity Check of Quality Sessions" anchor="section-7.7.1"> <name>Sanity Check of Quality Sessions</name>
<t> <t>
A session may finish due to several reasons (client shutdown, A session may finish due to several reasons (client shutdown,
client CANCEL request, constraints not reached, etc), and any client CANCEL request, constraints not reached, etc.), and any
session finished MUST release the assigned resources.</t> session finished <bcp14>MUST</bcp14> release the assigned resources.</t>
<t>
<t>
In order to release the assigned server resources for the session, In order to release the assigned server resources for the session,
the "Expires" header indicates the maximum interval of time the Expires header field indicates the maximum interval of time
without exchanging any Q4S message.</t> without exchanging any Q4S message.</t>
</section>
</section> </section>
<section anchor="sec-7.8" numbered="true" toc="default">
</section> <name>Dynamic Constraints and Flows</name>
<t>
<section title="Dynamic Constraints And Flows" anchor="section-7.8"><t>
Depending on the nature of the application, the quality Depending on the nature of the application, the quality
constraints to be reached may evolve, changing some or all quality constraints to be reached may evolve, changing some or all quality
constraint values in any direction.</t> constraint values in any direction.</t>
<t>
<t> The client <bcp14>MUST</bcp14> be able to deal with this possibility. When th
The client MUST be able to deal with this possibility. When the e
server sends an SDP document attached to a response (200 OK, or server sends an SDP document attached to a response (200 OK or
Q4S-ALERT, etc), the client MUST take all the new received values, Q4S-ALERT, etc.), the client <bcp14>MUST</bcp14> take all the new received va
lues,
overriding any previous value in use.</t> overriding any previous value in use.</t>
<t>
<t> The dynamic changes on the quality constraints can be a result
The dynamic changes on the quality constraints can be as a result
of two possibilities:</t> of two possibilities:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The application communicates to the Q4S serve <li>The application communicates to the Q4S server a change in
r a change in the constraints. In this case, the application requirements
the constraints. In this case the application requirements can evolve, and the Q4S server will be aware of them.</li>
can evolve and the Q4S server will be aware of them.</t> <li>The application uses TCP flows. In that case, in order to
<t>The application uses TCP flows. In that case, in order to
guarantee a constant throughput, the nature of TCP behavior guarantee a constant throughput, the nature of TCP behavior
forces the use of a composite constraint function, which forces the use of a composite constraint function, which
depends on RTT, packet loss and window control mechanism depends on RTT, packet loss, and a window control mechanism
implemented in each TCP stack.</t> implemented in each TCP stack.</li>
</ul>
</list> <t>
</t>
<t>
TCP throughput can be less than actual bandwidth if the TCP throughput can be less than actual bandwidth if the
Bandwidth-Delay Product (BDP) is large or if the network suffers Bandwidth-Delay Product (BDP) is large, or if the network suffers
from a high packet loss rate. In both cases, TCP congestion from a high packet loss rate. In both cases, TCP congestion
control algorithms may result in a suboptimal performance.</t> control algorithms may result in a suboptimal performance.</t>
<t>
<t> Different TCP congestion control implementations like Reno <xref target="RENO
Different TCP congestion control implementations like Reno <xref target="ref- " format="default"/>,
23" />, High Speed TCP <xref target="RFC3649" format="default"/>,
High Speed TCP (RFC 3649 <xref target="ref-24"/>), CUBIC <xref target="ref-25 CUBIC <xref target="I-D.rhee-tcpm-cubic" format="default"/>,
"/>, Compound TCP (CTCP Compound TCP (CTCP) <xref target="I-D.sridharan-tcpm-ctcp" format="default"/>
<xref target="ref-26"/>), etc. reach different throughputs under the same net ,
work etc., reach different throughputs under the same network
conditions of RTT and packet loss. In all cases, depending on the conditions of RTT and packet loss. In all cases, depending on the
RTT measured value, the Q4S server could change dynamically the RTT-measured value, the Q4S server could dynamically change the
packetloss constraints (defined in SDP) in order to make possible packetloss constraints (defined in the SDP) in order to make it possible
to reach a required throughput or vice versa (use packetloss to reach a required throughput or vice versa (using "measurement:packetloss"
measurement to change dynamically latency constraints).</t> to change dynamically the latency constraints).</t>
<t>
<t> A general guideline for calculating the packet loss constraint and the RTT
A general guideline to calculate the packetloss constraint and RTT constraint consists of approximating the throughput by using a
constraint consists in approximating the throughput using a
simplified formula, which should take into account the TCP stack simplified formula, which should take into account the TCP stack
implementation of the receiver, in addition to RTT and packet implementation of the receiver, in addition to the RTT and packet
loss:</t> loss:</t>
<sourcecode type="pseudocode"><![CDATA[
<figure><artwork><![CDATA[
Th= Function( RTT, packet loss, ...) Th= Function( RTT, packet loss, ...)
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> Then, depending on RTT-measured values, set dynamically the
Then, depending on RTT measured values, set dynamically the packet loss constraint.</t>
packetloss constraint.</t> <t>
<t>
It is possible to easily calculate a worst-case boundary for the It is possible to easily calculate a worst-case boundary for the
Reno algorithm, which should ensure for all algorithms that the Reno algorithm, which should ensure for all algorithms that the
target throughput is actually achieved. Except that, high-speed target throughput is actually achieved, except that high-speed
algorithms will then have even a larger throughput, if more algorithms will then have even larger throughput if more
bandwidth is available.</t> bandwidth is available.</t>
<t>
<t> For the Reno algorithm, the Mathis formula may be used <xref target="RENO" fo
For the Reno algorithm, the Mathis' formula may be used <xref target="ref-23" rmat="default"/> for
/> for
the upper bound on the throughput:</t> the upper bound on the throughput:</t>
<sourcecode type="pseudocode"><![CDATA[
<t><list hangIndent="9" style="hanging"><t> Th <= (MSS/RTT)*(1 / sqrt{p})
Th &lt;= (MSS/RTT)*(1 / sqrt{p})</t> ]]></sourcecode>
<t>
</list> In the absence of packet loss, a practical limit for the TCP
</t> throughput is the receiver_window_size divided by the RTT.
However, if the TCP implementation uses a window scale
<t>
In absence of packet loss, a practical limit for the TCP
throughput is the receiver_window_size divided by the round-trip
time. However, if the TCP implementation uses a window scale
option, this limit can reach the available bandwidth value.</t> option, this limit can reach the available bandwidth value.</t>
</section>
</section> <section anchor="sec-7.9" numbered="true" toc="default">
<name>"qos-level" Upgrade and Downgrade Operation</name>
<section title="Qos-level Upgrade And Downgrade Operation" anchor="sectio <t>
n-7.9"><t> Each time the server detects a violation of constraints, the alert
Each time the server detects violation of constraints, the alert mechanism is triggered, the "alert-pause" timer is started, and the
mechanism is triggered, the alert-pause timer is started, and the "qos-level" is increased. When this happens repeatedly, and the
qos-level is increased. When this happens repeatedly, and the qos-level reach "qos-level" reaches its maximum value (value 9), the session is
es its maximum value (value 9), the session is canceled. But when the violation of constraints stops before
cancelled. But when the violation of constraints stops before reaching "qos-level" maximum value, the recovery mechanism allows
reaching qos-level maximum value, the recovery mechanism allows for the "qos-level" upgrade gradually.</t>
for the qos-level upgrade gradually.</t> <t>
This downgrade and upgrade of "qos-level" is explained
<t> with the following example:</t>
Following, this downgrade and upgrade of qos-level is explained <ol spacing="normal" type="1">
with an example:</t> <li>A Q4S session is initiated successfully with "qos-level=0".</li>
<li>During the Continuity phase, violation of constraints is
<t><list style="numbers"><t>A Q4S session is initiated successfully with detected; the "qos-level" is increased to 1, a Q4S-ALERT is sent by
qos-level=0.</t> the server to the client, and an "alert-pause" timer is started.</li>
<li>The "alert-pause" timer expires, and still a violation of constrai
<t>During the continuity phase, violation of constraints is nts
detected; qos-level is increased to 1, a Q4S-ALERT is sent by is detected; the "qos-level" is increased to 2, a Q4S-ALERT is sent
the server to the client and alert-pause timer is started.</t> by the server to the client, and an "alert-pause" timer is started.</li>
<li>The "alert-pause" timer expires, but the violation of constraints
<t>Alert-pause timer expires and still violation of constraints has
is detected; qos-level is increased to 2, a Q4S-ALERT is sent stopped; the "recovery-pause" timer is started.</li>
by the server to the client and alert-pause timer is started.</t> <li>The "recovery-pause" timer expires, and no violation of
constraints has been detected. Meanwhile, the "qos-level" is
<t>Alert-pause timer expires but violation of constraints has
stopped; recovery-pause is started.</t>
<t>Recovery-pause timer expires, and no violation of
constraints has been detected meanwhile; qos-level is
decreased to 1, a Q4S-RECOVERY is sent by the server to the decreased to 1, a Q4S-RECOVERY is sent by the server to the
client and recovery-pause timer is started again.</t> client, and the "recovery-pause" timer is started again.</li>
<li>The "recovery-pause" timer expires again, and no violation of
<t>Recovery-pause timer expires again and no violation of constraints has been detected. Meanwhile, the "qos-level" is
constraints has been detected meanwhile; qos-level is decreased to 0, and a Q4S-RECOVERY is sent by the server to
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 client; recovery-pause timer is not started this time as the "qos-level" has reached its initial value.</li>
qos-level has reached its initial value.</t> </ol>
<t>
</list>
</t>
<t>
When the network configuration allows for the possibility of When the network configuration allows for the possibility of
managing Q4S flows and application flows independently (either is managing Q4S flows and application flows independently (either is
a network-based QoS or a Q4S aware network), the qos-level a network-based QoS or a Q4S-aware network), the "qos-level"
downgrade process could be managed more efficiently using a downgrade process could be managed more efficiently using a
strategy that allows for carrying out qos-level downgrades strategy that allows for carrying out "qos-level" downgrades
excluding app flows from SDP dynamically. The Q4S flows would be excluding application flows from SDP dynamically. The Q4S flows would be
downgraded to allow for measurements on a lower quality level downgraded to allow for measurements on a lower quality level
without interference of the application flows. A Q4S client MUST without interference of the application flows. A Q4S client <bcp14>MUST</bcp1
allow this kind of SDP modifications by the server.</t> 4>
allow this kind of SDP modification by the server.</t>
<t> <t>
Periodically (every several minutes, depending on the Periodically (every several minutes, depending on the
implementation) a Q4S-ALERT could be triggered, in which the level implementation) a Q4S-ALERT could be triggered, in which the level
is downgraded for Q4S flows, excluding application flows from the is downgraded for Q4S flows, excluding application flows from the
embedded SDP of that request.</t> embedded SDP of that request.</t>
<t>
<t> This mechanism allows the measurement at lower levels of quality while
This mechanism allows to measure at lower levels of quality while application flows continue using a higher "qos-level" value.</t>
application flows continue using a higher qos level value.</t> <ul spacing="normal">
<li>If the measurements in the lower level meet the quality
<t><list style="symbols"><t>If the measurements in the lower level meet t constraints, then a Q4S-RECOVERY message to this lower "qos-level" may be
he quality triggered, in which the SDP includes the
constraints, then a Q4S-RECOVERY message to this lower qos-level may be tr application flows in addition to the Q4S flows.</li>
iggered, in which the SDP includes the <li>If the measurements in the lower level do not meet the
application flows in addition to Q4S flows.</t> constraints, then a new Q4S-ALERT to the previous "qos-level"
<bcp14>MUST</bcp14> be triggered, in which the SDP includes only the Q4S
<t>If the measurements in the lower level do not meet the flows.</li>
constraints, then a new Q4S-ALERT to the previous qos-level </ul>
MUST be triggered, in which the SDP includes only the Q4S <figure anchor="ref-possible-evolution-of-qos-level">
flows.</t> <name>Possible Evolution of "qos-level"</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
</list>
</t>
<figure title="Possible evolution of qos-level" anchor="ref-possible-evol
ution-of-qos-level"><artwork><![CDATA[
+------------------------------------------------+ +------------------------------------------------+
| | | |
| qos-level | | qos-level |
| A | | A |
| | | | | |
| 4| | | 4| |
| | | | | |
| 3| +------+ | | 3| +------+ |
| | | | | | | | | |
| 2| +----+ +----+ +--- | | 2| +----+ +----+ +--- |
| | | | | | | | | | | |
| 1| +----+ +-----+ | | 1| +----+ +-----+ |
| | | | | | | |
| 0+---+---------------------------------> time | | 0+---+---------------------------------> time |
| | | |
+------------------------------------------------+ +------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
This mechanism, illustrated in Figure 14, avoids the risk of This mechanism, illustrated in <xref target="ref-possible-evolution-of-qos-le
disturbing the application, while the measurements are being run vel" format="default"/>, avoids the risk of
disturbing the application while the measurements are being run
in lower levels. However, this optional optimization of resources in lower levels. However, this optional optimization of resources
MUST be used carefully.</t> <bcp14>MUST</bcp14> be used carefully.</t>
<t>
<t> The chosen period to measure a lower "qos-level" is implementation
The chosen period to measure a lower qos level is implementation dependent. Therefore, it is not included as a "measurement:procedure" paramet
dependent. Therefore, it is not included as a measurement er.
procedure parameter. It is RECOMMENDED to use a large value, such It is <bcp14>RECOMMENDED</bcp14> to use a large value, such
as 20 minutes.</t> as 20 minutes.</t>
</section>
</section> </section>
<section anchor="sec-8" numbered="true" toc="default">
</section> <name>General User Agent Behavior</name>
<section anchor="sec-8.1" numbered="true" toc="default">
<section title="General User Agent Behavior" anchor="section-8"><section <name>Roles in Peer-to-Peer Scenarios</name>
title="Roles in Peer-to-Peer Scenarios" anchor="section-8.1"><t> <t>
In order to allow peer to peer applications, a Q4S User Agent (UA) In order to allow peer-to-peer applications, a Q4S User Agent (UA)
MUST be able to assume both client and server role. The role <bcp14>MUST</bcp14> be able to assume both the client and server role. The ro
le
assumed depends on who sends the first message.</t> assumed depends on who sends the first message.</t>
<t>
<t> In a communication between two UAs, the UA that first sends the Q4S
In a communication between two UAs, the UA that sends the Q4S BEGIN request to start the Handshake phase shall assume the client role.</t>
BEGIN request in the first place, for starting the handshake <t>
phase, shall assume the client role.</t> If both UAs send the BEGIN request at the same time, they will
wait for a random time to restart again as shown in <xref target="ref-p2p-rol
<t> es" format="default"/>.</t>
If both UASs send the BEGIN request at the same time, they will <t>
wait for a random time to restart again as shown in Figure 15.</t>
<t>
Otherwise, an UA may be configured to act only as server (e.g., Otherwise, an UA may be configured to act only as server (e.g.,
content provider's side).</t> content provider's side).</t>
<figure anchor="ref-p2p-roles">
<figure title="P2P roles." anchor="ref-p2p-roles."><artwork><![CDATA[ <name>P2P Roles</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------------------------------------+ +-----------------------------------------------+
| | | |
| UA(Client) UA(Server) | | UA(Client) UA(Server) |
| | | |
| -------- Q4S BEGIN -------------> | | -------- Q4S BEGIN -------------> |
| <------- Q4S BEGIN -------------- | | <------- Q4S BEGIN -------------- |
| | | |
| ------- Q4S BEGIN --------------> | | ------- Q4S BEGIN --------------> |
| <------ Q4S 200 OK -------------- | | <------ Q4S 200 OK -------------- |
| | | |
| | | |
+-----------------------------------------------+ +-----------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="sec-8.2" numbered="true" toc="default">
<section title="Multiple Quality Sessions in Parallel" anchor="section-8. <name>Multiple Quality Sessions in Parallel</name>
2"><t> <t>
A Q4S session is intended to be used for an application. It means A Q4S session is intended to be used for an application. This means
that for using the application, the client MUST establish only one that for using the application, the client <bcp14>MUST</bcp14> establish only
one
Q4S session against the server. Indeed, the relation between Q4S session against the server. Indeed, the relation between
session-id and application is 1 to 1.</t> the Session-Id and the application is 1 to 1.</t>
<t>
<t>
If a user wants to participate in several independent Q4S sessions If a user wants to participate in several independent Q4S sessions
simultaneously against different servers (or against the same simultaneously against different servers (or against the same
server) it can execute different Q4S clients to establish server), it can execute different Q4S clients to establish
separately different Q4S sessions but it is NOT RECOMMENDED, separately different Q4S sessions, but it is <bcp14>NOT RECOMMENDED</bcp14>
because:</t> because:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The establishment of a new Q4S session may af <li>The establishment of a new Q4S session may affect other
fect other
running applications over other Q4S sessions during bandwidth running applications over other Q4S sessions during bandwidth
measurement.</t> measurement.</li>
<li>If the Negotiation phase is executed separately before
<t>If the negotiation phase is executed separately before
running any application, the summation of bandwidth running any application, the summation of bandwidth
requirements could not be met when the applications are requirements could not be met when the applications are
running in parallel.</t> running in parallel.</li>
</ul>
</list> </section>
</t> <section anchor="sec-8.3" numbered="true" toc="default">
<name>General Client Behavior</name>
</section> <t>
A Q4S client has different behaviors. We will use letters X, Y, and Z to
<section title="General Client bBhavior" anchor="section-8.3"><t> designate each different behavior (follow the letters in
A Q4S Client has different behaviors. We will use letters X,Y,Z to <xref target="ref-phases-client-behaviors" format="default"/> and their descr
designate each different behavior (follow the letter bullets in iptions below).</t>
figure 16).</t> <dl newline="false" spacing="normal" indent="4">
<dt>X)</dt>
<t><list hangIndent="3" style="hanging"> <dd>When it sends messages over TCP (methods BEGIN, READY,
<t hangText="X)">When it sends messages over TCP (methods BEGIN, READY, Q4S-ALER Q4S-ALERT, Q4S-RECOVERY, and CANCEL), it behaves strictly like a state
T, Q4S-RECOVERY and CANCEL) it behaves strictly like a state
machine that sends requests and waits for responses. Depending machine that sends requests and waits for responses. Depending
on the response type it enters in a new state.</t> on the response type, it enters into a new state.</dd>
</dl>
</list> <t>
</t>
<t>
When it sends UDP messages (methods PING and BWIDTH), a Q4S client When it sends UDP messages (methods PING and BWIDTH), a Q4S client
is not strictly a state machine that sends messages and waits for is not strictly a state machine that sends messages and waits for
responses because:</t> responses because of the following:</t>
<dl newline="false" spacing="normal" indent="4">
<t><list hangIndent="3" style="hanging"> <dt>Y)</dt>
<t hangText="Y)">At latency, jitter and packet loss measurement, the PING <dd>During the measurement of latency, jitter, and packet loss, the PI
requests are sent periodically, not after receiving the response NG
to the previous request. In addition, the client MUST answer the requests are sent periodically, not just after receiving the response
to the previous request. In addition, the client <bcp14>MUST</bcp14> answe
r the
PING requests coming from the server, therefore the client PING requests coming from the server, therefore the client
assumes temporarily the role of a server.</t> assumes temporarily the role of a server.</dd>
</dl>
</list> <dl newline="false" spacing="normal" indent="4">
</t> <dt>Z)</dt>
<dd>During the bandwidth and packet loss measurement stage, the client
<t><list hangIndent="3" style="hanging">
<t hangText="Z)">At bandwidth and packet loss measurement stage, the client
does not expect to receive responses when sending BWIDTH does not expect to receive responses when sending BWIDTH
requests to the server. In addition, it MUST receive and process requests to the server. In addition, it <bcp14>MUST</bcp14> receive and pr ocess
all server messages in order to achieve the downlink all server messages in order to achieve the downlink
measurement.</t> measurement.</dd>
</dl>
</list> <t>
</t>
<t>
The Q4S-ALERT and CANCEL may have a conventional answer if an The Q4S-ALERT and CANCEL may have a conventional answer if an
error is produced, otherwise the corresponding answer is formatted error is produced, otherwise the corresponding answer is formatted
as a request message.</t> as a request message.</t>
<figure anchor="ref-phases-client-behaviors">
<figure title="Phases &amp; client behaviors" anchor="ref-phases-client-b <name>Phases and Client Behaviors</name>
ehaviors"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-----------+------------------------+-----------+-----------+ +-----------+------------------------+-----------+-----------+
| Handshake | Negotiation |Continuity |Termination| | Handshake | Negotiation |Continuity |Termination|
| Phase | Phase | Phase | Phase | | Phase | Phase | Phase | Phase |
| | | | | | | | | |
| X ---------> Y --> X --> Z --> X ---> Y --> X ---> X | | X ---------> Y --> X --> Z --> X ---> Y --> X ---> X |
| | A | A | | A | | | | | A | A | | A | | |
| | | | | | | | | | | | | | | | | | | | | |
| | +-----+ +-----+ | +-----+ | | | | +-----+ +-----+ | +-----+ | |
| | | | | | | | | |
+------------------------------------------------+-----------+ +------------------------------------------------+-----------+
]]></artwork> ]]></artwork>
</figure> </figure>
<section title="Generating Requests" anchor="section-8.3.1"><t> <section anchor="sec-8.3.1" numbered="true" toc="default">
A valid Q4S request formulated by a Client MUST, at a minimum, <name>Generating Requests</name>
contains the following header fields:</t> <t>
A valid Q4S request formulated by a client <bcp14>MUST</bcp14>, at a minimum,
<t><list style="symbols"><t>If no SDP is included: the header Session-Id contain the following header fields:</t>
and Sequence-Number are mandatory.</t> <dl>
<dt>If no SDP is included:</dt><dd>the header fields Session-Id and
<t>If SDP is included: Session-Id is embedded into SDP, Sequence-Number are mandatory.</dd>
therefore the inclusion of Session-Id header is optional but <dt>If SDP is included:</dt><dd>the Session-Id is embedded into the
if present must have the same value. Measurements are 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 embedded into the SDP only for Q4S-ALERT messages in order to
be signed.</t> be signed.</dd>
</dl>
</list> <t>
</t> At any time, if the server sends new SDP with updated values,
the client <bcp14>MUST</bcp14> take it into account.</t>
<t> </section>
At any time, if the server sends a new SDP with updated values, </section>
client MUST take it into account.</t> <section anchor="sec-8.4" numbered="true" toc="default">
<name>General Server Behavior</name>
</section> <t>
</section>
<section title="General Server Behavior" anchor="section-8.4"><t>
If a server does not understand a header field in a request (that 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 is, the header field is not defined in this specification or in
any supported extension), the server MUST ignore that header field any supported extension), the server <bcp14>MUST</bcp14> ignore that header f ield
and continue processing the message.</t> and continue processing the message.</t>
<t>
<t> The role of the server is changed at Negotiation and Continuity
The role of the server is changed at negotiation and continuity phases, in which the server <bcp14>MUST</bcp14> send packets to measure jitte
phases, in which server MUST send packets to measure jitter, r,
latency and bandwidth. Therefore, the different behaviors of latency, and bandwidth. Therefore, the different behaviors of
server are (follow the letter bullets in the figure 17):</t> the server are (follow the letters in <xref target="ref-phases-server-behavio
urs" format="default"/>
<t><list hangIndent="3" style="hanging"> and their descriptions below):</t>
<t hangText="R)"> <dl newline="false" spacing="normal" indent="4">
<dt>R)</dt>
<dd>
When the client sends messages over TCP (methods BEGIN, When the client sends messages over TCP (methods BEGIN,
READY Q4S-ALERT, Q4S-RECOVERY and CANCEL) it behaves strictly READY Q4S-ALERT, Q4S-RECOVERY, and CANCEL), it behaves strictly
like a state machine that receives messages and sends like a state machine that receives messages and sends
responses.</t> responses.</dd>
</dl>
</list> <t>
</t>
<t>
When the client begins to send UDP messages (methods PING and When the client begins to send UDP messages (methods PING and
BWIDTH), a Q4S server is not strictly a state machine that BWIDTH), a Q4S server is not strictly a state machine that
receives messages and sends responses because:</t> receives messages and sends responses because of the following:</t>
<dl newline="false" spacing="normal" indent="4">
<t><list hangIndent="3" style="hanging"> <dt>S)</dt>
<t hangText="S)"> <dd>
At latency, jitter and packet loss measurement, the PING During the measurement of latency, jitter, and packet loss, the PING
requests are sent periodically by the client but also by the requests are sent periodically by the client and also by the
server. In this case the server behaves as a server answering server. In this case, the server behaves as a server answering
client requests but also behaves temporarily as a client, client requests but also behaves temporarily as a client,
sending PING requests toward the client and receiving sending PING requests toward the client and receiving
responses.</t> responses.</dd>
</dl>
</list> <dl newline="false" spacing="normal" indent="4">
</t> <dt>T)</dt>
<dd>
<t><list hangIndent="3" style="hanging"> During bandwidth and packet loss measurement, the server sends
<t hangText="T)"> BWIDTH requests to the client. In addition, it <bcp14>MUST</bcp14> receive
At bandwidth and packet loss measurement, the server sends and
BWIDTH requests to the client. In addition, it MUST receive and
process client messages in order to achieve the uplink process client messages in order to achieve the uplink
measurement.</t> measurement.</dd>
</dl>
</list> <t>
</t>
<t>
The Q4S-ALERT and CANCEL may have a conventional answer if an The Q4S-ALERT and CANCEL may have a conventional answer if an
error is produced, otherwise the corresponding answer is formatted error is produced, otherwise the corresponding answer is formatted
as a request message.</t> as a request message.</t>
<figure anchor="ref-phases-server-behaviours">
<figure title="Phases &amp; server behaviours" anchor="ref-phases-server- <name>Phases and Server Behaviors</name>
behaviours"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-----------+------------------------+-----------+-----------+ +-----------+------------------------+-----------+-----------+
| Handshake | Negotiation |Continuity |Termination| | Handshake | Negotiation |Continuity |Termination|
| Phase | Phase | Phase | Phase | | Phase | Phase | Phase | Phase |
| | | | | | | | | |
| R ---------> S --> R --> T --> R ---> S --> R ---> R | | R ---------> S --> R --> T --> R ---> S --> R ---> R |
| | A | A | | A | | | | | A | A | | A | | |
| | | | | | | | | | | | | | | | | | | | | |
| | +-----+ +-----+ | +-----+ | | | | +-----+ +-----+ | +-----+ | |
| | | | | | | | | |
+------------------------------------------------+-----------+ +------------------------------------------------+-----------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section>
</section> <section anchor="sec-9" numbered="true" toc="default">
<name>Implementation Recommendations</name>
<section title="Implementation Recommendations" anchor="section-9"><secti <section anchor="sec-9.1" numbered="true" toc="default">
on title="Default Client Constraints" anchor="section-9.1"><t> <name>Default Client Constraints</name>
To provide a default configuration, it would be good that the <t>
client had a configurable set of Quality headers in the To provide a default configuration, it would be good if the
implementation settings menu. Otherwise these quality headers will 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.</t> not be present in the first message.</t>
<t>
<t>
Different business models (out of scope of this proposal) may be Different business models (out of scope of this proposal) may be
achieved: depending on who pays for the quality session, the achieved: depending on who pays for the quality session, the
server can accept certain Client parameters sent in the first server can accept certain client parameters sent in the first
message, or force billing parameters on the server side.</t> message, or force billing parameters on the server side.</t>
</section>
</section> <section anchor="sec-9.2" numbered="true" toc="default">
<name>Latency and Jitter Measurements</name>
<section title="Latency and Jitter Measurements" anchor="section-9.2"><t> <t>
Different client and server implementations may send a different Different client and server implementations may send a different
number of PING messages for measuring, although at least 255 number of PING messages for measuring, although at least 255
messages should be considered to perform the latency measurement. messages should be considered to perform the latency measurement.
The Stage 0 measurements only may be considered ended when neither The Stage 0 measurements may be considered ended only when neither
client nor server receive new PING messages after an the client nor server receive new PING messages after an
implementation-dependent guard time. Only after, client can send a implementation-dependent guard time. Only after, the client can send a
"READY 1" message.</t> "READY 1" message.</t>
<t>
<t>
In execution systems, where the timers are not accurate, a In execution systems, where the timers are not accurate, a
recommended approach consists of including the optional header recommended approach consists of including the optional Timestamp header fiel
"Timestamp" in the PING request with the time in which the message d
in the PING request with the time in which the message
has been sent. This allows an accurate measurement of the jitter has been sent. This allows an accurate measurement of the jitter
even with no identical intervals of time between PINGs.</t> even with no identical intervals of time between PINGs.</t>
</section>
</section> <section anchor="sec-9.3" numbered="true" toc="default">
<name>Bandwidth Measurements</name>
<section title="Bandwidth Measurements" anchor="section-9.3"><t> <t>
In programming languages or Operating Systems with limited timers In programming languages or operating systems with limited timers
or clock resolution, it is recommended to use an approach based on or clock resolution, it is recommended to use an approach based on
several intervals to send messages of 1KB (= 8000 bits), in order several intervals to send messages of 1KB (= 8000 bits) in order
to reach the required bandwidth consumption using a rate as close to reach the required bandwidth consumption, using a rate as close
as possible to a constant rate.</t> as possible to a constant rate.</t>
<t>
<t>
For example, if the resolution is 1 millisecond, and the bandwidth For example, if the resolution is 1 millisecond, and the bandwidth
to reach is 11Mbps, a good approach consists of sending: </t> to reach is 11 Mbps, a good approach consists of sending: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
1 message of 1KB every 1 millisecond + 1 message of 1KB every 1 millisecond +
1 message of 1KB every 3 milliseconds + 1 message of 1KB every 3 milliseconds +
1 message of 1KB every 23 milliseconds 1 message of 1KB every 23 milliseconds
]]></artwork></figure> ]]></artwork>
<t>
<t> The number of intervals depends on the required bandwidth and accuracy
The number of intervals depends on required bandwidth and accuracy
that the programmer wants to achieve.</t> that the programmer wants to achieve.</t>
<t>
<t>
Considering messages of 1KB (= 8000 bits), a general approach to Considering messages of 1KB (= 8000 bits), a general approach to
determine these intervals is determine these intervals is the following:
<list style="format (%d)">
<t> Compute Target bandwidth / 8000 bits. In the example above is
11Mbps/8000 = 1375 messages per second
</t>
<t> Divide the number of messages per second by 1000 to determine </t>
the number of messages per millisecond. 1375/1000 = 1'375. The <ol spacing="normal" type="(%d)">
<li> Compute target bandwidth / 8000 bits. In the example above, it is
11 Mbps / 8000 = 1375 messages per second.
</li>
<li> 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 integer value is the number of messages per millisecond (in this
case, one). The pending bandwidth is now 375 messages per second case, one). The pending bandwidth is now 375 messages per second.
</t> </li>
<li>
<t> To achieve the 375 messages per second, use a sub-multiple of <t> To achieve the 375 messages per second, use a submultiple of
1000 which must be less than 375 1000, which must be less than 375:
</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
1000 / 2 = 500 > 375
1000/2 = 500 > 375
1000/3 = 333 < 375
]]></artwork></figure>
In this case a message every 3 ms is suitable. The new pending
target bandwidth is 375 -333 = 42 messages per second</t>
<t> Repeat the same strategy as point 3, to reach the pending 1000 / 3 = 333 < 375
bandwidth. In this case, 23 ms is suitable because: ]]></artwork>
<t>
<figure><artwork><![CDATA[ In this case, a message every 3 ms is suitable. The new pending
target bandwidth is 375 - 333 = 42 messages per second.</t>
</li>
<li>
<t> 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 </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
1000 / 22 = 45 > 42
1000/23 = 43 >42 1000 / 23 = 43 > 42
1000 / 24 = 41.6 < 42 1000 / 24 = 41.6 < 42
]]></artwork>
]]></artwork></figure> </li>
</t> </ol>
</list> <t>
</t> 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
<t>
We can choose 24 ms but then we need to cover additional 0.4
messages per second (42-41.6=0.4) and 43 is a number higher than
42 but very close to it.</t> 42 but very close to it.</t>
<t>
<t>
In execution systems where the timers are not accurate, a In execution systems where the timers are not accurate, a
recommended approach consists of checking at each interval the recommended approach consists of checking at each interval the
number of packets that should have been sent at this timestamp number of packets that should have been sent at this timestamp
since origin and send the needed number of packets in order to since origin and send the needed number of packets in order to
reach the required bandwidth.</t> reach the required bandwidth.</t>
<t>
<t> The shorter the packets used, the more constant the rate of
The shorter packets are used, the more constant is the rate of
bandwidth measurement. However, this may stress the execution bandwidth measurement. However, this may stress the execution
system in charge of receiving and processing packets. As a system in charge of receiving and processing packets. As a
consequence, some packets may be lost because of stack overflows. consequence, some packets may be lost because of stack overflows.
To deal with this potential issue, a larger packet is RECOMMENDED To deal with this potential issue, a larger packet is <bcp14>RECOMMENDED</bcp
(2KB or more) taking into account the overhead produced by the 14>
chunks headers.</t> (2KB or more), taking into account the overhead produced by the
chunks' headers.</t>
</section> </section>
<section anchor="sec-9.4" numbered="true" toc="default">
<section title="Packet Loss Measurement Resolution" anchor="section-9.4"> <name>Packet Loss Measurement Resolution</name>
<t> <t>
Depending on application nature and network conditions, a packet Depending on the application nature and network conditions, a packet
loss resolution less than 1% may be needed. In such cases, there 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 is no limit to the number of samples used for this calculation. A
tradeoff between time and resolution should be reached in each trade-off between time and resolution should be reached in each
case. For example, in order to have a resolution of 1/10000, the case. For example, in order to have a resolution of 1/10000, the
last 10000 samples should be considered in the packet loss last 10000 samples should be considered in the packet loss
measured value.</t> measured value.</t>
<t>
<t>
The problem of this approach is the reliability of old samples. If The problem of this approach is the reliability of old samples. If
the interval used between PING messages is 50ms, then to have a 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 resolution of 1/1000, it takes 50 seconds, and a resolution of
1/10000 takes 500 seconds (more than 8 minutes). The reliability 1/10000 takes 500 seconds (more than 8 minutes). The reliability
of a packet loss calculation based on a sliding window of 8 of a packet loss calculation based on a sliding window of 8
minutes depends on how fast network conditions evolve.</t> minutes depends on how fast network conditions evolve.</t>
</section>
</section> <section anchor="sec-9.5" numbered="true" toc="default">
<name>Measurements and Reactions</name>
<section title="Measurements and Reactions" anchor="section-9.5"><t> <t>
Q4S can be used as a mechanism to measure and trigger network Q4S can be used as a mechanism to measure and trigger network
tuning and application level actions (i.e. lowering video bit-rate, reduce mu tuning and application-level actions (i.e. lowering video bit-rate,
ltiplayer interaction speed, etc) in real-time in reducing multiplayer interaction speed, etc.) in real time in
order to reach the application constraints, addressing measured order to reach the application constraints, addressing measured
possible network degradation.</t> possible network degradation.</t>
</section>
</section> <section anchor="sec-9.6" numbered="true" toc="default">
<name>Instability Treatments</name>
<section title="Instability Treatments" anchor="section-9.6"><t> <t>
There are two scenarios in which Q4S can be affected by network There are two scenarios in which Q4S can be affected by network
problems: loss of Q4S packets and outlier samples.</t> problems: loss of Q4S packets and outlier samples.</t>
<section anchor="sec-9.6.1" numbered="true" toc="default">
<section title="Loss of Control Packets" anchor="section-9.6.1"><t> <name>Loss of Control Packets</name>
<t>
Lost UDP packets (PING or BWIDTH messages) don't cause any Lost UDP packets (PING or BWIDTH messages) don't cause any
problems for the Q4S state machine, but if TCP packets are problems for the Q4S state machine, but if TCP packets are
delivered too late (which we will consider as "lost"), some delivered too late (which we will consider as "lost"), some
undesirable consequences could arise.</t> undesirable consequences could arise.</t>
<t>
<t>
Q4S does have protection mechanisms to overcome these situations. Q4S does have protection mechanisms to overcome these situations.
Examples:</t> Examples:</t>
<ul spacing="normal">
<t><list style="symbols"><t>If a BEGIN packet is lost or its correspondin <li>If a BEGIN packet or its corresponding answer is lost, after
g answer, after a certain timeout, the client <bcp14>SHOULD</bcp14> resend another BEGIN
a certain timeout, the client SHOULD resend another BEGIN packet, resetting the session</li>
packet, resetting the session</t> <li>If a READY packet is lost, after a certain timeout, the
client <bcp14>SHOULD</bcp14> resend another READY packet.</li>
<t>If a READY packet is lost, after a certain timeout, the <li>If a Q4S-ALERT request or its corresponding answer is lost,
client SHOULD resend another READY packet.</t> after a certain timeout, the originator <bcp14>SHOULD</bcp14> resend anoth
er
<t>If a QOS ALERT request is lost or its corresponding answer, Q4S-ALERT packet.</li>
after a certain timeout, the originator SHOULD resend another <li>If a CANCEL request or its corresponding answer is lost,
Q4S-ALERT packet.</t> after a certain timeout, the originator <bcp14>SHOULD</bcp14> resend anoth
er
<t>If a CANCEL request is lost or its corresponding answer, CANCEL packet.</li>
after a certain timeout, the originator SHOULD resend another </ul>
CANCEL packet.</t> </section>
<section anchor="sec-9.6.2" numbered="true" toc="default">
</list> <name>Outlier Samples</name>
</t> <t>
</section>
<section title="Outlier Samples" anchor="section-9.6.2"><t>
Outlier samples are those jitter or latency values far from the Outlier samples are those jitter or latency values far from the
general/average values of most samples.</t> general/average values of most samples.</t>
<t>
<t> Hence, the Q4S default measurement method uses the statistical median
Hence Q4S default measurement method uses the statistical median formula for latency calculation, and the outlier samples are
formula for latency calculation, the outlier samples are neutralized. This is a very common filter for noise or errors
neutralized. This is a very common filtering for noise or errors
on signal and image processing.</t> on signal and image processing.</t>
</section>
</section> </section>
<section anchor="sec-9.7" numbered="true" toc="default">
</section> <name>Scenarios</name>
<t>
<section title="Scenarios" anchor="section-9.7"><t>
Q4S could be used in two scenarios:</t> Q4S could be used in two scenarios:</t>
<ul spacing="normal">
<t><list style="symbols"><t>client to ACP (Application content provider)< <li>client to ACP </li>
/t> <li>client to client (peer-to-peer scenario)</li>
</ul>
<t>client to client (peer to peer scenario)</t> <section anchor="sec-9.7.1" numbered="true" toc="default">
<name>Client to ACP</name>
</list> <t>
</t>
<section title="Client to ACP" anchor="section-9.7.1"><t>
One server:</t> One server:</t>
<t>
<t> It is the common scenario in which the client contacts the server to
It is the common scenario in which client contact server to
establish a Q4S session.</t> establish a Q4S session.</t>
<t>
<t>
N servers:</t> N servers:</t>
<t>
<t>
In Content Delivery Networks and in general applications where In Content Delivery Networks and in general applications where
delivery of contents can be achieved by different delivery nodes, delivery of contents can be achieved by different delivery nodes,
two working mechanisms can be defined</t> two working mechanisms can be defined:</t>
<dl>
<t><list style="symbols"><t>Starting mode: End-user may run Q4S against s <dt>Starting mode:</dt><dd>the end user may run Q4S against several
everal delivery delivery
nodes and after some seconds choose the best one to start the nodes and after some seconds choose the best one to start the
multimedia session</t> multimedia session.</dd>
<dt>Prevention mode:</dt><dd>during a streaming session, the user ke
<t>Prevention mode: During streaming session, user keeps several eps several
Q4S dialogs against different alternative delivery nodes. In Q4S dialogs against different alternative delivery nodes. In
case of congestion, end-user MAY change to the best case of congestion, the end user <bcp14>MAY</bcp14> change to the best
alternative delivery node</t> alternative delivery node.</dd>
</dl>
</list> </section>
</t> <section anchor="sec-9.7.2" numbered="true" toc="default">
<name>Client to Client</name>
</section> <t>
In order to solve the client-to-client scenario, a Q4S register
<section title="Client to Client" anchor="section-9.7.2"><t> function <bcp14>MUST</bcp14> be implemented. This allows clients to contact e
In order to solve the client to client scenario, a Q4S register ach
function MUST be implemented. This allows clients contact each
other for sending the BEGIN message. In this scenario, the other for sending the BEGIN message. In this scenario, the
Register server would be used by peers to publish their Q4S-Resource-Server h Register server would be used by peers to publish their Q4S-Resource-Server h
eader and their public IP address to make eader and their public IP address to
possible the assumption of server role.</t> enable the assumption of the server role.</t>
<t>
<t> The register function is out of scope of this protocol version
The register function is out of scope of this protocol version, because different HTTP mechanisms can be used, and Q4S <bcp14>MUST NOT</bcp14
because different HTTP mechanisms can be used and Q4S MUST NOT >
force any.</t> force any.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sec-10" numbered="true" toc="default">
<name>Security Considerations</name>
</section> <section anchor="sec-10.1" numbered="true" toc="default">
<name>Confidentiality Issues</name>
<section title="Security Considerations" anchor="section-10"><section tit <t>
le="Confidentiality Issues" anchor="section-10.1"><t> Because Q4S does not transport any application data, Q4S does not
Hence Q4S does not transport any application data, Q4S does not
jeopardize the security of application data. However, other jeopardize the security of application data. However, other
certain considerations may take place, like identity impersonation certain considerations may take place, like identity impersonation
and measurements privacy and integrity.</t> and measurements privacy and integrity.</t>
</section>
</section> <section anchor="sec-10.2" numbered="true" toc="default">
<name>Integrity of Measurements and Authentication</name>
<section title="Integrity of Measurements and Authentication" anchor="sec <t>
tion-10.2"><t>
Identity impersonation could potentially produce anomalous Q4S Identity impersonation could potentially produce anomalous Q4S
measurements. If this attack is based on spoofing of server IP measurements. If this attack is based on spoofing of the server IP
address, it can be avoided using the digital signature mechanism, address, it can be avoided using the digital signature mechanism
included in the SDP. The network can easily validate this digital included in the SDP. The network can easily validate this digital
signature using the public key of the server certificate.</t> signature using the public key of the server certificate.</t>
<t>
<t>
Integrity of Q4S measurements under any malicious manipulation Integrity of Q4S measurements under any malicious manipulation
(such as Man-in-the-Middle (MITM) attack) relay on the same (such as a Man-in-the-Middle (MITM) attack) relies on the same
mechanism, the SDP signature.</t> mechanism, the SDP signature.</t>
<t>
<t> The Signature header field contains the signed hash value of the SDP
The Signature header contains the signed hash value of the SDP
body in order to protect all the SDP data, including the body in order to protect all the SDP data, including the
measurements. This signature not only protects the integrity of measurements. This signature not only protects the integrity of
data but also authenticates the server.</t> data but also authenticates the server.</t>
</section>
</section> <section anchor="sec-10.3" numbered="true" toc="default">
<name>Privacy of Measurements</name>
<section title="Privacy of Measurements" anchor="section-10.3"><t> <t>
This protocol could be supported over IPSec. Q4S relays on UDP and This protocol could be supported over IPsec. Q4S relies on UDP and
TCP, and IPSec supports both. If Q4S is used for application-based TCP, and IPsec supports both. If Q4S is used for application-based
QoS, then IPsec is operationally valid but if Q4S is used to QoS, then IPsec is operationally valid; however, if Q4S is used to
trigger network-based actions, then measurements could be wrong, trigger network-based actions, then measurements could be incorrect
unless IPSec ports be considered at any potential action over the unless the IPsec ports can be a target of potential action over the
network (such as prioritization of certain application flows).</t> network (such as prioritizing IPsec flows to measure the new, upgraded
state of certain application flows). </t>
</section> </section>
<section anchor="sec-10.4" numbered="true" toc="default">
<section title="Availability Issues" anchor="section-10.4"><t> <name>Availability Issues</name>
Any loss of connectivity may interrupt the availability of Q4S <t>
service, and results in higher packet-loss measurements, which is 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.</t> just the desired behavior in these situations.</t>
<t>
<t>
In order to mitigate availability issues caused by malicious In order to mitigate availability issues caused by malicious
attacks (such as DoS and DDoS), a good practice is to enable Q4S attacks (such as DoS and DDoS), a good practice is to enable the Q4S
service only for authenticated users. Q4S can be launched after service only for authenticated users. Q4S can be launched after the
user is authenticated by the application. At this moment, his IP 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 is known, and the Q4S service may be enabled for this IP
address. Otherwise Q4S service should appear unreachable.</t> address. Otherwise, the Q4S service should appear unreachable.</t>
</section>
</section> <section anchor="sec-10.5" numbered="true" toc="default">
<name>Bandwidth Occupancy Issues</name>
<section title="Bandwidth Occupancy Issues" anchor="section-10.5"><t> <t>
Q4S bandwidth measurement is limited to the application needs. It Q4S bandwidth measurement is limited to the application needs. It
means that all available bandwidth is not measured, but only the means that all available bandwidth is not measured, but only the
fraction required by the application. This allows other fraction required by the application. This allows other
applications to use normally the rest of available bandwidth.</t> applications to use the rest of available bandwidth normally.</t>
<t>
<t> However, a malicious Q4S client could restart Q4S sessions just
However, a malicious Q4S client could re-starts Q4S sessions just after finishing the Negotiation phase. The consequence would be to
after finishing the negotiation phase. The consequence would be to
waste bandwidth for nothing.</t> waste bandwidth for nothing.</t>
<t>
<t>
In order to mitigate this possible anomalous behavior, it is In order to mitigate this possible anomalous behavior, it is
RECOMMENDED to configure the server to reject sessions from the <bcp14>RECOMMENDED</bcp14> to configure the server to reject sessions from th
same end-point when this situation is detected.</t> e
same endpoint when this situation is detected.</t>
</section> </section>
</section>
</section> <section anchor="sec-11" numbered="true" toc="default">
<name>Future Code Point Requirements</name>
<section title="Future Code Point Requirements" anchor="section-11"><t> <t>
If the ideas described in this document are pursued to become a If the ideas described in this document are pursued to become a
protocol specification, then the code points described in this protocol specification, then the code points described in this
document will need to be assigned by IANA.</t> document will need to be assigned by IANA.</t>
<section anchor="sec-11.1" numbered="true" toc="default">
<section title="Service Port" anchor="section-11.1"><t> <name>Service Port</name>
The need for an assigned PORT is to make possible a future Q4S <t>
aware network, capable of react by itself to Q4S alerts. A 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 specific port would simplify the identification of the protocol by
network elements in charge of take possible reactive decisions. network elements in charge of making possible reactive decisions.
Therefore, the need for a port by IANA may be postponed to the Therefore, the need for a port assignment by IANA may be postponed until ther
need for a future Q4S aware network.</t> e is the
need for a future Q4S-aware network.</t>
<t> <t>
Service Name: Q4S</t> Service Name: Q4S</t>
<t>
<t>
Transport Protocol(s): TCP</t> Transport Protocol(s): TCP</t>
<dl newline="true" spacing="normal" indent="3">
<t><list style="hanging" hangIndent="3"><t hangText="Assignee :"> <dt>Assignee:</dt>
<vspace blankLines="1"/> <dd>
Name : Jose Javier Garcia Aranda <t>
<vspace blankLines="1"/> Name: Jose Javier Garcia Aranda
</t>
<t>
Email: jose_javier.garcia_aranda@nokia.com Email: jose_javier.garcia_aranda@nokia.com
</t> </t>
</dd>
<t hangText="Contact :"> <dt>Contact:</dt>
<vspace blankLines="1"/> <dd>
Name : Jose Javier Garcia Aranda <t>
<vspace blankLines="1"/> Name: Jose Javier Garcia Aranda
</t>
<t>
Email: jose_javier.garcia_aranda@nokia.com Email: jose_javier.garcia_aranda@nokia.com
</t> </t>
</dd>
</list> </dl>
</t> <dl newline="false" spacing="normal" indent="6">
<dt>Description:</dt>
<t><list style="hanging" hangIndent="6"> <dd>
<t hangText="Description:">
The service associated with this request is in The service associated with this request is in
charge of the establishment of new Q4S sessions, and during the charge of the establishment of new Q4S sessions, and during the
session manages the pass to a new protocol stage (handshake, session, manages the handoff to a new protocol phase (Handshake,
negotiation and continuity) as well as inform of alerts when Negotiation and Continuity) as well as sends alerts when
measurements do not meet the requirements.</t> measurements do not meet the requirements.</dd>
<dt>Reference:</dt>
<t hangText="Reference:"> <dd>
this document. This service does not use IP-layer This document. This service does not use IP-layer
broadcast, multicast, or anycast communication.</t> broadcast, multicast, or anycast communication.</dd>
</dl>
</list> </section>
</t> </section>
</section> <section anchor="sec-12" numbered="true" toc="default">
<name>IANA Considerations</name>
</section> <t>This document has no IANA actions.</t>
</section>
</middle> </middle>
<back>
<back>
<references title="Normative References">
<reference anchor="ref-1" target="https://www.rfc-editor.org/info/rfc7230
"><front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
</title>
<author fullname="R. Fielding" initials="R." surname="Fielding" role="edi
tor">
</author>
<author fullname="J. Reschke" initials="J." surname="Reschke" role="edito
r">
</author>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7230"/>
<seriesInfo name="DOI" value="10.17487/RFC7230"/>
</reference>
<reference anchor="ref-2" target="https://www.rfc-editor.org/info/rfc7231
"><front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</tit
le>
<author fullname="R. Fielding" initials="R." surname="Fielding" role="edi
tor">
</author>
<author fullname="J. Reschke" initials="J." surname="Reschke" role="edito
r">
</author>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7231"/>
<seriesInfo name="DOI" value="10.17487/RFC7231"/>
</reference>
<reference anchor="ref-3" target="https://www.rfc-editor.org/info/rfc7232
"><front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</titl
e>
<author fullname="R. Fielding" initials="R." surname="Fielding" role="edi
tor">
</author>
<author fullname="J. Reschke" initials="J." surname="Reschke" role="edito
r">
</author>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7232"/>
<seriesInfo name="DOI" value="10.17487/RFC7232"/>
</reference>
<reference anchor="ref-4" target="https://www.rfc-editor.org/info/rfc7233
"><front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
<author fullname="R. Fielding" initials="R." surname="Fielding" role="edi
tor">
</author>
<author fullname="Y. Lafon" initials="Y." surname="Lafon" role="editor">
</author>
<author fullname="J. Reschke" initials="J." surname="Reschke" role="edito
r">
</author>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7233"/>
<seriesInfo name="DOI" value="10.17487/RFC7233"/>
</reference>
<reference anchor="ref-5" target="https://www.rfc-editor.org/info/rfc7234
"><front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
<author fullname="R. Fielding" initials="R." surname="Fielding" role="edi
tor">
</author>
<author fullname="M. Nottingham" initials="M." surname="Nottingham" role=
"editor">
</author>
<author fullname="J. Reschke" initials="J." surname="Reschke" role="edito
r">
</author>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7234"/>
<seriesInfo name="DOI" value="10.17487/RFC7234"/>
</reference>
<reference anchor="ref-6" target="https://www.rfc-editor.org/info/rfc7235
"><front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
<author fullname="R. Fielding" initials="R." surname="Fielding" role="edi
tor">
</author>
<author fullname="J. Reschke" initials="J." surname="Reschke" role="edito
r">
</author>
<date month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7235"/>
<seriesInfo name="DOI" value="10.17487/RFC7235"/>
</reference>
<reference anchor="ref-8" target="https://www.rfc-editor.org/info/rfc3550
"><front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
</author>
<author fullname="S. Casner" initials="S." surname="Casner">
</author>
<author fullname="R. Frederick" initials="R." surname="Frederick">
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
</author>
<date month="July" year="2003"/>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<!-- Version-Independent Properties of QUIC; companion document RFC YYYY -->
<reference anchor="ref-9">
<front>
<title>Version-Independent Properties of QUIC</title>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<date month='July' day='10' year='2019' />
<abstract><t>This document defines the properties of the QUIC transport protocol
that are expected to remain unchanged over time as new versions of the protocol
are developed. Note to Readers Discussion of this draft takes place on the QU
IC working group mailing list (quic@ietf.org), which is archived at https://mail
archive.ietf.org/arch/search/?email_list=quic [1]. Working Group information ca
n be found at https://github.com/quicwg [2]; source code and issues list for thi
s draft can be found at https://github.com/quicwg/base-drafts/labels/-invariants
[3].</t></abstract>
</front>
<seriesInfo name="RFC" value="YYYY"/>
<seriesInfo name="DOI" value="10.17487/RFCYYYY"/>
</reference>
<reference anchor="ref-10" target="https://www.rfc-editor.org/info/rfc456
6"><front>
<title>SDP: Session Description Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley">
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
</author>
<date month="July" year="2006"/>
</front>
<seriesInfo name="RFC" value="4566"/>
<seriesInfo name="DOI" value="10.17487/RFC4566"/>
</reference>
<reference anchor="ref-11" target="https://www.rfc-editor.org/info/rfc211
9"><front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner">
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="ref-12" target="https://www.rfc-editor.org/info/rfc398
6"><front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
</author>
<author fullname="R. Fielding" initials="R." surname="Fielding">
</author>
<author fullname="L. Masinter" initials="L." surname="Masinter">
</author>
<date month="January" year="2005"/>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="ref-13" target="https://www.rfc-editor.org/info/rfc326
4"><front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</tit
le>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
</author>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
</author>
<date month="June" year="2002"/>
</front>
<seriesInfo name="RFC" value="3264"/>
<seriesInfo name="DOI" value="10.17487/RFC3264"/>
</reference>
<reference anchor="ref-14" target="https://www.rfc-editor.org/info/rfc463
4"><front>
<title>US Secure Hash Algorithms (SHA and HMAC-SHA)</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen">
</author>
<date month="July" year="2006"/>
</front>
<seriesInfo name="RFC" value="4634"/>
<seriesInfo name="DOI" value="10.17487/RFC4634"/>
</reference>
<reference anchor="ref-15" target="https://www.rfc-editor.org/info/rfc801
7"><front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<author fullname="K. Moriarty" initials="K." surname="Moriarty" role="edi
tor">
</author>
<author fullname="B. Kaliski" initials="B." surname="Kaliski">
</author>
<author fullname="J. Jonsson" initials="J." surname="Jonsson">
</author>
<author fullname="A. Rusch" initials="A." surname="Rusch">
</author>
<date month="November" year="2016"/>
</front>
<seriesInfo name="RFC" value="8017"/>
<seriesInfo name="DOI" value="10.17487/RFC8017"/>
</reference>
<reference anchor="ref-16" target="https://www.rfc-editor.org/info/rfc793
"><front>
<title>Transmission Control Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
</author>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="793"/>
<seriesInfo name="DOI" value="10.17487/RFC0793"/>
</reference>
<reference anchor="ref-17" target="https://www.rfc-editor.org/info/rfc768
"><front>
<title>User Datagram Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
</author>
<date month="August" year="1980"/>
</front>
<seriesInfo name="STD" value="6"/>
<seriesInfo name="RFC" value="768"/>
<seriesInfo name="DOI" value="10.17487/RFC0768"/>
</reference>
<reference anchor="ref-18" target="https://www.rfc-editor.org/info/rfc355
0"><front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
</author>
<author fullname="S. Casner" initials="S." surname="Casner">
</author>
<author fullname="R. Frederick" initials="R." surname="Frederick">
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
</author>
<date month="July" year="2003"/>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<reference anchor="ref-19" target="https://www.rfc-editor.org/info/rfc362
9"><front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author fullname="F. Yergeau" initials="F." surname="Yergeau">
</author>
<date month="November" year="2003"/>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
<seriesInfo name="DOI" value="10.17487/RFC3629"/>
</reference>
<reference anchor="ref-20" target="https://www.rfc-editor.org/info/rfc532
2"><front>
<title>Internet Message Format</title>
<author fullname="P. Resnick" initials="P." surname="Resnick" role="edito
r">
</author>
<date month="October" year="2008"/>
</front>
<seriesInfo name="RFC" value="5322"/>
<seriesInfo name="DOI" value="10.17487/RFC5322"/>
</reference>
<reference anchor="ref-21" target="https://www.rfc-editor.org/info/rfc817
4"><front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba">
</author>
<date month="May" year="2017"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="ref-22" target="https://www.rfc-editor.org/info/rfc326
1"><front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
</author>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
</author>
<author fullname="R. Sparks" initials="R." surname="Sparks">
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
</author>
<date month="June" year="2002"/>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>
<!-- [rfced] [ref-23] URL: https://cseweb.ucsd.edu/classes/wi01/cse222/papers/ma
this-tcpmodel-ccr97.pdf -->
<reference anchor="ref-23"><front>
<title>The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm
</title>
<author fullname="M. Mathis" initials="M." surname="Mathis">
</author>
<author fullname="J. Semke" initials="J." surname="Semke">
</author>
<author fullname="J. Mahdavi" initials="J." surname="Mahdavi">
</author>
<author fullname="T. Ott" initials="T." surname="Ott">
</author>
<date month="July" year="1997"/>
</front>
<seriesInfo name="Computer Communications Review," value="27(3)"/>
</reference>
<reference anchor="ref-24" target="https://www.rfc-editor.org/info/rfc364
9"><front>
<title>HighSpeed TCP for Large Congestion Windows</title>
<author fullname="S. Floyd" initials="S." surname="Floyd">
</author>
<date month="December" year="2003"/>
</front>
<seriesInfo name="RFC" value="3649"/>
<seriesInfo name="DOI" value="10.17487/RFC3649"/>
</reference>
<!-- draft-rhee-tcpm-cubic-02; Expired -->
<reference anchor='ref-25'>
<front>
<title>CUBIC for Fast Long-Distance Networks</title>
<author initials='I' surname='Rhee' fullname='Injong Rhee'>
<organization />
</author>
<author initials='L' surname='Xu' fullname='Lisong Xu'>
<organization />
</author>
<author initials='S' surname='Ha' fullname='Sangtae Ha'>
<organization />
</author>
<date month='August' day='26' year='2008' />
<abstract><t>CUBIC is an extension to the current TCP standards. The protocol d
iffers from the current TCP standards only in the congestion window adjustment f
unction in the sender side. In particular, it uses a cubic function instead of
a linear window increase of the current TCP standards to improve scalability and
stability under fast and long distance networks. BIC-TCP, a predecessor of CUB
IC, has been a default TCP adopted by Linux since year 2005 and has already been
deployed globally and in use for several years by the Internet community at lar
ge. CUBIC is using a similar window growth function as BIC-TCP and is designed
to be less aggressive and fairer to TCP in bandwidth usage than BIC-TCP while ma
intaining the strengths of BIC-TCP such as stability, window scalability and RTT
fairness. Through extensive testing in various Internet scenarios, we believe
that CUBIC is safe for deployment and testing in the global Internet. The inten
t of this document is to provide the protocol specification of CUBIC for a third
party implementation and solicit the community feedback through experimentation
on the performance of CUBIC. We expect this document to be eventually publishe
d as an experimental RFC.</t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-rhee-tcpm-cubic-02' />
</reference>
<!-- draft-sridharan-tcpm-ctcp-02; Expired -->
<reference anchor='ref-26'>
<front>
<title>Compound TCP: A New TCP Congestion Control for High-Speed and Long Distan
ce Networks</title>
<author initials='M' surname='Sridharan' fullname='Murali Sridharan'>
<organization />
</author>
<author initials='K' surname='Tan' fullname='Kun Tan'>
<organization />
</author>
<author initials='D' surname='Bansal' fullname='Deepak Bansal'>
<organization />
</author>
<author initials='D' surname='Thaler' fullname='Dave Thaler'>
<organization />
</author>
<date month='November' day='11' year='2008' />
<abstract><t>Compound TCP (CTCP) is a modification to TCP's congestion control m
echanism for use with TCP connections with large congestion windows. This docume
nt describes the Compound TCP algorithm in detail, and solicits experimentation
and feedback from the wider community. The key idea behind CTCP is to add a sca
lable delay-based component to the standard TCP's loss-based congestion control.
The sending rate of CTCP is controlled by both loss and delay components. The d
elay-based component has a scalable window increasing rule that not only efficie
ntly uses the link capacity, but on sensing queue build up, proactively reduces
the sending rate.</t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-sridharan-tcpm-ctcp-02' />
</reference>
<reference anchor="ref-27" target="https://www.rfc-editor.org/info/rfc465 <displayreference target="I-D.ietf-quic-transport" to="QUIC"/>
6"><front> <displayreference target="I-D.rhee-tcpm-cubic" to="CUBIC"/>
<title>A One-way Active Measurement Protocol (OWAMP)</title> <displayreference target="I-D.sridharan-tcpm-ctcp" to="CTCP"/>
<author fullname="S. Shalunov" initials="S." surname="Shalunov"> <references>
</author> <name>References</name>
<author fullname="B. Teitelbaum" initials="B." surname="Teitelbaum"> <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7230.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7231.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7232.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7233.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7235.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2818.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3629.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5322.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8017.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3264.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4566.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3550.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.0793.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.0792.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.
ietf-quic-transport.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4656.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5357.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3261.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.0768.xml"/>
<reference anchor="RENO">
<front>
<title>The Macroscopic Behavior of the TCP Congestion Avoidance Algo
rithm</title>
<seriesInfo name="DOI" value="10.1145/263932.264023"/>
<author fullname="M. Mathis" initials="M." surname="Mathis">
</author> </author>
<author fullname="A. Karp" initials="A." surname="Karp"> <author fullname="J. Semke" initials="J." surname="Semke">
</author> </author>
<author fullname="J. Boote" initials="J." surname="Boote"> <author fullname="J. Mahdavi" initials="J." surname="Mahdavi">
</author> </author>
<author fullname="M. Zekauskas" initials="M." surname="Zekauskas"> <author fullname="T. Ott" initials="T." surname="Ott">
</author> </author>
<date month="September" year="2006"/> <date month="July" year="1997"/>
</front> </front>
<seriesInfo name="RFC" value="4656"/> <refcontent>ACM SIGCOMM Computer Communication Review, pp. 67-82</re
<seriesInfo name="DOI" value="10.17487/RFC4656"/> fcontent>
</reference> </reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3649.xml"/>
<reference anchor="ref-28" target="https://www.rfc-editor.org/info/rfc535 <!-- draft-rhee-tcpm-cubic-02; Expired since 2009 -->
7"><front> <xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.
<title>A Two-Way Active Measurement Protocol (TWAMP)</title> rhee-tcpm-cubic.xml"/>
<author fullname="K. Hedayat" initials="K." surname="Hedayat">
</author>
<author fullname="R. Krzanowski" initials="R." surname="Krzanowski">
</author>
<author fullname="A. Morton" initials="A." surname="Morton">
</author>
<author fullname="K. Yum" initials="K." surname="Yum">
</author>
<author fullname="J. Babiarz" initials="J." surname="Babiarz">
</author>
<date month="October" year="2008"/>
</front>
<seriesInfo name="RFC" value="5357"/>
<seriesInfo name="DOI" value="10.17487/RFC5357"/>
</reference>
</references>
<section title="Acknowledgments" anchor="section-13"><t> <!-- draft-sridharan-tcpm-ctcp-02; Expired since 2009 -->
<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.
sridharan-tcpm-ctcp.xml"/>
</references>
</references>
<section anchor="sec-13" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
Many people have made comments and suggestions contributing to Many people have made comments and suggestions contributing to
this document. In particular, we would like to thank:</t> this document. In particular, we would like to thank:</t>
<t>
<t> <contact fullname="Victor Villagra"/>, <contact fullname="Sonia Herranz"/>,
Victor Villagra, Sonia Herranz, Clara Cubillo Pastor, Francisco <contact fullname="Clara Cubillo Pastor"/>, <contact fullname="Francisco Dura
Duran Pina, Michael Scharf, Jesus Soto Viso and Federico Guillen.</t> n Pina"/>,
<contact fullname="Michael Scharf"/>, <contact fullname="Jesus Soto Viso"/>,
<t> and
<contact fullname="Federico Guillen"/>.</t>
<t>
Additionally, we want to thank the Spanish Centre for the Additionally, we want to thank the Spanish Centre for the
Development of Industrial Technology (CDTI) as well as the Spanish Development of Industrial Technology (CDTI) as well as the Spanish
Science and Tech Ministry which funds this initiative through Science and Tech Ministry, which funds this initiative through
their innovation programs.</t> their innovation programs.</t>
</section>
<section anchor="sec-14" numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Jacobo Perez Lajo">
<organization>Nokia Spain</organization>
<address>
<email>jacobo.perez@nokia.com</email>
</address>
</contact>
</section> <contact fullname="Luis Miguel Diaz Vizcaino">
<organization>Nokia Spain</organization>
<section title="Contributors" anchor="section-14"><figure><artwork><![CDA <address>
TA[ <email>Luismi.Diaz@nokia.com</email>
Jacobo Perez Lajo </address>
Nokia Spain </contact>
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 <contact fullname="Gonzalo Munoz Fernandez">
Nokia Spain <organization>Nokia Spain</organization>
Email: manuel.alarcon_granero.ext@nokia.com <address>
<email>gonzalo.munoz_fernandez.ext@nokia.com</email>
</address>
</contact>
Francisco Jose juan Quintanilla <contact fullname="Manuel Alarcon Granero">
Nokia Spain <organization>Nokia Spain</organization>
Email: francisco_jose.juan_quintanilla.ext@nokia.com <address>
<email>manuel.alarcon_granero.ext@nokia.com</email>
</address>
</contact>
Carlos Barcenilla <contact fullname="Francisco Jose Juan Quintanilla">
Universidad Politecnica de Madrid <organization>Nokia Spain</organization>
<address>
<email>francisco_jose.juan_quintanilla.ext@nokia.com</email>
</address>
</contact>
Juan Quemada <contact fullname="Carlos Barcenilla">
Universidad Politecnica de Madrid <organization>Universidad Politecnica de Madrid</organization>
Email: jquemada@dit.upm.es </contact>
Ignacio Maestro <contact fullname="Juan Quemada">
Tecnalia Research & Innovation <organization>Universidad Politecnica de Madrid</organization>
Email: ignacio.maestro@tecnalia.com <address>
<email>jquemada@dit.upm.es</email>
</address>
</contact>
Lara Fajardo Ibanez <contact fullname="Ignacio Maestro">
Optiva Media <organization>Tecnalia Research &amp; Innovation</organization>
Email: lara.fajardo@optivamedia.com <address>
<email>ignacio.maestro@tecnalia.com</email>
</address>
</contact>
Pablo Lopez Zapico <contact fullname="Lara Fajardo Ibañez">
Optiva Media <organization>Optiva Media</organization>
Email: Pablo.lopez@optivamedia.com <address>
<email>lara.fajardo@optivamedia.com</email>
</address>
</contact>
David Muelas Recuenco <contact fullname="Pablo López Zapico">
Universidad Autonoma de Madrid <organization>Optiva Media</organization>
Email: dav.muelas@uam.es <address>
Jesus Molina Merchan <email>Pablo.lopez@optivamedia.com</email>
Universidad Autonoma de Madrid </address>
jesus.molina@uam.es </contact>
Jorge E. Lopez de Vergara Mendez <contact fullname="David Muelas Recuenco">
Universidad Autonoma de Madrid <organization>Universidad Autonoma de Madrid</organization>
Email: jorge.lopez_vergara@uam.es <address>
<email>dav.muelas@uam.es</email>
</address>
</contact>
Victor Manuel Maroto Ortega <contact fullname="Jesus Molina Merchan">
Optiva Media <organization>Universidad Autonoma de Madrid</organization>
Email: victor.maroto@optivamedia.com <address>
]]></artwork> <email>jesus.molina@uam.es</email>
</figure> </address>
</section> </contact>
</back> <contact fullname="Jorge E. Lopez de Vergara Mendez">
<organization>Universidad Autonoma de Madrid</organization>
<address>
<email>jorge.lopez_vergara@uam.es</email>
</address>
</contact>
</rfc> <contact fullname="Victor Manuel Maroto Ortega">
<organization>Optiva Media</organization>
<address>
<email>victor.maroto@optivamedia.com</email>
</address>
</contact>
</section>
</back>
</rfc>
 End of changes. 595 change blocks. 
3094 lines changed or deleted 2453 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/