cur:

The instantaneous observation value of the metric from the most recent sample (i.e., the current value).

percentile, with the letter 'p' followed by a number:

Gives the percentile specified by the number following the letter 'p'. The number MUST be a non-negative JSON number in the range [0, 100] (i.e., greater than or equal to 0 and less than or equal to 100), followed by an optional decimal part, if higher precision is needed. The decimal part should start with the '.' separator (U+002E) and be followed by a sequence of one or more ASCII numbers between '0' and '9'. Assume that this number is y, and consider the case where the samples are coming from a random variable X. The metric then returns x, such that the probability of X is less than or equal to x, i.e., Prob(X <= x), = y/100. For example, delay-ow:p99 gives the 99th percentile of observed one-way delay; delay-ow:p99.9 gives the 99.9th percentile. Note that some systems use quantile, which is in the range [0, 1]. When there is a more common form for a given percentile, it is RECOMMENDED that the common form be used; that is, instead of p0, use min; instead of p50, use median; instead of p100, use max.

min:

The minimal value of the observations.

max:

The maximal value of the observations.

median:

The midpoint (i.e., p50) of the observations.

mean:

The arithmetic mean value of the observations.

stddev:

The standard deviation of the observations.

stdvar:

The standard variance of the observations.

Intended Semantics:

To specify the temporal and spatial aggregated delay of a stream of packets from the specified source to the specified destination. The base semantics of the metric is the Unidirectional Delay metric as defined in [RFC 8571], [RFC 8570], and [RFC 7471], but instead of specifying the delay for a link, it is the (temporal) aggregation of the link delays from the source to the destination. A non-normative reference definition of the end-to-end one-way delay metric is provided in [RFC 7679]. The spatial aggregation level is specified in the query context, e.g., provider-defined identifier (PID) to PID, or endpoint to endpoint, where the PID is as defined in Section 5.1 of RFC 7285.

Use:

This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.

POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 239
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "delay-ow"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}

HTTP/1.1 200 OK
Content-Length: 247
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "delay-ow"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    10,
      "ipv4:198.51.100.34": 20
    }
  }
}

POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 252
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "delay-ow"
  },
  "endpoints": {
    "srcs": [
      "ipv6:2001:db8:100::1"
    ],
    "dsts": [
      "ipv6:2001:db8:100::2",
      "ipv6:2001:db8:100::3"
    ]
  }
}

HTTP/1.1 200 OK
Content-Length: 257
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "delay-ow"
    }
  },
  "endpoint-cost-map": {
    "ipv6:2001:db8:100::1": {
      "ipv6:2001:db8:100::2": 10,
      "ipv6:2001:db8:100::3": 20
    }
  }
}

"nominal":

Typically, network one-way delay does not have a nominal value.

"sla":

Many networks provide delay-related parameters in their application-level SLAs. It is RECOMMENDED that the "parameters" field of an "sla" one-way delay metric include a link (i.e., a field named "link") providing a URI for the specification of SLA details, if available. Such a specification can be either (1) free text for possible presentation to the user or (2) a formal specification. The format of the specification is outside the scope of this document.

"estimation":

The exact estimation method is outside the scope of this document. There can be multiple sources for estimating one-way delay. For example, the ALTO server may estimate the end-to-end delay by aggregation of routing protocol link metrics; the server may also estimate the delay using active, end-to-end measurements -- for example, using the IPPM framework [RFC 2330].

Intended Semantics:

To specify temporal and spatial aggregated round-trip delay between the specified source and specified destination. The base semantics is that it is the sum of the one-way delay from the source to the destination and the one-way delay from the destination back to the source, where the one-way delay is as defined in Section 4.1. A non-normative reference definition of the end-to-end round-trip delay metric is provided in [RFC 2681]. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint).

Note that it is possible for a client to query two one-way delay (delay-ow) items and then compute the round-trip delay. The server should be cognizant of the consistency of values.

Use:

This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.

POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "delay-rt"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}

HTTP/1.1 200 OK
Content-Length: 245
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "delay-rt"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    4,
      "ipv4:198.51.100.34": 3
    }
  }
}

"nominal":

Typically, network round-trip delay does not have a nominal value.

"sla":

See the "sla" entry in Section 4.1.4.

"estimation":

See the "estimation" entry in Section 4.1.4. For estimation by aggregation of routing protocol link metrics, the aggregation should include all links from the source to the destination and then back to the source; for estimation using IPPM, the IPPM metric MUST be round-trip delay (i.e., IPPM RTDelay* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile).

Intended Semantics:

To specify temporal and spatial aggregated delay variation (also called delay jitter) with respect to the minimum delay observed on the stream over the one-way delay from the specified source and destination, where the one-way delay is as defined in Section 4.1. A non-normative reference definition of the end-to-end one-way delay variation metric is provided in [RFC 3393]. Note that [RFC 3393] allows the specification of a generic selection function F to unambiguously define the two packets selected to compute delay variations. This document defines the specific case where F selects the packet with the smallest one-way delay as the "first" packet. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint).

Note that in statistics, variation is typically evaluated by the distance from samples relative to the mean. In the context of networking, it is more commonly defined from samples relative to the min. This definition follows the networking convention.

Use:

This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.

POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 245
Content-Type: application/alto-endpointcostparams+json
Accept:
   application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "delay-variation"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}

HTTP/1.1 200 OK
Content-Length: 252
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "delay-variation"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    0,
      "ipv4:198.51.100.34": 1
    }
  }
}

"nominal":

Typically, network delay variation does not have a nominal value.

"sla":

See the "sla" entry in Section 4.1.4.

"estimation":

See the "estimation" entry in Section 4.1.4. For estimation by aggregation of routing protocol link metrics, the default aggregation of the average of delay variations is the sum of the link delay variations; for estimation using IPPM, the IPPM metric MUST be delay variation (i.e., IPPM OWPDV* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile).

Intended Semantics:

To specify the temporal and spatial aggregated one-way packet loss rate from the specified source and the specified destination. The base semantics of the metric is the Unidirectional Link Loss metric as defined in [RFC 8571], [RFC 8570], and [RFC 7471], but instead of specifying the loss for a link, it is the aggregated loss of all links from the source to the destination. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint).

Use:

This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.

POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "lossrate"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}

HTTP/1.1 200 OK
Content-Length: 248
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "lossrate"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    0,
      "ipv4:198.51.100.34": 0.01
    }
  }
}

"nominal":

Typically, the packet loss rate does not have a nominal value, although some networks may specify zero losses.

"sla":

See the "sla" entry in Section 4.1.4.

"estimation":

See the "estimation" entry in Section 4.1.4. For estimation by aggregation of routing protocol link metrics, the default aggregation of the average loss rate is the sum of the link loss rates. But this default aggregation is valid only if two conditions are met: (1) link loss rates are low and (2) one assumes that each link's loss events are uncorrelated with every other link's loss events. When loss rates at the links are high but independent, the general formula for aggregating loss, assuming that each link is independent, is to compute end-to-end loss as one minus the product of the success rate for each link. Aggregation when losses at links are correlated can be more complex, and the ALTO server should be cognizant of correlated loss rates. For estimation using IPPM, the IPPM metric MUST be packet loss (i.e., IPPM OWLoss* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile).

Intended Semantics:

To specify the number of hops in the path from the specified source to the specified destination. The hop count is a basic measurement of distance in a network and can be exposed as the number of router hops computed from the routing protocols originating this information. A hop, however, may represent other units. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint).

Use:

This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.

POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "hopcount"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}

HTTP/1.1 200 OK
Content-Length: 245
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "hopcount"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    5,
      "ipv4:198.51.100.34": 3
    }
  }
}

"nominal":

Typically, the hop count does not have a nominal value.

"sla":

Typically, the hop count does not have an SLA value.

"estimation":

The exact estimation method is outside the scope of this document. An example of estimating hop count values is by importing from IGP routing protocols. It is RECOMMENDED that the "parameters" field of an "estimation" hop count define the meaning of a hop.

Intended Semantics:

To give the throughput of a congestion control conforming TCP flow from the specified source to the specified destination. The throughput SHOULD be interpreted as only an estimation, and the estimation is designed only for bulk flows.

Use:

This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.

POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 234
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "tput"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}

HTTP/1.1 200 OK
Content-Length: 251
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "tput"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    256000,
      "ipv4:198.51.100.34": 128000
    }
  }
}

"nominal":

Typically, TCP throughput does not have a nominal value and SHOULD NOT be generated.

"sla":

Typically, TCP throughput does not have an SLA value and SHOULD NOT be generated.

"estimation":

The exact estimation method is outside the scope of this document. It is RECOMMENDED that the "parameters" field of an "estimation" TCP throughput metric include the following information: (1) the congestion control algorithm and (2) the estimation methodology. To specify (1), it is RECOMMENDED that the "parameters" field (object) include a field named "congestion-control-algorithm", which provides a URI for the specification of the algorithm; for example, for an ALTO server to provide estimation of the throughput of a CUBIC congestion control flow, its "parameters" field includes the "congestion-control-algorithm" field, with value being set to the URI for [RFC 9438]; for an ongoing congestion control algorithm such as BBR, a link to its specification can be added. To specify (2), the "parameters" field includes as many details as possible; for example, for the TCP Cubic throughout estimation, the "parameters" field specifies that the throughput is estimated by setting _C_ to 0.4, and the equation in RFC 9438, Section 5.1, Figure 8 is applied; as an alternative, the methodology may be based on the NUM model [Prophet] or the model described in [G2]. The exact specification of the "parameters" field is outside the scope of this document.

Intended Semantics:

To specify temporal and spatial residual bandwidth from the specified source to the specified destination. The base semantics of the metric is the Unidirectional Residual Bandwidth metric as defined in [RFC 8571], [RFC 8570], and [RFC 7471], but instead of specifying the residual bandwidth for a link, it is the residual bandwidth of the path from the source to the destination. Hence, it is the minimal residual bandwidth among all links from the source to the destination. When the max statistical operator is defined for the metric, it typically provides the minimum of the link capacities along the path, as the default value of the residual bandwidth of a link is its link capacity [RFC 8571] [RFC 8570] [RFC 7471]. The spatial aggregation unit is specified in the query context (e.g., PID to PID, or endpoint to endpoint).

The default statistical operator for residual bandwidth is the current instantaneous sample; that is, the default is assumed to be "cur".

Use:

This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.

POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 241
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "bw-residual"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}

HTTP/1.1 200 OK
Content-Length: 255
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "bw-residual"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2":  {
      "ipv4:192.0.2.89":       0,
      "ipv4:198.51.100.34": 2000
    }
  }
}

"nominal":

Typically, residual bandwidth does not have a nominal value.

"sla":

Typically, residual bandwidth does not have an SLA value.

"estimation":

See the "estimation" entry in Section 4.1.4. The current ("cur") residual bandwidth of a path is the minimal residual bandwidth of all links on the path.

Intended Semantics:

To specify temporal and spatial available bandwidth from the specified source to the specified destination. The base semantics of the metric is the Unidirectional Available Bandwidth metric as defined in [RFC 8571], [RFC 8570], and [RFC 7471], but instead of specifying the available bandwidth for a link, it is the available bandwidth of the path from the source to the destination. Hence, it is the minimal available bandwidth among all links from the source to the destination. The spatial aggregation unit is specified in the query context (e.g., PID to PID, or endpoint to endpoint).

The default statistical operator for available bandwidth is the current instantaneous sample; that is, the default is assumed to be "cur".

Use:

This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.

POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 244
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "bw-available"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}

HTTP/1.1 200 OK
Content-Length: 255
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "bw-available"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":       0,
      "ipv4:198.51.100.34": 2000
    }
  }
}

"nominal":

Typically, available bandwidth does not have a nominal value.

"sla":

Typically, available bandwidth does not have an SLA value.

"estimation":

See the "estimation" entry in Section 4.1.4. The current ("cur") available bandwidth of a path is the minimum of the available bandwidth of all links on the path.

Identifier:

The name of the desired ALTO cost source type.

Intended Semantics:

ALTO cost source types carry with them semantics to guide their usage by ALTO clients. Hence, a document defining a new type should provide guidance to both ALTO service providers and applications utilizing ALTO clients as to how values of the registered ALTO endpoint property should be interpreted.

Security Considerations:

ALTO cost source types expose information to ALTO clients. ALTO service providers should be made aware of the security ramifications related to the exposure of a cost source type.

[IANA-IPPM]

IANA, "Performance Metrics",
<https://www.iana.org/assignments/performance-metrics/>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3630]

D. Katz, K. Kompella, and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.

[RFC5305]

T. Li, and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008,
<https://www.rfc-editor.org/info/rfc5305>.

[RFC6390]

A. Clark, and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011,
<https://www.rfc-editor.org/info/rfc6390>.

[RFC7285]

R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. Roome, S. Shalunov, and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.

[RFC7471]

S. Giacalone, D. Ward, J. Drake, A. Atlas, and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8259]

T. Bray, "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.

[RFC8446]

E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

[RFC8570]

L. Ginsberg, S. Previdi, S. Giacalone, D. Ward, J. Drake, and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019,
<https://www.rfc-editor.org/info/rfc8570>.

[RFC8571]

L. Ginsberg, S. Previdi, Q. Wu, J. Tantsura, and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.

[RFC8895]

W. Roome, and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 2020,
<https://www.rfc-editor.org/info/rfc8895>.

[RFC9110]

R. Fielding, M. Nottingham, and J. Reschke, "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.

[RFC9438]

, , , , and , "CUBIC for Fast and Long-Distance Networks", RFC 9438, DOI 10.17487/RFC9438, August 2023,
<https://www.rfc-editor.org/info/rfc9438>.

[FlowDirector]

E Pujol, I Poese, J Zerwas, G Smaragdakis, and A Feldmann, "Steering Hyper-Giants' Traffic at Scale", December 2019.

[G2]

J Ros-Giralt, A Bohara, S Yellamraju, M Harper Langston, R Lethin, Y Jiang, L Tassiulas, J Li, Y Tan, and M Veeraraghavan, "On the Bottleneck Structure of Congestion-Controlled Networks", DOI 10.1145/3366707, December 2019,
<https://dl.acm.org/doi/10.1145/3366707>.

[Prometheus]

J Volz, and B Rabenstein, "Prometheus: A Next-Generation Monitoring System (Talk)", May 2015.

[Prophet]

J Zhang, K Gao, YR Yang, and J Bi, "Prophet: Toward Fast, Error-Tolerant Model-Based Throughput Prediction for Reactive Flows in DC Networks", December 2020,
<https://dl.acm.org/doi/10.1109/TNET.2020.3016838>.

[QUIC-THROUGHPUT-TESTING]

EXFO, K. Corre, "Framework for QUIC Throughput Testing", Internet-Draft draft-corre-quic-throughput-testing-00, September 2021,
<https://datatracker.ietf.org/doc/html/draft-corre-quic-throughput-testing-00>.

[RFC2330]

V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>.

[RFC2681]

G. Almes, S. Kalidindi, and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
<https://www.rfc-editor.org/info/rfc2681>.

[RFC3393]

C. Demichelis, and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>.

[RFC5357]

K. Hedayat, R. Krzanowski, A. Morton, K. Yum, and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.

[RFC7679]

G. Almes, S. Kalidindi, M. Zekauskas, and A. Morton, "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016,
<https://www.rfc-editor.org/info/rfc7679>.

[RFC7971]

M. Stiemerling, S. Kiesel, M. Scharf, H. Seidel, and S. Previdi, "Application-Layer Traffic Optimization (ALTO) Deployment Considerations", RFC 7971, DOI 10.17487/RFC7971, October 2016,
<https://www.rfc-editor.org/info/rfc7971>.

[RFC9000]

J. Iyengar, and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.

Qin Wu

Y. Richard Yang

Young Lee

Dhruv Dhody

Sabine Randriamasy

Luis Miguel Contreras Murillo