draft-ietf-ippm-initial-registry-06.txt   draft-ietf-ippm-initial-registry-07.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Standards Track M. Bagnulo Intended status: Standards Track M. Bagnulo
Expires: September 5, 2018 UC3M Expires: January 1, 2019 UC3M
P. Eardley P. Eardley
BT BT
K. D'Souza K. D'Souza
AT&T Labs AT&T Labs
March 4, 2018 June 30, 2018
Initial Performance Metric Registry Entries Initial Performance Metric Registry Entries
draft-ietf-ippm-initial-registry-06 draft-ietf-ippm-initial-registry-07
Abstract Abstract
This memo defines the Initial Entries for the Performance Metrics This memo defines the Initial Entries for the Performance Metrics
Registry. This version includes: Registry. This version includes:
* Revised implementation of Passive TCP RTT metrics in section 10 * Revised implementation of Passive TCP RTT metrics in section 10
(Adding HandShake metric). (from comments).
* remaining question on DNS measurement method(s) * remaining question on DNS measurement method(s)
Still need: Add MBM metric entry. Still need: Add MBM metric entry.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14[RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 1, 2019.
This Internet-Draft will expire on September 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 44 skipping to change at page 3, line 45
5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 26 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 26
6. DNS Response Latency and Loss Registry Entries . . . . . . . 26 6. DNS Response Latency and Loss Registry Entries . . . . . . . 26
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 27 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 27
6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 27 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 27
6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 27 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 27
6.1.6. Version (of Registry Format) . . . . . . . . . . . . 27 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 27
6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 27 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 27
6.2.1. Reference Definition . . . . . . . . . . . . . . . . 27 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 28
6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 28 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 28
6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 30 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 30
6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 30 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 30
6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 32 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 32
6.3.3. Traffic Filtering (observation) Details . . . . . . . 32 6.3.3. Traffic Filtering (observation) Details . . . . . . . 32
6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 32 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 32
6.3.5. Run-time Parameters and Data Format . . . . . . . . . 32 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 32
6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 34 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4.2. Reference Definition . . . . . . . . . . . . . . . . 34 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 34
6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 35 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 35
6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 35 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 35
6.5. Administrative items . . . . . . . . . . . . . . . . . . 35 6.5. Administrative items . . . . . . . . . . . . . . . . . . 35
6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 35 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 35
6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 35 6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 35
6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 35 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 35
6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 36 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 36
skipping to change at page 6, line 13 skipping to change at page 6, line 16
10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 68 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 68
10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 68 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 68
10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 68 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 68
10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 69 10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 69
10.1.4. Description . . . . . . . . . . . . . . . . . . . . 69 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 69
10.1.5. Change Controller . . . . . . . . . . . . . . . . . 69 10.1.5. Change Controller . . . . . . . . . . . . . . . . . 69
10.1.6. Version (of Registry Format) . . . . . . . . . . . . 69 10.1.6. Version (of Registry Format) . . . . . . . . . . . . 69
10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 69 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 69
10.2.1. Reference Definitions . . . . . . . . . . . . . . . 69 10.2.1. Reference Definitions . . . . . . . . . . . . . . . 69
10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 72 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 72
10.3. Method of Measurement . . . . . . . . . . . . . . . . . 73 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 72
10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 73 10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 73
10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 74 10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 74
10.3.3. Traffic Filtering (observation) Details . . . . . . 75 10.3.3. Traffic Filtering (observation) Details . . . . . . 75
10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 75 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 75
10.3.5. Run-time Parameters and Data Format . . . . . . . . 75 10.3.5. Run-time Parameters and Data Format . . . . . . . . 75
10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 76 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 76
10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 76 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 76 10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 76
10.4.2. Reference Definition . . . . . . . . . . . . . . . . 76 10.4.2. Reference Definition . . . . . . . . . . . . . . . . 76
10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 78 10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 78
skipping to change at page 8, line 11 skipping to change at page 8, line 15
This memo proposes an initial set of entries for the Performance This memo proposes an initial set of entries for the Performance
Metric Registry. It uses terms and definitions from the IPPM Metric Registry. It uses terms and definitions from the IPPM
literature, primarily [RFC2330]. literature, primarily [RFC2330].
Although there are several standard templates for organizing Although there are several standard templates for organizing
specifications of performance metrics (see [RFC2679] for an example specifications of performance metrics (see [RFC2679] for an example
of the traditional IPPM template, based to large extent on the of the traditional IPPM template, based to large extent on the
Benchmarking Methodology Working Group's traditional template in Benchmarking Methodology Working Group's traditional template in
[RFC1242], and see [RFC6390] for a similar template), none of these [RFC1242], and see [RFC6390] for a similar template), none of these
templates were intended to become the basis for the columns of an templates were intended to become the basis for the columns of an
IETF-wide registry of metrics. While examinating aspects of metric IETF-wide registry of metrics. While examining aspects of metric
specifications which need to be registered, it became clear that none specifications which need to be registered, it became clear that none
of the existing metric templates fully satisfies the particular needs of the existing metric templates fully satisfies the particular needs
of a registry. of a registry.
Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format
for a Performance Metric Registry. Section 5 of for a Performance Metric Registry. Section 5 of
[I-D.ietf-ippm-metric-registry] also gives guidelines for those [I-D.ietf-ippm-metric-registry] also gives guidelines for those
requesting registration of a Metric, that is the creation of entry(s) requesting registration of a Metric, that is the creation of entry(s)
in the Performance Metric Registry: "In essence, there needs to be in the Performance Metric Registry: "In essence, there needs to be
evidence that a candidate Registered Performance Metric has evidence that a candidate Registered Performance Metric has
skipping to change at page 26, line 34 skipping to change at page 26, line 34
an alternate metric, IPDV. an alternate metric, IPDV.
6. DNS Response Latency and Loss Registry Entries 6. DNS Response Latency and Loss Registry Entries
@@@@ comment from Brian: there is an interesting method for DNS @@@@ comment from Brian: there is an interesting method for DNS
measurement by encoding information in the query itself. It is a measurement by encoding information in the query itself. It is a
question of what exactly we are trying to measure: specific RR, or question of what exactly we are trying to measure: specific RR, or
the infrastructure itself. (at this time we measure a specific RR). the infrastructure itself. (at this time we measure a specific RR).
This section gives initial registry entries for DNS Response Latency This section gives initial registry entries for DNS Response Latency
and Loss. RFC 2681 [RFC2681] defines a Round-trip delay metric. We and Loss from a network user's perspective, for a specific named
resource. The metric can be measured repeatedly using different
names. RFC 2681 [RFC2681] defines a Round-trip delay metric. We
build on that metric by specifying several of the input parameters to build on that metric by specifying several of the input parameters to
precisely define two metrics for measuring DNS latency and loss. precisely define two metrics for measuring DNS latency and loss.
Note to IANA: Each Registry "Name" below specifies a single registry Note to IANA: Each Registry "Name" below specifies a single registry
entry, whose output format varies in accordance with the name. entry, whose output format varies in accordance with the name.
All column entries beside the ID, Name, Description, and Output All column entries beside the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes Reference Method categories are the same, thus this section proposes
two closely-related registry entries. As a result, IANA is also two closely-related registry entries. As a result, IANA is also
asked to assign corresponding URNs and URLs to each Named Metric. asked to assign corresponding URNs and URLs to each Named Metric.
6.1. Summary 6.1. Summary
This category includes multiple indexes to the registry entries, the This category includes multiple indexes to the registry entries, the
element ID and metric name. element ID and metric name.
<skipping some admin columns for now> <skipping some admin columns>
6.1.1. ID (Identifier) 6.1.1. ID (Identifier)
<insert numeric identifier, an integer> <insert numeric identifier, an integer>
IANA is asked to assign different numeric identifiers to each of the IANA is asked to assign different numeric identifiers to each of the
two Named Metrics. two Named Metrics.
6.1.2. Name 6.1.2. Name
skipping to change at page 27, line 28 skipping to change at page 27, line 30
RLDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Logical_Raw RLDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Logical_Raw
6.1.3. URI 6.1.3. URI
URI: Prefix urn:ietf:metrics:perf:<name> URI: Prefix urn:ietf:metrics:perf:<name>
URL: http://<TBD by IANA>/<name> URL: http://<TBD by IANA>/<name>
6.1.4. Description 6.1.4. Description
This is a metric for DNS Response performance from a network user's
perspective, for a specific named resource. The metric can be
measured repeatedly using different resource names.
RTDNS: This metric assesses the response time, the interval from the RTDNS: This metric assesses the response time, the interval from the
query transmission to the response. query transmission to the response.
RLDNS: This metric indicates that the response was deemed lost. In RLDNS: This metric indicates that the response was deemed lost. In
other words, the response time exceeded the maximum waiting time. other words, the response time exceeded the maximum waiting time.
6.1.5. Change Controller 6.1.5. Change Controller
IETF IETF
skipping to change at page 68, line 48 skipping to change at page 68, line 48
where <statistic> is one of: where <statistic> is one of:
o Mean o Mean
o Min o Min
o Max o Max
RTDelay_Passive_IP-TCP-HS_RFCXXXXsecY_Seconds_Singleton RTDelay_Passive_IP-TCP-HS_RFCXXXXsecY_Seconds_Singleton
@@@@ Note that a mid-point observer only has the opportuinty to Note that a mid-point observer only has the opportuinty to compose a
compose a single RTDelay on the TSC Hand Shake. single RTDelay on the TCP Hand Shake.
RTLoss_Passive_IP-TCP_RFCXXXXsecY_Packet_Count RTLoss_Passive_IP-TCP_RFCXXXXsecY_Packet_Count
10.1.3. URIs 10.1.3. URIs
URN: Prefix urn:ietf:metrics:perf:<name> URN: Prefix urn:ietf:metrics:perf:<name>
URL: http://<TBD by IANA>/<name> URL: http://<TBD by IANA>/<name>
10.1.4. Description 10.1.4. Description
RTDelay: This metric assesses the round-trip delay of TCP packets RTDelay: This metric assesses the round-trip delay of TCP packets
constituting a single connection, exchanged between two hosts. The constituting a single connection, exchanged between two hosts. We
Observation Point [RFC7011] is assumed to be in the network at a consider the measurement of round-trip delay based on a single
remote point from the end hosts. The Output is the Round-trip delay Observation Point [RFC7011] somewhere in the network. The Output is
for all successfully exchanged packets expressed as the <statistic> the Round-trip delay for all successfully exchanged packets expressed
of their conditional delay distribution, where <statistic> is one of: as the <statistic> of their conditional delay distribution, where
<statistic> is one of:
o Mean o Mean
o Min o Min
o Max o Max
RTLoss: This metric assesses the estimated loss count for TCP packets RTLoss: This metric assesses the estimated loss count for TCP packets
constituting a single connection, exchanged between two hosts. The constituting a single connection, exchanged between two hosts. We
Observation Point [RFC7011] is assumed to be in the network at a consider the measurement of round-trip delay based on a single
remote point from the end hosts. The Output is the estimated Loss Observation Point [RFC7011] somewhere in the network. The Output is
Count for the measurement interval. the estimated Loss Count for the measurement interval.
10.1.5. Change Controller 10.1.5. Change Controller
IETF IETF
10.1.6. Version (of Registry Format) 10.1.6. Version (of Registry Format)
1.0 1.0
10.2. Metric Definition 10.2. Metric Definition
skipping to change at page 70, line 18 skipping to change at page 70, line 18
[RFC2681] [RFC2681]
<specific section reference and additional clarifications, if needed> <specific section reference and additional clarifications, if needed>
This metric definition uses the terms singleton and sample as defined This metric definition uses the terms singleton and sample as defined
in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the
reference definition of the singleton (single value) Round-trip delay reference definition of the singleton (single value) Round-trip delay
metric. Section 3.4 of [RFC2681] provides the reference definition metric. Section 3.4 of [RFC2681] provides the reference definition
expanded to cover a multi-singleton sample.) expanded to cover a multi-singleton sample.)
With the Observation Point [RFC7011] (OP) located between the hosts With the Observation Point [RFC7011] (OP) typically located between
participating in the TCP connection, the Round-trip Delay metric the hosts participating in the TCP connection, the Round-trip Delay
requires two individual measurements between the OP and each host, metric requires two individual measurements between the OP and each
such that the Spatial Composition [RFC6049]of the measurements yields host, such that the Spatial Composition [RFC6049]of the measurements
a Round-trip Delay singleton. yields a Round-trip Delay singleton (we are extending the composition
of one-way subpath delays to subpath round-trip delay).
Using the direction of TCP SYN transmission to anchor the Using the direction of TCP SYN transmission to anchor the
nomenclature, host A sends the SYN and host B replies with SYN-ACK nomenclature, host A sends the SYN and host B replies with SYN-ACK
during connection establishment. The direction of SYN transfer is during connection establishment. The direction of SYN transfer is
the Forward direction of transmission, from A through OP to B considered the Forward direction of transmission, from A through OP
(Reverse is B through OP to A). to B (Reverse is B through OP to A).
Traffic filters reduce the packet stream at the OP to a Qualified Traffic filters reduce the packet stream at the OP to a Qualified
bidirectional flow packets. bidirectional flow packets.
In the definitions below, Corresponding Packets are transferred in In the definitions below, Corresponding Packets are transferred in
different directions and convey a common value in a TCP header field different directions and convey a common value in a TCP header field
that establishes correspondence (to the extent possible). Examples that establishes correspondence (to the extent possible). Examples
may be found in the TCP timestamp fields. may be found in the TCP timestamp fields.
For a real number, RTD_fwd, >> the Round-trip Delay in the Forward For a real number, RTD_fwd, >> the Round-trip Delay in the Forward
direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP
observed a Qualified packet to host B at wire-time T', that host B observed a Qualified Packet to host B at wire-time T', that host B
received that packet and sent a Corresponding Packet back to host A, received that packet and sent a Corresponding Packet back to host A,
and OP observed the Corresponding Packet at wire-time T' + RTD_fwd. and OP observed the Corresponding Packet at wire-time T' + RTD_fwd.
For a real number, RTD_rev, >> the Round-trip Delay in the Reverse For a real number, RTD_rev, >> the Round-trip Delay in the Reverse
direction from OP to host A at time T'' is RTD_rev << REQUIRES that direction from OP to host A at time T'' is RTD_rev << REQUIRES that
OP observed a Qualified packet to host A at wire-time T'', that host OP observed a Qualified Packet to host A at wire-time T'', that host
A received that packet and sent a Corresponding Packet back to host A received that packet and sent a Corresponding Packet back to host
B, and that OP observed the Corresponding Packet at wire-time T'' + B, and that OP observed the Corresponding Packet at wire-time T'' +
RTD_rev. RTD_rev.
Ideally, the packet sent from host B to host A in both definitions Ideally, the packet sent from host B to host A in both definitions
above SHOULD be the same packet (or, when measuring RTD_rev first, above SHOULD be the same packet (or, when measuring RTD_rev first,
the packet from host A to host B in both definitions should be the the packet from host A to host B in both definitions should be the
same). same).
The REQUIRED Composition Function for a singleton of Round-trip Delay The REQUIRED Composition Function for a singleton of Round-trip Delay
at time T (where T is the earliest of T' and T'' above) is: at time T (where T is the earliest of T' and T'' above) is:
RTDelay = RTD_fwd + RTD_rev RTDelay = RTD_fwd + RTD_rev
Note that when OP is located at host A or host B, one of the terms Note that when OP is located at host A or host B, one of the terms
composing RTDelay will be zero or negligible. composing RTDelay will be zero or negligible.
@@@@ NEW HS STUFF @@@@
When the Qualified and Corresponding Packets are a TCP-SYN and a TCP- When the Qualified and Corresponding Packets are a TCP-SYN and a TCP-
SYN-ACK, then RTD_fwd == RTD_HS_fwd. SYN-ACK, then RTD_fwd == RTD_HS_fwd.
When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a
TCP-ACK, then RTD_rev == RTD_HS_rev. TCP-ACK, then RTD_rev == RTD_HS_rev.
The REQUIRED Composition Function for a singleton of Round-trip Delay The REQUIRED Composition Function for a singleton of Round-trip Delay
for the connection Hand Shake: for the connection Hand Shake:
RTDelay_HS = RTD_HS_fwd + RTD_HS_rev RTDelay_HS = RTD_HS_fwd + RTD_HS_rev
@@@@ END new stuff
The definition of Round-trip Loss Count uses the nomenclature The definition of Round-trip Loss Count uses the nomenclature
developed above, based on observation of the TCP header sequence developed above, based on observation of the TCP header sequence
numbers and storing the sequence number gaps observed. Packet Losses numbers and storing the sequence number gaps observed. Packet Losses
can be inferred from: can be inferred from:
o Out-of-order segments: TCP segments are normally monotonically o Out-of-order segments: TCP segments are transmitted with
increasing. Section 3 of [RFC4737] describes the notion of "next monotonically increasing sequence numbers, but these segments may
expected" sequence numbers which can be adapted to TCP segments be received out of order. Section 3 of [RFC4737] describes the
(for the purpose of detecting reordered packets). Observation of notion of "next expected" sequence numbers which can be adapted to
out-of-order segments indicates loss on the path prior to the OP, TCP segments (for the purpose of detecting reordered packets).
and creates a gap. Observation of out-of-order segments indicates loss on the path
prior to the OP, and creates a gap.
o Duplicate segments: Section 2 of [RFC5560] defines identical o Duplicate segments: Section 2 of [RFC5560] defines identical
packets and is suitable for evaluation of TCP packets to detect packets and is suitable for evaluation of TCP packets to detect
duplication. Observation of duplicate segments *without a duplication. Observation of duplicate segments *without a
corresponding gap* indicates loss on the path following the OP corresponding gap* indicates loss on the path following the OP
(because they overlap part of the delivered sequence numbers (because they overlap part of the delivered sequence numbers
already observed at OP). already observed at OP).
Each observation of an out-of-order or duplicate infers a singleton Each observation of an out-of-order or duplicate infers a singleton
of loss, but composition of Round-trip Loss Counts will be conducted of loss, but composition of Round-trip Loss Counts will be conducted
skipping to change at page 72, line 40 skipping to change at page 72, line 38
* Protocol: Set to 06 (TCP) * Protocol: Set to 06 (TCP)
o IPv6 header values: o IPv6 header values:
* DSCP: set to 0 * DSCP: set to 0
* Protocol: Set to 06 (TCP) * Protocol: Set to 06 (TCP)
o TCP header values: o TCP header values:
* Flags: ACK, SYN, @@@@@ others?? * Flags: ACK, SYN, FIN, @@@@@ others??
* Checksum: the checksum MUST be calculated and included in the
header
* Timestamp Option (TSopt): Set * Timestamp Option (TSopt): Set
+ Kind: 8 + Kind: 8
+ Length: 10 bytes + Length: 10 bytes
o o
10.3. Method of Measurement 10.3. Method of Measurement
skipping to change at page 74, line 11 skipping to change at page 74, line 5
measurement using a packet unless it makes progress in the transfer measurement using a packet unless it makes progress in the transfer
(advances the left edge of the send window, consistent (advances the left edge of the send window, consistent
with[Strowes]). with[Strowes]).
A different heuristic from [Trammell-14] is to exclude any RTD_rev A different heuristic from [Trammell-14] is to exclude any RTD_rev
that is larger than previously observed values. This would tend to that is larger than previously observed values. This would tend to
exclude Reverse measurements taken when the Application has no data exclude Reverse measurements taken when the Application has no data
ready to send, because considerable time could be added to RTD_rev ready to send, because considerable time could be added to RTD_rev
from this source of error. from this source of error.
@@@@ Note that the above Heuristic assumes that host A is sending
data. Host A expecting a download would mean that this heuristic
should be applied to RTD_fwd.
The statistic calculations to summarize the delay (RTDelay) SHALL be The statistic calculations to summarize the delay (RTDelay) SHALL be
performed on the conditional distribution, conditioned on successful performed on the conditional distribution, conditioned on successful
Forward and Reverse measurements which follow the Heuristics. Forward and Reverse measurements which follow the Heuristics.
Method for Inferring Loss: Method for Inferring Loss:
The OP tracks sequence numbers and stores gaps for each direction of The OP tracks sequence numbers and stores gaps for each direction of
transmission, as well as the next-expected sequence number as in transmission, as well as the next-expected sequence number as in
[Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order [Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order
segments and Duplicate segments. segments and Duplicate segments.
skipping to change at page 76, line 5 skipping to change at page 76, line 5
interval. The start time is controlled through other means. interval. The start time is controlled through other means.
Td Optionally, the end of a measurement interval, (format "date-and- Td Optionally, the end of a measurement interval, (format "date-and-
time" as specified in Section 5.6 of [RFC3339], see also Section 3 time" as specified in Section 5.6 of [RFC3339], see also Section 3
of [RFC6991]), or the duration (see T0). The UTC Time Zone is of [RFC6991]), or the duration (see T0). The UTC Time Zone is
required by Section 6.1 of [RFC2330]. Alternatively, the end of required by Section 6.1 of [RFC2330]. Alternatively, the end of
the measurement interval MAY be controlled by the measured the measurement interval MAY be controlled by the measured
connection, where the second pair of FIN and ACK packets exchanged connection, where the second pair of FIN and ACK packets exchanged
between host A and B effectively ends the interval. between host A and B effectively ends the interval.
... ... TTL or Hop Limit Set at desired value.
10.3.6. Roles 10.3.6. Roles
<lists the names of the different roles from the measurement method> <lists the names of the different roles from the measurement method>
host A launches the SYN packet to open the connection, and host A launches the SYN packet to open the connection, and
synonymous with an IP address. synonymous with an IP address.
host B replies with the SYN-ACK packet to open the connection, and host B replies with the SYN-ACK packet to open the connection, and
synonymous with an IP address. synonymous with an IP address.
skipping to change at page 91, line 5 skipping to change at page 91, line 5
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>. 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>. 2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC8174] Leiba, B., "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>.
17.2. Informative References 17.2. Informative References
[RFC1242] Bradner, S., "Benchmarking Terminology for Network [RFC1242] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242,
July 1991, <https://www.rfc-editor.org/info/rfc1242>. July 1991, <https://www.rfc-editor.org/info/rfc1242>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
skipping to change at page 92, line 27 skipping to change at page 92, line 32
Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Protocol (RTCP) Extended Report (XR) Block for Burst/Gap
Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003,
September 2013, <https://www.rfc-editor.org/info/rfc7003>. September 2013, <https://www.rfc-editor.org/info/rfc7003>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594, Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015, DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>. <https://www.rfc-editor.org/info/rfc7594>.
[Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times", [Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times,
Communications of the ACM, Vol. 56 No. 10, Pages 57-64",
September 2013. September 2013.
[Trammell-14] [Trammell-14]
Trammell, B., "Inline Data Integrity Signals for Passive Trammell, B., "Inline Data Integrity Signals for Passive
Measurement", March 2014. Measurement, TMA 2014
https://trammell.ch/pdf/qof-tma14.pdf", March 2014.
Authors' Addresses Authors' Addresses
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown,, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
 End of changes. 29 change blocks. 
51 lines changed or deleted 63 lines changed or added

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