File: rfc8802.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (6290 lines) | stat: -rw-r--r-- 331,755 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8802: The Quality for Service (Q4S) Protocol</title>
<meta content="Jose Javier Garcia Aranda" name="author">
<meta content="Mónica Cortés" name="author">
<meta content="Joaquín Salvachúa" name="author">
<meta content="Maribel Narganes" name="author">
<meta content="Iñaki Martínez-Sarriegui" name="author">
<meta content="
       
   This memo describes an application-level protocol for the
   communication of end-to-end QoS compliance information based on
   the HyperText Transfer Protocol (HTTP) and the Session
   Description Protocol (SDP).  The Quality for Service 
   (Q4S) protocol provides a mechanism to negotiate and monitor latency,
   jitter, bandwidth, and packet loss, and to alert whenever one of the
   negotiated conditions is violated. 
       
   Implementation details on the actions to be triggered upon
   reception/detection of QoS alerts exchanged by the protocol are
   out of scope of this document; it is either application dependent (e.g.,
   act to increase quality or reduce bit-rate) or network dependent
   (e.g., change connection's quality profile). 
       
   This protocol specification is the product of research conducted
   over a number of years; it is presented here as a permanent
   record and to offer a foundation for future similar work.  It does
   not represent a standard protocol and does not have IETF
   consensus. 
    " name="description">
<meta content="xml2rfc 2.47.0" name="generator">
<meta content="quality measurement" name="keyword">
<meta content="measurement protocol" name="keyword">
<meta content="latency" name="keyword">
<meta content="jitter" name="keyword">
<meta content="bandwidth" name="keyword">
<meta content="packet-loss" name="keyword">
<meta content="8802" name="rfc.number">
<link href="rfc8802.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8802" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-aranda-dispatch-q4s-10" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8802</td>
<td class="center">The Quality for Service (Q4S) Protocol</td>
<td class="right">July 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Aranda, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8802" class="eref">8802</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-07" class="published">July 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">J.J. Aranda</div>
<div class="org">Nokia</div>
</div>
<div class="author">
      <div class="author-name">M. Cortés</div>
<div class="org">Nokia</div>
</div>
<div class="author">
      <div class="author-name">J. Salvachúa</div>
<div class="org">Univ. Politecnica de Madrid</div>
</div>
<div class="author">
      <div class="author-name">M. Narganes</div>
<div class="org">Tecnalia</div>
</div>
<div class="author">
      <div class="author-name">I. Martínez-Sarriegui</div>
<div class="org">Optiva Media</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8802</h1>
<h1 id="title">The Quality for Service (Q4S) Protocol</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   This memo describes an application-level protocol for the
   communication of end-to-end QoS compliance information based on
   the HyperText Transfer Protocol (HTTP) and the Session
   Description Protocol (SDP).  The Quality for Service 
   (Q4S) protocol provides a mechanism to negotiate and monitor latency,
   jitter, bandwidth, and packet loss, and to alert whenever one of the
   negotiated conditions is violated.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">
   Implementation details on the actions to be triggered upon
   reception/detection of QoS alerts exchanged by the protocol are
   out of scope of this document; it is either application dependent (e.g.,
   act to increase quality or reduce bit-rate) or network dependent
   (e.g., change connection's quality profile).<a href="#section-abstract-2" class="pilcrow">¶</a></p>
<p id="section-abstract-3">
   This protocol specification is the product of research conducted
   over a number of years; it is presented here as a permanent
   record and to offer a foundation for future similar work.  It does
   not represent a standard protocol and does not have IETF
   consensus.<a href="#section-abstract-3" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8802">https://www.rfc-editor.org/info/rfc8802</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-scope" class="xref">Scope</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-motivation" class="xref">Motivation</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.1.2.3">
                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-summary-of-features" class="xref">Summary of Features</a><a href="#section-toc.1-1.1.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.1.2.4">
                <p id="section-toc.1-1.1.2.4.1"><a href="#section-1.4" class="xref">1.4</a>.  <a href="#name-differences-from-owamp-twam" class="xref">Differences from OWAMP/TWAMP</a><a href="#section-toc.1-1.1.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-overview-of-operation" class="xref">Overview of Operation</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-q4s-messages" class="xref">Q4S Messages</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-requests" class="xref">Requests</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-responses" class="xref">Responses</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-header-fields" class="xref">Header Fields</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3.2.1">
                    <p id="section-toc.1-1.4.2.3.2.1.1"><a href="#section-4.3.1" class="xref">4.3.1</a>.  <a href="#name-common-q4s-header-fields" class="xref">Common Q4S Header Fields</a><a href="#section-toc.1-1.4.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3.2.2">
                    <p id="section-toc.1-1.4.2.3.2.2.1"><a href="#section-4.3.2" class="xref">4.3.2</a>.  <a href="#name-specific-q4s-request-header" class="xref">Specific Q4S Request Header Fields</a><a href="#section-toc.1-1.4.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3.2.3">
                    <p id="section-toc.1-1.4.2.3.2.3.1"><a href="#section-4.3.3" class="xref">4.3.3</a>.  <a href="#name-specific-q4s-response-heade" class="xref">Specific Q4S Response Header Fields</a><a href="#section-toc.1-1.4.2.3.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-bodies" class="xref">Bodies</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.4.2.1">
                    <p id="section-toc.1-1.4.2.4.2.1.1"><a href="#section-4.4.1" class="xref">4.4.1</a>.  <a href="#name-encoding" class="xref">Encoding</a><a href="#section-toc.1-1.4.2.4.2.1.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-q4s-method-definitions" class="xref">Q4S Method Definitions</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-begin" class="xref">BEGIN</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-ready" class="xref">READY</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-ping" class="xref">PING</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-bwidth" class="xref">BWIDTH</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-q4s-alert" class="xref">Q4S-ALERT</a><a href="#section-toc.1-1.5.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-q4s-recovery" class="xref">Q4S-RECOVERY</a><a href="#section-toc.1-1.5.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-cancel" class="xref">CANCEL</a><a href="#section-toc.1-1.5.2.7.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-response-codes" class="xref">Response Codes</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-100-trying" class="xref">100 Trying</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-success-2xx" class="xref">Success 2xx</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2.2.1">
                    <p id="section-toc.1-1.6.2.2.2.1.1"><a href="#section-6.2.1" class="xref">6.2.1</a>.  <a href="#name-200-ok" class="xref">200 OK</a><a href="#section-toc.1-1.6.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-redirection-3xx" class="xref">Redirection 3xx</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-request-failure-4xx" class="xref">Request Failure 4xx</a><a href="#section-toc.1-1.6.2.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4.2.1">
                    <p id="section-toc.1-1.6.2.4.2.1.1"><a href="#section-6.4.1" class="xref">6.4.1</a>.  <a href="#name-400-bad-request" class="xref">400 Bad Request</a><a href="#section-toc.1-1.6.2.4.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4.2.2">
                    <p id="section-toc.1-1.6.2.4.2.2.1"><a href="#section-6.4.2" class="xref">6.4.2</a>.  <a href="#name-404-not-found" class="xref">404 Not Found</a><a href="#section-toc.1-1.6.2.4.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4.2.3">
                    <p id="section-toc.1-1.6.2.4.2.3.1"><a href="#section-6.4.3" class="xref">6.4.3</a>.  <a href="#name-405-method-not-allowed" class="xref">405 Method Not Allowed</a><a href="#section-toc.1-1.6.2.4.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4.2.4">
                    <p id="section-toc.1-1.6.2.4.2.4.1"><a href="#section-6.4.4" class="xref">6.4.4</a>.  <a href="#name-406-not-acceptable" class="xref">406 Not Acceptable</a><a href="#section-toc.1-1.6.2.4.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4.2.5">
                    <p id="section-toc.1-1.6.2.4.2.5.1"><a href="#section-6.4.5" class="xref">6.4.5</a>.  <a href="#name-408-request-timeout" class="xref">408 Request Timeout</a><a href="#section-toc.1-1.6.2.4.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4.2.6">
                    <p id="section-toc.1-1.6.2.4.2.6.1"><a href="#section-6.4.6" class="xref">6.4.6</a>.  <a href="#name-413-request-entity-too-larg" class="xref">413 Request Entity Too Large</a><a href="#section-toc.1-1.6.2.4.2.6.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4.2.7">
                    <p id="section-toc.1-1.6.2.4.2.7.1"><a href="#section-6.4.7" class="xref">6.4.7</a>.  <a href="#name-414-request-uri-too-long" class="xref">414 Request-URI Too Long</a><a href="#section-toc.1-1.6.2.4.2.7.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4.2.8">
                    <p id="section-toc.1-1.6.2.4.2.8.1"><a href="#section-6.4.8" class="xref">6.4.8</a>.  <a href="#name-415-unsupported-media-type" class="xref">415 Unsupported Media Type</a><a href="#section-toc.1-1.6.2.4.2.8.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4.2.9">
                    <p id="section-toc.1-1.6.2.4.2.9.1"><a href="#section-6.4.9" class="xref">6.4.9</a>.  <a href="#name-416-unsupported-uri-scheme" class="xref">416 Unsupported URI Scheme</a><a href="#section-toc.1-1.6.2.4.2.9.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-server-failure-5xx" class="xref">Server Failure 5xx</a><a href="#section-toc.1-1.6.2.5.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.5.2.1">
                    <p id="section-toc.1-1.6.2.5.2.1.1"><a href="#section-6.5.1" class="xref">6.5.1</a>.  <a href="#name-500-server-internal-error" class="xref">500 Server Internal Error</a><a href="#section-toc.1-1.6.2.5.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.5.2.2">
                    <p id="section-toc.1-1.6.2.5.2.2.1"><a href="#section-6.5.2" class="xref">6.5.2</a>.  <a href="#name-501-not-implemented" class="xref">501 Not Implemented</a><a href="#section-toc.1-1.6.2.5.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.5.2.3">
                    <p id="section-toc.1-1.6.2.5.2.3.1"><a href="#section-6.5.3" class="xref">6.5.3</a>.  <a href="#name-503-service-unavailable" class="xref">503 Service Unavailable</a><a href="#section-toc.1-1.6.2.5.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.5.2.4">
                    <p id="section-toc.1-1.6.2.5.2.4.1"><a href="#section-6.5.4" class="xref">6.5.4</a>.  <a href="#name-504-server-time-out" class="xref">504 Server Time-Out</a><a href="#section-toc.1-1.6.2.5.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.5.2.5">
                    <p id="section-toc.1-1.6.2.5.2.5.1"><a href="#section-6.5.5" class="xref">6.5.5</a>.  <a href="#name-505-version-not-supported" class="xref">505 Version Not Supported</a><a href="#section-toc.1-1.6.2.5.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.5.2.6">
                    <p id="section-toc.1-1.6.2.5.2.6.1"><a href="#section-6.5.6" class="xref">6.5.6</a>.  <a href="#name-513-message-too-large" class="xref">513 Message Too Large</a><a href="#section-toc.1-1.6.2.5.2.6.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.6">
                <p id="section-toc.1-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-global-failures-6xx" class="xref">Global Failures 6xx</a><a href="#section-toc.1-1.6.2.6.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.6.2.1">
                    <p id="section-toc.1-1.6.2.6.2.1.1"><a href="#section-6.6.1" class="xref">6.6.1</a>.  <a href="#name-600-session-does-not-exist" class="xref">600 Session Does Not Exist</a><a href="#section-toc.1-1.6.2.6.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.6.2.2">
                    <p id="section-toc.1-1.6.2.6.2.2.1"><a href="#section-6.6.2" class="xref">6.6.2</a>.  <a href="#name-601-quality-level-not-allow" class="xref">601 Quality Level Not Allowed</a><a href="#section-toc.1-1.6.2.6.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.6.2.3">
                    <p id="section-toc.1-1.6.2.6.2.3.1"><a href="#section-6.6.3" class="xref">6.6.3</a>.  <a href="#name-603-session-not-allowed" class="xref">603 Session Not Allowed</a><a href="#section-toc.1-1.6.2.6.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.6.2.4">
                    <p id="section-toc.1-1.6.2.6.2.4.1"><a href="#section-6.6.4" class="xref">6.6.4</a>.  <a href="#name-604-authorization-not-allow" class="xref">604 Authorization Not Allowed</a><a href="#section-toc.1-1.6.2.6.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-protocol" class="xref">Protocol</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-protocol-phases" class="xref">Protocol Phases</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-sdp-structure" class="xref">SDP Structure</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.1">
                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-qos-level-attribute" class="xref">"qos-level" Attribute</a><a href="#section-toc.1-1.7.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.2">
                    <p id="section-toc.1-1.7.2.2.2.2.1"><a href="#section-7.2.2" class="xref">7.2.2</a>.  <a href="#name-alerting-mode-attribute" class="xref">"alerting-mode" Attribute</a><a href="#section-toc.1-1.7.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.3">
                    <p id="section-toc.1-1.7.2.2.2.3.1"><a href="#section-7.2.3" class="xref">7.2.3</a>.  <a href="#name-alert-pause-attribute" class="xref">"alert-pause" Attribute</a><a href="#section-toc.1-1.7.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.4">
                    <p id="section-toc.1-1.7.2.2.2.4.1"><a href="#section-7.2.4" class="xref">7.2.4</a>.  <a href="#name-recovery-pause-attribute" class="xref">"recovery-pause" Attribute</a><a href="#section-toc.1-1.7.2.2.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.5">
                    <p id="section-toc.1-1.7.2.2.2.5.1"><a href="#section-7.2.5" class="xref">7.2.5</a>.  <a href="#name-public-address-attributes" class="xref">"public-address" Attributes</a><a href="#section-toc.1-1.7.2.2.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.6">
                    <p id="section-toc.1-1.7.2.2.2.6.1"><a href="#section-7.2.6" class="xref">7.2.6</a>.  <a href="#name-latency-attribute" class="xref">"latency" Attribute</a><a href="#section-toc.1-1.7.2.2.2.6.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.7">
                    <p id="section-toc.1-1.7.2.2.2.7.1"><a href="#section-7.2.7" class="xref">7.2.7</a>.  <a href="#name-jitter-attribute" class="xref">"jitter" Attribute</a><a href="#section-toc.1-1.7.2.2.2.7.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.8">
                    <p id="section-toc.1-1.7.2.2.2.8.1"><a href="#section-7.2.8" class="xref">7.2.8</a>.  <a href="#name-bandwidth-attribute" class="xref">"bandwidth" Attribute</a><a href="#section-toc.1-1.7.2.2.2.8.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.9">
                    <p id="section-toc.1-1.7.2.2.2.9.1"><a href="#section-7.2.9" class="xref">7.2.9</a>.  <a href="#name-packetloss-attribute" class="xref">"packetloss" Attribute</a><a href="#section-toc.1-1.7.2.2.2.9.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.10">
                    <p id="section-toc.1-1.7.2.2.2.10.1"><a href="#section-7.2.10" class="xref">7.2.10</a>. <a href="#name-flow-attributes" class="xref">"flow" Attributes</a><a href="#section-toc.1-1.7.2.2.2.10.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.11">
                    <p id="section-toc.1-1.7.2.2.2.11.1"><a href="#section-7.2.11" class="xref">7.2.11</a>. <a href="#name-measurement-attributes" class="xref">"measurement" Attributes</a><a href="#section-toc.1-1.7.2.2.2.11.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.12">
                    <p id="section-toc.1-1.7.2.2.2.12.1"><a href="#section-7.2.12" class="xref">7.2.12</a>. <a href="#name-max-content-length-attribut" class="xref">"max-content-length" Attribute</a><a href="#section-toc.1-1.7.2.2.2.12.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-measurements" class="xref">Measurements</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3.2.1">
                    <p id="section-toc.1-1.7.2.3.2.1.1"><a href="#section-7.3.1" class="xref">7.3.1</a>.  <a href="#name-latency" class="xref">Latency</a><a href="#section-toc.1-1.7.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3.2.2">
                    <p id="section-toc.1-1.7.2.3.2.2.1"><a href="#section-7.3.2" class="xref">7.3.2</a>.  <a href="#name-jitter" class="xref">Jitter</a><a href="#section-toc.1-1.7.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3.2.3">
                    <p id="section-toc.1-1.7.2.3.2.3.1"><a href="#section-7.3.3" class="xref">7.3.3</a>.  <a href="#name-bandwidth" class="xref">Bandwidth</a><a href="#section-toc.1-1.7.2.3.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3.2.4">
                    <p id="section-toc.1-1.7.2.3.2.4.1"><a href="#section-7.3.4" class="xref">7.3.4</a>.  <a href="#name-packet-loss" class="xref">Packet Loss</a><a href="#section-toc.1-1.7.2.3.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-handshake-phase" class="xref">Handshake Phase</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.5">
                <p id="section-toc.1-1.7.2.5.1"><a href="#section-7.5" class="xref">7.5</a>.  <a href="#name-negotiation-phase" class="xref">Negotiation Phase</a><a href="#section-toc.1-1.7.2.5.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.5.2.1">
                    <p id="section-toc.1-1.7.2.5.2.1.1"><a href="#section-7.5.1" class="xref">7.5.1</a>.  <a href="#name-stage-0-measurement-of-late" class="xref">Stage 0: Measurement of Latencies and Jitter</a><a href="#section-toc.1-1.7.2.5.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.5.2.2">
                    <p id="section-toc.1-1.7.2.5.2.2.1"><a href="#section-7.5.2" class="xref">7.5.2</a>.  <a href="#name-stage-1-measurement-of-band" class="xref">Stage 1: Measurement of Bandwidth and Packet Loss</a><a href="#section-toc.1-1.7.2.5.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.5.2.3">
                    <p id="section-toc.1-1.7.2.5.2.3.1"><a href="#section-7.5.3" class="xref">7.5.3</a>.  <a href="#name-quality-constraints-not-rea" class="xref">Quality Constraints Not Reached</a><a href="#section-toc.1-1.7.2.5.2.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.5.2.3.2.1">
                        <p id="section-toc.1-1.7.2.5.2.3.2.1.1"><a href="#section-7.5.3.1" class="xref">7.5.3.1</a>.  <a href="#name-actuator-role" class="xref">Actuator Role</a><a href="#section-toc.1-1.7.2.5.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                      <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.5.2.3.2.2">
                        <p id="section-toc.1-1.7.2.5.2.3.2.2.1"><a href="#section-7.5.3.2" class="xref">7.5.3.2</a>.  <a href="#name-policy-server-role" class="xref">Policy Server Role</a><a href="#section-toc.1-1.7.2.5.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                    </ul>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.5.2.4">
                    <p id="section-toc.1-1.7.2.5.2.4.1"><a href="#section-7.5.4" class="xref">7.5.4</a>.  <a href="#name-qos-level-changes" class="xref">"qos-level" Changes</a><a href="#section-toc.1-1.7.2.5.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.6">
                <p id="section-toc.1-1.7.2.6.1"><a href="#section-7.6" class="xref">7.6</a>.  <a href="#name-continuity-phase" class="xref">Continuity Phase</a><a href="#section-toc.1-1.7.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.7">
                <p id="section-toc.1-1.7.2.7.1"><a href="#section-7.7" class="xref">7.7</a>.  <a href="#name-termination-phase" class="xref">Termination Phase</a><a href="#section-toc.1-1.7.2.7.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.7.2.1">
                    <p id="section-toc.1-1.7.2.7.2.1.1"><a href="#section-7.7.1" class="xref">7.7.1</a>.  <a href="#name-sanity-check-of-quality-ses" class="xref">Sanity Check of Quality Sessions</a><a href="#section-toc.1-1.7.2.7.2.1.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.8">
                <p id="section-toc.1-1.7.2.8.1"><a href="#section-7.8" class="xref">7.8</a>.  <a href="#name-dynamic-constraints-and-flo" class="xref">Dynamic Constraints and Flows</a><a href="#section-toc.1-1.7.2.8.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.9">
                <p id="section-toc.1-1.7.2.9.1"><a href="#section-7.9" class="xref">7.9</a>.  <a href="#name-qos-level-upgrade-and-downg" class="xref">"qos-level" Upgrade and Downgrade Operation</a><a href="#section-toc.1-1.7.2.9.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-general-user-agent-behavior" class="xref">General User Agent Behavior</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-roles-in-peer-to-peer-scena" class="xref">Roles in Peer-to-Peer Scenarios</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-multiple-quality-sessions-i" class="xref">Multiple Quality Sessions in Parallel</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-general-client-behavior" class="xref">General Client Behavior</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.8.2.3.2.1">
                    <p id="section-toc.1-1.8.2.3.2.1.1"><a href="#section-8.3.1" class="xref">8.3.1</a>.  <a href="#name-generating-requests" class="xref">Generating Requests</a><a href="#section-toc.1-1.8.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-general-server-behavior" class="xref">General Server Behavior</a><a href="#section-toc.1-1.8.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-implementation-recommendati" class="xref">Implementation Recommendations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-default-client-constraints" class="xref">Default Client Constraints</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-latency-and-jitter-measurem" class="xref">Latency and Jitter Measurements</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.3">
                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-bandwidth-measurements" class="xref">Bandwidth Measurements</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.4">
                <p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4" class="xref">9.4</a>.  <a href="#name-packet-loss-measurement-res" class="xref">Packet Loss Measurement Resolution</a><a href="#section-toc.1-1.9.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.5">
                <p id="section-toc.1-1.9.2.5.1"><a href="#section-9.5" class="xref">9.5</a>.  <a href="#name-measurements-and-reactions" class="xref">Measurements and Reactions</a><a href="#section-toc.1-1.9.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.6">
                <p id="section-toc.1-1.9.2.6.1"><a href="#section-9.6" class="xref">9.6</a>.  <a href="#name-instability-treatments" class="xref">Instability Treatments</a><a href="#section-toc.1-1.9.2.6.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.9.2.6.2.1">
                    <p id="section-toc.1-1.9.2.6.2.1.1"><a href="#section-9.6.1" class="xref">9.6.1</a>.  <a href="#name-loss-of-control-packets" class="xref">Loss of Control Packets</a><a href="#section-toc.1-1.9.2.6.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.6.2.2">
                    <p id="section-toc.1-1.9.2.6.2.2.1"><a href="#section-9.6.2" class="xref">9.6.2</a>.  <a href="#name-outlier-samples" class="xref">Outlier Samples</a><a href="#section-toc.1-1.9.2.6.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.7">
                <p id="section-toc.1-1.9.2.7.1"><a href="#section-9.7" class="xref">9.7</a>.  <a href="#name-scenarios" class="xref">Scenarios</a><a href="#section-toc.1-1.9.2.7.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.9.2.7.2.1">
                    <p id="section-toc.1-1.9.2.7.2.1.1"><a href="#section-9.7.1" class="xref">9.7.1</a>.  <a href="#name-client-to-acp" class="xref">Client to ACP</a><a href="#section-toc.1-1.9.2.7.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.7.2.2">
                    <p id="section-toc.1-1.9.2.7.2.2.1"><a href="#section-9.7.2" class="xref">9.7.2</a>.  <a href="#name-client-to-client" class="xref">Client to Client</a><a href="#section-toc.1-1.9.2.7.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-confidentiality-issues" class="xref">Confidentiality Issues</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-integrity-of-measurements-a" class="xref">Integrity of Measurements and Authentication</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-privacy-of-measurements" class="xref">Privacy of Measurements</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.4">
                <p id="section-toc.1-1.10.2.4.1"><a href="#section-10.4" class="xref">10.4</a>.  <a href="#name-availability-issues" class="xref">Availability Issues</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5">
                <p id="section-toc.1-1.10.2.5.1"><a href="#section-10.5" class="xref">10.5</a>.  <a href="#name-bandwidth-occupancy-issues" class="xref">Bandwidth Occupancy Issues</a><a href="#section-toc.1-1.10.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-future-code-point-requireme" class="xref">Future Code Point Requirements</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-service-port" class="xref">Service Port</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.13.2.1">
                <p id="section-toc.1-1.13.2.1.1"><a href="#section-13.1" class="xref">13.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.13.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.13.2.2">
                <p id="section-toc.1-1.13.2.2.1"><a href="#section-13.2" class="xref">13.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.13.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.16.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="sec-1">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
   The World Wide Web (WWW) is a distributed hypermedia system
   that has gained widespread acceptance among Internet users.
   Although WWW browsers support other, preexisting Internet
   application protocols, the primary protocol used between WWW
   clients and servers became the HyperText Transfer Protocol (HTTP)
   (<span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>, <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>, 
    <span>[<a href="#RFC7232" class="xref">RFC7232</a>]</span>, <span>[<a href="#RFC7233" class="xref">RFC7233</a>]</span>, 
    <span>[<a href="#RFC7234" class="xref">RFC7234</a>]</span>, and <span>[<a href="#RFC7235" class="xref">RFC7235</a>]</span>).  
   Since then, HTTP over TLS (known as HTTPS
   and described in <span>[<a href="#RFC2818" class="xref">RFC2818</a>]</span>) has become an imperative for
   providing secure and authenticated WWW access.  The mechanisms
   described in this document are equally applicable to HTTP and
   HTTPS.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   The ease of use of the Web has prompted its widespread employment
   as a client/server architecture for many applications.  Many of
   such applications require the client and the server to be able to
   communicate with each other and exchange information with certain
   quality constraints.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
   Quality in communications at the application level consists of
   four measurable parameters:<a href="#section-1-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-1-4">
        <dt id="section-1-4.1">Latency:</dt>
        <dd style="margin-left: 3.0em" id="section-1-4.2">The time a message takes to travel from source to
        destination. It may be approximated as RTT/2 (round-trip
        time), assuming the networks are symmetrical. In this context,
        we will consider the statistical median formula.<a href="#section-1-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-1-4.3">Jitter:</dt>
        <dd style="margin-left: 3.0em" id="section-1-4.4">Latency variation. There are some formulas to
        calculate jitter, and in this context, we will consider the
        arithmetic mean formula.<a href="#section-1-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-1-4.5">Bandwidth:</dt>
        <dd style="margin-left: 3.0em" id="section-1-4.6">Bit rate of communication. To ensure quality, a
        protocol must ensure the availability of the bandwidth needed
        by the application.<a href="#section-1-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-1-4.7">Packet loss:</dt>
        <dd style="margin-left: 3.0em" id="section-1-4.8">The percentage of packet loss is closely related
        to bandwidth and jitter. Packet loss affects bandwidth because a high
        packet loss sometimes implies retransmissions that also
        consumes extra bandwidth, other times the retransmissions are
        not achieved (for example, in video streaming over UDP), and
        the information received is less than the required bandwidth.
        In terms of jitter, a packet loss sometimes is seen by the
        destination as a larger time between arrivals, causing a
        jitter growth.<a href="#section-1-4.8" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-1-5">
   Any other communication parameter, such as throughput, is not a
   network parameter because it depends on protocol window size and
   other implementation-dependent aspects.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">
   The Q4S protocol provides a mechanism for
   quality monitoring based on an HTTP syntax and the Session
   Description Protocol (SDP) in order to be easily integrated in the
   WWW, but it may be used by any type of application, not only those
   based on HTTP. Quality requirements may be needed by any type of
   application that communicates using any kind of protocol,
   especially those with real-time constraints. Depending on the
   nature of each application, the constraints may be different,
   leading to different parameter thresholds that need to be met.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">
   Q4S is an application-level client/server protocol that
   continuously measures session quality for a given flow (or set of
   flows), end-to-end (e2e) and in real time; raising alerts if
   quality parameters are below a given negotiated threshold and
   sending recoveries when quality parameters are restored. Q4S
   describes when these notifications, alerts, and recoveries need to
   be sent and the entity receiving them. The actions undertaken by
   the receiver of the alert are out of scope of the protocol.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">
   Q4S is session-independent from the application flows to minimize
   the impact on them. To perform the measurements, two control flows
   are created on both communication paths (forward and reverse
   directions).<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">
   This protocol specification is the product of research conducted
   over a number of years and is presented here as a permanent
   record and to offer a foundation for future similar work.  It does
   not represent a standard protocol and does not have IETF
   consensus.<a href="#section-1-9" class="pilcrow">¶</a></p>
<div id="sec-1.1">
<section id="section-1.1">
        <h3 id="name-scope">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-scope" class="section-name selfRef">Scope</a>
        </h3>
<p id="section-1.1-1">
   The purpose of Q4S is to measure end-to-end network quality in
   real time. Q4S does not transport any application data. This means
   that Q4S is designed to be used jointly with other transport
   protocols such as Real-time Transport Protocol (RTP) <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>,
   Transmission Control Protocol (TCP) <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span>, 
   QUIC <span>[<a href="#I-D.ietf-quic-transport" class="xref">QUIC</a>]</span>, 
   HTTP <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>, etc.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
   Some existent transport protocols are focused on real-time media
   transport and certain connection metrics are available, which is
   the case of RTP and RTP Control Protocol (RTCP) <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>. Other
   protocols such as QUIC provide low connection latencies as well as
   advanced congestion control. These protocols transport data
   efficiently and provide a lot of functionalities. However, there are
   currently no other quality measurement protocols offering the same
   level of function as Q4S.  See <a href="#sec-1.4" class="xref">Section 1.4</a> for a discussion of the
   IETF's quality measurement protocols, One-Way Active Measurement Protocol (OWAMP) and 
   Two-Way Active Measurement Protocol (TWAMP).<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">
   Q4S enables applications to become reactive under e2e network
   quality changes. To achieve it, an independent Q4S stack
   application must run in parallel with the target application. Then, Q4S
   metrics may be used to trigger actions on the target application, such
   as speed adaptation to latency in multiuser games, bitrate control
   at streaming services, intelligent commutation of delivery node at
   Content Delivery Networks, and whatever the target application allows.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-1.2">
<section id="section-1.2">
        <h3 id="name-motivation">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-motivation" class="section-name selfRef">Motivation</a>
        </h3>
<p id="section-1.2-1">
   Monitoring quality of service (QoS) in computer networks is useful
   for several reasons:<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.2-2.1">It enables real-time services and applications to verify whether
        network resources achieve a certain QoS level. This helps
        real-time services and applications to run over the
        Internet, allowing the existence of Application Content
        Providers (ACPs), which offer guaranteed real-time services to
        the end users.<a href="#section-1.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.2">Real-time monitoring allows applications to adapt themselves
        to network conditions (application-based QoS) and/or request
        more network quality from the Internet Service Provider (ISP)
        (if the ISP offers this possibility).<a href="#section-1.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.3">Monitoring may also be required by peer-to-peer (P2P) real-time 
           applications for which Q4S can be used.<a href="#section-1.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.4">Monitoring enables ISPs to offer QoS to any ACP or end user application
        in an accountable way.<a href="#section-1.2-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.5">
            <p id="section-1.2-2.5.1">Monitoring enables e2e negotiation of QoS parameters, independently of
        the ISPs of both endpoints.<a href="#section-1.2-2.5.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-1.2-3">

        A protocol to monitor QoS must address the following issues:<a href="#section-1.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.2-4.1">Must be ready to be used in conjunction with current standard
        protocols and applications, without forcing a change on them.<a href="#section-1.2-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-4.2">Must have a formal and compact way to specify quality
        constraints desired by the application to run.<a href="#section-1.2-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-4.3">Must have measurement mechanisms that avoid application
        disruption and minimize network resources consumption.<a href="#section-1.2-4.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-4.4">Must have specific messages to alert about the violation of
        quality constraints in different directions (forward and
        reverse) because network routing may not be symmetrical, and
        of course, quality constraints may not be symmetrical.<a href="#section-1.2-4.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-4.5">After having alerted about the violation of quality
        constraints, must have specific messages to inform about
        the recovery of quality constraints in corresponding directions
        (forward and reverse).<a href="#section-1.2-4.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-4.6">Must protect the data (constraints, measurements, QoS levels
        demanded from the network) in order to avoid the injection of
        malicious data in the measurements.<a href="#section-1.2-4.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="sec-1.3">
<section id="section-1.3">
        <h3 id="name-summary-of-features">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-summary-of-features" class="section-name selfRef">Summary of Features</a>
        </h3>
<p id="section-1.3-1">
   The Quality for Service (Q4S) protocol is a message-oriented
   communication protocol that can be used in conjunction with any
   other application-level protocol. Q4S is a measurement protocol.
   Any action taken derived from its measurements are out of scope of
   the protocol. These actions depend on the application provider and may
   be application-level adaptive reactions, may involve requests to
   the ISP, or whatever the application provider decides.<a href="#section-1.3-1" class="pilcrow">¶</a></p>
<p id="section-1.3-2">
   The benefits in quality measurements provided by Q4S can be used
   by any type of application that uses any type of protocol for data
   transport. It provides a quality monitoring scheme for any
   communication that takes place between the client and the server,
   not only for the Q4S communication itself.<a href="#section-1.3-2" class="pilcrow">¶</a></p>
<p id="section-1.3-3">
   Q4S does not establish multimedia sessions, and it does not
   transport application data. It monitors the fulfillment of the
   quality requirements of the communication between the client and
   the server; therefore, it does not impose any restrictions on the
   type of application, protocol, or usage of the
   monitored quality connection.<a href="#section-1.3-3" class="pilcrow">¶</a></p>
<p id="section-1.3-4">
   Some applications may vary their quality requirements dynamically
   for any given quality parameter. Q4S is able to adapt to the
   changing application needs, modifying the parameter thresholds to
   the new values and monitoring the network quality according to the
   new quality constraints. It will raise alerts if the new
   constraints are violated.<a href="#section-1.3-4" class="pilcrow">¶</a></p>
<p id="section-1.3-5">
   The Q4S session lifetime is composed of four phases with different
   purposes: Handshake, Negotiation, Continuity, and Termination.
   Negotiation and Continuity phases perform network parameter
   measurements per a negotiated measurement procedure. Different
   measurement procedures could be used inside Q4S, although one
   default measurement mechanism is needed for compatibility reasons
   and is the one defined in this document. Basically, Q4S defines
   how to transport application quality requirements and measurement
   results between a client and server and how to provide monitoring and
   alerting, too.<a href="#section-1.3-5" class="pilcrow">¶</a></p>
<p id="section-1.3-6">
   Q4S must be executed just before starting a client-server
   application that needs a quality connection in terms of latency,
   jitter, bandwidth, and/or packet loss. Once the client and server have
   succeeded in establishing communication under quality constraints,
   the application can start, and Q4S continues measuring and
   alerting if necessary.<a href="#section-1.3-6" class="pilcrow">¶</a></p>
<p id="section-1.3-7">
   The quality parameters can be suggested by the client in the first
   message of the Handshake phase, but it is the server that accepts
   these parameter values or forces others. The server is in charge
   of deciding the final values of quality connection.<a href="#section-1.3-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-1.4">
<section id="section-1.4">
        <h3 id="name-differences-from-owamp-twam">
<a href="#section-1.4" class="section-number selfRef">1.4. </a><a href="#name-differences-from-owamp-twam" class="section-name selfRef">Differences from OWAMP/TWAMP</a>
        </h3>
<p id="section-1.4-1">
   OWAMP <span>[<a href="#RFC4656" class="xref">RFC4656</a>]</span> and 
   TWAMP <span>[<a href="#RFC5357" class="xref">RFC5357</a>]</span> are two protocols
   to measure network quality in terms of RTT, but they have a different
   goal than Q4S. The main difference is the scope: Q4S is designed
   to assist reactive applications, whereas OWAMP/TWAMP is designed
   to measure just network delay.<a href="#section-1.4-1" class="pilcrow">¶</a></p>
<p id="section-1.4-2">
   The differences can be summarized in the following points:<a href="#section-1.4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.4-3.1">OWAMP and TWAMP are not intended for measuring availability of
      resources (certain bandwidth availability, for example) but
      only RTT. However, Q4S is intended for measuring required
      bandwidth, packet loss, jitter, and latency in both
      directions. Available bandwidth is not measured by Q4S, but
      bandwidth required for a specific application is.<a href="#section-1.4-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.4-3.2">OWAMP and TWAMP do not have responsivity control (which
      defines the speed of protocol reactions under network quality
      changes) because these protocols are designed to measure
      network performance, not to assist reactive applications, and
      do not detect the fluctuations of quality within certain time
      intervals to take reactive actions. However, responsivity
      control is a key feature of Q4S.<a href="#section-1.4-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.4-3.3">OWAMP and TWAMP are not intended to run in parallel with reactive
      applications, but the Q4S protocol's goal is to run in parallel and assist
      reactive applications in making decisions based on Q4S-ALERT
      packets, which may trigger actions.<a href="#section-1.4-3.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="sec-2">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>",
    "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be
    interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals, as
    shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-3">
<section id="section-3">
      <h2 id="name-overview-of-operation">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-overview-of-operation" class="section-name selfRef">Overview of Operation</a>
      </h2>
<p id="section-3-1">
   This section introduces the basic operation of Q4S using simple
   examples.  This section is of a tutorial nature and does not contain
   any normative statements.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
   The first example shows the basic functions of Q4S:
   communication establishment between a client and a server, quality
   requirement negotiations for the requested application,
   application start and continuous quality parameter measurements,
   and finally communication termination.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">
   The client triggers the establishment of the communication by
   requesting a specific service or application from the server. This
   first message must have a special URI <span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span>, which may
   force the use of the Q4S protocol if it is implemented in a
   standard web browser. This message consists of a Q4S BEGIN method,
   which can optionally include a proposal for the communication
   quality requirements in an SDP body. This option gives the client
   a certain negotiation capacity about quality requirements, but it
   will be the server who finally decides the stated
   requirements.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">
   This request is answered by the server with a Q4S 200 OK response
   letting the client know that it accepts the request. This response
   message must contain an SDP body with the following:<a href="#section-3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-5.1">The assigned Q4S sess-id.<a href="#section-3-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-5.2">The quality constraints required by the requested application.<a href="#section-3-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-5.3">The measurement procedure to use.<a href="#section-3-5.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-5.4">
          <p id="section-3-5.4.1">"alerting-mode" attribute: There are two different scenarios for
      sending alerts that trigger actions either on the network or
      in the application when measurements identify violated
      quality constraints. In both cases, alerts are triggered by
      the server.<a href="#section-3-5.4.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-3-5.4.2">
            <dt>(a)</dt>
<dd id="section-3-5.4.2.1">
              <p id="section-3-5.4.2.1.1">Q4S-aware-network scenario: The network is Q4S aware
           and reacts by itself to these alerts. In this scenario,
           Q4S-ALERT messages are sent by the server to the client,
           and network elements inspect and process these alert
           messages. The alerting mode in this scenario is called
           Q4S-aware-network alerting mode.<a href="#section-3-5.4.2.1.1" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt>(b)</dt>
<dd id="section-3-5.4.2.2">
              <p id="section-3-5.4.2.2.1">Reactive scenario: As shown in 
           <a href="#ref-reactive-scenario" class="xref">Figure 1</a>, the network
           is not Q4S aware. In this scenario, alert notifications
           are sent to a specific node, called an Actuator, which is
           in charge of making decisions regarding what actions to
           trigger: either to change application behavior to adapt
           it to network conditions and/or invoke a network policy
           server in order to reconfigure the network and request
           better quality for application flows.<a href="#section-3-5.4.2.2.1" class="pilcrow">¶</a></p>
<span id="name-reactive-scenario"></span><div id="ref-reactive-scenario">
<figure id="figure-1">
                <div class="artwork art-text alignLeft" id="section-3-5.4.2.2.2.1">
<pre>
         +------+                           +-----------+
         |  App |&lt;----- app flows----------&gt;|Application|
         |Client|                           +-----------+
         +------+                                 A
                                                  |
         +------+             +------+       +--------+
         | Q4S  |&lt;----Q4S----&gt;| Q4S  |&lt;-----&gt;|Actuator|
         |Client|             |Server|       +--------+
         +------+             +------+            |
                                                  V
                                           +-------------+
                                           |policy server|
                                           +-------------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-reactive-scenario" class="selfRef">Reactive Scenario</a>
                </figcaption></figure>
</div>
<p id="section-3-5.4.2.2.3">The format of messages exchanged between the server stack and
      the Actuator doesn't follow Q4S codification rules;
      their format will be implementation dependent. In this way,
      we will call the messages sent from the server stack to the
      Actuator "notifications" (e.g., alert notifications) and the
      messages sent from the Actuator to the server stack in
      response to notifications "acknowledges" (e.g., alert
      acknowledges).<a href="#section-3-5.4.2.2.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
</dl>
</li>
      </ul>
<ul class="normal">
<li class="normal" id="section-3-6.1">"alert-pause" attribute: The amount of time between consecutive alerts.
      In the Q4S-aware-network scenario, the server has to wait
      this period of time between Q4S-ALERT messages sent to the
      client. In the Reactive scenario, the server stack has to
      wait this period of time between alert notifications sent to
      the Actuator. Measurements are not stopped in Negotiation or
      Continuity phases during this period of time, but no alerts
      are sent, even with violated network quality constraints, in
      order to leave time for network reconfiguration or for
      application adjustments.<a href="#section-3-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-6.2">"recovery-pause" attribute: The amount of time the Q4S server waits
      before trying to recover the initial "qos-level" (<a href="#sec-7.2.1" class="xref">Section 7.2.1</a>). 
      After having
      detected violation of quality constraints several times, the
      "qos-level" will have been increased accordingly. If this
      violation detection finally stops, the server waits for a
      period of time (recovery time), and if the situation persists,
      it tries to recover to previous "qos-level" values gradually by
      sending Q4S-RECOVERY messages to the client in the Q4S-aware-network scenario, or recovery notifications to the
      Actuator in the Reactive scenario (<a href="#sec-7.9" class="xref">Section 7.9</a>).<a href="#section-3-6.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-7">
   It is important to highlight that any Q4S 200 OK response sent by
   the server to the client at any time during the life of a quality
   session may contain an SDP body with new values of quality
   constraints required by the application. Depending on the phase
   and the state of the measurement procedure within the specific
   phase, the client will react accordingly to take into
   account the new quality constraints in the measurement procedure.<a href="#section-3-7" class="pilcrow">¶</a></p>
<p id="section-3-8">
   Once the communication has been established (i.e., the Handshake phase is
   finished), the protocol will verify that the communication path
   between the client and the server meets the quality constraints in
   both directions, from and to the server (Negotiation phase). This
   Negotiation phase requires taking measurements of the quality
   parameters: latencies, jitter, bandwidth, and packet loss. This
   phase is initiated with a client message containing a Q4S READY
   method, which will be answered by the server with a Q4S 200 OK
   response.<a href="#section-3-8" class="pilcrow">¶</a></p>
<p id="section-3-9">
   Negotiation measurements are achieved in two sequential stages:<a href="#section-3-9" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-10">
        <dt id="section-3-10.1">Stage 0:</dt>
        <dd style="margin-left: 3.0em" id="section-3-10.2"> latency and jitter measurements<a href="#section-3-10.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-10.3">Stage 1:</dt>
        <dd style="margin-left: 3.0em" id="section-3-10.4"> bandwidth and packet loss measurements<a href="#section-3-10.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-11">
   Stage 0 measurements are taken through Q4S PING messages
   sent from both the client and the server. All Q4S PING
   requests will be answered by Q4S 200 OK messages to allow for
   bidirectional measurements.<a href="#section-3-11" class="pilcrow">¶</a></p>
<p id="section-3-12">
   Different client and server implementations may send a different
   number of PING messages for measuring, although at least 255
   messages should be considered to perform the latency measurement.
   The Stage 0 measurements only may be considered ended when neither
   client nor server receive new PING messages after an
   implementation-dependent guard time. Only after Stage 0 has ended, can the client send a
   "READY 1" message.<a href="#section-3-12" class="pilcrow">¶</a></p>
<p id="section-3-13">
   After a pre-agreed number of measurements have been performed,
   determined by the measurement procedure sent by the server, three
   scenarios may be possible:<a href="#section-3-13" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-3-14">
        <dt>(a)</dt>
<dd id="section-3-14.1"> Measurements do not meet the 
        requirements: in this case, the
 stage 0 is repeated after sending an alert from the server to
      the client or from the server stack to the Actuator, depending
      on the alerting mode defined in the Handshake phase. Notice
      that measurements continue to be taken but no alerts are sent
      during the "alert-pause" time. In the Reactive scenario, the
      Actuator will decide either to forward the alert notification
      to the network policy server or to the application, depending
      on where reconfiguration actions have to be taken.<a href="#section-3-14.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(b)</dt>
<dd id="section-3-14.2"> Measurements do meet the requirements: in this case, client
 moves to stage 1 by sending a new READY message.<a href="#section-3-14.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(c)</dt>
<dd id="section-3-14.3"> At any time during the measurement procedure, the Q4S 200 OK
 message sent by the server to the client, in response to a Q4S
      PING message, contains an SDP body with new values of quality
      constraints required by the application. This means the
      application has varied their quality requirements dynamically;
      therefore, quality thresholds used while monitoring quality
      parameters have to be changed to the new constraints. In this
      case, the client moves to the beginning of Stage 0 for
      initiating the negotiation measurements again.<a href="#section-3-14.3" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-15">
   Stage 1 is optional. Its purpose is to measure the availability of
   application-needed bandwidth. If the "bandwidth" attribute is 
   set to zero kbps in the SDP, the client can skip stage 1 by 
   sending a "READY 2" message after completion of stage 0. Stage 1
   measurements are achieved through Q4S BWIDTH messages sent
   from both the client and the server. Unlike PING messages, Q4S BWIDTH
   requests will not be answered.<a href="#section-3-15" class="pilcrow">¶</a></p>
<p id="section-3-16">
   If Stage 0 and 1 meet the application quality constraints, the
   application may start. Q4S will enter the Continuity phase
   by measuring the network quality parameters through the Q4S PING
   message exchange on both connection paths and raising alerts in
   case of violation.<a href="#section-3-16" class="pilcrow">¶</a></p>
<p id="section-3-17">
   Once the client wants to terminate the quality session, it sends a
   Q4S CANCEL message, which will be acknowledged by the server with
   another Q4S CANCEL message. Termination of quality sessions are
   always initiated by the client because Q4S TCP requests follow the
   client/server schema.<a href="#section-3-17" class="pilcrow">¶</a></p>
<p id="section-3-18"><a href="#ref-successful-q4s-message-exchange" class="xref">Figure 2</a> 
   depicts the message exchange in a successful scenario.<a href="#section-3-18" class="pilcrow">¶</a></p>
<span id="name-successful-q4s-message-exch"></span><div id="ref-successful-q4s-message-exchange">
<figure id="figure-2">
        <div class="artwork art-text alignLeft" id="section-3-19.1">
<pre>
            +-------------------------------------------+
            |                                           |
            | Client                             Server |
            |                                           |
Handshake   |     --------- Q4S BEGIN -----------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |                                           |
Negotiation |                                           |
(Stage 0)   |     --------- Q4S READY 0----------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |                                           |
            |     --------- Q4S PING ------------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |     &lt;-------- Q4S PING -------------      |
            |      -------- Q4S 200 OK ----------&gt;      |
            |     --------- Q4S PING ------------&gt;      |
            |     &lt;-------- Q4S PING -------------      |
            |     --------- Q4S 200 OK ----------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |                    ...                    |
Negotiation |                                           |
(Stage 1)   |     --------- Q4S READY 1----------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |                                           |
            |     --------- Q4S BWITDH ----------&gt;      |
            |     &lt;-------- Q4S BWIDTH------------      |
            |     --------- Q4S BWITDH ----------&gt;      |
            |     &lt;-------- Q4S BWIDTH------------      |
            |                    ...                    |
Continuity  |     --------- Q4S READY 2 ---------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      | app start
            |                                           |
            |     --------- Q4S PING ------------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |     &lt;-------- Q4S PING -------------      |
            |      -------- Q4S 200 OK ----------&gt;      |
            |                                           |
Termination |     --------- Q4S CANCEL ----------&gt;      | app end
            |     &lt;-------- Q4S CANCEL -----------      |
            |                                           |
            +-------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-successful-q4s-message-exch" class="selfRef">Successful Q4S Message Exchange</a>
        </figcaption></figure>
</div>
<p id="section-3-20">
   Both client and server measurements are included in the PING and BWIDTH
   messages, allowing both sides of the communication channel to be aware
   of all measurements in both directions.<a href="#section-3-20" class="pilcrow">¶</a></p>
<p id="section-3-21">
   The following two examples show the behavior of the Q4S protocol
   when quality constraints are violated, and alerts are generated; and,
   later on, when the violation of quality constraints stops leading to the
   execution of the recovery process. The first example 
   (<a href="#ref-q4s-aware-network-alerting-mode" class="xref">Figure 3</a>)
   shows the Q4S-aware-network alerting mode scenario:<a href="#section-3-21" class="pilcrow">¶</a></p>
<span id="name-q4s-aware-network-alerting-"></span><div id="ref-q4s-aware-network-alerting-mode">
<figure id="figure-3">
        <div class="artwork art-text alignLeft" id="section-3-22.1">
<pre>
            +-------------------------------------------+
            |                                           |
            | Client                             Server |
            |                                           |
Handshake   |     --------- Q4S BEGIN -----------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |                                           |
Negotiation |                                           |
(Stage 0)   |     --------- Q4S READY 0----------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |                                           |
            |     --------- Q4S PING ------------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |     &lt;-------- Q4S PING -------------      |
            |      -------- Q4S 200 OK ----------&gt;      |
            |                    ...                    |
            |                                           |
            |     &lt;-------- Q4S-ALERT ------------      |
            |     -------- Q4S-ALERT ------------&gt;      |
            |          (alert-pause start)              |
Repetition  |                                           |
of Stage 0  |     --------- Q4S READY 0----------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |                                           |
            |     --------- Q4S PING ------------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |     &lt;-------- Q4S PING -------------      |
            |                    ...                    |
Negotiation |                                           |
(Stage 1)   |     --------- Q4S READY 1----------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |                                           |
            |     --------- Q4S BWITDH ----------&gt;      |
            |     &lt;-------- Q4S BWIDTH------------      |
            |                    ...                    |
            |                                           |
Continuity  |     --------- Q4S READY 2 ---------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      | app start
            |                                           |
            |     --------- Q4S PING ------------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |     &lt;-------- Q4S PING -------------      |
            |      -------- Q4S 200 OK ----------&gt;      |
            |                    ...                    |
            |(alert-pause expires &amp;                     |
            |                   violated constraints)   |
            |     &lt;-------- Q4S-ALERT ------------      |
            |     --------- Q4S-ALERT -----------&gt;      |
            |                                           |
            |           (alert-pause start)             |
            |     --------- Q4S PING ------------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |     &lt;-------- Q4S PING -------------      |
            |     --------- Q4S 200 OK ----------&gt;      |
            |                    ...                    |
            |(alert-pause expires &amp;                     |
            |                   violated constraints)   |
            |     &lt;-------- Q4S-ALERT ------------      |
            |     --------- Q4S-ALERT -----------&gt;      |
            |           (alert-pause)                   |
            |     --------- Q4S PING ------------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |     &lt;-------- Q4S PING -------------      |
            |      -------- Q4S 200 OK ----------&gt;      |
            |                    ...                    |
            |(alert-pause expires &amp;                     |
            |                 Fulfilled constraints)    |
            |                                           |
            |           (recovery-pause start)          |
            |                                           |
            |     --------- Q4S PING ------------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |     &lt;-------- Q4S PING -------------      |
            |      -------- Q4S 200 OK ----------&gt;      |
            |                    ...                    |
            |(recovery-pause expires &amp;                  |
            |                 Fulfilled constraints)    |
            |     &lt;--------- Q4S-RECOVERY ---------     |
            |     -------- Q4S-RECOVERY -----------&gt;    |
            |                                           |
            |          (recovery-pause start)           |
            |     --------- Q4S PING ------------&gt;      |
            |     &lt;-------- Q4S 200 OK -----------      |
            |     &lt;-------- Q4S PING -------------      |
            |      -------- Q4S 200 OK ----------&gt;      |
            |                    ...                    |
            |                                           |
Termination |     --------- Q4S CANCEL ----------&gt;      | app end
            |     &lt;-------- Q4S CANCEL -----------      |
            |                                           |
            +-------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-q4s-aware-network-alerting-" class="selfRef">Q4S-Aware-Network Alerting Mode</a>
        </figcaption></figure>
</div>
<p id="section-3-23">
   In this Q4S-aware-network alerting mode scenario, the server may
   send Q4S alerts to the client at any time upon detection of violated
   quality constraints. This alerting exchange must not interrupt the
   continuity quality parameter measurements between client and
   server.<a href="#section-3-23" class="pilcrow">¶</a></p>
<p id="section-3-24">
   The second example depicted in <a href="#ref-reactive-alerting-mode" class="xref">Figure 4</a> represents the
   Reactive scenario, in which alert notifications are sent from the
   server stack to the Actuator, which is in charge of deciding 
   to act over application behavior and/or to invoke a network policy
   server. The Actuator is an entity that has a defined set of
   different quality levels and decides how to act depending on the
   actions stated for each of these levels; it can take actions for
   making adjustments on the application, or it can send a request to
   the policy server for acting on the network. The policy server
   also has a defined set of different quality levels previously agreed
   upon between the Application Content Provider and the ISP. The
   Reactive alerting mode is the default mode.<a href="#section-3-24" class="pilcrow">¶</a></p>
<span id="name-reactive-alerting-mode"></span><div id="ref-reactive-alerting-mode">
<figure id="figure-4">
        <div class="artwork art-text alignLeft" id="section-3-25.1">
<pre>
            +-------------------------------------------+
            |                                           |
            | Client               Server      Actuator |
Handshake   |   ----- Q4S BEGIN -----&gt;                  |
            |   &lt;---- Q4S 200 OK -----                  |
            |                                           |
Negotiation |                                           |
(Stage 0)   |   ----- Q4S READY 0----&gt;                  |
            |   &lt;---- Q4S 200 OK -----                  |
            |                                           |
            |   ----- Q4S PING ------&gt;                  |
            |   &lt;---- Q4S 200 OK -----                  |
            |   &lt;---- Q4S PING -------                  |
            |    ---- Q4S 200 OK ----&gt;                  |
            |              ...                          |
            |  (alert-pause start)                      |
            |                          --alert          |
            |                         notification--&gt;   |
            |                                           |
            |                         &lt;--alert          |
            |                          acknowledge---   |
            |                                           |
Repetition  |                                           |
of Stage 0  |   ----- Q4S READY 0----&gt;                  |
            |   &lt;---- Q4S 200 OK -----                  |
            |                                           |
            |   ----- Q4S PING ------&gt;                  |
            |   &lt;---- Q4S 200 OK -----                  |
            |   &lt;---- Q4S PING -------                  |
            |              ...                          |
            |(alert-pause expires &amp;                     |
            |                   violated constraints)   |
            |                                           |
            |                         --alert           |
            |                         notification--&gt;   |
            |                                           |
            |                         &lt;--alert          |
            |                          acknowledge---   |
            |                                           |
            |   ----- Q4S PING ------&gt;                  |
            |   &lt;---- Q4S 200 OK -----                  |
            |   &lt;---- Q4S PING -------                  |
            |              ...                          |
Negotiation |                                           |
(Stage 1)   |   ----- Q4S READY 1----&gt;                  |
            |   &lt;---- Q4S 200 OK -----                  |
            |                                           |
            |   ----- Q4S BWITDH ----&gt;                  |
            |   &lt;---- Q4S BWIDTH------                  |
            |              ...                          |
Continuity  |   ----- Q4S READY 2 ---&gt;                  |
            |   &lt;---- Q4S 200 OK -----                  | app start
            |                                           |
            |(alert-pause expires &amp;                     |
            |                  fulfilled constraints)   |
            |                                           |
            |(recovery-pause start)                     |
            |   ----- Q4S PING ------&gt;                  |
            |   &lt;---- Q4S 200 OK -----                  |
            |   &lt;---- Q4S PING -------                  |
            |   ----- Q4S PING ------&gt;                  |
            |                                           |
            |(recovery-pause expires &amp;                  |
            |                  fulfilled constraints)   |
            |                                           |
            |                         --recovery        |
            |                         notification--&gt;   |
            |                                           |
            |                         &lt;--recovery       |
            |                          acknowledge---   |
            |                                           |
            |(recovery-pause start)                     |
            |   &lt;---- Q4S 200 OK -----                  |
            |   &lt;---- Q4S PING -------                  |
            |   ----- Q4S 200 OK ----&gt;                  |
            |   ----- Q4S PING ------&gt;                  |
            |              ...                          |
            |                                           |
Termination |   ----- Q4S CANCEL ----&gt;                  | app end
            |                          --cancel         |
            |                          notification--&gt;  |
            |                                           |
            |                          &lt;--cancel        |
            |                           acknowledge--   |
            |   &lt;---- Q4S CANCEL -----                  |
            |                                           |
            +-------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-reactive-alerting-mode" class="selfRef">Reactive Alerting Mode</a>
        </figcaption></figure>
</div>
<p id="section-3-26">
   At the end of any stage of the Negotiation phase, the server sends an
   alert notification to the Actuator if quality constraints are
   violated. During the period of time defined by the "alert-pause"
   attribute, no further alert notifications are sent, but
   measurements are not interrupted. This way, both the client and
   the server will detect network improvements as soon as possible.
   In a similar way during the Continuity phase, the server may send
   alert notifications at any time to the Actuator upon detection of
   violated quality constraints. This alerting exchange must not
   interrupt the continuity measurements between client and server.<a href="#section-3-26" class="pilcrow">¶</a></p>
<p id="section-3-27">
   Finally, in the Termination phase, Q4S CANCEL messages sent from
   the client to the server must be forwarded from the server to the
   Actuator in order to release possible assigned resources for the
   session.<a href="#section-3-27" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-4">
<section id="section-4">
      <h2 id="name-q4s-messages">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-q4s-messages" class="section-name selfRef">Q4S Messages</a>
      </h2>
<p id="section-4-1">
   Q4S is a text-based protocol and uses the UTF-8 charset 
   <span>[<a href="#RFC3629" class="xref">RFC3629</a>]</span>. A Q4S message is either a request or a response.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
   Both request and response messages use the basic format of
   Internet Message Format <span>[<a href="#RFC5322" class="xref">RFC5322</a>]</span>. Both types of messages
   consist of a start-line, one or more header fields, an empty line
   indicating the end of the header fields, and an optional message-body.
   This document uses ABNF notation <span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span>
   for the definitions of the syntax of messages.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">
   The start-line, each message-header line, and the empty line <span class="bcp14">MUST</span>
   be terminated by a carriage-return line-feed sequence (CRLF).
   Note that the empty line <span class="bcp14">MUST</span> be present even if the message-body
   is not.<a href="#section-4-3" class="pilcrow">¶</a></p>
<div id="section-4-4">
<pre class="sourcecode lang-abnf">
      generic-message  =  start-line CRLF
                          *message-header CRLF
                          CRLF
                          [ message-body ]
      start-line       =  Request-Line / Status-Line
</pre><a href="#section-4-4" class="pilcrow">¶</a>
</div>
<p id="section-4-5">
   Much of Q4S's messages and header field syntax are identical to
   HTTP/1.1. However, Q4S is not an extension of HTTP.<a href="#section-4-5" class="pilcrow">¶</a></p>
<div id="sec-4.1">
<section id="section-4.1">
        <h3 id="name-requests">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-requests" class="section-name selfRef">Requests</a>
        </h3>
<p id="section-4.1-1">
   Q4S requests are distinguished by having a Request-Line for a
   start-line. A Request-Line contains a method name, a Request-URI,
   and the protocol version separated by a single space (SP)
   character.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">
   The Request-Line ends with CRLF. No CR or LF are allowed except in
   the end-of-line CRLF sequence. No linear whitespace (LWSP) is allowed
   in any of the elements.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<div id="section-4.1-3">
<pre class="sourcecode lang-abnf">
   Request-Line  =  Method SP Request-URI SP Q4S-Version CRLF
</pre><a href="#section-4.1-3" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-4.1-4">
          <dt id="section-4.1-4.1">Method:</dt>
          <dd style="margin-left: 3.0em" id="section-4.1-4.2">
 This specification defines seven methods: BEGIN for
 starting and negotiating quality sessions, READY for
      synchronization of measurements, PING and BWIDTH for
      quality measurements purposes, CANCEL for terminating
      sessions, Q4S-ALERT for reporting quality violations, and
      Q4S-RECOVERY for reporting quality recovery.<a href="#section-4.1-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-4.3">Request-URI:</dt>
          <dd style="margin-left: 3.0em" id="section-4.1-4.4">
 The Request-URI is a Q4S URI <span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span> as described
 in <a href="#sec-7.4" class="xref">Section 7.4</a>. The Request-URI <span class="bcp14">MUST NOT</span> contain unescaped spaces
      or control characters and <span class="bcp14">MUST NOT</span> be enclosed in "&lt;&gt;".<a href="#section-4.1-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-4.5">Q4S-Version:</dt>
          <dd style="margin-left: 3.0em" id="section-4.1-4.6">
 Both request and response messages include the
 version of Q4S in use. To be compliant with this
      specification, applications sending Q4S messages <span class="bcp14">MUST</span>
      include a Q4S-Version of "Q4S/1.0".  The Q4S-Version string
      is case insensitive, but implementations <span class="bcp14">MUST</span> 
      send uppercase. Unlike HTTP/1.1, Q4S treats the version number as a
      literal string.  In practice, this should make no difference.<a href="#section-4.1-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec-4.2">
<section id="section-4.2">
        <h3 id="name-responses">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-responses" class="section-name selfRef">Responses</a>
        </h3>
<p id="section-4.2-1">
   Q4S responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol
   version followed by a numeric Status-Code and its associated
   textual phrase, with each element separated by a single SP
   character. No CR or LF is allowed except in the final CRLF
   sequence.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="section-4.2-2">
<pre class="sourcecode lang-abnf">
   Status-Line  =  Q4S-Version SP Status-Code SP Reason-Phrase CRLF
</pre><a href="#section-4.2-2" class="pilcrow">¶</a>
</div>
<p id="section-4.2-3">
   The Status-Code is a 3-digit integer result code that indicates
   the outcome of an attempt to understand and satisfy a request. The
   Reason-Phrase is intended to give a short textual description of
   the Status-Code.  The Status-Code is intended for use by automata,
   whereas the Reason-Phrase is intended for the human user. A client
   is not required to examine or display the Reason-Phrase.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">
   While this specification suggests specific wording for the 
   Reason-Phrase, implementations <span class="bcp14">MAY</span> choose other text, for example, in the
   language indicated in the Accept-Language header field of the
   request.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">
   The first digit of the Status-Code defines the class of response.
   The last two digits do not have any categorization role.  For this
   reason, any response with a status code between 100 and 199 is
   referred to as a "1xx response", any response with a status code
   between 200 and 299 as a "2xx response", and so on.  Q4S/1.0
   allows following values for the first digit:<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.2-6">
          <dt id="section-4.2-6.1">1xx:</dt>
          <dd style="margin-left: 3.0em" id="section-4.2-6.2">
 Provisional -- request received, continuing to process the request;<a href="#section-4.2-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-6.3">2xx:</dt>
          <dd style="margin-left: 3.0em" id="section-4.2-6.4">
 Success -- the action was successfully received, understood, and accepted;<a href="#section-4.2-6.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-6.5">3xx:</dt>
          <dd style="margin-left: 3.0em" id="section-4.2-6.6">
 Redirection -- further action needs to be taken in order to complete the request;<a href="#section-4.2-6.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-6.7">4xx:</dt>
          <dd style="margin-left: 3.0em" id="section-4.2-6.8">
 Request Failure -- the request contains bad syntax or cannot be fulfilled at this server;<a href="#section-4.2-6.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-6.9">5xx:</dt>
          <dd style="margin-left: 3.0em" id="section-4.2-6.10"> 
        Server Error -- the server failed to fulfill an apparently valid request;<a href="#section-4.2-6.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-6.11">6xx:</dt>
          <dd style="margin-left: 3.0em" id="section-4.2-6.12"> 
        Global Failure -- the request cannot be fulfilled at any server.<a href="#section-4.2-6.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.2-7">
   The status codes are the same as described in HTTP <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>. In
   the same way as HTTP, Q4S applications are not required to
   understand the meaning of all registered status codes, though such
   understanding is obviously desirable. However, applications <span class="bcp14">MUST</span>
   understand the class of any status code, as indicated by the first
   digit, and treat any unrecognized response as being equivalent to
   the x00 status code of that class.<a href="#section-4.2-7" class="pilcrow">¶</a></p>
<p id="section-4.2-8">
   The Q4S-ALERT, Q4S-RECOVERY, and CANCEL requests do not have to be
   responded to. However, after receiving a Q4S-ALERT, Q4S-RECOVERY, or
   CANCEL request, the server <span class="bcp14">SHOULD</span> send a Q4S-ALERT, Q4S-RECOVERY,
   or CANCEL request to the client.<a href="#section-4.2-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-4.3">
<section id="section-4.3">
        <h3 id="name-header-fields">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-header-fields" class="section-name selfRef">Header Fields</a>
        </h3>
<p id="section-4.3-1">
   Q4S header fields are identical to HTTP header fields in both
   syntax and semantics.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">
   Some header fields only make sense in requests or responses. These
   are called request header fields and response header fields,
   respectively.  If a header field appears in a message that does not match
   its category (such as a request header field in a response), it
   <span class="bcp14">MUST</span> be ignored.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<div id="sec-4.3.1">
<section id="section-4.3.1">
          <h4 id="name-common-q4s-header-fields">
<a href="#section-4.3.1" class="section-number selfRef">4.3.1. </a><a href="#name-common-q4s-header-fields" class="section-name selfRef">Common Q4S Header Fields</a>
          </h4>
<p id="section-4.3.1-1"> These fields may appear in request and response messages.<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.3.1-2">
            <dt id="section-4.3.1-2.1">Session-Id:</dt>
            <dd style="margin-left: 3.0em" id="section-4.3.1-2.2">the value for this header field is the same sess-id
      used in SDP (embedded in the SDP "o=" line) and is assigned
      by the server. The messages without SDP <span class="bcp14">MUST</span> include this
      header field. If a message has an SDP body, this header field is
      optional. The method of sess-id allocation is up to the
      creating tool, but it is suggested that a UTC timestamp be
      used to ensure uniqueness.<a href="#section-4.3.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.3.1-2.3">Sequence-Number:</dt>
            <dd style="margin-left: 3.0em" id="section-4.3.1-2.4">sequential and cyclic positive integer
      number assigned to PING and BWIDTH messages and acknowledged
      in 200 OK responses.<a href="#section-4.3.1-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.3.1-2.5">Timestamp:</dt>
            <dd style="margin-left: 3.0em" id="section-4.3.1-2.6">this optional header field contains the system time
      (with the best possible accuracy). It indicates the time in
      which the PING request was sent. If this header field is present in
      PING messages, then the 200 OK response messages <span class="bcp14">MUST</span> include
      this value.<a href="#section-4.3.1-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.3.1-2.7">Stage:</dt>
            <dd style="margin-left: 3.0em" id="section-4.3.1-2.8">this is used in the client's READY requests and the server's
      200 OK responses during the Negotiation and Continuity phases
      in order to synchronize the initiation of the measurements.
      Example:  Stage: 0<a href="#section-4.3.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec-4.3.2">
<section id="section-4.3.2">
          <h4 id="name-specific-q4s-request-header">
<a href="#section-4.3.2" class="section-number selfRef">4.3.2. </a><a href="#name-specific-q4s-request-header" class="section-name selfRef">Specific Q4S Request Header Fields</a>
          </h4>
<p id="section-4.3.2-1">
   In addition to HTTP header fields, these are the specific Q4S
   request header fields:<a href="#section-4.3.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.3.2-2">
            <dt id="section-4.3.2-2.1">User-Agent:</dt>
            <dd style="margin-left: 3.0em" id="section-4.3.2-2.2">this header field contains information about the
      implementation of the user agent. This is for statistical
      purposes, the tracing of protocol violations, and the
      automated recognition of user agents for the sake of
      tailoring responses to avoid particular user agent
      limitations. User agents <span class="bcp14">SHOULD</span> include this field with
      requests. The field <span class="bcp14">MAY</span> contain multiple product tokens and
      comments identifying the agent and any sub-products that 
      form a significant part of the user agent. By convention, the
      product tokens are listed in order of their significance for
      identifying the application.<a href="#section-4.3.2-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.3.2-2.3">Signature:</dt>
            <dd style="margin-left: 3.0em" id="section-4.3.2-2.4">
              <p id="section-4.3.2-2.4.1">this header field contains a digital signature that can
      be used by the network, Actuator, or policy server to validate
      the SDP, preventing security attacks. The Signature is an
      optional header field generated by the server according to the 
      pre-agreed security policies between the Application Content
      Provider and the ISP. For example, a hash algorithm and
      encryption method such as SHA256 <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span> 
      and RSA <span>[<a href="#RFC8017" class="xref">RFC8017</a>]</span> based on the server certificate could be used.
      This certificate is supposed to be delivered by a
      Certification Authority (CA) or policy owner to the server.
      The signature is applied to the SDP body.<a href="#section-4.3.2-2.4.1" class="pilcrow">¶</a></p>
<div id="section-4.3.2-2.4.2">
<pre class="sourcecode lang-abnf">
      Signature= RSA ( SHA256 (&lt;sdp&gt;), &lt;certificate&gt; )
</pre><a href="#section-4.3.2-2.4.2" class="pilcrow">¶</a>
</div>
<p id="section-4.3.2-2.4.3">If the Signature header field is not present, other validation mechanisms
      <span class="bcp14">MAY</span> be implemented in order to provide assured quality with
      security and control.<a href="#section-4.3.2-2.4.3" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-4.3.2-2.5">Measurements:</dt>
            <dd style="margin-left: 3.0em" id="section-4.3.2-2.6">
              <p id="section-4.3.2-2.6.1">this header field carries the measurements of the
      quality parameters in PING and BWIDTH requests. The format
      is:<a href="#section-4.3.2-2.6.1" class="pilcrow">¶</a></p>
<div id="section-4.3.2-2.6.2">
<pre class="sourcecode lang-abnf">
  Measurements: "l=" " "|[0..9999] ", j=" " "|[0..9999] ", pl="
  " "|[0.00 .. 100.00] ", bw=" " "|[0..999999]
</pre><a href="#section-4.3.2-2.6.2" class="pilcrow">¶</a>
</div>
<p id="section-4.3.2-2.6.3">
      Where "l" stands for latency followed by the measured value
      (in milliseconds) or an empty space, "j" stands for jitter
      followed by the measured value (in milliseconds) or an empty
      space, "pl" stands for packet loss followed by the measured
      value (in percentage with two decimals) or an empty space,
      and "bw" stands for bandwidth followed by the measured value
      (in kbps) or an empty space.<a href="#section-4.3.2-2.6.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec-4.3.3">
<section id="section-4.3.3">
          <h4 id="name-specific-q4s-response-heade">
<a href="#section-4.3.3" class="section-number selfRef">4.3.3. </a><a href="#name-specific-q4s-response-heade" class="section-name selfRef">Specific Q4S Response Header Fields</a>
          </h4>
<span class="break"></span><dl class="dlParallel" id="section-4.3.3-1">
            <dt id="section-4.3.3-1.1">Expires:</dt>
            <dd style="margin-left: 3.0em" id="section-4.3.3-1.2">
              <p id="section-4.3.3-1.2.1">its purpose is to provide a sanity check and allow
      the server to close inactive sessions. If the client does not
      send a new request before the expiration time, the server <span class="bcp14">MAY</span>
      close the session. The value <span class="bcp14">MUST</span> be an integer, and the
      measurement units are milliseconds.<a href="#section-4.3.3-1.2.1" class="pilcrow">¶</a></p>
<p id="section-4.3.3-1.2.2">
 In order to keep the session open, the server <span class="bcp14">MUST</span> send a Q4S
      alert before the session expiration (Expires header field), with
      the same quality levels and an alert cause of "keep-alive".
      The purpose of this alert is to avoid TCP sockets, which were
      opened with READY message, from being closed, specially in
      NAT scenarios.<a href="#section-4.3.3-1.2.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="sec-4.4">
<section id="section-4.4">
        <h3 id="name-bodies">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-bodies" class="section-name selfRef">Bodies</a>
        </h3>
<p id="section-4.4-1">
   Requests, including new requests defined in extensions to this
   specification, <span class="bcp14">MAY</span> contain message bodies unless otherwise noted.
   The interpretation of the body depends on the request method.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">
   For response messages, the request method and the response status
   code determine the type and interpretation of any message body.
   All responses <span class="bcp14">MAY</span> include a body.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">
   The Internet media type of the message body <span class="bcp14">MUST</span> be given by the
   Content-Type header field.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<div id="sec-4.4.1">
<section id="section-4.4.1">
          <h4 id="name-encoding">
<a href="#section-4.4.1" class="section-number selfRef">4.4.1. </a><a href="#name-encoding" class="section-name selfRef">Encoding</a>
          </h4>
<p id="section-4.4.1-1">
   The body <span class="bcp14">MUST NOT</span> be compressed. This mechanism is valid for
   other protocols such as HTTP and SIP <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>, 
   but a compression/coding scheme will limit the way the request 
   is parsed to certain logical implementations, thus making
   the protocol concept more implementation dependent. In addition, the
   bandwidth calculation may not be valid if compression is used.
   Therefore, the HTTP Accept-Encoding request header field cannot be
   used in Q4S with values different from "identity", and if it is
   present in a request, the server <span class="bcp14">MUST</span> ignore it. In addition, the
   response header field Content-Encoding is optional, but if present,
   the unique permitted value is "identity".<a href="#section-4.4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.4.1-2">
   The body length in bytes <span class="bcp14">MUST</span> be provided by the Content-Length
   header field. The "chunked" transfer encoding of HTTP/1.1 <span class="bcp14">MUST NOT</span>
   be used for Q4S.<a href="#section-4.4.1-2" class="pilcrow">¶</a></p>
<aside id="section-4.4.1-3">
            <p id="section-4.4.1-3.1">Note: The chunked encoding modifies the body of a
   message in order to transfer it as a series of chunks, each one
   with its own size indicator.<a href="#section-4.4.1-3.1" class="pilcrow">¶</a></p>
</aside>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sec-5">
<section id="section-5">
      <h2 id="name-q4s-method-definitions">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-q4s-method-definitions" class="section-name selfRef">Q4S Method Definitions</a>
      </h2>
<p id="section-5-1">
   The Method token indicates the method to be performed on the
   resource identified by the Request-URI. The method is case sensitive.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="section-5-2">
<pre class="sourcecode lang-abnf">
 Method  = "BEGIN" | "READY" | "PING" | "BWIDTH" |
           "Q4S-ALERT" | "Q4S-RECOVERY" | "CANCEL" | extension-method

 extension-method = token
</pre><a href="#section-5-2" class="pilcrow">¶</a>
</div>
<p id="section-5-3">
   The list of methods allowed by a resource can be specified in an
   Allow header field <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>. The return code of the
   response always notifies the client when a method is currently
   allowed on a resource, since the set of allowed methods can change
   dynamically. Any server application <span class="bcp14">SHOULD</span> return the status code
   405 (Method Not Allowed) if the method is known, but not allowed
   for the requested resource, and 501 (Not Implemented) if the
   method is unrecognized or not implemented by the server.<a href="#section-5-3" class="pilcrow">¶</a></p>
<div id="sec-5.1">
<section id="section-5.1">
        <h3 id="name-begin">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-begin" class="section-name selfRef">BEGIN</a>
        </h3>
<p id="section-5.1-1">
   The BEGIN method requests information from a resource identified
   by a Q4S URI. The purpose of this method is to start the
   quality session.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">
   This method is used only during the Handshake phase to retrieve
   the SDP containing the sess-id and all quality and operation
   parameters for the desired application to run.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">
   When a BEGIN message is received by the server, any current
   quality session <span class="bcp14">MUST</span> be canceled, and a new session should be
   created.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<p id="section-5.1-4">
   The response to a Q4S BEGIN request is not cacheable.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-5.2">
<section id="section-5.2">
        <h3 id="name-ready">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-ready" class="section-name selfRef">READY</a>
        </h3>
<p id="section-5.2-1">
   The READY method is used to synchronize the starting time for the
   sending of PING and BWIDTH messages over UDP between clients and
   servers. Including the Stage header field in this method is mandatory.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
   This message is used only in Negotiation and Continuity phases,
   and only just before making a measurement. Otherwise (outside of this
   context), the server <span class="bcp14">MUST</span> ignore this method.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-5.3">
<section id="section-5.3">
        <h3 id="name-ping">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-ping" class="section-name selfRef">PING</a>
        </h3>
<p id="section-5.3-1">
   This message is used during the Negotiation and Continuity phases
   to measure the RTT and jitter of a session. The message <span class="bcp14">MUST</span> be
   sent only over UDP ports.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">
   The fundamental difference between the PING and BWIDTH requests is
   reflected in the different measurements achieved with them. PING
   is a short message, and it <span class="bcp14">MUST</span> be answered in order to measure RTT
   and jitter, whereas BWIDTH is a long message and <span class="bcp14">MUST NOT</span> be
   answered.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<p id="section-5.3-3">
   PING is a request method that can be originated by either the client or
   the server. The client <span class="bcp14">MUST</span> also answer the server PING messages,
   assuming a "server role" for these messages during the measurement
   process.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<p id="section-5.3-4">
   Including the Measurements header field in this method is mandatory, and
   provides updated measurements values for latency, jitter, and
   packet loss to the counterpart.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-5.4">
<section id="section-5.4">
        <h3 id="name-bwidth">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-bwidth" class="section-name selfRef">BWIDTH</a>
        </h3>
<p id="section-5.4-1">
   This message is used only during the Negotiation phase to measure
   the bandwidth and packet loss of a session. The message <span class="bcp14">MUST</span> be
   sent only over UDP ports.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">
   BWIDTH is a request method that can be originated by either the client
   or the server. Both client and server <span class="bcp14">MUST NOT</span> answer
   BWIDTH messages.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<p id="section-5.4-3">
   Including the Measurements header field in this method is mandatory and
   provides updated measurements values for bandwidth and packet loss
   to the counterpart.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-5.5">
<section id="section-5.5">
        <h3 id="name-q4s-alert">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-q4s-alert" class="section-name selfRef">Q4S-ALERT</a>
        </h3>
<p id="section-5.5-1">
   This is the request message that Q4S generates when the
   measurements indicate that quality constraints are being violated.
   It is used during the Negotiation and Continuity phases.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<p id="section-5.5-2">
   This informative message indicates that the user experience is
   being degraded and includes the details of the problem (bandwidth,
   jitter, packet loss measurements). The Q4S-ALERT message does not
   contain any detail on the actions to be taken, which depend on
   the agreements between all involved parties.<a href="#section-5.5-2" class="pilcrow">¶</a></p>
<p id="section-5.5-3">
   Unless there is an error condition, an answer to a Q4S-ALERT 
   request is optional and is formatted as a request Q4S-ALERT message. 
   If there is an error condition, then a response message is sent.
   The response to a Q4S-ALERT request is not cacheable.<a href="#section-5.5-3" class="pilcrow">¶</a></p>
<p id="section-5.5-4">
   This method <span class="bcp14">MUST</span> be initiated by the server in both alerting
   modes. In the Q4S-aware-network alerting mode, the Q4S-ALERT messages
   are sent by the server to the client, advising the
   network to react by itself. In the Reactive alerting mode, alert
   notifications are triggered by the server stack and sent to the
   Actuator (see <a href="#ref-reactive-scenario" class="xref">Figure 1</a>, "Reactive Scenario").<a href="#section-5.5-4" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-5.5-5">
<pre>
Client----q4s----SERVER STACK---&gt;ACTUATOR--&gt;APP OR POLICY SERVER
</pre><a href="#section-5.5-5" class="pilcrow">¶</a>
</div>
<p id="section-5.5-6">
   The way in which the server stack notifies the Actuator is
   implementation dependent, and the communication between the
   Actuator and the network policy server is defined by the protocol
   and API that the policy server implements.<a href="#section-5.5-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-5.6">
<section id="section-5.6">
        <h3 id="name-q4s-recovery">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-q4s-recovery" class="section-name selfRef">Q4S-RECOVERY</a>
        </h3>
<p id="section-5.6-1">
   This is the request message that Q4S generates when the
   measurements indicate that quality constraints, which had been violated,
   have been fulfilled during a period of time
   ("recovery-pause"). It is used during the Negotiation and Continuity
   phases.<a href="#section-5.6-1" class="pilcrow">¶</a></p>
<p id="section-5.6-2">
   This informative message indicates that the "qos-level" could be
   increased gradually until the initial "qos-level" is recovered (the
   "qos-level" established at the beginning of the session that was
   decreased during violation of constraints. See <a href="#sec-7.9" class="xref">Section 7.9</a>). 
   The Q4S-RECOVERY
   message does not contain any detail on the actions to be taken,
   which depends on the agreements between all involved parties.<a href="#section-5.6-2" class="pilcrow">¶</a></p>
<p id="section-5.6-3">
   The answer to a Q4S-RECOVERY request is formatted as a request
   Q4S-RECOVERY message. A Q4S-RECOVERY request <span class="bcp14">MUST NOT</span> be answered 
   with a response message unless there is an error condition. 
   The response to a Q4S-RECOVERY request is not cacheable.<a href="#section-5.6-3" class="pilcrow">¶</a></p>
<p id="section-5.6-4">
   Like the Q4S-ALERT message, the Q4S-RECOVERY method is always
   initiated by the server in both alerting modes. In the 
   Q4S-aware-network alerting mode, the Q4S-RECOVERY messages are sent by the
   server to the client, advising the network to react by
   itself. In the Reactive alerting mode, recovery notifications are
   triggered by the server stack and sent to the Actuator (see <a href="#ref-reactive-scenario" class="xref">Figure 1</a>, 
   "Reactive Scenario").<a href="#section-5.6-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-5.7">
<section id="section-5.7">
        <h3 id="name-cancel">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-cancel" class="section-name selfRef">CANCEL</a>
        </h3>
<p id="section-5.7-1">
   The purpose of the CANCEL message is the release of the Q4S 
   Session-Id and the possible resources assigned to the session. This
   message could be triggered by the Q4S stack or by the application
   using the stack (through an implementation-dependent API).<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<p id="section-5.7-2">
   In the same way as Q4S-ALERT, CANCEL must not be answered with a
   response message, but with an answer formatted as a request Q4S-CANCEL message.<a href="#section-5.7-2" class="pilcrow">¶</a></p>
<p id="section-5.7-3">
   In the Reactive scenario, the server stack <span class="bcp14">MUST</span> react to the Q4S
   CANCEL messages received from the client by forwarding a cancel
   notification to the Actuator, in order to release possible
   assigned resources for the session (at the application or at the policy
   server). The Actuator <span class="bcp14">MUST</span> answer the cancel notification with a
   cancel acknowledge towards the server stack, acknowledging the
   reception.<a href="#section-5.7-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-6">
<section id="section-6">
      <h2 id="name-response-codes">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-response-codes" class="section-name selfRef">Response Codes</a>
      </h2>
<p id="section-6-1">
   Q4S response codes are used for TCP and UDP. However, in UDP, only
   the response code 200 is used.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
   The receiver of an unknown response code must take a generic
   action for the received error group (1xx, 2xx, 3xx, 4xx, 5xx,
   6xx). In case of an unknown error group, the expected action should
   be the same as with the 6xx error group.<a href="#section-6-2" class="pilcrow">¶</a></p>
<div id="sec-6.1">
<section id="section-6.1">
        <h3 id="name-100-trying">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-100-trying" class="section-name selfRef">100 Trying</a>
        </h3>
<p id="section-6.1-1">
   This response indicates that the request has been received by the
   next-hop server and that some unspecified action is being taken on
   behalf of this request (for example, a database is being
   consulted). This response, like all other provisional responses,
   stops retransmissions of a Q4S-ALERT during the "alert-pause" time.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.2">
<section id="section-6.2">
        <h3 id="name-success-2xx">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-success-2xx" class="section-name selfRef">Success 2xx</a>
        </h3>
<p id="section-6.2-1">
   2xx responses give information about the success of a request.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<div id="sec-6.2.1">
<section id="section-6.2.1">
          <h4 id="name-200-ok">
<a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-200-ok" class="section-name selfRef">200 OK</a>
          </h4>
<p id="section-6.2.1-1">
   The request has succeeded.<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-6.3">
<section id="section-6.3">
        <h3 id="name-redirection-3xx">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-redirection-3xx" class="section-name selfRef">Redirection 3xx</a>
        </h3>
<p id="section-6.3-1">
   3xx responses give information about the user's new location or
   about alternative services that might be able to satisfy the
   request.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">
   The requesting client <span class="bcp14">SHOULD</span> retry the request at the new
   address(es) given by the Location header field.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.4">
<section id="section-6.4">
        <h3 id="name-request-failure-4xx">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-request-failure-4xx" class="section-name selfRef">Request Failure 4xx</a>
        </h3>
<p id="section-6.4-1">
   4xx responses are definite failure responses from a particular
   server. The client <span class="bcp14">SHOULD NOT</span> retry the same request without
   modification (for example, adding appropriate header fields or SDP
   values). However, the same request to a different server might be
   successful.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
<div id="sec-6.4.1">
<section id="section-6.4.1">
          <h4 id="name-400-bad-request">
<a href="#section-6.4.1" class="section-number selfRef">6.4.1. </a><a href="#name-400-bad-request" class="section-name selfRef">400 Bad Request</a>
          </h4>
<p id="section-6.4.1-1">
   The request could not be understood due to malformed syntax. The
   Reason-Phrase <span class="bcp14">SHOULD</span> identify the syntax problem in more detail,
   for example, "Missing Sequence-Number header field".<a href="#section-6.4.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.4.2">
<section id="section-6.4.2">
          <h4 id="name-404-not-found">
<a href="#section-6.4.2" class="section-number selfRef">6.4.2. </a><a href="#name-404-not-found" class="section-name selfRef">404 Not Found</a>
          </h4>
<p id="section-6.4.2-1">
   The server has definitive information that the user does not exist
   at the domain specified in the Request-URI. This status is also
   returned if the domain in the Request-URI does not match any of
   the domains handled by the recipient of the request.<a href="#section-6.4.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.4.3">
<section id="section-6.4.3">
          <h4 id="name-405-method-not-allowed">
<a href="#section-6.4.3" class="section-number selfRef">6.4.3. </a><a href="#name-405-method-not-allowed" class="section-name selfRef">405 Method Not Allowed</a>
          </h4>
<p id="section-6.4.3-1">
   The method specified in the Request-Line is understood, but not
   allowed for the address identified by the Request-URI.<a href="#section-6.4.3-1" class="pilcrow">¶</a></p>
<p id="section-6.4.3-2">
   The response <span class="bcp14">MUST</span> include an Allow header field containing a list
   of valid methods for the indicated address.<a href="#section-6.4.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.4.4">
<section id="section-6.4.4">
          <h4 id="name-406-not-acceptable">
<a href="#section-6.4.4" class="section-number selfRef">6.4.4. </a><a href="#name-406-not-acceptable" class="section-name selfRef">406 Not Acceptable</a>
          </h4>
<p id="section-6.4.4-1">
   The resource identified by the request is only able to generate
   response entities that have content characteristics that are not acceptable
   according to the Accept header field sent in the request.<a href="#section-6.4.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.4.5">
<section id="section-6.4.5">
          <h4 id="name-408-request-timeout">
<a href="#section-6.4.5" class="section-number selfRef">6.4.5. </a><a href="#name-408-request-timeout" class="section-name selfRef">408 Request Timeout</a>
          </h4>
<p id="section-6.4.5-1">
   The server could not produce a response within a suitable amount
   of time, and the client <span class="bcp14">MAY</span> repeat the request without
   modifications at any later time.<a href="#section-6.4.5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.4.6">
<section id="section-6.4.6">
          <h4 id="name-413-request-entity-too-larg">
<a href="#section-6.4.6" class="section-number selfRef">6.4.6. </a><a href="#name-413-request-entity-too-larg" class="section-name selfRef">413 Request Entity Too Large</a>
          </h4>
<p id="section-6.4.6-1">
   The server is refusing to process a request because the request
   entity-body is larger than the one that the server is willing or
   able to process. The server <span class="bcp14">MAY</span> close the connection to prevent
   the client from continuing the request.<a href="#section-6.4.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.4.7">
<section id="section-6.4.7">
          <h4 id="name-414-request-uri-too-long">
<a href="#section-6.4.7" class="section-number selfRef">6.4.7. </a><a href="#name-414-request-uri-too-long" class="section-name selfRef">414 Request-URI Too Long</a>
          </h4>
<p id="section-6.4.7-1">
   The server is refusing to process the request because the Request-URI is longer than the one that the server accepts.<a href="#section-6.4.7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.4.8">
<section id="section-6.4.8">
          <h4 id="name-415-unsupported-media-type">
<a href="#section-6.4.8" class="section-number selfRef">6.4.8. </a><a href="#name-415-unsupported-media-type" class="section-name selfRef">415 Unsupported Media Type</a>
          </h4>
<p id="section-6.4.8-1">
   The server is refusing to process the request because the message
   body of the request is in a format not supported by the server for
   the requested method. The server <span class="bcp14">MUST</span> return a list of acceptable
   formats using the Accept, Accept-Encoding, or Accept-Language
   header field, depending on the specific problem with the content.<a href="#section-6.4.8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.4.9">
<section id="section-6.4.9">
          <h4 id="name-416-unsupported-uri-scheme">
<a href="#section-6.4.9" class="section-number selfRef">6.4.9. </a><a href="#name-416-unsupported-uri-scheme" class="section-name selfRef">416 Unsupported URI Scheme</a>
          </h4>
<p id="section-6.4.9-1">
   The server cannot process the request because the scheme of the
   URI in the Request-URI is unknown to the server.<a href="#section-6.4.9-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-6.5">
<section id="section-6.5">
        <h3 id="name-server-failure-5xx">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-server-failure-5xx" class="section-name selfRef">Server Failure 5xx</a>
        </h3>
<p id="section-6.5-1">
   5xx responses are failure responses given when a server itself is
   having trouble.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<div id="sec-6.5.1">
<section id="section-6.5.1">
          <h4 id="name-500-server-internal-error">
<a href="#section-6.5.1" class="section-number selfRef">6.5.1. </a><a href="#name-500-server-internal-error" class="section-name selfRef">500 Server Internal Error</a>
          </h4>
<p id="section-6.5.1-1">
   The server encountered an unexpected condition that prevented it
   from fulfilling the request. The client <span class="bcp14">MAY</span> display the specific
   error condition and <span class="bcp14">MAY</span> retry the request after several seconds.<a href="#section-6.5.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.5.2">
<section id="section-6.5.2">
          <h4 id="name-501-not-implemented">
<a href="#section-6.5.2" class="section-number selfRef">6.5.2. </a><a href="#name-501-not-implemented" class="section-name selfRef">501 Not Implemented</a>
          </h4>
<p id="section-6.5.2-1">
   The server does not support the functionality required to fulfill
   the request. This is the appropriate response when a server does
   not recognize the request method, and it is not capable of
   supporting it for any user.<a href="#section-6.5.2-1" class="pilcrow">¶</a></p>
<p id="section-6.5.2-2">
   Note that a 405 (Method Not Allowed) is sent when the server
   recognizes the request method, but that method is not allowed or
   supported.<a href="#section-6.5.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.5.3">
<section id="section-6.5.3">
          <h4 id="name-503-service-unavailable">
<a href="#section-6.5.3" class="section-number selfRef">6.5.3. </a><a href="#name-503-service-unavailable" class="section-name selfRef">503 Service Unavailable</a>
          </h4>
<p id="section-6.5.3-1">
   The server is temporarily unable to process the request due to a
   temporary overloading or maintenance of the server. The server <span class="bcp14">MAY</span>
   indicate when the client should retry the request in a Retry-After
   header field. If no Retry-After is given, the client <span class="bcp14">MUST</span> act as
   if it had received a 500 (Server Internal Error) response.<a href="#section-6.5.3-1" class="pilcrow">¶</a></p>
<p id="section-6.5.3-2">
   A client receiving a 503 (Service Unavailable) <span class="bcp14">SHOULD</span> attempt to
   forward the request to an alternate server. It <span class="bcp14">SHOULD NOT</span> forward
   any other requests to that server for the duration specified in
   the Retry-After header field, if present.<a href="#section-6.5.3-2" class="pilcrow">¶</a></p>
<p id="section-6.5.3-3">
   Servers <span class="bcp14">MAY</span> refuse the connection or drop the request instead of
   responding with 503 (Service Unavailable).<a href="#section-6.5.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.5.4">
<section id="section-6.5.4">
          <h4 id="name-504-server-time-out">
<a href="#section-6.5.4" class="section-number selfRef">6.5.4. </a><a href="#name-504-server-time-out" class="section-name selfRef">504 Server Time-Out</a>
          </h4>
<p id="section-6.5.4-1">
   The server did not receive a timely response from an external
   server it accessed in attempting to process the request.<a href="#section-6.5.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.5.5">
<section id="section-6.5.5">
          <h4 id="name-505-version-not-supported">
<a href="#section-6.5.5" class="section-number selfRef">6.5.5. </a><a href="#name-505-version-not-supported" class="section-name selfRef">505 Version Not Supported</a>
          </h4>
<p id="section-6.5.5-1">
   The server does not support, or refuses to support, the Q4S
   protocol version that was used in the request. The server is
   indicating that it is unable or unwilling to complete the request
   using the same major version as the client, other than with this
   error message.<a href="#section-6.5.5-1" class="pilcrow">¶</a></p>
<p id="section-6.5.5-2">
   In the case that the Q4S version is not supported, this error may be
   sent by the server in the Handshake phase just after receiving the
   first BEGIN message from client.<a href="#section-6.5.5-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.5.6">
<section id="section-6.5.6">
          <h4 id="name-513-message-too-large">
<a href="#section-6.5.6" class="section-number selfRef">6.5.6. </a><a href="#name-513-message-too-large" class="section-name selfRef">513 Message Too Large</a>
          </h4>
<p id="section-6.5.6-1">
   The server was unable to process the request because the message
   length exceeded its capabilities.<a href="#section-6.5.6-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-6.6">
<section id="section-6.6">
        <h3 id="name-global-failures-6xx">
<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-global-failures-6xx" class="section-name selfRef">Global Failures 6xx</a>
        </h3>
<p id="section-6.6-1">
   6xx responses indicate that a server has definitive information
   about a particular policy not satisfied for processing the
   request.<a href="#section-6.6-1" class="pilcrow">¶</a></p>
<div id="sec-6.6.1">
<section id="section-6.6.1">
          <h4 id="name-600-session-does-not-exist">
<a href="#section-6.6.1" class="section-number selfRef">6.6.1. </a><a href="#name-600-session-does-not-exist" class="section-name selfRef">600 Session Does Not Exist</a>
          </h4>
<p id="section-6.6.1-1">
   The Session-Id is not valid.<a href="#section-6.6.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.6.2">
<section id="section-6.6.2">
          <h4 id="name-601-quality-level-not-allow">
<a href="#section-6.6.2" class="section-number selfRef">6.6.2. </a><a href="#name-601-quality-level-not-allow" class="section-name selfRef">601 Quality Level Not Allowed</a>
          </h4>
<p id="section-6.6.2-1">
   The "qos-level" requested is not allowed for the client/server pair.<a href="#section-6.6.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.6.3">
<section id="section-6.6.3">
          <h4 id="name-603-session-not-allowed">
<a href="#section-6.6.3" class="section-number selfRef">6.6.3. </a><a href="#name-603-session-not-allowed" class="section-name selfRef">603 Session Not Allowed</a>
          </h4>
<p id="section-6.6.3-1">
   The session is not allowed due to some policy (the number of sessions
   allowed for the server is exceeded, or the time band of the Q4S-ALERT 
   is not allowed for the client/server pair, etc.).<a href="#section-6.6.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-6.6.4">
<section id="section-6.6.4">
          <h4 id="name-604-authorization-not-allow">
<a href="#section-6.6.4" class="section-number selfRef">6.6.4. </a><a href="#name-604-authorization-not-allow" class="section-name selfRef">604 Authorization Not Allowed</a>
          </h4>
<p id="section-6.6.4-1">
   The policy server does not authorize the Q4S-ALERT quality session
   improvement operation due to an internal or external reason.<a href="#section-6.6.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sec-7">
<section id="section-7">
      <h2 id="name-protocol">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-protocol" class="section-name selfRef">Protocol</a>
      </h2>
<p id="section-7-1">
   This section describes the measurement procedures, the SDP
   structure of the Q4S messages, the different Q4S protocol phases,
   and the messages exchanged in them.<a href="#section-7-1" class="pilcrow">¶</a></p>
<div id="sec-7.1">
<section id="section-7.1">
        <h3 id="name-protocol-phases">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-protocol-phases" class="section-name selfRef">Protocol Phases</a>
        </h3>
<p id="section-7.1-1">
   All elements of the IP network contribute to quality in
   terms of latency, jitter, bandwidth, and packet loss. All these
   elements have their own quality policies in terms of priorities,
   traffic mode, etc., and each element has its own way to manage the
   quality. The purpose of a quality connection is to establish 
   end-to-end communication with enough quality for the application
   to function flawlessly.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">
   To monitor quality constraints of the application, four phases are
   defined and can be seen in <a href="#ref-session-lifetime-phases" class="xref">Figure 5</a>:<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<span id="name-session-lifetime-phases"></span><div id="ref-session-lifetime-phases">
<figure id="figure-5">
          <div class="artwork art-text alignLeft" id="section-7.1-3.1">
<pre>
+---------------------------------------------------------------+
|                                                               |
|                                                               |
| Handshake ---&gt; Negotiation -+--&gt; Continuity ----&gt; Termination |
|                   A         |    (app start) |    (app end)   |
|                   |         V        A       V       A        |
|                   |     violated     |     violated  |        |
|                   |    constraints   |   constraints |        |
|                   |      |     |     |_______|   ____|        |
|                   |      |     |     +-------+       |        |
|                   |      |     |                     |        |
|                   +------+     +---------------------+        |
|                                                               |
+---------------------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-session-lifetime-phases" class="selfRef">Session Lifetime Phases</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-7.1-4">
          <dt id="section-7.1-4.1">Handshake phase:</dt>
          <dd id="section-7.1-4.2">in which the server is contacted by the
      client, and in the answer message, the quality constraints for
      the application are communicated in the embedded SDP.<a href="#section-7.1-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-4.3">Negotiation phase:</dt>
          <dd id="section-7.1-4.4">in which the quality of the connection is
      measured in both directions (latency, jitter, bandwidth, and
      packet loss), and Q4S messages may be sent in order to alert
      if the measured quality does not meet the constraints. This
      phase is iterative until quality constraints are reached, or
      the session is canceled after a number of measurement cycles
      with consistent violation of the quality constraints. The
      number of measurement cycles executed depends on the "qos-level", 
      which is incremented in each cycle until a maximum "qos-level" value 
      is reached. Just after reaching the quality
      requirements, Q4S provides a simple optional mechanism using
      HTTP to start the application.<a href="#section-7.1-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-4.5">Continuity phase:</dt>
          <dd id="section-7.1-4.6">in which quality is continuously measured.
      In this phase, the measurements <span class="bcp14">MUST</span> avoid disturbing the
      application by consuming network resources. If quality
      constraints are not met, the server stack will notify the
      Actuator with an alert notification. If later the quality
      improves, the server stack will notify the Actuator, in this
      case with a recovery notification. After several alert
      notifications with no quality improvements, the Q4S stack
      <span class="bcp14">SHOULD</span> move to the Termination phase.<a href="#section-7.1-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-4.7">Termination phase:</dt>
          <dd id="section-7.1-4.8">in which the Q4S session is terminated.
      The application may be closed also or may not start.<a href="#section-7.1-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec-7.2">
<section id="section-7.2">
        <h3 id="name-sdp-structure">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-sdp-structure" class="section-name selfRef">SDP Structure</a>
        </h3>
<p id="section-7.2-1">
   The original goal of SDP was to announce necessary information for
   the participants and multicast MBONE (Multicast Backbone)
   applications. Right now, its use has been extended to the
   announcement and the negotiation of multimedia sessions. The
   purpose of Q4S is not to establish media stream sessions, but to
   monitor a quality connection. This connection may be later used to
   establish any type of session including media sessions; Q4S does
   not impose any conditions on the type of communication requiring
   quality parameters.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">
   SDP will be used by Q4S to exchange quality constraints and will
   therefore always have all the media descriptions ("m=") set to zero.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
<p id="section-7.2-3">
   The SDP embedded in the messages is the container of the quality
   parameters. As these may vary depending on the direction of the
   communication (to and from the client), all quality parameters need
   to specify the uplink and downlink values: &lt;uplink&gt; / &lt;downlink&gt;
   (see <a href="#sec-7.5.3" class="xref">Section 7.5.3</a> for an example).
   When one or both of these values are empty, it <span class="bcp14">MUST</span> be understood
   as needing no constraint on that parameter and/or that direction.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
<p id="section-7.2-4">
   The uplink direction <span class="bcp14">MUST</span> be considered as being the communication
   from the client to the server. The downlink direction <span class="bcp14">MUST</span> be
   considered as being the communication from the server to the
   client.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
<p id="section-7.2-5">
   The SDP information can comprise all or some of the following
   parameters shown in the example below. This is an example of an
   SDP message used by Q4S included in the 200 OK response to a Q4S
   BEGIN request.<a href="#section-7.2-5" class="pilcrow">¶</a></p>
<div id="section-7.2-6">
<pre class="sourcecode lang-sdp">
v=0
o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33
s=Q4S
i=Q4S parameters
t=0 0
a=qos-level:0/0
a=alerting-mode:Reactive
a=alert-pause:5000
a=public-address:client IP4 198.51.100.51
a=public-address:server IP4 198.51.100.58
a=measurement:procedure default(50/50,75/75,5000,40/80,100/256)
a=latency:40
a=jitter:10/10
a=bandwidth:20/6000
a=packetloss:0.50/0.50
a=flow:app clientListeningPort TCP/10000-20000
a=flow:app clientListeningPort UDP/15000-18000
a=flow:app serverListeningPort TCP/56000
a=flow:app serverListeningPort UDP/56000
a=flow:q4s clientListeningPort UDP/55000
a=flow:q4s clientListeningPort TCP/55001
a=flow:q4s serverListeningPort UDP/56000
a=flow:q4s serverListeningPort TCP/56001
</pre><a href="#section-7.2-6" class="pilcrow">¶</a>
</div>
<p id="section-7.2-7">
   As quality constraints may be changed by applications at any time
   during the Q4S session lifetime, any Q4S 200 OK response sent by
   the server to the client in the Negotiation and Continuity phases
   could also include an SDP body with the new quality requirements
   stated by the applications from then on. Therefore, in response to
   any PING request sent by the client to the server, the server
   could send a Q4S 200 OK with an embedded SDP message that
   specifies new quality constraints requested by the application.<a href="#section-7.2-7" class="pilcrow">¶</a></p>
<div id="sec-7.2.1">
<section id="section-7.2.1">
          <h4 id="name-qos-level-attribute">
<a href="#section-7.2.1" class="section-number selfRef">7.2.1. </a><a href="#name-qos-level-attribute" class="section-name selfRef">"qos-level" Attribute</a>
          </h4>
<p id="section-7.2.1-1">
   The "qos-level" attribute contains the QoS level for uplink and
   downlink. Default values are 0 for both directions. The meaning of
   each level is out of scope of Q4S, but a higher level <span class="bcp14">SHOULD</span>
   correspond to a better service quality.<a href="#section-7.2.1-1" class="pilcrow">¶</a></p>
<p id="section-7.2.1-2">
   Appropriate attribute values: [0..9] "/" [0..9]<a href="#section-7.2.1-2" class="pilcrow">¶</a></p>
<p id="section-7.2.1-3">
   The "qos-level" attribute may be changed during the session
   lifetime, raising or lowering the value as necessary following the
   network measurements and the application needs.<a href="#section-7.2.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.2.2">
<section id="section-7.2.2">
          <h4 id="name-alerting-mode-attribute">
<a href="#section-7.2.2" class="section-number selfRef">7.2.2. </a><a href="#name-alerting-mode-attribute" class="section-name selfRef">"alerting-mode" Attribute</a>
          </h4>
<p id="section-7.2.2-1">
   The "alerting-mode" attribute specifies the player in charge of
   triggering Q4S alerts in the case of constraint violation. There are
   two possible values:<a href="#section-7.2.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2.2-2">
   Appropriate attribute values: &lt;"Q4S-aware-network"|"Reactive"&gt;<a href="#section-7.2.2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.2.2-3">
            <dt id="section-7.2.2-3.1">Q4S-aware-network:</dt>
            <dd style="margin-left: 3.0em" id="section-7.2.2-3.2">Q4S-ALERT messages are triggered by the
 server to the client. In this case, the network is supposed to
        be Q4S aware, and reacts by itself to these alerts.<a href="#section-7.2.2-3.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.2.2-3.3"> Reactive:</dt>
            <dd style="margin-left: 3.0em" id="section-7.2.2-3.4">alert notifications are sent by the server stack to
 the Actuator. In this case, the network is not Q4S aware, and a
      specific node (Actuator) is in charge of triggering tuning
      mechanisms, either on the network or in the application.<a href="#section-7.2.2-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-7.2.2-4">
   The "alerting-mode" attribute is optional, and if not present,
   Reactive alerting mode is assumed.<a href="#section-7.2.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.2.3">
<section id="section-7.2.3">
          <h4 id="name-alert-pause-attribute">
<a href="#section-7.2.3" class="section-number selfRef">7.2.3. </a><a href="#name-alert-pause-attribute" class="section-name selfRef">"alert-pause" Attribute</a>
          </h4>
<p id="section-7.2.3-1">
   In the Q4S-aware-network scenario, the "alert-pause" attribute
   specifies the amount of time (in milliseconds) the server waits
   between consecutive Q4S-ALERT messages sent to the client. In the
   Reactive scenario, the "alert-pause" attribute specifies the
   amount of time (in milliseconds) the server stack waits between
   consecutive alert notifications sent to the Actuator. Measurements
   are not stopped in Negotiation or Continuity phases during this
   period of time, but no Q4S-ALERT messages or alert notifications
   are fired, even with violated quality constraints, allowing for either
   network reconfigurations or application adjustments.<a href="#section-7.2.3-1" class="pilcrow">¶</a></p>
<p id="section-7.2.3-2">
   Appropriate attribute values: [0..60000]<a href="#section-7.2.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.2.4">
<section id="section-7.2.4">
          <h4 id="name-recovery-pause-attribute">
<a href="#section-7.2.4" class="section-number selfRef">7.2.4. </a><a href="#name-recovery-pause-attribute" class="section-name selfRef">"recovery-pause" Attribute</a>
          </h4>
<p id="section-7.2.4-1">
   In the Q4S-aware-network scenario, the "recovery-pause" attribute
   specifies the amount of time (in milliseconds) the server waits
   for initiating the "qos-level" recovery process. Once the recovery
   process has started, the "recovery-pause" attribute also states
   the amount of time (in milliseconds) between consecutive Q4S-RECOVERY 
   messages sent by the server to the client (in the Q4S-aware-network scenario) or between recovery notifications sent by
   the server stack to the Actuator (in the Reactive scenario).<a href="#section-7.2.4-1" class="pilcrow">¶</a></p>
<p id="section-7.2.4-2">
   Appropriate attribute values: [0..60000]<a href="#section-7.2.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.2.5">
<section id="section-7.2.5">
          <h4 id="name-public-address-attributes">
<a href="#section-7.2.5" class="section-number selfRef">7.2.5. </a><a href="#name-public-address-attributes" class="section-name selfRef">"public-address" Attributes</a>
          </h4>
<p id="section-7.2.5-1">
   This attribute contains the public IP address of the client and
   the server. The server fills these attributes with its own public
   IP address and the public IP address of the first message received
   from the client in the Handshake phase.<a href="#section-7.2.5-1" class="pilcrow">¶</a></p>
<p id="section-7.2.5-2">
   The purpose of these attributes is to make available the
   addressing information to the network policy server or other external
   entities in charge of processing Q4S-ALERT messages.<a href="#section-7.2.5-2" class="pilcrow">¶</a></p>
<p id="section-7.2.5-3">
   Appropriate attribute values: &lt;"client"|"server"&gt; &lt;"IP4"|"IP6"&gt;
   &lt;value of IP address&gt;<a href="#section-7.2.5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.2.6">
<section id="section-7.2.6">
          <h4 id="name-latency-attribute">
<a href="#section-7.2.6" class="section-number selfRef">7.2.6. </a><a href="#name-latency-attribute" class="section-name selfRef">"latency" Attribute</a>
          </h4>
<p id="section-7.2.6-1">
   The maximum latency (considered equal for uplink and downlink)
   tolerance is specified in the "latency" attribute, expressed in
   milliseconds. In the Q4S-aware-network scenario, if the latency
   constraints are not met, a Q4S-ALERT method will be sent to the
   client. In the Reactive scenario, if the latency constraints are
   not met, an alert notification will be sent to the Actuator. If
   the "latency" attribute is not present or has a 0 value, no
   latency constraints need to be met, and no measurements <span class="bcp14">MAY</span> be
   taken.<a href="#section-7.2.6-1" class="pilcrow">¶</a></p>
<p id="section-7.2.6-2">
   Appropriate attribute values: [0..9999]<a href="#section-7.2.6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.2.7">
<section id="section-7.2.7">
          <h4 id="name-jitter-attribute">
<a href="#section-7.2.7" class="section-number selfRef">7.2.7. </a><a href="#name-jitter-attribute" class="section-name selfRef">"jitter" Attribute</a>
          </h4>
<p id="section-7.2.7-1">
   The maximum uplink and downlink jitter tolerance is specified in
   the "jitter" attribute, expressed in milliseconds. In the Q4S-aware-network scenario, if the jitter constraints are not met, a
   Q4S-ALERT method will be sent to the client. In the Reactive
   scenario, if the latency constraints are not met, an alert
   notification will be sent to the Actuator. If the "jitter" attribute
   is not present or has a 0 value, no jitter constraints need to be
   met, and no measurements <span class="bcp14">MAY</span> be taken.<a href="#section-7.2.7-1" class="pilcrow">¶</a></p>
<p id="section-7.2.7-2">
   Appropriate attribute values: [0..9999] "/" [0..9999]<a href="#section-7.2.7-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.2.8">
<section id="section-7.2.8">
          <h4 id="name-bandwidth-attribute">
<a href="#section-7.2.8" class="section-number selfRef">7.2.8. </a><a href="#name-bandwidth-attribute" class="section-name selfRef">"bandwidth" Attribute</a>
          </h4>
<p id="section-7.2.8-1">
   The minimum uplink and downlink bandwidth is specified in the
   "bandwidth" attribute, expressed in kbps. In the Q4S-aware-network
   scenario, if the bandwidth constraints are not met, a Q4S-ALERT
   method will be sent to the client. In the Reactive scenario, an
   alert notification will be sent to the Actuator. If the "bandwidth"
   attribute is not present or has a 0 value, no bandwidth
   constraints need to be met, and no measurements <span class="bcp14">MAY</span> be taken.<a href="#section-7.2.8-1" class="pilcrow">¶</a></p>
<p id="section-7.2.8-2">
   Appropriate attribute values: [0..99999] "/" [0..99999]<a href="#section-7.2.8-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.2.9">
<section id="section-7.2.9">
          <h4 id="name-packetloss-attribute">
<a href="#section-7.2.9" class="section-number selfRef">7.2.9. </a><a href="#name-packetloss-attribute" class="section-name selfRef">"packetloss" Attribute</a>
          </h4>
<p id="section-7.2.9-1">
   The maximum uplink and downlink packet loss tolerance is
   specified in the "packetloss" attribute expressed in percentage
   (two decimal accuracy). In the Q4S-aware-network scenario, if the
   packetloss constraints are not met, a Q4S-ALERT method will be
   sent to the client. In the Reactive scenario, an alert
   notification will be sent to the Actuator. If the "packetloss"
   attribute is not present or has a 0 value, no packet loss
   constraints need to be met, and no measurements <span class="bcp14">MAY</span> be taken.<a href="#section-7.2.9-1" class="pilcrow">¶</a></p>
<p id="section-7.2.9-2">
   Appropriate attribute values: [0.00 ..100.00] "/"[0.00 ..100.00]<a href="#section-7.2.9-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.2.10">
<section id="section-7.2.10">
          <h4 id="name-flow-attributes">
<a href="#section-7.2.10" class="section-number selfRef">7.2.10. </a><a href="#name-flow-attributes" class="section-name selfRef">"flow" Attributes</a>
          </h4>
<p id="section-7.2.10-1">
   These attributes specify the flows (protocol, destination
   IP/ports) of data over TCP and UDP ports to be used in uplink and
   downlink communications.<a href="#section-7.2.10-1" class="pilcrow">¶</a></p>
<p id="section-7.2.10-2">
   Several "flow" attributes can be defined. These flows identify the
   listening port (client or server), the protocol (TCP <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span> 
   or UDP <span>[<a href="#RFC0768" class="xref">RFC0768</a>]</span>) 
   with the range of ports that are going
   to be used by the application and, of course, by the Q4S protocol
   (for quality measurements). All defined flows ("app" and "q4s") will
   be considered within the same quality profile, which is determined
   by the "qos-level" attribute in each direction. This allows us to
   assume that measurements on "q4s" flows are the same as experienced by
   the application, which is using "app" flows.<a href="#section-7.2.10-2" class="pilcrow">¶</a></p>
<p id="section-7.2.10-3">
   During Negotiation and Continuity phases, the specified Q4S ports
   in the "flow:q4s" attributes of SDP will be used for Q4S messages.<a href="#section-7.2.10-3" class="pilcrow">¶</a></p>
<p id="section-7.2.10-4">
   The Q4S flows comprise two UDP flows and two TCP flows (one uplink
   and one downlink for each one), whereas application traffic <span class="bcp14">MAY</span>
   consist of many flows, depending on its nature. The Handshake
   phase takes place through the Q4S Contact URI, using the standard
   Q4S TCP port. However, the Negotiation and Continuity phases will
   take place on the Q4S ports (UDP and TCP) specified in
   the SDP.<a href="#section-7.2.10-4" class="pilcrow">¶</a></p>
<p id="section-7.2.10-5">
   The "clientListeningPort" is a port on which the client listens
   for server requests and <span class="bcp14">MUST</span> be used as the origin port of client
   responses. The "serverListeningPort" is a port on which the server is
   listening for incoming messages from the client. The origin port
   of server responses may be different than the "serverListeningPort"
   value.<a href="#section-7.2.10-5" class="pilcrow">¶</a></p>
<p id="section-7.2.10-6">
   If "clientListeningPort" is zero ("a=flow:q4s clientListeningPort
   TCP/0"), the client <span class="bcp14">MAY</span> choose one randomly per OS standard
   rules. Client ports inside the SDP must always be matched against
   actual received port values on the server side in order to deal
   with NAT/NAPT devices. If a zero value or incorrect value is
   present, the server must set the value to the received origin port in
   the next message with SDP (200 OK, ALERT, and CANCEL messages).<a href="#section-7.2.10-6" class="pilcrow">¶</a></p>
<div id="section-7.2.10-7">
<pre class="sourcecode lang-abnf">
Attribute values:
   &lt;"q4s"|"app"&gt; &lt;"serverListeningPort"|"clientListeningPort"&gt;
&lt;"UDP"|"TCP"&gt; &lt;0..65535&gt; [ "-" [0..65535]]
</pre><a href="#section-7.2.10-7" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="sec-7.2.11">
<section id="section-7.2.11">
          <h4 id="name-measurement-attributes">
<a href="#section-7.2.11" class="section-number selfRef">7.2.11. </a><a href="#name-measurement-attributes" class="section-name selfRef">"measurement" Attributes</a>
          </h4>
<p id="section-7.2.11-1">
   These attributes contain the measurement procedure and the results
   of the quality measurements.<a href="#section-7.2.11-1" class="pilcrow">¶</a></p>
<p id="section-7.2.11-2">
   Measurement parameters are included using the session attribute
   "measurement". The first measurement parameter is the procedure.
   Q4S provides a "default" procedure for measurements, but others
   like RTP/RTCP might be used and defined later. This document will
   only define and explain the "default" procedure.<a href="#section-7.2.11-2" class="pilcrow">¶</a></p>
<p id="section-7.2.11-3">
   In the initial client request, a set of measurement procedures can
   be sent to the server for negotiation. One measurement procedure
   line <span class="bcp14">MUST</span> be included in the SDP message for each proposed method.
   The server <span class="bcp14">MUST</span> answer with only one line with the chosen
   procedure.<a href="#section-7.2.11-3" class="pilcrow">¶</a></p>
<p id="section-7.2.11-4">
   For each procedure, a set of values of parameters separated by ","
   can be included in the same attribute line. The amount and type of
   parameters depends on the procedure type.<a href="#section-7.2.11-4" class="pilcrow">¶</a></p>
<p id="section-7.2.11-5">
   In the following example, the "default" procedure type is chosen:<a href="#section-7.2.11-5" class="pilcrow">¶</a></p>
<div id="section-7.2.11-6">
<pre class="sourcecode lang-sdp">
   a=measurement:procedure default(50/50,75/75,5000,40/80,100/256)
</pre><a href="#section-7.2.11-6" class="pilcrow">¶</a>
</div>
<p id="section-7.2.11-7">
   In the "default" procedure, the meaning of these parameters is
the following:<a href="#section-7.2.11-7" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.2.11-8.1">The first parameter is the interval of time (in milliseconds)
      between PING requests during the Negotiation phase. Uplink
      and downlink values from the client's point of view are
      separated by "/". This allows different responsiveness
      values depending on the control resources used in each
      direction.<a href="#section-7.2.11-8.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-7.2.11-8.2">The second parameter is the time interval (in milliseconds)
      between PING requests during the Continuity phase. Uplink and
      downlink values are separated by "/". This allows two
      different responsiveness values depending on the control
      resources used in each direction.<a href="#section-7.2.11-8.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-7.2.11-8.3">The third parameter is the time interval to be used to
      measure bandwidth during the Negotiation phase.<a href="#section-7.2.11-8.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-7.2.11-8.4">The fourth parameter indicates the window size for jitter and
      latency calculations. Uplink and downlink values are
      separated by "/".<a href="#section-7.2.11-8.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-7.2.11-8.5">The fifth parameter indicates the window size for packet loss
      calculations. Uplink and downlink values are separated by
      "/".<a href="#section-7.2.11-8.5" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-7.2.11-9">
   There are four more "measurement" attributes:<a href="#section-7.2.11-9" class="pilcrow">¶</a></p>
<div id="section-7.2.11-10">
<pre class="sourcecode lang-sdp">
a=measurement:latency 45
a=measurement:jitter 3/12
a=measurement:bandwidth 200/9800
a=measurement:packetloss 0.00/1.00
</pre><a href="#section-7.2.11-10" class="pilcrow">¶</a>
</div>
<p id="section-7.2.11-11">
   The "measurement:latency", "measurement:jitter", "measurement:bandwidth", and "measurement:packetloss" 
   attributes contain the values measured for each of these quality
   parameters in uplink and downlink directions. Notice that latency
   is considered equal for uplink and downlink directions. Quality
   parameter values in these "measurement" attributes provide a
   snapshot of the quality reached and <span class="bcp14">MUST</span> only be 
   included in Q4S-ALERT messages in the SDP body such that they can be protected
   from malicious attacks as these alerts include a signature of the
   SDP body in the header. The rest of the messages will include the
   measured values in the Measurements header field.<a href="#section-7.2.11-11" class="pilcrow">¶</a></p>
<p id="section-7.2.11-12">
   In the case of the "default" procedure, the valid values are as follows:<a href="#section-7.2.11-12" class="pilcrow">¶</a></p>
<div id="section-7.2.11-13">
<pre class="sourcecode lang-abnf">
a=measurement:procedure default,[0..999]"/" [0..999]  "," [0..999]
"/" [0..999] "," [0..9999] "," [0..999]/[0..999] ","
[0..999]/[0..999]
</pre><a href="#section-7.2.11-13" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="sec-7.2.12">
<section id="section-7.2.12">
          <h4 id="name-max-content-length-attribut">
<a href="#section-7.2.12" class="section-number selfRef">7.2.12. </a><a href="#name-max-content-length-attribut" class="section-name selfRef">"max-content-length" Attribute</a>
          </h4>
<p id="section-7.2.12-1">
   The adaptation of measurement traffic to approximate the actual
   data streams' characteristics is convenient to accurately estimate
   the expected QoS for applications. Particularly, packet size can
   have a remarkable effect on bandwidth estimations. Moreover, this
   can produce problems depending on the MTU of the end hosts and
   links along the path.<a href="#section-7.2.12-1" class="pilcrow">¶</a></p>
<p id="section-7.2.12-2">
   Therefore, the maximum content length <span class="bcp14">MAY</span> be set in an attribute
   denoted as "max-content-length". Its value <span class="bcp14">MUST</span> be given in bytes
   and <span class="bcp14">MUST NOT</span> include application, transport, network, or link layer
   headers, i.e., size of the content length at the application
   layer. If not set, the value <span class="bcp14">MUST</span> be 1000 bytes.<a href="#section-7.2.12-2" class="pilcrow">¶</a></p>
<p id="section-7.2.12-3">
   Furthermore, this attribute <span class="bcp14">MAY</span> be used to communicate MTU limits
   in endpoints, hence reducing possible bias as a result of
   network-layer fragmentation.<a href="#section-7.2.12-3" class="pilcrow">¶</a></p>
<p id="section-7.2.12-4">
   For instance:<a href="#section-7.2.12-4" class="pilcrow">¶</a></p>
<p id="section-7.2.12-5">
   a=max-content-length:1300<a href="#section-7.2.12-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-7.3">
<section id="section-7.3">
        <h3 id="name-measurements">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-measurements" class="section-name selfRef">Measurements</a>
        </h3>
<p id="section-7.3-1">
   This section describes the way quality parameters are measured as
   defined by the "default" procedure. Measurements <span class="bcp14">MUST</span> be taken for
   any quality parameter with constraints, that is, specified in the
   SDP attributes with non-zero values. For absent attributes,
   measurements <span class="bcp14">MAY</span> be omitted.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<div id="sec-7.3.1">
<section id="section-7.3.1">
          <h4 id="name-latency">
<a href="#section-7.3.1" class="section-number selfRef">7.3.1. </a><a href="#name-latency" class="section-name selfRef">Latency</a>
          </h4>
<p id="section-7.3.1-1">
   Latency measurements will be performed if the "latency" attribute
   and/or the "a=measurement:latency" attribute are present and have non-zero values.<a href="#section-7.3.1-1" class="pilcrow">¶</a></p>
<p id="section-7.3.1-2">
   Q4S defines a PING method in order to exchange packets between the
   client and the server. Based on this PING exchange, the client and
   the server are able to calculate the round-trip time (RTT). The
   RTT is the sum of downlink latency (normally named "reverse latency") and uplink latency (normally named "forward latency").<a href="#section-7.3.1-2" class="pilcrow">¶</a></p>
<p id="section-7.3.1-3">
   At least 255 samples of RTT <span class="bcp14">MUST</span> be taken by the client and
   server. As the forward and reverse latencies are impossible to
   measure, the client and server will assume that both latencies are
   identical (symmetric network assumption). The latency will
   therefore be calculated as the statistical median value of all the
   RTT samples divided by 2.<a href="#section-7.3.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.3.2">
<section id="section-7.3.2">
          <h4 id="name-jitter">
<a href="#section-7.3.2" class="section-number selfRef">7.3.2. </a><a href="#name-jitter" class="section-name selfRef">Jitter</a>
          </h4>
<p id="section-7.3.2-1">
   Jitter measurements will be performed if the "jitter" attribute
   and/or the "a=measurement:jitter" attribute are present and have non-zero values.<a href="#section-7.3.2-1" class="pilcrow">¶</a></p>
<p id="section-7.3.2-2">
   The jitter can be calculated independently by the client and by
   the server. The downlink jitter is calculated by the client taking
   into account the time interval between PING requests as defined by
   the "measurement:procedure" attribute in the first or second
   parameter depending on the Q4S protocol phase. The client and the
   server <span class="bcp14">MUST</span> send these PING requests at the specified intervals.
   The client measures the downlink jitter, whereas the server
   measures the uplink jitter. Note that PING responses are not taken
   into account when calculating jitter values.<a href="#section-7.3.2-2" class="pilcrow">¶</a></p>
<p id="section-7.3.2-3">
   Every time a PING request is received by an endpoint 
   (either server or client), the corresponding jitter value is 
   updated with the statistical jitter value, which is 
   the arithmetic mean of the absolute values of elapsed times
   calculated on the first 255 packets received.<a href="#section-7.3.2-3" class="pilcrow">¶</a></p>
<p id="section-7.3.2-4">
   Each endpoint sends a PING periodically with a fixed interval,
   and each value of "elapsed time" (ET) should be very close to this
   interval. If a PING message is lost, the ET value is
   doubled. Identifying lost PING messages, however, is not an issue
   because all PING messages are labeled with a Sequence-Number
   header field. Therefore, the receiver can discard this ET
   value.<a href="#section-7.3.2-4" class="pilcrow">¶</a></p>
<p id="section-7.3.2-5">
   In order to have the first jitter sample, the receiver <span class="bcp14">MUST</span> wait
   until it receives 3 PING requests, because each ET is the time
   between two PINGs, and a jitter measurement needs at least two ET.<a href="#section-7.3.2-5" class="pilcrow">¶</a></p>
<p id="section-7.3.2-6">
   The client measures the values of RTT and downlink jitter, and the
   server measures RTT and uplink jitter, but all measurements are
   shared with the counterpart by means of the Measurements header field of
   the PING message.<a href="#section-7.3.2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.3.3">
<section id="section-7.3.3">
          <h4 id="name-bandwidth">
<a href="#section-7.3.3" class="section-number selfRef">7.3.3. </a><a href="#name-bandwidth" class="section-name selfRef">Bandwidth</a>
          </h4>
<p id="section-7.3.3-1">
   Bandwidth measurements will be performed if the "bandwidth"
   attribute and/or the "a=measurement:bandwidth" attribute is present
   and has non-zero values.<a href="#section-7.3.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3.3-2">
   In order to measure the available bandwidth, both the client and
   the server <span class="bcp14">MUST</span> start sending BWIDTH messages simultaneously using
   the UDP control ports exchanged during the Handshake phase in the
   SDP message at the needed rate to verify the availability of the
   bandwidth constraint in each direction. The messages are sent
   during the period of time defined in the third parameter of the
   SDP "measurement:procedure default" attribute in milliseconds.<a href="#section-7.3.3-2" class="pilcrow">¶</a></p>
<span id="name-bandwidth-and-packet-loss-m"></span><div id="ref-bandwidth-and-packet-loss-measurements">
<figure id="figure-6">
            <div class="artwork art-text alignLeft" id="section-7.3.3-3.1">
<pre>
a=measurement:procedure default(50/50,75/75,5000,256/256,256/256)

        +------------------------------------------------+
        |             Rate                               |
        |              A                                 |
        |              |                                 |
        |downlink rate-|-------------------+ &lt;-- traffic |
        |              |                   |     sent by |
        |              |                   |     server  |
        |              |                   |             |
        |              |                   |             |
        |              |                   |             |
        |              |                   |             |
        |              |                   |             |
        |              |                   |             |
        |              |                   |             |
        |              |                   |             |
        |              |                   |             |
        |              |                   |             |
        |              |                   |             |
        |              |                   |             |
        |  uplink rate-|-------------------+ &lt;-- traffic |
        |              |                   |     sent by |
        |              |                   |     client  |
        |              |                   |             |
        |              |                   |             |
        |              |---|---|---|---|---|----&gt; time   |
        |              0   1   2   3   4   5     (sec.)  |
        |                                                |
        +------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-bandwidth-and-packet-loss-m" class="selfRef">Bandwidth and Packet Loss Measurements</a>
            </figcaption></figure>
</div>
<p id="section-7.3.3-4">
   The goal of these measurements is not to identify the available
   bandwidth of the communication path, but to determine if the
   required bandwidth is available, meeting the application's
   constraints. Therefore, the requested bandwidth <span class="bcp14">MUST</span> be measured
   sending only the highest bitrate required by the bandwidth
   attribute. This is illustrated in <a href="#ref-bandwidth-and-packet-loss-measurements" class="xref">Figure 6</a>.<a href="#section-7.3.3-4" class="pilcrow">¶</a></p>
<p id="section-7.3.3-5">
   ALERTS are not expected during bandwidth measurement, but
   only at the end of the measurement time.<a href="#section-7.3.3-5" class="pilcrow">¶</a></p>
<p id="section-7.3.3-6">
   When measuring bandwidth, all BWIDTH requests sent <span class="bcp14">MUST</span> be 1
   kilobyte in length (UDP payload length by default), they <span class="bcp14">MUST</span>
   include a Sequence-Number header field with a sequential number starting
   at 0, and their content <span class="bcp14">MUST</span> consist of randomly generated values
   to minimize the effect of compression elements along the path. The
   Sequence-Number <span class="bcp14">MUST</span> be incremented by 1 with each BWIDTH packet
   sent. If any measurement stage needs to be repeated, the sequence
   number <span class="bcp14">MUST</span> start at zero again. BWIDTH requests <span class="bcp14">MUST NOT</span> be
   answered. Examples:<a href="#section-7.3.3-6" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7.3.3-7">
<pre>
Client message:
=========================
       BWIDTH q4s://www.example.com Q4S/1.0
       User-Agent: q4s-ua-experimental-1.0
       Session-Id: 53655765
       Sequence-Number: 0
       Content-Type: text
       Content-Length: XXXX
       Measurements: l=22, j=10, pl=0.00, bw=3000

       VkZaU1FrNVZNVlZSV0doT1ZrZ (to complete up to "max-content-
                                 length" bytes UDP payload length)
=========================
</pre><a href="#section-7.3.3-7" class="pilcrow">¶</a>
</div>
<p id="section-7.3.3-8">
   The client <span class="bcp14">MUST</span> send BWIDTH packets to the server to allow the
   server to measure the uplink bandwidth. The server <span class="bcp14">MUST</span> send
   BWIDTH packets to the client to allow the client to measure the
   downlink bandwidth.<a href="#section-7.3.3-8" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7.3.3-9">
<pre>
Server message:
=========================
       BWIDTH q4s://www.example.com Q4S/1.0
       Session-Id: 53655765
       Sequence-Number: 0
       Content-Type: text
       Content-Length: XXXX
       Measurements: l=22, j=7, pl=0.00, bw=200

       ZY0VaT1ZURlZVVmhyUFE9PQ (to complete up to max-content-
                               length UDP payload length)
=========================
</pre><a href="#section-7.3.3-9" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="sec-7.3.4">
<section id="section-7.3.4">
          <h4 id="name-packet-loss">
<a href="#section-7.3.4" class="section-number selfRef">7.3.4. </a><a href="#name-packet-loss" class="section-name selfRef">Packet Loss</a>
          </h4>
<p id="section-7.3.4-1">
   Packet loss and bandwidth are measured simultaneously using the
   BWIDTH packets sent by both the client and the server. Because the
   BWIDTH packets contain a Sequence-Number header field incremented
   sequentially with each sent packet, lost packets can be easily
   identified. The lost packets <span class="bcp14">MUST</span> be counted during the
   measurement time.<a href="#section-7.3.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-7.4">
<section id="section-7.4">
        <h3 id="name-handshake-phase">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-handshake-phase" class="section-name selfRef">Handshake Phase</a>
        </h3>
<p id="section-7.4-1">
   The first phase consists of a Q4S BEGIN method issued from the
   client to the server as shown in <a href="#ref-handshake-phase" class="xref">Figure 7</a>.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<p id="section-7.4-2">
   The first Q4S message <span class="bcp14">MUST</span> have a special URI <span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span>,
   which forces the use of the Q4S protocol if it is implemented in a
   standard web browser.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
<p id="section-7.4-3">
   This URI, named "Contact URI", is used to request the start of a
   session. Its scheme <span class="bcp14">MUST</span> be:<a href="#section-7.4-3" class="pilcrow">¶</a></p>
<div id="section-7.4-4">
<pre class="sourcecode lang-abnf">
      "q4s:" "//" host [":" port] [path["?" query]
</pre><a href="#section-7.4-4" class="pilcrow">¶</a>
</div>
<p id="section-7.4-5">
   Optionally, the client can send the desired quality parameters
   enclosed in the body of the message as an SDP document. The server
   <span class="bcp14">MAY</span> take them into account when building the answer message with
   the final values in the SDP body, following a request/response
   schema <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>.<a href="#section-7.4-5" class="pilcrow">¶</a></p>
<p id="section-7.4-6">
   If the request is accepted, the server <span class="bcp14">MUST</span> answer it with a Q4S
   200 OK message, which <span class="bcp14">MUST</span> contain an SDP body <span>[<a href="#RFC4566" class="xref">RFC4566</a>]</span>
   with the assigned sess-id (embedded in the SDP "o=" line),
   the IP addresses to be used, the flow ports to be used, the
   measurement procedure to be followed, and information about the
   required quality constraints. Additionally, the "alerting-mode" and
   "alert-pause" time attributes may be included. Q4S responses should
   use the protocol designator "Q4S/1.0".<a href="#section-7.4-6" class="pilcrow">¶</a></p>
<p id="section-7.4-7">
   After these two messages are exchanged, the first phase is
   completed. The quality parameter thresholds have been sent to the
   client. The next step is to measure the actual quality of the
   communication path between the client and the server and alert if
   the Service Level Agreement (SLA) is being violated.<a href="#section-7.4-7" class="pilcrow">¶</a></p>
<span id="name-handshake-phase-2"></span><div id="ref-handshake-phase">
<figure id="figure-7">
          <div class="artwork art-text alignLeft" id="section-7.4-8.1">
<pre>
        +------------------------------------------------+
        |                                                |
        | Client                            Server       |
        |                                                |
        |     ------- Q4S BEGIN ------------&gt;            |
        |                                                |
        |     &lt;------ Q4S 200 OK ------------            |
        |                                                |
        |                                                |
        +------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-handshake-phase-2" class="selfRef">Handshake Phase</a>
          </figcaption></figure>
</div>
<p id="section-7.4-9">
   The following is an example of a client request and a server answer:<a href="#section-7.4-9" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7.4-10">
<pre>
Client Request:
=========================
BEGIN q4s://www.example.com Q4S/1.0
Content-Type: application/sdp
User-Agent: q4s-ua-experimental-1.0
Content-Length: 142

(SDP not shown)
=========================

Server Answer:
=========================
Q4S/1.0 200 OK
Date: Mon, 10 Jun 2010 10:00:01 GMT
Content-Type: application/sdp
Expires: 3000
Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4
Content-Length: 131

(SDP not shown)
=========================
</pre><a href="#section-7.4-10" class="pilcrow">¶</a>
</div>
<p id="section-7.4-11">The header fields used are explained in <a href="#sec-4.3" class="xref">Section 4.3</a>.<a href="#section-7.4-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.5">
<section id="section-7.5">
        <h3 id="name-negotiation-phase">
<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-negotiation-phase" class="section-name selfRef">Negotiation Phase</a>
        </h3>
<p id="section-7.5-1">
   The Negotiation phase is in charge of measuring the quality
   parameters and verifying that the communication paths meet the
   required quality constraints in both directions as specified in
   the SDP body.<a href="#section-7.5-1" class="pilcrow">¶</a></p>
<p id="section-7.5-2">
   The measured parameters will be compared with the quality
   constraints specified in the SDP body. If the quality session is
   compliant with all the quality constraints, the application can
   start.<a href="#section-7.5-2" class="pilcrow">¶</a></p>
<p id="section-7.5-3">If the quality constraints are not met, a higher quality
      service level will be demanded. Depending on the scenario,
      this quality upgrade will be managed as follows:<a href="#section-7.5-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.5-4">
          <dt id="section-7.5-4.1">In the Q4S-aware-network scenario:</dt>
          <dd id="section-7.5-4.2">a Q4S-ALERT method will be triggered
      by the server to the client, and the client will answer with
      the same Q4S-ALERT method. After receiving the same Q4S-ALERT
      from the counterpart, no other alerts will be triggered by
      the server during the "alert-pause" period of time in order
      to allow the network to react, but measurements will continue
      to be taken to achieve early detection of improved network
      quality conditions and a fast application start.<a href="#section-7.5-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.5-4.3">In the Reactive scenario:</dt>
          <dd id="section-7.5-4.4">an alert notification will be sent
      by the server stack to the Actuator, and the Actuator will
      answer with an alert acknowledgement. After receiving the
      alert acknowledgement from the Actuator, the server stack
      will not send other alert notifications during the "alert-pause" 
      period of time in order to allow the Actuator to
      react and trigger actions on the application or on the policy
      server, but measurements will continue to be taken to achieve
      early detection of improved network quality conditions and a
      fast application start.<a href="#section-7.5-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.5-5">
   In both scenarios stated above, if after several measurement
   cycles, the network constraints cannot be met, the quality session
   is terminated. Concretely when, under all possible actions taken by
   Actuator, the quality remains below requirements, the session must
   be terminated.<a href="#section-7.5-5" class="pilcrow">¶</a></p>
<p id="section-7.5-6">
   The steps to be taken in this phase depend on the measurement
   procedure exchanged during the Handshake phase. This document only
   describes the "default" procedure, but others can be used, like
   RTP/RTCP <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>.<a href="#section-7.5-6" class="pilcrow">¶</a></p>
<p id="section-7.5-7">
   Measurements of latency and jitter are made by calculating the
   differences in the arrival times of packets and can be achieved with
   little bandwidth consumption. The bandwidth measurement, on the
   other hand, involves higher bandwidth consumption in both
   directions (uplink and downlink).<a href="#section-7.5-7" class="pilcrow">¶</a></p>
<p id="section-7.5-8">
   To avoid wasting unnecessary network resources, these two types of
   measurements will be performed in two separate stages. If the
   required latencies and jitters cannot be reached, it makes no
   sense to waste network resources measuring bandwidth. In addition,
   if achieving the required latency and jitter thresholds implies
   upgrading the quality session level, the chance of obtaining
   compliant bandwidth measurements without retries is higher, saving
   network traffic again. Therefore, the "default" procedure
   determines that the measurements are taken in two stages:<a href="#section-7.5-8" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.5-9">
          <dt id="section-7.5-9.1">Stage 0:</dt>
          <dd style="margin-left: 3.0em" id="section-7.5-9.2"> Measurement of latencies, jitters, and packet loss<a href="#section-7.5-9.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.5-9.3">Stage 1:</dt>
          <dd style="margin-left: 3.0em" id="section-7.5-9.4"> Measurement of bandwidths and packet loss<a href="#section-7.5-9.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.5-10">
   Notice that packet loss can be measured in both stages, as all
   messages exchanged include a Sequence-Number header field that allows
   for easy packet loss detection.<a href="#section-7.5-10" class="pilcrow">¶</a></p>
<p id="section-7.5-11">
   The client starts the Negotiation phase by sending a READY request
   using the TCP Q4S ports defined in the SDP. This READY request
   includes a Stage header field that indicates the measurement stage.<a href="#section-7.5-11" class="pilcrow">¶</a></p>
<p id="section-7.5-12">
   If either jitter, latency, or both are specified, the Negotiation
   phase begins with the measurement of latencies and jitters (stage
   0). If none of those attributes is specified, stage 0 is skipped.<a href="#section-7.5-12" class="pilcrow">¶</a></p>
<div id="sec-7.5.1">
<section id="section-7.5.1">
          <h4 id="name-stage-0-measurement-of-late">
<a href="#section-7.5.1" class="section-number selfRef">7.5.1. </a><a href="#name-stage-0-measurement-of-late" class="section-name selfRef">Stage 0: Measurement of Latencies and Jitter</a>
          </h4>
<p id="section-7.5.1-1">
   The Stage 0 <span class="bcp14">MUST</span> start with a synchronization message exchange
   initiated with the client's READY message.<a href="#section-7.5.1-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7.5.1-2">
<pre>
Client Request, READY message:
=========================
       READY q4s://www.example.com Q4S/1.0
       Stage: 0
       Session-Id: 53655765
       User-Agent: q4s-ua-experimental-1.0
       Content-Length: 0
=========================

Server Response:
=========================
  Q4S/1.0 200 OK
       Session-Id: 53655765
       Stage:0
       Content-Length: 0
=========================
</pre><a href="#section-7.5.1-2" class="pilcrow">¶</a>
</div>
<p id="section-7.5.1-3">
   This triggers the exchange of a sequence of PING requests and
   responses that will lead to the calculation of RTT (latency),
   jitter, and packet loss.<a href="#section-7.5.1-3" class="pilcrow">¶</a></p>
<p id="section-7.5.1-4">
   After receiving a 200 OK, the client must send the first PING
   message, and the server will wait to send PINGs until the reception
   of this first client PING.<a href="#section-7.5.1-4" class="pilcrow">¶</a></p>
<p id="section-7.5.1-5">
   The client and server <span class="bcp14">MUST</span> send PING requests to each other. The
   Sequence-Number header field of the first PING <span class="bcp14">MUST</span> be set to 0. The client
   and server will manage their own sequence numbers.<a href="#section-7.5.1-5" class="pilcrow">¶</a></p>
<span id="name-simultaneous-exchange-of-pi"></span><div id="ref-simultaneous-exchange-of-ping-request-and-responses">
<figure id="figure-8">
            <div class="artwork art-text alignLeft" id="section-7.5.1-6.1">
<pre>
        +------------------------------------------------+
        |                                                |
        | Client                                Server   |
        |                                                |
        |      --------- Q4S READY 0 ---------&gt;          |
        |      &lt;-------- Q4S 200 OK -----------          |
        |                                                |
        |      --------- Q4S PING ------------&gt;          |
        |      &lt;-------- Q4S 200 OK -----------          |
        |      &lt;-------- Q4S PING -------------          |
        |       -------- Q4S 200 OK ----------&gt;          |
        |      --------- Q4S PING ------------&gt;          |
        |      &lt;-------- Q4S PING -------------          |
        |      --------- Q4S 200 OK ----------&gt;          |
        |      &lt;-------- Q4S 200 OK -----------          |
        |                     ...                        |
        |                                                |
        +------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-simultaneous-exchange-of-pi" class="selfRef">Simultaneous Exchange of PING Request and Responses</a>
            </figcaption></figure>
</div>
<p id="section-7.5.1-7">
   The following is 
   an example of the PING request sent from the client
   and the server's response:<a href="#section-7.5.1-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7.5.1-8">
<pre>
Client Request:
=========================
       PING q4s://www.example.com Q4S/1.0
       Session-Id: 53655765
       Sequence-Number: 0
       User-Agent: q4s-ua-experimental-1.0
       Measurements: l=22, j=12, pl=0.20, bw=
       Content-Length: 0
=========================

Server Response:
=========================
  Q4S/1.0 200 OK
       Session-Id: 53655765
       Sequence-Number: 0
       Content-Length: 0
=========================
</pre><a href="#section-7.5.1-8" class="pilcrow">¶</a>
</div>
<p id="section-7.5.1-9">
   The function of the PING method is similar to the ICMP echo
   request message <span>[<a href="#RFC0792" class="xref">RFC0792</a>]</span>. 
   The server <span class="bcp14">MUST</span> answer as soon as it receives the
   message.<a href="#section-7.5.1-9" class="pilcrow">¶</a></p>
<p id="section-7.5.1-10">
   Both endpoints <span class="bcp14">MUST</span> send Q4S PING messages with the periodicity
   specified in the first parameter of SDP "measurement:procedure"
   attribute, always using the same UDP ports and incrementing the
   Sequence-Number with each message.<a href="#section-7.5.1-10" class="pilcrow">¶</a></p>
<p id="section-7.5.1-11">
   In the following example, the value of the first parameter of the SDP "measurement:procedure" attribute
   is 50 milliseconds (from the client to the server) and
   60 ms (from the server to the client):<a href="#section-7.5.1-11" class="pilcrow">¶</a></p>
<div id="section-7.5.1-12">
<pre class="sourcecode lang-sdp">
a=measurement:procedure default(50/60,50/50,5000,256/256,256/256)
</pre><a href="#section-7.5.1-12" class="pilcrow">¶</a>
</div>
<p id="section-7.5.1-13">
   They <span class="bcp14">MUST NOT</span> wait for a response to send the next PING request.
   The Sequence-Number header field value is incremented sequentially and
   <span class="bcp14">MUST</span> start at zero. If this stage is repeated, the initial
   Sequence-Number <span class="bcp14">MUST</span> start at zero again.<a href="#section-7.5.1-13" class="pilcrow">¶</a></p>
<p id="section-7.5.1-14">
   All PING requests <span class="bcp14">MUST</span> contain a Measurements header field with the
   values of the latency, jitter, and packet loss measured by each
   entity up to that moment. The client will send its measurements to
   the server, and the server will send its measurements to the client. Example:<a href="#section-7.5.1-14" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7.5.1-15">
<pre>
      Measurements: l=22, j=13, pl=0.10, bw=
</pre><a href="#section-7.5.1-15" class="pilcrow">¶</a>
</div>
<p id="section-7.5.1-16">
   Where "l" stands for latency, "j" for jitter, "pl" for packet loss, and "bw"
   for bandwidth. The bandwidth value is omitted, as it is not
   measured at this stage.<a href="#section-7.5.1-16" class="pilcrow">¶</a></p>
<p id="section-7.5.1-17">
   Optionally the PING request can include a Timestamp header field with
   the time in which the message has been sent. In the case that the header field is
   present, the server <span class="bcp14">MUST</span> include the header field in the response
   without changing the value.<a href="#section-7.5.1-17" class="pilcrow">¶</a></p>
<p id="section-7.5.1-18">
   A minimum number of PING messages <span class="bcp14">MUST</span> be exchanged in order to be
   able to measure latency, jitter, and packet loss with certain
   accuracy (at least 256 samples are <span class="bcp14">RECOMMENDED</span> to get an accurate
   packet loss measurement). Both the client and the server calculate
   the respective measured parameter values. The mechanisms to
   calculate the different parameters are described in <a href="#sec-7.3" class="xref">Section 7.3</a>.<a href="#section-7.5.1-18" class="pilcrow">¶</a></p>
<p id="section-7.5.1-19">
   At the end of this stage 0, there are three possibilities:<a href="#section-7.5.1-19" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.5.1-20.1">The latency, jitter, and packetloss constraints are reached
      in both directions<a href="#section-7.5.1-20.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-7.5.1-20.2">The latency, jitter, and packetloss constraints are not
      reached in one or both directions<a href="#section-7.5.1-20.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-7.5.1-21">
   In the first case, Stage 0 is finished. The client and server are
   ready for Stage 1: bandwidth and packet loss measurement. The
   client moves to stage 1 by sending a READY message that includes the
   header field, "Stage: 1".<a href="#section-7.5.1-21" class="pilcrow">¶</a></p>
<p id="section-7.5.1-22">
   If the bandwidth constraints are either empty or have a value of zero, the
   Negotiation phase <span class="bcp14">MUST</span> terminate, and both client and server may
   initiate the Continuity phase. In this case, client moves to the 
   Continuity phase by sending a READY message that includes the header field,
   "Stage: 2".<a href="#section-7.5.1-22" class="pilcrow">¶</a></p>
<p id="section-7.5.1-23">
   The second case, in which one or more quality constraints have not
   been met, is detailed in <a href="#sec-7.5.4" class="xref">Section 7.5.4</a>.<a href="#section-7.5.1-23" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.5.2">
<section id="section-7.5.2">
          <h4 id="name-stage-1-measurement-of-band">
<a href="#section-7.5.2" class="section-number selfRef">7.5.2. </a><a href="#name-stage-1-measurement-of-band" class="section-name selfRef">Stage 1: Measurement of Bandwidth and Packet Loss</a>
          </h4>
<p id="section-7.5.2-1">
   This stage begins in a similar way to stage 0, sending a READY
   request over TCP. The value of the READY message's Stage header field is 1.
   The server answers with a Q4S 200 OK message to synchronize the
   initiation of the measurements as shown in 
   <a href="#ref-starting-bandwidth-and-packet-loss-measurement" class="xref">Figure 9</a>.<a href="#section-7.5.2-1" class="pilcrow">¶</a></p>
<span id="name-starting-bandwidth-and-pack"></span><div id="ref-starting-bandwidth-and-packet-loss-measurement">
<figure id="figure-9">
            <div class="artwork art-text alignLeft" id="section-7.5.2-2.1">
<pre>
        +------------------------------------------------+
        |                                                |
        | Client                                Server   |
        |                                                |
        |      --------- Q4S READY 1 -----------&gt;        |
        |      &lt;-------- Q4S 200 OK -------------        |
        |                                                |
        |      --------- Q4S BWIDTH  -----------&gt;        |
        |      &lt;-------- Q4S BWIDTH  ------------        |
        |      --------- Q4S BWIDTH  -----------&gt;        |
        |      &lt;-------- Q4S BWIDTH  ------------        |
        |                  ...                           |
        |                                                |
        +------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-starting-bandwidth-and-pack" class="selfRef">Starting Bandwidth and Packet Loss Measurement</a>
            </figcaption></figure>
</div>
<div class="artwork art-text alignLeft" id="section-7.5.2-3">
<pre>
Client Request:
=========================
       READY q4s://www.example.com Q4S/1.0
       User-Agent: q4s-ua-experimental-1.0
       Stage: 1
       Session-Id: 53655765
       Content-Length: 0

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

Server Response:
=========================
  Q4S/1.0 200 OK
       Session-Id: 53655765
       Stage: 1
       Content-Length: 0

=========================
</pre><a href="#section-7.5.2-3" class="pilcrow">¶</a>
</div>
<p id="section-7.5.2-4">
   Just after receiving the 200 OK, both the client and the server
   <span class="bcp14">MUST</span> start sending BWIDTH messages simultaneously using the UDP
   "q4s" ports. <a href="#sec-7.3.3" class="xref">Section 7.3.3</a> describes the bandwidth measurement in
   detail.<a href="#section-7.5.2-4" class="pilcrow">¶</a></p>
<p id="section-7.5.2-5">
   At the end of this stage 1, there are three possibilities:<a href="#section-7.5.2-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.5.2-6.1">The bandwidth and packetloss constraints are reached in both
      directions.<a href="#section-7.5.2-6.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-7.5.2-6.2">The bandwidth and packetloss constraints are not reached in
      one or both directions.<a href="#section-7.5.2-6.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-7.5.2-7">
   In the first case, Stage 1 is finished. The client and server are
   ready for the Continuity phase. The client moves to this phase by
   sending a READY message that includes the header field, "Stage: 2". The
   server answer <span class="bcp14">MUST</span> be 200 OK as shown in 
   <a href="#ref-trigger-the-application-using-http-uri" class="xref">Figure 10</a>.<a href="#section-7.5.2-7" class="pilcrow">¶</a></p>
<span id="name-trigger-the-application-usi"></span><div id="ref-trigger-the-application-using-http-uri">
<figure id="figure-10">
            <div class="artwork art-text alignLeft" id="section-7.5.2-8.1">
<pre>
        +------------------------------------------------+
        |                                                |
        | Client                                Server   |
        |                                                |
        |     ---------  Q4S READY 2 --------------&gt;     |
        |     &lt;---- Q4S 200 OK with trigger URI-----     |
        |                                                |
        |     ---------   HTTP GET ----------------&gt;     |
        |                                                |
        |            (Application starts)                |
        |                                                |
        +------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-trigger-the-application-usi" class="selfRef">Trigger the Application Using HTTP URI</a>
            </figcaption></figure>
</div>
<div class="artwork art-text alignLeft" id="section-7.5.2-9">
<pre>
Client Request:
=========================
READY q4s://www.example.com Q4S/1.0
User-Agent: q4s-ua-experimental-1.0
Stage: 2
Session-Id: 53655765
Content-Length: 0

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

Server Answer:
=========================
Q4S/1.0 200 OK
Date: Mon, 10 Jun 2010 10:00:01 GMT
Session-Id: 53655765
Trigger-URI: http://www.example.com/app_start
Expires: 3000
Content-Type: application/sdp
Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4
Content-Length: 131

(SDP not shown)
=========================
</pre><a href="#section-7.5.2-9" class="pilcrow">¶</a>
</div>
<p id="section-7.5.2-10">
   If the Trigger-URI header field is present, the client <span class="bcp14">SHOULD</span> send an
   HTTP request to this URI.<a href="#section-7.5.2-10" class="pilcrow">¶</a></p>
<p id="section-7.5.2-11">
   The second case, with violated network constraints, is explained in
   <a href="#sec-7.5.4" class="xref">Section 7.5.4</a>.<a href="#section-7.5.2-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.5.3">
<section id="section-7.5.3">
          <h4 id="name-quality-constraints-not-rea">
<a href="#section-7.5.3" class="section-number selfRef">7.5.3. </a><a href="#name-quality-constraints-not-rea" class="section-name selfRef">Quality Constraints Not Reached</a>
          </h4>
<p id="section-7.5.3-1">
   After finishing Stage 1 of the Negotiation phase, the client and
   the server have each other's measured parameter values as these have
   been exchanged in the Measurements header fields of the PING and
   BWIDTH messages. If there is one or more parameters that do not
   comply with the uplink or downlink application constraints
   required, both the server and the client are aware of it.<a href="#section-7.5.3-1" class="pilcrow">¶</a></p>
<p id="section-7.5.3-2">
   If there is any quality parameter that does not meet the uplink or
   downlink quality constraints specified in the SDP message, two
   scenarios are possible depending on the specified alerting mode
   (if not present, the default value is Reactive alerting mode):<a href="#section-7.5.3-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-7.5.3-3">
            <dt>(a)</dt>
<dd id="section-7.5.3-3.1">
              <p id="section-7.5.3-3.1.1"> Q4S-aware-network alerting mode: the server <span class="bcp14">MUST</span> send a 
      Q4S-ALERT message to the client including the digital Signature
      header field, and the client <span class="bcp14">MUST</span> 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 <span class="bcp14">MUST</span> contain the "measurement" parameters in the
      body.<a href="#section-7.5.3-3.1.1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7.5.3-3.1.2">
<pre>
Server request
=========================
Q4S-ALERT q4s://www.example.com Q4S/1.0
Host: www.example.com
User-Agent: q4s-ua-experimental-1.0
Session-Id: 53655765
Content-Type: application/sdp
Content-Length: 142

v=0
o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33
s=Q4S
i=Q4S parameters
t=0 0
a=qos-level:1/2
a=alerting-mode: Q4S-aware-network
a=alert-pause:5000
a=public-address:client IP4 198.51.100.51
a=public-address:server IP4 198.51.100.58
a=latency:40
a=jitter:10/10
a=bandwidth:20/6000
a=packetloss:0.50/0.50
a=flow:app downlink TCP/10000-20000
a=flow:app uplink TCP/56000
a=flow:q4s downlink UDP/55000
a=flow:q4s downlink TCP/55001
a=flow:q4s uplink UDP/56000
a=flow:q4s uplink TCP/56001
a=measurement:procedure default(50/50,50/50,5000,256/256,256/256)
a=measurement:latency 30
a=measurement:jitter 6/4
a=measurement:bandwidth 200/4000
a=measurement:packetloss 0.20/0.33
=========================
</pre><a href="#section-7.5.3-3.1.2" class="pilcrow">¶</a>
</div>
<p id="section-7.5.3-3.1.3">
   At this point, both the client and server keep on measuring but
   without sending new Q4S-ALERT messages during the "alert-pause"
   milliseconds.<a href="#section-7.5.3-3.1.3" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt>(b)</dt>
<dd id="section-7.5.3-3.2">  Reactive alerting mode: the server stack <span class="bcp14">MUST</span> send an alert
      notification to the Actuator, and the Actuator <span class="bcp14">MUST</span> answer with
      an acknowledgement to the received alert notification. The
      alert notification sent to the Actuator by the server stack
      doesn't follow Q4S message style but should have all the
      information the Actuator will need for the actions to be taken,
      which will be implementation dependent.<a href="#section-7.5.3-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-7.5.3-4">
   At this point during Negotiation phase, both the client and server
   keep on measuring without sending new alert notifications to the
   Actuator during the "alert-pause" milliseconds specified in the
   SDP. This way, both client and server will detect any improvement
   in network conditions as soon as the network reacts. The
   application can start as soon as the number of measurements
   indicated in the "measurement:procedure" attribute indicates that
   the quality parameters are met.<a href="#section-7.5.3-4" class="pilcrow">¶</a></p>
<p id="section-7.5.3-5">
   The same applies to Continuity phase: the measurement dialog between
   client and server must not be interrupted by any possible ALERT
   message.<a href="#section-7.5.3-5" class="pilcrow">¶</a></p>
<div id="sec-7.5.3.1">
<section id="section-7.5.3.1">
            <h5 id="name-actuator-role">
<a href="#section-7.5.3.1" class="section-number selfRef">7.5.3.1. </a><a href="#name-actuator-role" class="section-name selfRef">Actuator Role</a>
            </h5>
<p id="section-7.5.3.1-1">
   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.<a href="#section-7.5.3.1-1" class="pilcrow">¶</a></p>
<p id="section-7.5.3.1-2">
   The Actuator logic activates mechanisms at the application level
   and/or the network level based on a quality level dictionary, in which
   the meaning of each level is implementation dependent, and each level
   involves different actions based on rules to keep a certain user
   experience quality.<a href="#section-7.5.3.1-2" class="pilcrow">¶</a></p>
<p id="section-7.5.3.1-3">
   The type of actions that an Actuator can take at the application level
   are application dependent and <span class="bcp14">MAY</span> involve:<a href="#section-7.5.3.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.5.3.1-4.1">Reduction of application functionalities, such as limitation
      of application speed or application options.<a href="#section-7.5.3.1-4.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.5.3.1-4.2">Reduction of application resources usage, such as reduction
      of frames per second in a video application or any other parameter
      modification in order to adapt to network conditions.<a href="#section-7.5.3.1-4.2" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-7.5.3.1-5">
   Apart from actions at the application level, the Actuator <span class="bcp14">MAY</span> act at
   the network level if a network policy server is available.<a href="#section-7.5.3.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.5.3.2">
<section id="section-7.5.3.2">
            <h5 id="name-policy-server-role">
<a href="#section-7.5.3.2" class="section-number selfRef">7.5.3.2. </a><a href="#name-policy-server-role" class="section-name selfRef">Policy Server Role</a>
            </h5>
<p id="section-7.5.3.2-1">
   A network policy server may be part of the Reactive scenario, and
   it is in charge of managing network quality provision. A network
   policy server may implement all or some of these features (but implementation is not
   exclusive to):<a href="#section-7.5.3.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.5.3.2-2.1">Server validation in terms of quality constraints<a href="#section-7.5.3.2-2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.5.3.2-2.2">Authentication (Signature validation) and security (blocking of 
      malicious clients)<a href="#section-7.5.3.2-2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.5.3.2-2.3">
                <p id="section-7.5.3.2-2.3.1">Policy rules (the following rules are only examples):<a href="#section-7.5.3.2-2.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.5.3.2-2.3.2.1">Maximum quality level allowed for the ACP<a href="#section-7.5.3.2-2.3.2.1" class="pilcrow">¶</a>
</li>
                  <li class="normal" id="section-7.5.3.2-2.3.2.2">Time bands allowed for providing quality sessions<a href="#section-7.5.3.2-2.3.2.2" class="pilcrow">¶</a>
</li>
                  <li class="normal" id="section-7.5.3.2-2.3.2.3">Number of simultaneous quality sessions allowed<a href="#section-7.5.3.2-2.3.2.3" class="pilcrow">¶</a>
</li>
                  <li class="normal" id="section-7.5.3.2-2.3.2.4">Maximum time used by allowed quality sessions<a href="#section-7.5.3.2-2.3.2.4" class="pilcrow">¶</a>
</li>
                  <li class="normal" id="section-7.5.3.2-2.3.2.5">Etc.<a href="#section-7.5.3.2-2.3.2.5" class="pilcrow">¶</a>
</li>
                </ul>
</li>
            </ul>
<p id="section-7.5.3.2-3">
   If any of the policy rules fail, a Q4S-ALERT message <span class="bcp14">MUST</span> be
   answered by a 6xx error indicating the cause.<a href="#section-7.5.3.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-7.5.4">
<section id="section-7.5.4">
          <h4 id="name-qos-level-changes">
<a href="#section-7.5.4" class="section-number selfRef">7.5.4. </a><a href="#name-qos-level-changes" class="section-name selfRef">"qos-level" Changes</a>
          </h4>
<p id="section-7.5.4-1">
   If any constraint was violated, the server <span class="bcp14">MAY</span> trigger a Q4S-ALERT
   asking for a higher "qos-level" attribute. The maximum "qos-level"
   allowed is 9 for both uplink and downlink.<a href="#section-7.5.4-1" class="pilcrow">¶</a></p>
<p id="section-7.5.4-2">
   If the "qos-level" has reached the maximum value for the downlink or
   uplink without matching the constraints, then a CANCEL request
   <span class="bcp14">MUST</span> be sent by the client using the TCP port determined in the
   Handshake phase in order to release the session. In reaction to
   the reception of the CANCEL request, the server <span class="bcp14">MUST</span> send a CANCEL
   request, too. If no CANCEL request is received, the expiration time
   cancels the session on the server side.<a href="#section-7.5.4-2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7.5.4-3">
<pre>
Client Request:
=========================
CANCEL q4s://www.example.com Q4S/1.0
User-Agent: q4s-ua-experimental-1.0
Session-Id: 53655765
Content-Type: application/sdp
Content-Length: 142

(SDP not shown)
=========================

Server Request in reaction to Client Request:
=========================
CANCEL q4s://www.example.com Q4S/1.0
Session-Id: 53655765
Expires: 0
Content-Type: application/sdp
Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4
Content-Length: 131

(SDP not shown)
=========================
</pre><a href="#section-7.5.4-3" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="sec-7.6">
<section id="section-7.6">
        <h3 id="name-continuity-phase">
<a href="#section-7.6" class="section-number selfRef">7.6. </a><a href="#name-continuity-phase" class="section-name selfRef">Continuity Phase</a>
        </h3>
<p id="section-7.6-1">
   During the Negotiation phase, latency, jitter, bandwidth, and
   packet loss have been measured. During the Continuity phase,
   bandwidth will not be measured again because bandwidth
   measurements may disturb application performance.<a href="#section-7.6-1" class="pilcrow">¶</a></p>
<p id="section-7.6-2">
   This phase is supposed to be executed at the same time as the
   real-time application is being used.<a href="#section-7.6-2" class="pilcrow">¶</a></p>
<p id="section-7.6-3">
   This document only covers the "default" procedure. The continuity
   operation with the "default" procedure is based on a sliding window of
   samples. The number of samples involved in the sliding window may
   be different for jitter and latency than for packet loss
   calculations according to the fifth and sixth parameters of the
   "measurement:procedure" attribute. In the example, shown in 
   <a href="#ref-sliding-samples-window" class="xref">Figure 11</a>, 
   the jitter and latency sliding window comprises 40 samples,
   whereas the size of the packet loss sliding window is 100 samples:<a href="#section-7.6-3" class="pilcrow">¶</a></p>
<div id="section-7.6-4">
<pre class="sourcecode lang-sdp">
a=measurement:procedure default(50/50,75/75,5000,40/40,100/100)
</pre><a href="#section-7.6-4" class="pilcrow">¶</a>
</div>
<p id="section-7.6-5">
   In addition, the sizes of these windows are configurable per
   direction: uplink and downlink values may differ.<a href="#section-7.6-5" class="pilcrow">¶</a></p>
<p id="section-7.6-6">
   PING requests are sent continuously (in both directions), and when
   the Sequence-Number header field reaches the maximum value, the client
   continues sending PING messages with the Sequence-Number header field
   starting again at zero. When the server PING Sequence-Number
   header field reaches the maximum value, it does the same, starting again
   from zero.<a href="#section-7.6-6" class="pilcrow">¶</a></p>
<p id="section-7.6-7">
   On the client side, the measured values of downlink jitter,
   downlink packet loss, and latency are calculated using the last
   samples, discarding older ones, in a sliding window schema.<a href="#section-7.6-7" class="pilcrow">¶</a></p>
<span id="name-sliding-samples-window"></span><div id="ref-sliding-samples-window">
<figure id="figure-11">
          <div class="artwork art-text alignLeft" id="section-7.6-8.1">
<pre>
       +--------------------------------------------------+
       |                                                  |
       | 55 56 57 . . . 253 254 255 0 1 2 . . . 55 56     |
       |        A                                   A     |
       |        |                                   |     |
       |        +-----------------------------------+     |
       |                                                  |
       +--------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-sliding-samples-window" class="selfRef">Sliding Samples Window</a>
          </figcaption></figure>
</div>
<p id="section-7.6-9">
   Only if the server detects that the measured values (downlink or
   uplink jitter, packet loss, or latency) are not reaching the
   quality constraints, a Q4S-ALERT is triggered and sent either to
   the client or to the Actuator, depending on the alerting mode, and
   the "alert-pause" timer is started.<a href="#section-7.6-9" class="pilcrow">¶</a></p>
<p id="section-7.6-10">
   In the Q4S-aware-network alerting mode shown in 
   <a href="#ref-continuity-in-q4s-aware-network-alerting-mode" class="xref">Figure 12</a>, 
   if the
   client receives a Q4S-ALERT message, it <span class="bcp14">MUST</span> answer by sending the
   Q4S-ALERT request message including the SDP
   (with its corresponding digital signature) back to the server.<a href="#section-7.6-10" class="pilcrow">¶</a></p>
<p id="section-7.6-11">
    Both client and server will keep performing measurements, 
    but Q4S-ALERT messages <span class="bcp14">MUST NOT</span> be sent during 
    "alert-pause" milliseconds. 
   The operations needed to act on the network and the
   agents in charge of them are out of scope of this document.<a href="#section-7.6-11" class="pilcrow">¶</a></p>
<span id="name-continuity-in-q4s-aware-net"></span><div id="ref-continuity-in-q4s-aware-network-alerting-mode">
<figure id="figure-12">
          <div class="artwork art-text alignLeft" id="section-7.6-12.1">
<pre>
        +------------------------------------------------+
        |                                                |
        | Client                      Server             |
        |                                                |
        |               ...                              |
        |   ----------- PING ----------&gt;                 |
        |   &lt;--------- 200 OK ----------                 |
        |   &lt;------- Q4S-ALERT ---------                 |
        |   -------- Q4S-ALERT --------&gt;                 |
        |   &lt;---------- PING -----------                 |
        |   ---------- 200 OK ---------&gt;                 |
        |   ----------- PING ----------&gt;                 |
        |   &lt;--------- 200 OK ----------                 |
        |   &lt;---------- PING -----------                 |
        |   ---------- 200 OK ---------&gt;                 |
        |        ...                                     |
        |                                                |
        +------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-continuity-in-q4s-aware-net" class="selfRef">Continuity in Q4S-Aware-Network Alerting Mode</a>
          </figcaption></figure>
</div>
<p id="section-7.6-13">
   In the Reactive scenario shown in <a href="#ref-continuity-in-reactive-alerting-mode" class="xref">Figure 13</a>, 
   if the server detects
   that the measured values (downlink or uplink jitter, packet loss,
   or latency) are not reaching the quality constraints, an alert
   notification is triggered and sent to the Actuator. The Actuator
   <span class="bcp14">MUST</span> then answer to the server stack with an alert acknowledgement.<a href="#section-7.6-13" class="pilcrow">¶</a></p>
<p id="section-7.6-14">
   The measurement dialog between the client and the server <span class="bcp14">MUST NOT</span>
   be interrupted by any possible ALERT message.<a href="#section-7.6-14" class="pilcrow">¶</a></p>
<span id="name-continuity-in-reactive-aler"></span><div id="ref-continuity-in-reactive-alerting-mode">
<figure id="figure-13">
          <div class="artwork art-text alignLeft" id="section-7.6-15.1">
<pre>
        +------------------------------------------------+
        |                                                |
        | Client             Server             Actuator |
        |        ...                                     |
        |   --- PING ----------&gt;                         |
        |   &lt;-- 200 OK----------                         |
        |   &lt;----- PING --------                         |
        |   &lt;--- 200 OK -------- ---- alert              |
        |                            notification --&gt;    |
        |                                                |
        |   --- PING ----------&gt; &lt;--- alert              |
        |                             acknowledge ---    |
        |   &lt;-- 200 OK----------                         |
        |   &lt;----- PING --------                         |
        |   --- 200 OK --------&gt;                         |
        |        ...                                     |
        |                                                |
        +------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-continuity-in-reactive-aler" class="selfRef">Continuity in Reactive Alerting Mode</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sec-7.7">
<section id="section-7.7">
        <h3 id="name-termination-phase">
<a href="#section-7.7" class="section-number selfRef">7.7. </a><a href="#name-termination-phase" class="section-name selfRef">Termination Phase</a>
        </h3>
<p id="section-7.7-1">
   The Termination phase is the endpoint for the established Q4S
   session that is reached in the following cases:<a href="#section-7.7-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.7-2.1">A CANCEL message has been received. The client sends a
      CANCEL message due to the network's inability to
      meet the required quality constraints. The client and server
      application will be notified by their respective Q4S stacks.<a href="#section-7.7-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.7-2.2">Session expires: if after the Expires time, no client or
      server activity is detected, that end cancels the session.<a href="#section-7.7-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.7-2.3">A BEGIN message has been received by the server. 
     The pre-existing Q4S quality session is canceled, and a new session
      will be initiated.<a href="#section-7.7-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.7-3">
   The meaning of the Termination phase in terms of the release of resources
   or accounting is application dependent and out of scope of the Q4S
   protocol.<a href="#section-7.7-3" class="pilcrow">¶</a></p>
<p id="section-7.7-4">
   In the Reactive alerting mode, Q4S CANCEL messages received by the Q4S
   server must cause the server stack to send cancel notifications 
   to the Actuator in order to release possible
   assigned resources for the session.<a href="#section-7.7-4" class="pilcrow">¶</a></p>
<div id="sec-7.7.1">
<section id="section-7.7.1">
          <h4 id="name-sanity-check-of-quality-ses">
<a href="#section-7.7.1" class="section-number selfRef">7.7.1. </a><a href="#name-sanity-check-of-quality-ses" class="section-name selfRef">Sanity Check of Quality Sessions</a>
          </h4>
<p id="section-7.7.1-1">
   A session may finish due to several reasons (client shutdown,
   client CANCEL request, constraints not reached, etc.), and any
   session finished <span class="bcp14">MUST</span> release the assigned resources.<a href="#section-7.7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.7.1-2">
   In order to release the assigned server resources for the session,
   the Expires header field indicates the maximum interval of time
   without exchanging any Q4S message.<a href="#section-7.7.1-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-7.8">
<section id="section-7.8">
        <h3 id="name-dynamic-constraints-and-flo">
<a href="#section-7.8" class="section-number selfRef">7.8. </a><a href="#name-dynamic-constraints-and-flo" class="section-name selfRef">Dynamic Constraints and Flows</a>
        </h3>
<p id="section-7.8-1">
   Depending on the nature of the application, the quality
   constraints to be reached may evolve, changing some or all quality
   constraint values in any direction.<a href="#section-7.8-1" class="pilcrow">¶</a></p>
<p id="section-7.8-2">
   The client <span class="bcp14">MUST</span> be able to deal with this possibility. When the
   server sends an SDP document attached to a response (200 OK or
   Q4S-ALERT, etc.), the client <span class="bcp14">MUST</span> take all the new received values,
   overriding any previous value in use.<a href="#section-7.8-2" class="pilcrow">¶</a></p>
<p id="section-7.8-3">
   The dynamic changes on the quality constraints can be a result
   of two possibilities:<a href="#section-7.8-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.8-4.1">The application communicates to the Q4S server a change in
      the constraints. In this case, the application requirements
      can evolve, and the Q4S server will be aware of them.<a href="#section-7.8-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.8-4.2">The application uses TCP flows. In that case, in order to
      guarantee a constant throughput, the nature of TCP behavior
      forces the use of a composite constraint function, which
      depends on RTT, packet loss, and a window control mechanism
      implemented in each TCP stack.<a href="#section-7.8-4.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.8-5">
   TCP throughput can be less than actual bandwidth if the
   Bandwidth-Delay Product (BDP) is large, or if the network suffers
   from a high packet loss rate. In both cases, TCP congestion
   control algorithms may result in a suboptimal performance.<a href="#section-7.8-5" class="pilcrow">¶</a></p>
<p id="section-7.8-6">
   Different TCP congestion control implementations like Reno <span>[<a href="#RENO" class="xref">RENO</a>]</span>,
   High Speed TCP <span>[<a href="#RFC3649" class="xref">RFC3649</a>]</span>, 
   CUBIC <span>[<a href="#I-D.rhee-tcpm-cubic" class="xref">CUBIC</a>]</span>, 
   Compound TCP (CTCP) <span>[<a href="#I-D.sridharan-tcpm-ctcp" class="xref">CTCP</a>]</span>, 
   etc., reach different throughputs under the same network
   conditions of RTT and packet loss. In all cases, depending on the
   RTT-measured value, the Q4S server could dynamically change the
   packetloss constraints (defined in the SDP) in order to make it possible
   to reach a required throughput or vice versa (using "measurement:packetloss"
   to change dynamically the latency constraints).<a href="#section-7.8-6" class="pilcrow">¶</a></p>
<p id="section-7.8-7">
   A general guideline for calculating the packet loss constraint and the RTT
   constraint consists of approximating the throughput by using a
   simplified formula, which should take into account the TCP stack
   implementation of the receiver, in addition to the RTT and packet
   loss:<a href="#section-7.8-7" class="pilcrow">¶</a></p>
<div id="section-7.8-8">
<pre class="sourcecode lang-pseudocode">
          Th= Function( RTT, packet loss, ...)
</pre><a href="#section-7.8-8" class="pilcrow">¶</a>
</div>
<p id="section-7.8-9">
   Then, depending on RTT-measured values, set dynamically the
   packet loss constraint.<a href="#section-7.8-9" class="pilcrow">¶</a></p>
<p id="section-7.8-10">
   It is possible to easily calculate a worst-case boundary for the
   Reno algorithm, which should ensure for all algorithms that the
   target throughput is actually achieved, except that high-speed
   algorithms will then have even larger throughput if more
   bandwidth is available.<a href="#section-7.8-10" class="pilcrow">¶</a></p>
<p id="section-7.8-11">
   For the Reno algorithm, the Mathis formula may be used <span>[<a href="#RENO" class="xref">RENO</a>]</span> for
   the upper bound on the throughput:<a href="#section-7.8-11" class="pilcrow">¶</a></p>
<div id="section-7.8-12">
<pre class="sourcecode lang-pseudocode">
          Th &lt;= (MSS/RTT)*(1 / sqrt{p})
</pre><a href="#section-7.8-12" class="pilcrow">¶</a>
</div>
<p id="section-7.8-13">
   In the absence of packet loss, a practical limit for the TCP
   throughput is the receiver_window_size divided by the RTT.
   However, if the TCP implementation uses a window scale
   option, this limit can reach the available bandwidth value.<a href="#section-7.8-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-7.9">
<section id="section-7.9">
        <h3 id="name-qos-level-upgrade-and-downg">
<a href="#section-7.9" class="section-number selfRef">7.9. </a><a href="#name-qos-level-upgrade-and-downg" class="section-name selfRef">"qos-level" Upgrade and Downgrade Operation</a>
        </h3>
<p id="section-7.9-1">
   Each time the server detects a violation of constraints, the alert
   mechanism is triggered, the "alert-pause" timer is started, and the
   "qos-level" is increased. When this happens repeatedly, and the 
   "qos-level" reaches its maximum value (value 9), the session is
   canceled. But when the violation of constraints stops before
   reaching "qos-level" maximum value, the recovery mechanism allows
   for the "qos-level" upgrade gradually.<a href="#section-7.9-1" class="pilcrow">¶</a></p>
<p id="section-7.9-2">
   This downgrade and upgrade of "qos-level" is explained
   with the following example:<a href="#section-7.9-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-7.9-3">
          <li id="section-7.9-3.1">A Q4S session is initiated successfully with "qos-level=0".<a href="#section-7.9-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-7.9-3.2">During the Continuity phase, violation of constraints is
      detected; the "qos-level" is increased to 1, a Q4S-ALERT is sent by
      the server to the client, and an "alert-pause" timer is started.<a href="#section-7.9-3.2" class="pilcrow">¶</a>
</li>
          <li id="section-7.9-3.3">The "alert-pause" timer expires, and still a violation of constraints
      is detected; the "qos-level" is increased to 2, a Q4S-ALERT is sent
      by the server to the client, and an "alert-pause" timer is started.<a href="#section-7.9-3.3" class="pilcrow">¶</a>
</li>
          <li id="section-7.9-3.4">The "alert-pause" timer expires, but the violation of constraints has
      stopped; the "recovery-pause" timer is started.<a href="#section-7.9-3.4" class="pilcrow">¶</a>
</li>
          <li id="section-7.9-3.5">The "recovery-pause" timer expires, and no violation of
      constraints has been detected. Meanwhile, the "qos-level" is
      decreased to 1, a Q4S-RECOVERY is sent by the server to the
      client, and the "recovery-pause" timer is started again.<a href="#section-7.9-3.5" class="pilcrow">¶</a>
</li>
          <li id="section-7.9-3.6">The "recovery-pause" timer expires again, and no violation of
      constraints has been detected. Meanwhile, the "qos-level" is
      decreased to 0, and a Q4S-RECOVERY is sent by the server to
      the client. The "recovery-pause" timer is not started this time as
      the "qos-level" has reached its initial value.<a href="#section-7.9-3.6" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-7.9-4">
   When the network configuration allows for the possibility of
   managing Q4S flows and application flows independently (either is
   a network-based QoS or a Q4S-aware network), the "qos-level"
   downgrade process could be managed more efficiently using a
   strategy that allows for carrying out "qos-level" downgrades
   excluding application flows from SDP dynamically. The Q4S flows would be
   downgraded to allow for measurements on a lower quality level
   without interference of the application flows. A Q4S client <span class="bcp14">MUST</span>
   allow this kind of SDP modification by the server.<a href="#section-7.9-4" class="pilcrow">¶</a></p>
<p id="section-7.9-5">
   Periodically (every several minutes, depending on the
   implementation) a Q4S-ALERT could be triggered, in which the level
   is downgraded for Q4S flows, excluding application flows from the
   embedded SDP of that request.<a href="#section-7.9-5" class="pilcrow">¶</a></p>
<p id="section-7.9-6">
   This mechanism allows the measurement at lower levels of quality while
   application flows continue using a higher "qos-level" value.<a href="#section-7.9-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.9-7.1">If the measurements in the lower level meet the quality
      constraints, then a Q4S-RECOVERY message to this lower "qos-level" may be triggered, in which the SDP includes the
      application flows in addition to the Q4S flows.<a href="#section-7.9-7.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.9-7.2">If the measurements in the lower level do not meet the
      constraints, then a new Q4S-ALERT to the previous "qos-level"
      <span class="bcp14">MUST</span> be triggered, in which the SDP includes only the Q4S
      flows.<a href="#section-7.9-7.2" class="pilcrow">¶</a>
</li>
        </ul>
<span id="name-possible-evolution-of-qos-l"></span><div id="ref-possible-evolution-of-qos-level">
<figure id="figure-14">
          <div class="artwork art-text alignLeft" id="section-7.9-8.1">
<pre>
        +------------------------------------------------+
        |                                                |
        | qos-level                                      |
        |   A                                            |
        |   |                                            |
        |  4|                                            |
        |   |                                            |
        |  3|             +------+                       |
        |   |             |      |                       |
        |  2|        +----+      +----+     +---         |
        |   |        |                |     |            |
        |  1|   +----+                +-----+            |
        |   |   |                                        |
        |  0+---+---------------------------------&gt; time |
        |                                                |
        +------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
<a href="#name-possible-evolution-of-qos-l" class="selfRef">Possible Evolution of "qos-level"</a>
          </figcaption></figure>
</div>
<p id="section-7.9-9">
   This mechanism, illustrated in <a href="#ref-possible-evolution-of-qos-level" class="xref">Figure 14</a>, avoids the risk of
   disturbing the application while the measurements are being run
   in lower levels. However, this optional optimization of resources
   <span class="bcp14">MUST</span> be used carefully.<a href="#section-7.9-9" class="pilcrow">¶</a></p>
<p id="section-7.9-10">
   The chosen period to measure a lower "qos-level" is implementation
   dependent. Therefore, it is not included as a "measurement:procedure" parameter. 
   It is <span class="bcp14">RECOMMENDED</span> to use a large value, such
   as 20 minutes.<a href="#section-7.9-10" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-8">
<section id="section-8">
      <h2 id="name-general-user-agent-behavior">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-general-user-agent-behavior" class="section-name selfRef">General User Agent Behavior</a>
      </h2>
<div id="sec-8.1">
<section id="section-8.1">
        <h3 id="name-roles-in-peer-to-peer-scena">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-roles-in-peer-to-peer-scena" class="section-name selfRef">Roles in Peer-to-Peer Scenarios</a>
        </h3>
<p id="section-8.1-1">
   In order to allow peer-to-peer applications, a Q4S User Agent (UA)
   <span class="bcp14">MUST</span> be able to assume both the client and server role. The role
   assumed depends on who sends the first message.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">
   In a communication between two UAs, the UA that first sends the Q4S
   BEGIN request to start the Handshake phase shall assume the client role.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
<p id="section-8.1-3">
   If both UAs send the BEGIN request at the same time, they will
   wait for a random time to restart again as shown in <a href="#ref-p2p-roles" class="xref">Figure 15</a>.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
<p id="section-8.1-4">
   Otherwise, an UA may be configured to act only as server (e.g.,
   content provider's side).<a href="#section-8.1-4" class="pilcrow">¶</a></p>
<span id="name-p2p-roles"></span><div id="ref-p2p-roles">
<figure id="figure-15">
          <div class="artwork art-text alignLeft" id="section-8.1-5.1">
<pre>
        +-----------------------------------------------+
        |                                               |
        | UA(Client)                         UA(Server) |
        |                                               |
        |     -------- Q4S BEGIN -------------&gt;         |
        |     &lt;------- Q4S BEGIN --------------         |
        |                                               |
        |     ------- Q4S BEGIN --------------&gt;         |
        |     &lt;------ Q4S 200 OK --------------         |
        |                                               |
        |                                               |
        +-----------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
<a href="#name-p2p-roles" class="selfRef">P2P Roles</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sec-8.2">
<section id="section-8.2">
        <h3 id="name-multiple-quality-sessions-i">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-multiple-quality-sessions-i" class="section-name selfRef">Multiple Quality Sessions in Parallel</a>
        </h3>
<p id="section-8.2-1">
   A Q4S session is intended to be used for an application. This means
   that for using the application, the client <span class="bcp14">MUST</span> establish only one
   Q4S session against the server. Indeed, the relation between
   the Session-Id and the application is 1 to 1.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="section-8.2-2">
   If a user wants to participate in several independent Q4S sessions
   simultaneously against different servers (or against the same
   server), it can execute different Q4S clients to establish
   separately different Q4S sessions, but it is <span class="bcp14">NOT RECOMMENDED</span>
   because:<a href="#section-8.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.2-3.1">The establishment of a new Q4S session may affect other
      running applications over other Q4S sessions during bandwidth
      measurement.<a href="#section-8.2-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.2-3.2">If the Negotiation phase is executed separately before
      running any application, the summation of bandwidth
      requirements could not be met when the applications are
      running in parallel.<a href="#section-8.2-3.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="sec-8.3">
<section id="section-8.3">
        <h3 id="name-general-client-behavior">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-general-client-behavior" class="section-name selfRef">General Client Behavior</a>
        </h3>
<p id="section-8.3-1">
   A Q4S client has different behaviors. We will use letters X, Y, and Z to
   designate each different behavior (follow the letters in
   <a href="#ref-phases-client-behaviors" class="xref">Figure 16</a> and their descriptions below).<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.3-2">
          <dt id="section-8.3-2.1">X)</dt>
          <dd style="margin-left: 2.0em" id="section-8.3-2.2">When it sends messages over TCP (methods BEGIN, READY, 
      Q4S-ALERT, Q4S-RECOVERY, and CANCEL), it behaves strictly like a state
      machine that sends requests and waits for responses. Depending
      on the response type, it enters into a new state.<a href="#section-8.3-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.3-3">
   When it sends UDP messages (methods PING and BWIDTH), a Q4S client
   is not strictly a state machine that sends messages and waits for
   responses because of the following:<a href="#section-8.3-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.3-4">
          <dt id="section-8.3-4.1">Y)</dt>
          <dd style="margin-left: 2.0em" id="section-8.3-4.2">During the measurement of latency, jitter, and packet loss, the PING
      requests are sent periodically, not just after receiving the response
      to the previous request. In addition, the client <span class="bcp14">MUST</span> answer the
      PING requests coming from the server, therefore the client
      assumes temporarily the role of a server.<a href="#section-8.3-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel" id="section-8.3-5">
          <dt id="section-8.3-5.1">Z)</dt>
          <dd style="margin-left: 2.0em" id="section-8.3-5.2">During the bandwidth and packet loss measurement stage, the client
      does not expect to receive responses when sending BWIDTH
      requests to the server. In addition, it <span class="bcp14">MUST</span> receive and process
      all server messages in order to achieve the downlink
      measurement.<a href="#section-8.3-5.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.3-6">
   The Q4S-ALERT and CANCEL may have a conventional answer if an
   error is produced, otherwise the corresponding answer is formatted
   as a request message.<a href="#section-8.3-6" class="pilcrow">¶</a></p>
<span id="name-phases-and-client-behaviors"></span><div id="ref-phases-client-behaviors">
<figure id="figure-16">
          <div class="artwork art-text alignLeft" id="section-8.3-7.1">
<pre>
  +-----------+------------------------+-----------+-----------+
  | Handshake |    Negotiation         |Continuity |Termination|
  |   Phase   |      Phase             |   Phase   |  Phase    |
  |           |                        |           |           |
  | X ---------&gt; Y --&gt; X --&gt; Z --&gt; X ---&gt; Y --&gt; X ---&gt; X       |
  |           |  A     |     A     |   |  A     |  |           |
  |           |  |     |     |     |   |  |     |  |           |
  |           |  +-----+     +-----+   |  +-----+  |           |
  |           |                        |           |           |
  +------------------------------------------------+-----------+
</pre>
</div>
<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
<a href="#name-phases-and-client-behaviors" class="selfRef">Phases and Client Behaviors</a>
          </figcaption></figure>
</div>
<div id="sec-8.3.1">
<section id="section-8.3.1">
          <h4 id="name-generating-requests">
<a href="#section-8.3.1" class="section-number selfRef">8.3.1. </a><a href="#name-generating-requests" class="section-name selfRef">Generating Requests</a>
          </h4>
<p id="section-8.3.1-1">
   A valid Q4S request formulated by a client <span class="bcp14">MUST</span>, at a minimum,
   contain the following header fields:<a href="#section-8.3.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.3.1-2">
            <dt id="section-8.3.1-2.1">If no SDP is included:</dt>
            <dd id="section-8.3.1-2.2">the header fields Session-Id and Sequence-Number are mandatory.<a href="#section-8.3.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.3.1-2.3">If SDP is included:</dt>
            <dd id="section-8.3.1-2.4">the Session-Id is embedded into the SDP,
      therefore the inclusion of the Session-Id header field is optional, but
      if present, must have the same value. Measurements are
      embedded into the SDP only for Q4S-ALERT messages in order to
      be signed.<a href="#section-8.3.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-8.3.1-3">
   At any time, if the server sends new SDP with updated values,
   the client <span class="bcp14">MUST</span> take it into account.<a href="#section-8.3.1-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-8.4">
<section id="section-8.4">
        <h3 id="name-general-server-behavior">
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-general-server-behavior" class="section-name selfRef">General Server Behavior</a>
        </h3>
<p id="section-8.4-1">
   If a server does not understand a header field in a request (that
   is, the header field is not defined in this specification or in
   any supported extension), the server <span class="bcp14">MUST</span> ignore that header field
   and continue processing the message.<a href="#section-8.4-1" class="pilcrow">¶</a></p>
<p id="section-8.4-2">
   The role of the server is changed at Negotiation and Continuity
   phases, in which the server <span class="bcp14">MUST</span> send packets to measure jitter,
   latency, and bandwidth. Therefore, the different behaviors of
   the server are (follow the letters in <a href="#ref-phases-server-behaviours" class="xref">Figure 17</a> 
and their descriptions below):<a href="#section-8.4-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.4-3">
          <dt id="section-8.4-3.1">R)</dt>
          <dd style="margin-left: 2.0em" id="section-8.4-3.2">
       When the client sends messages over TCP (methods BEGIN,
      READY Q4S-ALERT, Q4S-RECOVERY, and CANCEL), it behaves strictly
      like a state machine that receives messages and sends
      responses.<a href="#section-8.4-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.4-4">
   When the client begins to send UDP messages (methods PING and
   BWIDTH), a Q4S server is not strictly a state machine that
   receives messages and sends responses because of the following:<a href="#section-8.4-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.4-5">
          <dt id="section-8.4-5.1">S)</dt>
          <dd style="margin-left: 2.0em" id="section-8.4-5.2">
      During the measurement of latency, jitter, and packet loss, the PING
      requests are sent periodically by the client and also by the
      server. In this case, the server behaves as a server answering
      client requests but also behaves temporarily as a client,
      sending PING requests toward the client and receiving
      responses.<a href="#section-8.4-5.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel" id="section-8.4-6">
          <dt id="section-8.4-6.1">T)</dt>
          <dd style="margin-left: 2.0em" id="section-8.4-6.2">
      During bandwidth and packet loss measurement, the server sends
      BWIDTH requests to the client. In addition, it <span class="bcp14">MUST</span> receive and
      process client messages in order to achieve the uplink
      measurement.<a href="#section-8.4-6.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.4-7">
   The Q4S-ALERT and CANCEL may have a conventional answer if an
   error is produced, otherwise the corresponding answer is formatted
   as a request message.<a href="#section-8.4-7" class="pilcrow">¶</a></p>
<span id="name-phases-and-server-behaviors"></span><div id="ref-phases-server-behaviours">
<figure id="figure-17">
          <div class="artwork art-text alignLeft" id="section-8.4-8.1">
<pre>
  +-----------+------------------------+-----------+-----------+
  | Handshake |    Negotiation         |Continuity |Termination|
  |   Phase   |      Phase             |   Phase   |  Phase    |
  |           |                        |           |           |
  | R ---------&gt; S --&gt; R --&gt; T --&gt; R ---&gt; S --&gt; R ---&gt; R       |
  |           |  A     |     A     |   |  A     |  |           |
  |           |  |     |     |     |   |  |     |  |           |
  |           |  +-----+     +-----+   |  +-----+  |           |
  |           |                        |           |           |
  +------------------------------------------------+-----------+
</pre>
</div>
<figcaption><a href="#figure-17" class="selfRef">Figure 17</a>:
<a href="#name-phases-and-server-behaviors" class="selfRef">Phases and Server Behaviors</a>
          </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="sec-9">
<section id="section-9">
      <h2 id="name-implementation-recommendati">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-implementation-recommendati" class="section-name selfRef">Implementation Recommendations</a>
      </h2>
<div id="sec-9.1">
<section id="section-9.1">
        <h3 id="name-default-client-constraints">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-default-client-constraints" class="section-name selfRef">Default Client Constraints</a>
        </h3>
<p id="section-9.1-1">
   To provide a default configuration, it would be good if the
   client had a configurable set of quality headers in the
   implementation settings menu. Otherwise, these quality headers will
   not be present in the first message.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
<p id="section-9.1-2">
   Different business models (out of scope of this proposal) may be
   achieved: depending on who pays for the quality session, the
   server can accept certain client parameters sent in the first
   message, or force billing parameters on the server side.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-9.2">
<section id="section-9.2">
        <h3 id="name-latency-and-jitter-measurem">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-latency-and-jitter-measurem" class="section-name selfRef">Latency and Jitter Measurements</a>
        </h3>
<p id="section-9.2-1">
   Different client and server implementations may send a different
   number of PING messages for measuring, although at least 255
   messages should be considered to perform the latency measurement.
   The Stage 0 measurements may be considered ended only when neither
   the client nor server receive new PING messages after an
   implementation-dependent guard time. Only after, the client can send a
   "READY 1" message.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<p id="section-9.2-2">
   In execution systems, where the timers are not accurate, a
   recommended approach consists of including the optional Timestamp header field
   in the PING request with the time in which the message
   has been sent. This allows an accurate measurement of the jitter
   even with no identical intervals of time between PINGs.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-9.3">
<section id="section-9.3">
        <h3 id="name-bandwidth-measurements">
<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-bandwidth-measurements" class="section-name selfRef">Bandwidth Measurements</a>
        </h3>
<p id="section-9.3-1">
   In programming languages or operating systems with limited timers
   or clock resolution, it is recommended to use an approach based on
   several intervals to send messages of 1KB (= 8000 bits) in order
   to reach the required bandwidth consumption, using a rate as close
   as possible to a constant rate.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
<p id="section-9.3-2">
   For example, if the resolution is 1 millisecond, and the bandwidth
   to reach is 11 Mbps, a good approach consists of sending:<a href="#section-9.3-2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-9.3-3">
<pre>
      1 message of 1KB every 1 millisecond +

      1 message of 1KB every 3 milliseconds +

      1 message of 1KB every 23 milliseconds
</pre><a href="#section-9.3-3" class="pilcrow">¶</a>
</div>
<p id="section-9.3-4">
   The number of intervals depends on the required bandwidth and accuracy
   that the programmer wants to achieve.<a href="#section-9.3-4" class="pilcrow">¶</a></p>
<p id="section-9.3-5">
   Considering messages of 1KB (= 8000 bits), a general approach to
   determine these intervals is the following:<a href="#section-9.3-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-9.3-6">
          <dt>(1)</dt>
<dd id="section-9.3-6.1"> Compute target bandwidth / 8000 bits. In the example above, it is
            11 Mbps / 8000 = 1375 messages per second.<a href="#section-9.3-6.1" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-9.3-6.2"> Divide the number of messages per second by 1000 to determine
     the number of messages per millisecond: 1375 / 1000 = 1.375. The
      integer value is the number of messages per millisecond (in this
      case, one). The pending bandwidth is now 375 messages per second.<a href="#section-9.3-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(3)</dt>
<dd id="section-9.3-6.3">
            <p id="section-9.3-6.3.1"> To achieve the 375 messages per second, use a submultiple of
 1000, which must be less than 375:<a href="#section-9.3-6.3.1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-9.3-6.3.2">
<pre>
      1000 / 2 = 500 &gt; 375

      1000 / 3 = 333 &lt; 375
</pre><a href="#section-9.3-6.3.2" class="pilcrow">¶</a>
</div>
<p id="section-9.3-6.3.3">

   In this case, a message every 3 ms is suitable. The new pending
   target bandwidth is 375 - 333 = 42 messages per second.<a href="#section-9.3-6.3.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt>(4)</dt>
<dd id="section-9.3-6.4">
            <p id="section-9.3-6.4.1"> Repeat the same strategy as point 3 to reach the pending
         bandwidth. In this case, 23 ms is suitable because of the following:<a href="#section-9.3-6.4.1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-9.3-6.4.2">
<pre>
      1000 / 22 = 45 &gt; 42

      1000 / 23 = 43 &gt; 42

      1000 / 24 = 41.6 &lt; 42
</pre><a href="#section-9.3-6.4.2" class="pilcrow">¶</a>
</div>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-9.3-7">
   We can choose 24 ms, but then we need to cover an additional 0.4
   messages per second (42 - 41.6 = 0.4), and 43 is a number higher than
   42 but very close to it.<a href="#section-9.3-7" class="pilcrow">¶</a></p>
<p id="section-9.3-8">
   In execution systems where the timers are not accurate, a
   recommended approach consists of checking at each interval the
   number of packets that should have been sent at this timestamp
   since origin and send the needed number of packets in order to
   reach the required bandwidth.<a href="#section-9.3-8" class="pilcrow">¶</a></p>
<p id="section-9.3-9">
   The shorter the packets used, the more constant the rate of
   bandwidth measurement. However, this may stress the execution
   system in charge of receiving and processing packets. As a
   consequence, some packets may be lost because of stack overflows.
   To deal with this potential issue, a larger packet is <span class="bcp14">RECOMMENDED</span>
   (2KB or more), taking into account the overhead produced by the
   chunks' headers.<a href="#section-9.3-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-9.4">
<section id="section-9.4">
        <h3 id="name-packet-loss-measurement-res">
<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-packet-loss-measurement-res" class="section-name selfRef">Packet Loss Measurement Resolution</a>
        </h3>
<p id="section-9.4-1">
   Depending on the application nature and network conditions, a packet
   loss resolution less than 1% may be needed. In such cases, there
   is no limit to the number of samples used for this calculation. A
   trade-off between time and resolution should be reached in each
   case. For example, in order to have a resolution of 1/10000, the
   last 10000 samples should be considered in the packet loss
   measured value.<a href="#section-9.4-1" class="pilcrow">¶</a></p>
<p id="section-9.4-2">
   The problem of this approach is the reliability of old samples. If
   the interval used between PING messages is 50 ms, then to have a
   resolution of 1/1000, it takes 50 seconds, and a resolution of
   1/10000 takes 500 seconds (more than 8 minutes). The reliability
   of a packet loss calculation based on a sliding window of 8
   minutes depends on how fast network conditions evolve.<a href="#section-9.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-9.5">
<section id="section-9.5">
        <h3 id="name-measurements-and-reactions">
<a href="#section-9.5" class="section-number selfRef">9.5. </a><a href="#name-measurements-and-reactions" class="section-name selfRef">Measurements and Reactions</a>
        </h3>
<p id="section-9.5-1">
   Q4S can be used as a mechanism to measure and trigger network
   tuning and application-level actions (i.e. lowering video bit-rate, 
   reducing multiplayer interaction speed, etc.) in real time in
   order to reach the application constraints, addressing measured
   possible network degradation.<a href="#section-9.5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-9.6">
<section id="section-9.6">
        <h3 id="name-instability-treatments">
<a href="#section-9.6" class="section-number selfRef">9.6. </a><a href="#name-instability-treatments" class="section-name selfRef">Instability Treatments</a>
        </h3>
<p id="section-9.6-1">
   There are two scenarios in which Q4S can be affected by network
   problems: loss of Q4S packets and outlier samples.<a href="#section-9.6-1" class="pilcrow">¶</a></p>
<div id="sec-9.6.1">
<section id="section-9.6.1">
          <h4 id="name-loss-of-control-packets">
<a href="#section-9.6.1" class="section-number selfRef">9.6.1. </a><a href="#name-loss-of-control-packets" class="section-name selfRef">Loss of Control Packets</a>
          </h4>
<p id="section-9.6.1-1">
   Lost UDP packets (PING or BWIDTH messages) don't cause any
   problems for the Q4S state machine, but if TCP packets are
   delivered too late (which we will consider as "lost"), some
   undesirable consequences could arise.<a href="#section-9.6.1-1" class="pilcrow">¶</a></p>
<p id="section-9.6.1-2">
   Q4S does have protection mechanisms to overcome these situations.
   Examples:<a href="#section-9.6.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.6.1-3.1">If a BEGIN packet or its corresponding answer is lost, after
      a certain timeout, the client <span class="bcp14">SHOULD</span> resend another BEGIN
      packet, resetting the session<a href="#section-9.6.1-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.6.1-3.2">If a READY packet is lost, after a certain timeout, the
      client <span class="bcp14">SHOULD</span> resend another READY packet.<a href="#section-9.6.1-3.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.6.1-3.3">If a Q4S-ALERT request or its corresponding answer is lost,
      after a certain timeout, the originator <span class="bcp14">SHOULD</span> resend another
      Q4S-ALERT packet.<a href="#section-9.6.1-3.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.6.1-3.4">If a CANCEL request or its corresponding answer is lost,
      after a certain timeout, the originator <span class="bcp14">SHOULD</span> resend another
      CANCEL packet.<a href="#section-9.6.1-3.4" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="sec-9.6.2">
<section id="section-9.6.2">
          <h4 id="name-outlier-samples">
<a href="#section-9.6.2" class="section-number selfRef">9.6.2. </a><a href="#name-outlier-samples" class="section-name selfRef">Outlier Samples</a>
          </h4>
<p id="section-9.6.2-1">
   Outlier samples are those jitter or latency values far from the
   general/average values of most samples.<a href="#section-9.6.2-1" class="pilcrow">¶</a></p>
<p id="section-9.6.2-2">
   Hence, the Q4S default measurement method uses the statistical median
   formula for latency calculation, and the outlier samples are
   neutralized. This is a very common filter for noise or errors
   on signal and image processing.<a href="#section-9.6.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-9.7">
<section id="section-9.7">
        <h3 id="name-scenarios">
<a href="#section-9.7" class="section-number selfRef">9.7. </a><a href="#name-scenarios" class="section-name selfRef">Scenarios</a>
        </h3>
<p id="section-9.7-1">
   Q4S could be used in two scenarios:<a href="#section-9.7-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.7-2.1">client to ACP<a href="#section-9.7-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-9.7-2.2">client to client (peer-to-peer scenario)<a href="#section-9.7-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<div id="sec-9.7.1">
<section id="section-9.7.1">
          <h4 id="name-client-to-acp">
<a href="#section-9.7.1" class="section-number selfRef">9.7.1. </a><a href="#name-client-to-acp" class="section-name selfRef">Client to ACP</a>
          </h4>
<p id="section-9.7.1-1">
   One server:<a href="#section-9.7.1-1" class="pilcrow">¶</a></p>
<p id="section-9.7.1-2">
   It is the common scenario in which the client contacts the server to
   establish a Q4S session.<a href="#section-9.7.1-2" class="pilcrow">¶</a></p>
<p id="section-9.7.1-3">
   N servers:<a href="#section-9.7.1-3" class="pilcrow">¶</a></p>
<p id="section-9.7.1-4">
   In Content Delivery Networks and in general applications where
   delivery of contents can be achieved by different delivery nodes,
   two working mechanisms can be defined:<a href="#section-9.7.1-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-9.7.1-5">
            <dt id="section-9.7.1-5.1">Starting mode:</dt>
            <dd id="section-9.7.1-5.2">the end user may run Q4S against several delivery
      nodes and after some seconds choose the best one to start the
      multimedia session.<a href="#section-9.7.1-5.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.7.1-5.3">Prevention mode:</dt>
            <dd id="section-9.7.1-5.4">during a streaming session, the user keeps several
      Q4S dialogs against different alternative delivery nodes. In
      case of congestion, the end user <span class="bcp14">MAY</span> change to the best
      alternative delivery node.<a href="#section-9.7.1-5.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec-9.7.2">
<section id="section-9.7.2">
          <h4 id="name-client-to-client">
<a href="#section-9.7.2" class="section-number selfRef">9.7.2. </a><a href="#name-client-to-client" class="section-name selfRef">Client to Client</a>
          </h4>
<p id="section-9.7.2-1">
   In order to solve the client-to-client scenario, a Q4S register
   function <span class="bcp14">MUST</span> be implemented. This allows clients to contact each
   other for sending the BEGIN message. In this scenario, the
   Register server would be used by peers to publish their Q4S-Resource-Server header and their public IP address to
   enable the assumption of the server role.<a href="#section-9.7.2-1" class="pilcrow">¶</a></p>
<p id="section-9.7.2-2">
   The register function is out of scope of this protocol version
   because different HTTP mechanisms can be used, and Q4S <span class="bcp14">MUST NOT</span>
   force any.<a href="#section-9.7.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sec-10">
<section id="section-10">
      <h2 id="name-security-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<div id="sec-10.1">
<section id="section-10.1">
        <h3 id="name-confidentiality-issues">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-confidentiality-issues" class="section-name selfRef">Confidentiality Issues</a>
        </h3>
<p id="section-10.1-1">
   Because Q4S does not transport any application data, Q4S does not
   jeopardize the security of application data. However, other
   certain considerations may take place, like identity impersonation
   and measurements privacy and integrity.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-10.2">
<section id="section-10.2">
        <h3 id="name-integrity-of-measurements-a">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-integrity-of-measurements-a" class="section-name selfRef">Integrity of Measurements and Authentication</a>
        </h3>
<p id="section-10.2-1">
   Identity impersonation could potentially produce anomalous Q4S
   measurements. If this attack is based on spoofing of the server IP
   address, it can be avoided using the digital signature mechanism
   included in the SDP. The network can easily validate this digital
   signature using the public key of the server certificate.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
<p id="section-10.2-2">
   Integrity of Q4S measurements under any malicious manipulation
   (such as a Man-in-the-Middle (MITM) attack) relies on the same
   mechanism, the SDP signature.<a href="#section-10.2-2" class="pilcrow">¶</a></p>
<p id="section-10.2-3">
   The Signature header field contains the signed hash value of the SDP
   body in order to protect all the SDP data, including the
   measurements. This signature not only protects the integrity of
   data but also authenticates the server.<a href="#section-10.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-10.3">
<section id="section-10.3">
        <h3 id="name-privacy-of-measurements">
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-privacy-of-measurements" class="section-name selfRef">Privacy of Measurements</a>
        </h3>
<p id="section-10.3-1">
   This protocol could be supported over IPsec. Q4S relies on UDP and
   TCP, and IPsec supports both.  If Q4S is used for application-based 
   QoS, then IPsec is operationally valid; however, if Q4S is used to 
   trigger network-based actions, then measurements could be incorrect 
   unless the IPsec ports can be a target of potential action over the 
   network (such as prioritizing IPsec flows to measure the new, upgraded 
   state of certain application flows).<a href="#section-10.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-10.4">
<section id="section-10.4">
        <h3 id="name-availability-issues">
<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-availability-issues" class="section-name selfRef">Availability Issues</a>
        </h3>
<p id="section-10.4-1">
   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.<a href="#section-10.4-1" class="pilcrow">¶</a></p>
<p id="section-10.4-2">
   In order to mitigate availability issues caused by malicious
   attacks (such as DoS and DDoS), a good practice is to enable the Q4S
   service only for authenticated users. Q4S can be launched after the
   user is authenticated by the application. At this moment, the user's IP
   address is known, and the Q4S service may be enabled for this IP
   address. Otherwise, the Q4S service should appear unreachable.<a href="#section-10.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-10.5">
<section id="section-10.5">
        <h3 id="name-bandwidth-occupancy-issues">
<a href="#section-10.5" class="section-number selfRef">10.5. </a><a href="#name-bandwidth-occupancy-issues" class="section-name selfRef">Bandwidth Occupancy Issues</a>
        </h3>
<p id="section-10.5-1">
   Q4S bandwidth measurement is limited to the application needs. It
   means that all available bandwidth is not measured, but only the
   fraction required by the application. This allows other
   applications to use the rest of available bandwidth normally.<a href="#section-10.5-1" class="pilcrow">¶</a></p>
<p id="section-10.5-2">
   However, a malicious Q4S client could restart Q4S sessions just
   after finishing the Negotiation phase. The consequence would be to
   waste bandwidth for nothing.<a href="#section-10.5-2" class="pilcrow">¶</a></p>
<p id="section-10.5-3">
   In order to mitigate this possible anomalous behavior, it is
   <span class="bcp14">RECOMMENDED</span> to configure the server to reject sessions from the
   same endpoint when this situation is detected.<a href="#section-10.5-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-11">
<section id="section-11">
      <h2 id="name-future-code-point-requireme">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-future-code-point-requireme" class="section-name selfRef">Future Code Point Requirements</a>
      </h2>
<p id="section-11-1">
   If the ideas described in this document are pursued to become a
   protocol specification, then the code points described in this
   document will need to be assigned by IANA.<a href="#section-11-1" class="pilcrow">¶</a></p>
<div id="sec-11.1">
<section id="section-11.1">
        <h3 id="name-service-port">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-service-port" class="section-name selfRef">Service Port</a>
        </h3>
<p id="section-11.1-1">
   An assigned port would make possible a future Q4S-aware 
   network capable of reacting by itself to Q4S alerts. A
   specific port would simplify the identification of the protocol by
   network elements in charge of making possible reactive decisions.
   Therefore, the need for a port assignment by IANA may be postponed until there is the
   need for a future Q4S-aware network.<a href="#section-11.1-1" class="pilcrow">¶</a></p>
<p id="section-11.1-2">
   Service Name: Q4S<a href="#section-11.1-2" class="pilcrow">¶</a></p>
<p id="section-11.1-3">
   Transport Protocol(s): TCP<a href="#section-11.1-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-11.1-4">
          <dt id="section-11.1-4.1">Assignee:</dt>
          <dd style="margin-left: 1.5em" id="section-11.1-4.2">
            <p id="section-11.1-4.2.1">
 Name: Jose Javier Garcia Aranda<a href="#section-11.1-4.2.1" class="pilcrow">¶</a></p>
<p id="section-11.1-4.2.2">
 Email: jose_javier.garcia_aranda@nokia.com<a href="#section-11.1-4.2.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-4.3">Contact:</dt>
          <dd style="margin-left: 1.5em" id="section-11.1-4.4">
            <p id="section-11.1-4.4.1">
 Name: Jose Javier Garcia Aranda<a href="#section-11.1-4.4.1" class="pilcrow">¶</a></p>
<p id="section-11.1-4.4.2">
 Email: jose_javier.garcia_aranda@nokia.com<a href="#section-11.1-4.4.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel" id="section-11.1-5">
          <dt id="section-11.1-5.1">Description:</dt>
          <dd style="margin-left: 3.0em" id="section-11.1-5.2">
   The service associated with this request is in
   charge of the establishment of new Q4S sessions, and during the
   session, manages the handoff to a new protocol phase (Handshake,
   Negotiation and Continuity) as well as sends alerts when
   measurements do not meet the requirements.<a href="#section-11.1-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-5.3">Reference:</dt>
          <dd style="margin-left: 3.0em" id="section-11.1-5.4">
   This document. This service does not use IP-layer
   broadcast, multicast, or anycast communication.<a href="#section-11.1-5.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="sec-12">
<section id="section-12">
      <h2 id="name-iana-considerations">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-12-1">This document has no IANA actions.<a href="#section-12-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-13">
      <h2 id="name-references">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-13.1">
        <h3 id="name-normative-references">
<a href="#section-13.1" class="section-number selfRef">13.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC7230">[RFC7230]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor"> and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"</span>, <span class="seriesInfo">RFC 7230</span>, <span class="seriesInfo">DOI 10.17487/RFC7230</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7230">https://www.rfc-editor.org/info/rfc7230</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7231">[RFC7231]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor"> and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"</span>, <span class="seriesInfo">RFC 7231</span>, <span class="seriesInfo">DOI 10.17487/RFC7231</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7231">https://www.rfc-editor.org/info/rfc7231</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7232">[RFC7232]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor"> and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests"</span>, <span class="seriesInfo">RFC 7232</span>, <span class="seriesInfo">DOI 10.17487/RFC7232</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7232">https://www.rfc-editor.org/info/rfc7232</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7233">[RFC7233]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor">, Lafon, Y., Ed.</span><span class="refAuthor">, and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Range Requests"</span>, <span class="seriesInfo">RFC 7233</span>, <span class="seriesInfo">DOI 10.17487/RFC7233</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7233">https://www.rfc-editor.org/info/rfc7233</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7234">[RFC7234]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor">, Nottingham, M., Ed.</span><span class="refAuthor">, and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Caching"</span>, <span class="seriesInfo">RFC 7234</span>, <span class="seriesInfo">DOI 10.17487/RFC7234</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7234">https://www.rfc-editor.org/info/rfc7234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7235">[RFC7235]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor"> and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Authentication"</span>, <span class="seriesInfo">RFC 7235</span>, <span class="seriesInfo">DOI 10.17487/RFC7235</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7235">https://www.rfc-editor.org/info/rfc7235</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2818">[RFC2818]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"HTTP Over TLS"</span>, <span class="seriesInfo">RFC 2818</span>, <span class="seriesInfo">DOI 10.17487/RFC2818</span>, <time datetime="2000-05" class="refDate">May 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2818">https://www.rfc-editor.org/info/rfc2818</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3986">[RFC3986]</dt>
        <dd>
<span class="refAuthor">Berners-Lee, T.</span><span class="refAuthor">, Fielding, R.</span><span class="refAuthor">, and L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3629">[RFC3629]</dt>
        <dd>
<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a transformation format of ISO 10646"</span>, <span class="seriesInfo">STD 63</span>, <span class="seriesInfo">RFC 3629</span>, <span class="seriesInfo">DOI 10.17487/RFC3629</span>, <time datetime="2003-11" class="refDate">November 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3629">https://www.rfc-editor.org/info/rfc3629</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5322">[RFC5322]</dt>
        <dd>
<span class="refAuthor">Resnick, P., Ed.</span>, <span class="refTitle">"Internet Message Format"</span>, <span class="seriesInfo">RFC 5322</span>, <span class="seriesInfo">DOI 10.17487/RFC5322</span>, <time datetime="2008-10" class="refDate">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5322">https://www.rfc-editor.org/info/rfc5322</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5234">[RFC5234]</dt>
        <dd>
<span class="refAuthor">Crocker, D., Ed.</span><span class="refAuthor"> and P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01" class="refDate">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6234">[RFC6234]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span><span class="refAuthor"> and T. Hansen</span>, <span class="refTitle">"US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)"</span>, <span class="seriesInfo">RFC 6234</span>, <span class="seriesInfo">DOI 10.17487/RFC6234</span>, <time datetime="2011-05" class="refDate">May 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6234">https://www.rfc-editor.org/info/rfc6234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8017">[RFC8017]</dt>
        <dd>
<span class="refAuthor">Moriarty, K., Ed.</span><span class="refAuthor">, Kaliski, B.</span><span class="refAuthor">, Jonsson, J.</span><span class="refAuthor">, and A. Rusch</span>, <span class="refTitle">"PKCS #1: RSA Cryptography Specifications Version 2.2"</span>, <span class="seriesInfo">RFC 8017</span>, <span class="seriesInfo">DOI 10.17487/RFC8017</span>, <time datetime="2016-11" class="refDate">November 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8017">https://www.rfc-editor.org/info/rfc8017</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3264">[RFC3264]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor"> and H. Schulzrinne</span>, <span class="refTitle">"An Offer/Answer Model with Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 3264</span>, <span class="seriesInfo">DOI 10.17487/RFC3264</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3264">https://www.rfc-editor.org/info/rfc3264</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4566">[RFC4566]</dt>
      <dd>
<span class="refAuthor">Handley, M.</span><span class="refAuthor">, Jacobson, V.</span><span class="refAuthor">, and C. Perkins</span>, <span class="refTitle">"SDP: Session Description Protocol"</span>, <span class="seriesInfo">RFC 4566</span>, <span class="seriesInfo">DOI 10.17487/RFC4566</span>, <time datetime="2006-07" class="refDate">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4566">https://www.rfc-editor.org/info/rfc4566</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-13.2">
        <h3 id="name-informative-references">
<a href="#section-13.2" class="section-number selfRef">13.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC3550">[RFC3550]</dt>
        <dd>
<span class="refAuthor">Schulzrinne, H.</span><span class="refAuthor">, Casner, S.</span><span class="refAuthor">, Frederick, R.</span><span class="refAuthor">, and V. Jacobson</span>, <span class="refTitle">"RTP: A Transport Protocol for Real-Time Applications"</span>, <span class="seriesInfo">STD 64</span>, <span class="seriesInfo">RFC 3550</span>, <span class="seriesInfo">DOI 10.17487/RFC3550</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3550">https://www.rfc-editor.org/info/rfc3550</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0793">[RFC0793]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Transmission Control Protocol"</span>, <span class="seriesInfo">STD 7</span>, <span class="seriesInfo">RFC 793</span>, <span class="seriesInfo">DOI 10.17487/RFC0793</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc793">https://www.rfc-editor.org/info/rfc793</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0792">[RFC0792]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Control Message Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 792</span>, <span class="seriesInfo">DOI 10.17487/RFC0792</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc792">https://www.rfc-editor.org/info/rfc792</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-quic-transport">[QUIC]</dt>
        <dd>
<span class="refAuthor">Iyengar, J.</span><span class="refAuthor"> and M. Thomson</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-transport-29</span>, <time datetime="2020-06-09" class="refDate">9 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-transport-29">https://tools.ietf.org/html/draft-ietf-quic-transport-29</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4656">[RFC4656]</dt>
        <dd>
<span class="refAuthor">Shalunov, S.</span><span class="refAuthor">, Teitelbaum, B.</span><span class="refAuthor">, Karp, A.</span><span class="refAuthor">, Boote, J.</span><span class="refAuthor">, and M. Zekauskas</span>, <span class="refTitle">"A One-way Active Measurement Protocol (OWAMP)"</span>, <span class="seriesInfo">RFC 4656</span>, <span class="seriesInfo">DOI 10.17487/RFC4656</span>, <time datetime="2006-09" class="refDate">September 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4656">https://www.rfc-editor.org/info/rfc4656</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5357">[RFC5357]</dt>
        <dd>
<span class="refAuthor">Hedayat, K.</span><span class="refAuthor">, Krzanowski, R.</span><span class="refAuthor">, Morton, A.</span><span class="refAuthor">, Yum, K.</span><span class="refAuthor">, and J. Babiarz</span>, <span class="refTitle">"A Two-Way Active Measurement Protocol (TWAMP)"</span>, <span class="seriesInfo">RFC 5357</span>, <span class="seriesInfo">DOI 10.17487/RFC5357</span>, <time datetime="2008-10" class="refDate">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5357">https://www.rfc-editor.org/info/rfc5357</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3261">[RFC3261]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Schulzrinne, H.</span><span class="refAuthor">, Camarillo, G.</span><span class="refAuthor">, Johnston, A.</span><span class="refAuthor">, Peterson, J.</span><span class="refAuthor">, Sparks, R.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and E. Schooler</span>, <span class="refTitle">"SIP: Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 3261</span>, <span class="seriesInfo">DOI 10.17487/RFC3261</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3261">https://www.rfc-editor.org/info/rfc3261</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0768">[RFC0768]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"User Datagram Protocol"</span>, <span class="seriesInfo">STD 6</span>, <span class="seriesInfo">RFC 768</span>, <span class="seriesInfo">DOI 10.17487/RFC0768</span>, <time datetime="1980-08" class="refDate">August 1980</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc768">https://www.rfc-editor.org/info/rfc768</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RENO">[RENO]</dt>
        <dd>
<span class="refAuthor">Mathis, M.</span><span class="refAuthor">, Semke, J.</span><span class="refAuthor">, Mahdavi, J.</span><span class="refAuthor">, and T. Ott</span>, <span class="refTitle">"The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm"</span>, <span class="refContent">ACM SIGCOMM Computer Communication Review, pp. 67-82</span>, <span class="seriesInfo">DOI 10.1145/263932.264023</span>, <time datetime="1997-07" class="refDate">July 1997</time>, <span>&lt;<a href="https://doi.org/10.1145/263932.264023">https://doi.org/10.1145/263932.264023</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3649">[RFC3649]</dt>
        <dd>
<span class="refAuthor">Floyd, S.</span>, <span class="refTitle">"HighSpeed TCP for Large Congestion Windows"</span>, <span class="seriesInfo">RFC 3649</span>, <span class="seriesInfo">DOI 10.17487/RFC3649</span>, <time datetime="2003-12" class="refDate">December 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3649">https://www.rfc-editor.org/info/rfc3649</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.rhee-tcpm-cubic">[CUBIC]</dt>
        <dd>
<span class="refAuthor">Rhee, I.</span><span class="refAuthor">, Xu, L.</span><span class="refAuthor">, and S. Ha</span>, <span class="refTitle">"CUBIC for Fast Long-Distance Networks"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-rhee-tcpm-cubic-02</span>, <time datetime="2008-08-26" class="refDate">26 August 2008</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-rhee-tcpm-cubic-02">https://tools.ietf.org/html/draft-rhee-tcpm-cubic-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.sridharan-tcpm-ctcp">[CTCP]</dt>
      <dd>
<span class="refAuthor">Sridharan, M.</span><span class="refAuthor">, Tan, K.</span><span class="refAuthor">, Bansal, D.</span><span class="refAuthor">, and D. Thaler</span>, <span class="refTitle">"Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-sridharan-tcpm-ctcp-02</span>, <time datetime="2008-11-11" class="refDate">11 November 2008</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02">https://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="sec-13">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">
   Many people have made comments and suggestions contributing to
   this document. In particular, we would like to thank:<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">
   <span class="contact-name">Victor Villagra</span>, <span class="contact-name">Sonia Herranz</span>, 
   <span class="contact-name">Clara Cubillo Pastor</span>, <span class="contact-name">Francisco Duran Pina</span>, 
   <span class="contact-name">Michael Scharf</span>, <span class="contact-name">Jesus Soto Viso</span>, and 
   <span class="contact-name">Federico Guillen</span>.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">
   Additionally, we want to thank the Spanish Centre for the
   Development of Industrial Technology (CDTI) as well as the Spanish
   Science and Tech Ministry, which funds this initiative through
   their innovation programs.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-14">
<section id="section-appendix.b">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jacobo Perez Lajo</span></div>
<div dir="auto" class="left"><span class="org">Nokia Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jacobo.perez@nokia.com" class="email">jacobo.perez@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Luis Miguel Diaz Vizcaino</span></div>
<div dir="auto" class="left"><span class="org">Nokia Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Luismi.Diaz@nokia.com" class="email">Luismi.Diaz@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Gonzalo Munoz Fernandez</span></div>
<div dir="auto" class="left"><span class="org">Nokia Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:gonzalo.munoz_fernandez.ext@nokia.com" class="email">gonzalo.munoz_fernandez.ext@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Manuel Alarcon Granero</span></div>
<div dir="auto" class="left"><span class="org">Nokia Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:manuel.alarcon_granero.ext@nokia.com" class="email">manuel.alarcon_granero.ext@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Francisco Jose Juan Quintanilla</span></div>
<div dir="auto" class="left"><span class="org">Nokia Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:francisco_jose.juan_quintanilla.ext@nokia.com" class="email">francisco_jose.juan_quintanilla.ext@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Carlos Barcenilla</span></div>
<div dir="auto" class="left"><span class="org">Universidad Politecnica de Madrid</span></div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Juan Quemada</span></div>
<div dir="auto" class="left"><span class="org">Universidad Politecnica de Madrid</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jquemada@dit.upm.es" class="email">jquemada@dit.upm.es</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ignacio Maestro</span></div>
<div dir="auto" class="left"><span class="org">Tecnalia Research &amp; Innovation</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ignacio.maestro@tecnalia.com" class="email">ignacio.maestro@tecnalia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Lara Fajardo Ibañez</span></div>
<div dir="auto" class="left"><span class="org">Optiva Media</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:lara.fajardo@optivamedia.com" class="email">lara.fajardo@optivamedia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Pablo López Zapico</span></div>
<div dir="auto" class="left"><span class="org">Optiva Media</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Pablo.lopez@optivamedia.com" class="email">Pablo.lopez@optivamedia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">David Muelas Recuenco</span></div>
<div dir="auto" class="left"><span class="org">Universidad Autonoma de Madrid</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:dav.muelas@uam.es" class="email">dav.muelas@uam.es</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jesus Molina Merchan</span></div>
<div dir="auto" class="left"><span class="org">Universidad Autonoma de Madrid</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jesus.molina@uam.es" class="email">jesus.molina@uam.es</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jorge E. Lopez de Vergara Mendez</span></div>
<div dir="auto" class="left"><span class="org">Universidad Autonoma de Madrid</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jorge.lopez_vergara@uam.es" class="email">jorge.lopez_vergara@uam.es</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Victor Manuel Maroto Ortega</span></div>
<div dir="auto" class="left"><span class="org">Optiva Media</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:victor.maroto@optivamedia.com" class="email">victor.maroto@optivamedia.com</a>
</div>
</address>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jose Javier Garcia Aranda</span></div>
<div dir="auto" class="left"><span class="org">Nokia</span></div>
<div dir="auto" class="left"><span class="street-address">María Tubau 9</span></div>
<div dir="auto" class="left">
<span class="postal-code">28050</span> <span class="locality">Madrid</span> </div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+34%2091%20330%204348" class="tel">+34 91 330 4348</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:jose_javier.garcia_aranda@nokia.com" class="email">jose_javier.garcia_aranda@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mónica Cortés</span></div>
<div dir="auto" class="left"><span class="org">Nokia</span></div>
<div dir="auto" class="left"><span class="street-address">María Tubau 9</span></div>
<div dir="auto" class="left">
<span class="postal-code">28050</span> <span class="locality">Madrid</span> </div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:monica.cortes_sack@nokia.com" class="email">monica.cortes_sack@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Joaquín Salvachúa</span></div>
<div dir="auto" class="left"><span class="org">Universidad Politecnica de Madrid</span></div>
<div dir="auto" class="left"><span class="street-address">Avenida Complutense 30</span></div>
<div dir="auto" class="left">
<span class="postal-code">28040</span> <span class="locality">Madrid</span> </div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+34%2091%200672134" class="tel">+34 91 0672134</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:Joaquin.salvachua@upm.es" class="email">Joaquin.salvachua@upm.es</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Maribel Narganes</span></div>
<div dir="auto" class="left"><span class="org">Tecnalia Research &amp; Innovation</span></div>
<div dir="auto" class="left"><span class="extended-address">Parque Científico y Tecnológico de Bizkaia</span></div>
<div dir="auto" class="left"><span class="street-address">Astondo Bidea, Edificio 700</span></div>
<div dir="auto" class="left">
<span class="postal-code">E-48160</span> <span class="locality">Derio</span> <span class="region">Bizkaia</span>
</div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+34%20946%20430%20850" class="tel">+34 946 430 850</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:maribel.narganes@tecnalia.com" class="email">maribel.narganes@tecnalia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Iñaki Martínez-Sarriegui</span></div>
<div dir="auto" class="left"><span class="org">Optiva Media</span></div>
<div dir="auto" class="left"><span class="street-address">Edificio Europa II,<br>Calle Musgo 2, 1G,<br>28023 Madrid<br>Spain</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+34%2091%20297%207271" class="tel">+34 91 297 7271</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:inaki.martinez@optivamedia.com" class="email">inaki.martinez@optivamedia.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>