idnits 2.17.1 draft-ietf-ippm-route-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2330, updated by this document, for RFC5378 checks: 1998-05-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 11, 2019) is 1688 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2460' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'RFC2675' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: 'RFC4494' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'RFC5644' is defined on line 1077, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: 'RFC6437' is defined on line 1096, but no explicit reference was found in the text == Unused Reference: 'RFC6564' is defined on line 1106, but no explicit reference was found in the text == Unused Reference: 'RFC7045' is defined on line 1115, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-07 ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 2991 ** Downref: Normative reference to an Informational RFC: RFC 5835 ** Downref: Normative reference to an Informational RFC: RFC 7312 ** Downref: Normative reference to an Informational RFC: RFC 7799 ** Downref: Normative reference to an Experimental RFC: RFC 7820 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Alvarez-Hamelin 3 Internet-Draft Universidad de Buenos Aires 4 Updates: 2330 (if approved) A. Morton 5 Intended status: Standards Track AT&T Labs 6 Expires: March 14, 2020 J. Fabini 7 TU Wien 8 C. Pignataro 9 Cisco Systems, Inc. 10 R. Geib 11 Deutsche Telekom 12 September 11, 2019 14 Advanced Unidirectional Route Assessment (AURA) 15 draft-ietf-ippm-route-05 17 Abstract 19 This memo introduces an advanced unidirectional route assessment 20 (AURA) metric and associated measurement methodology, based on the IP 21 Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC 22 2330 in the areas of path-related terminology and path description, 23 primarily to include the possibility of parallel subpaths between a 24 given Source and Destination pair, owing to the presence of multi- 25 path technologies. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14[RFC2119] [RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on March 14, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Issues with Earlier Work to define Route . . . . . . . . 3 70 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Route Metric Terms and Definitions . . . . . . . . . . . . . 5 72 3.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 7 75 3.4. Related Round-Trip Delay and Loss Definitions . . . . . . 9 76 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10 78 4. Route Assessment Methodologies . . . . . . . . . . . . . . . 11 79 4.1. Active Methodologies . . . . . . . . . . . . . . . . . . 11 80 4.1.1. Temporal Composition for Route Metrics . . . . . . . 13 81 4.1.2. Routing Class C Identification . . . . . . . . . . . 14 82 4.1.3. Intermediate Observation Point Route Measurement . . 15 83 4.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 15 84 4.3. Combining Different Methods . . . . . . . . . . . . . . . 16 85 5. Background on Round-Trip Delay Measurement Goals . . . . . . 16 86 6. Tools to Measure Delays in the Internet . . . . . . . . . . . 17 87 7. RTD Measurements Statistics . . . . . . . . . . . . . . . . . 18 88 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 92 12. Appendix I MPLS Methods for Route Assessment . . . . . . . . 21 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 95 13.2. Informative References . . . . . . . . . . . . . . . . . 25 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 98 1. Introduction 100 The IETF IP Performance Metrics (IPPM) working group first created a 101 framework for metric development in [RFC2330]. This framework has 102 stood the test of time and enabled development of many fundamental 103 metrics. It has been updated in the area of metric composition 104 [RFC5835], and in several areas related to active stream measurement 105 of modern networks with reactive properties [RFC7312]. 107 The [RFC2330] framework motivated the development of "performance and 108 reliability metrics for paths through the Internet," and Section 5 of 109 [RFC2330] defines terms that support description of a path under 110 test. However, metrics for assessment of path components and related 111 performance aspects had not been attempted in IPPM when the [RFC2330] 112 framework was written. 114 This memo takes-up the route measurement challenge and specifies a 115 new route metric, two practical frameworks for methods of measurement 116 (using either active or hybrid active-passive methods [RFC7799]), and 117 round-trip delay and link information discovery using the results of 118 measurements. All route measurements are limited by the willingness 119 of hosts along the path to be discovered, to cooperate with the 120 methods used, or to recognize that the measurement operation is 121 taking place (such as when tunnels are present). 123 1.1. Issues with Earlier Work to define Route 125 Section 7 of [RFC2330] presented a simple example of a "route" metric 126 along with several other examples. The example is reproduced below 127 (where the reference is to Section 5 of [RFC2330]): 129 "route: The path, as defined in Section 5, from A to B at a given 130 time." 132 This example provides a starting point to develop a more complete 133 definition of route. Areas needing clarification include: 135 Time: In practice, the route will be assessed over a time interval, 136 because active path detection methods like [PT] rely on TTL limits 137 for their operation and cannot accomplish discovery of all hosts 138 using a single packet. 140 Type-P: The legacy route definition lacks the option to cater for 141 packet-dependent routing. In this memo, we assess the route for a 142 specific packet of Type-P, and reflect this in the metric 143 definition. The methods of measurement determine the specific 144 Type-P used. 146 Parallel Paths: This a reality of Internet paths and a strength of 147 advanced route assessment methods, so the metric must acknowledge 148 this possibility. Use of Equal Cost Multi-Path (ECMP) and Unequal 149 Cost Multi-Path (UCMP) technologies are common sources of parallel 150 subpaths. 152 Cloud Subpath: May contain hosts that do not decrement TTL or Hop 153 Limit, but may have two or more exchange links connecting 154 "discoverable" hosts or routers. Parallel subpaths contained 155 within clouds cannot be discovered. The assessment methods only 156 discover hosts or routers on the path that decrement TTL or Hop 157 Count, or cooperate with interrogation protocols. The presence of 158 tunnels and nested tunnels further complicate assessment by hiding 159 hops. 161 Hop: Although the [RFC2330] definition was a link-host pair, only 162 hosts are discoverable or have the capability to cooperate with 163 interrogation protocols where link information may be exposed. 165 The refined definition of Route metrics begins in the sections that 166 follow. 168 2. Scope 170 The purpose of this memo is to add new route metrics and methods of 171 measurement to the existing set of IPPM metrics. 173 The scope is to define route metrics that can identify the path taken 174 by a packet or a flow traversing the Internet between two hosts. 175 Although primarily intended for hosts communicating on the Internet 176 with IP, the definitions and metrics are constructed to be applicable 177 to other network domains, if desired. The methods of measurement to 178 assess the path may not be able to discover all hosts comprising the 179 path, but such omissions are often deterministic and explainable 180 sources of error. 182 Also, to specify a framework for active methods of measurement which 183 use the techniques described in [PT] at a minimum, and a framework 184 for hybrid active-passive methods of measurement, such as the Hybrid 185 Type I method [RFC7799] described in 186 [I-D.ietf-ippm-ioam-data](intended only for single administrative 187 domains), which do not rely on ICMP and provide a protocol for 188 explicit interrogation of nodes on a path. Combinations of active 189 methods and hybrid active-passive methods are also in-scope. 191 Further, this memo provides additional analysis of the round-trip 192 delay measurements made possible by the methods, in an effort to 193 discover more details about the path, such as the link technology in 194 use. 196 This memo updates Section 5 of [RFC2330] in the areas of path-related 197 terminology and path description, primarily to include the 198 possibility of parallel subpaths between a given Source and 199 Destination address pair (possibly resulting from Equal Cost Multi- 200 Path (ECMP) and Unequal Cost Multi-Path (UCMP) technologies). 202 There are several simple non-goals of this memo. There is no attempt 203 to assess the reverse path from any host on the path to the host 204 attempting the path measurement. The reverse path contribution to 205 delay will be that experienced by ICMP packets (in active methods), 206 and may be different from delays experienced by UDP or TCP packets. 207 Also, the round trip delay will include an unknown contribution of 208 processing time at the host that generates the ICMP response. 209 Therefore, the ICMP-based active methods are not supposed to yield 210 accurate, reproducible estimations of the round-trip delay that UDP 211 or TCP packets will experience. 213 3. Route Metric Terms and Definitions 215 This section sets requirements for the following components to 216 support the Route Metric: 218 Host A Host as defined in [RFC2330] (a computer capable of IP 219 communication, includes routers), a.k.a. RFC 2330 Host. 221 Node A Node is any network function on the path capable of IP-layer 222 Communication, includes RFC 2330 Hosts. 224 Node Identity The unique address for Nodess communicating within the 225 network domain. For Nodes communicating on the Internet with IP, 226 it is the globally routable IP address(es) which the Node uses 227 when communicating with other Nodes under normal or error 228 conditions. The Node Identity revealed (and its connection to a 229 Node Name through reverse DNS) determines whether interfaces to 230 parallel links can be associated with a single Node, or appear to 231 identify unique Nodes. 233 Discoverable Node Nodes that convey their Node Identity according to 234 the requirements of their network domain, such as when error 235 conditions are detected by that Node. For Nodes communicating 236 with IP packets, compliance with Section 3.2.2.4 of [RFC1122] when 237 discarding a packet due to TTL or Hop Limit Exceeded condition, 238 MUST result in sending the corresponding Time Exceeded message 239 (containing a form of Node identity) to the source. This 240 requirement is also consistent with section 5.3.1 of [RFC1812] for 241 routers. 243 Cooperating Node Nodes that MUST respond to direct queries for their 244 Node identity as part of a previously agreed and established 245 interrogation protocol. Nodes SHOULD also provide information 246 such as arrival/departure interface identification, arrival 247 timestamp, and any relevant information about the Node or specific 248 link which delivered the query to the Node. 250 Hop A Hop MUST contain a Node Identity, and MAY contain arrival and/ 251 or departure interface identification, round trip delay, and an 252 arrival timestamp. 254 3.1. Formal Name 256 Type-P-Route-Ensemble-Method-Variant, abbreviated as Route Ensemble. 258 Note that Type-P depends heavily on the chosen method and variant. 260 3.2. Parameters 262 This section lists the REQUIRED input factors to specify a Route 263 metric. 265 o Src, the address of a Node (such as the globally routable IP 266 address). 268 o Dst, the address of a Node (such as the globally routable IP 269 address). 271 o i, the limit on the number of Hops a specific packet may visit as 272 it traverses from the Node at Src to the Node at Dst (such as the 273 TTL or Hop Limit). 275 o MaxHops, the maximum value of i used, (i=1,2,3,...MaxHops). 277 o T0, a time (start of measurement interval) 279 o Tf, a time (end of measurement interval) 281 o T, the Node time of a packet as measured at MP(Src), meaning 282 Measurement Point at the Source. 284 o Ta, the Node time of a reply packet's *arrival* as measured at 285 MP(Src), assigned to packets that arrive within a "reasonable" 286 time (see parameter below). 288 o Tmax, a maximum waiting time for reply packets to return to the 289 source, set sufficiently long to disambiguate packets with long 290 delays from packets that are discarded (lost), such that the 291 distribution of round-trip delay is not truncated. 293 o F, the number of different flows simulated by the method and 294 variant. 296 o flow, the stream of packets with the same n-tuple of designated 297 header fields that (when held constant) result in identical 298 treatment in a multi-path decision (such as the decision taken in 299 load balancing). Note: The IPv6 flow label MAY be included in the 300 flow definition when routers have complied with [RFC6438] 301 guidelines at the Tunnel End Points (TEP), and the source of the 302 measurement is a TEP. 304 o Type-P, the complete description of the packets for which this 305 assessment applies (including the flow-defining fields). 307 3.3. Metric Definitions 309 This section defines the REQUIRED measurement components of the Route 310 metrics (unless otherwise indicated): 312 M, the total number of packets sent between T0 and Tf. 314 N, the smallest value of i needed for a packet to be received at Dst 315 (sent between T0 and Tf). 317 Nmax, the largest value of i needed for a packet to be received at 318 Dst (sent between T0 and Tf). Nmax may be equal to N. 320 Next, define a *singleton* definition for a Hop on the path, with 321 sufficient indexes to identify all Hops identified in a measurement 322 interval. 324 A Hop, designated h(i,j), the IP address and/or identity of one of j 325 Discoverable Nodes (or Cooperating Nodes) that are i hops away from 326 the Node with address = Src during the measurement interval, T0 to 327 Tf. As defined above, a Hop singleton measurement MUST contain a 328 Node Identity, hid(i,j), and MAY contain one or more of the following 329 attributes: 331 o a(i,j) Arrival Interface ID (e.g., when [RFC5837] is supported) 333 o d(i,j) Departure Interface ID (e.g., when [RFC5837] is supported) 334 o t(i,j) Arrival Timestamp (where t(i,j) is ideally supplied by the 335 hop, or approximated from the sending time of the packet that 336 revealed the hop) 338 o Measurements of Round Trip Delay (for each packet that reveals the 339 same Node Identity and attributes, but not timestamp of course, 340 see next section) 342 Now that Node Identities and related information can be positioned 343 according to their distance from the Node with address Src in hops, 344 we introduce two forms of Routes: 346 A Route Ensemble is defined as the combination of all routes 347 traversed by different flows from the Node at Src address to the Node 348 at Dst address. The route traversed by each flow (with addresses Src 349 and Dst, and other fields which constitute flow criteria) is a member 350 of the ensemble and called a Member Route. 352 Using h(i,j) and components and parameters, further define: 354 When considering the set of Hops in the context of a single flow, a 355 Member Route j is an ordered list {h(1,j), ... h(Nj, j)} where h(i-1, 356 j) and h(i, j) are by 1 hop away from each other and Nj satisfying 357 h(Nj,j)=Dst is the minimum count of hops needed by the packet on 358 Member Route j to reach Dst. Member Routes must be unique. The 359 uniqueness property requires that any two Member routes j and k that 360 are part of the same Route Ensemble differ either in terms of minimum 361 hop count Nj and Nk to reach the destination Dst, or, in the case of 362 identical hop count Nj=Nk, they have at least one distinct hop: 363 h(i,j) != h(i, k) for at least one i (i=1..Nj). 365 All the optional information collected to describe a Member Route, 366 such as the arrival interface, departure interface, and Round Trip 367 Delay at each Hop, turs each list item into a rich structure. There 368 may be information on the links between Hops, possibly information on 369 the routing (arrival int. to departure int.), an estimate of distance 370 between Hops based on Round Trip Delay measurements and calculations, 371 and a time stamp indicating when all the additional detail was valid. 373 The Route Ensemble from Src to Dst, during the measurement interval 374 T0 to Tf, is the aggregate of all m distinct Member Routes discovered 375 between the two Nodes with Src and Dst addresses. More formally, 376 with the Node having address Src omitted: 378 Route Ensemble = { 379 {h(1,1), h(2,1), h(3,1), ... h(N1,1)=Dst}, 380 {h(1,2), h(2,2), h(3,2),..., h(N2,2)=Dst}, 381 ... 382 {h(1,m), h(2,m), h(3,m), ....h(Nm,m)=Dst} 383 } 385 where the following conditions apply: i <= Nj <= Nmax (j=1..m) 387 Note that some h(i,j) may be empty (null) in the case that systems do 388 not reply (not discoverable, or not cooperating). 390 h(i-1,j) and h(i,j) are the Hops on the same Member Route one hop 391 away from each other. 393 Hop h(i,j) may be identical with h(k,l) for i!=k and j!=l ; which 394 means there may be portions shared among different Member Routes 395 (parts of various routes may overlap). 397 3.4. Related Round-Trip Delay and Loss Definitions 399 RTD(i,j,T) is defined as a singleton of the [RFC2681] Round-trip 400 Delay between the Node with address = Src and the Node at Hop h(i,j) 401 at time T. 403 RTL(i,j,T) is defined as a singleton of the [RFC6673] Round-trip Loss 404 between the Node with address = Src and the Node at Hop h(i,j) at 405 time T. 407 3.5. Discussion 409 Depending on the way that Node Identity is revealed, it may be 410 difficult to determine parallel subpaths between the same pair of 411 Nodes (i.e. multiple parallel links). It is easier to detect 412 parallel subpaths involving different Nodes. 414 o If a pair of discovered Nodes identify two different addresses, 415 then they will appear to be different Nodes. 417 o If a pair of discovered Nodes identify two different IP addresses, 418 and the IP addresses resolve to the same Node name (in the DNS), 419 then they will appear to be the same Nodes. 421 o If a discovered Node always replies using the same network 422 address, regardless of the interface a packet arrives on, then 423 multiple parallel links cannot be detected in that network domain. 425 This condition may apply to traceroute-style methods, but may not 426 apply to other hybrid methods based on IOAM. 428 o If parallel links between routers are aggregated below the IP 429 layer, In other words, all links share the same pair of IP 430 addresses, then the existence of these parallel links can't be 431 detected at IP layer. This applies to other network domains with 432 layers below them, as well. 434 @@@@ This paragraph on Temporal Composition moved to support a more 435 complete section on Methodology (section 4). 437 When a route assessment employs IP packets (for example), the reality 438 of flow assignment to parallel subpaths involves layers above IP. 439 Thus, the measured Route Ensemble is applicable to IP and higher 440 layers (as described in the methodology's packet of Type-P and flow 441 parameters). 443 @@@@ The Temporal Measurement and Route Class C (unrelated to address 444 classes of the past) is now partly addressed in Section 4. 446 3.6. Reporting the Metric 448 @@@@ now partly addressed, based on feedback at IETF-101: 450 An Information Model and an XML Data Model for Storing Traceroute 451 Measurements is available in [RFC5388]. The measured information at 452 each hop includes four pieces of information: a one-dimensional hop 453 index, Node symbolic address, Node IP address, and RTD for each 454 response. 456 The description of Hop information that may be collected according to 457 this memo covers more dimensions, as defined in Section 3.3 above. 458 For example, the Hop index is two-dimensional to capture the 459 complexity of a Route Ensemble, and it contains corresponding Node 460 identities at a minimum. The models need to be expanded to include 461 these features, as well as Arrival Interface ID, Departure Interface 462 ID, and Arrival Timestamp, when available. 464 @@@@ can we leave updates to RFC 5388 for further work? Or, do we 465 need to take-on this topic in an Appendix here? IETF-105 feedback 466 indicates that we should collect requirements here, and punt future 467 work to a YANG model. 469 4. Route Assessment Methodologies 471 There are two classes of methods described in this section, active 472 methods relying on the reaction to TTL or Hop Limit Exceeded 473 condition to discover Nodes on a path, and Hybrid active-passive 474 methods that involve direct interrogation of cooperating Nodes 475 (usually within a single domain). Description of these methods 476 follow. 478 @@@@ Editor's Note: We need to incorporate description of Type-P 479 packets (with the flow parameters) used in each method below (done 480 for Active). 482 4.1. Active Methodologies 484 We have chosen to describe the method based on that employed in 485 current open source tools, thereby providing a practical framework 486 for further advanced techniques to be included as method variants. 487 This method is applicable to use across multiple administrative 488 domains. 490 Paris-traceroute [PT] provides some measure of protection from path 491 variation generated by ECMP load balancing, and it ensures traceroute 492 packets will follow the same path in 98% of cases according to 493 [SCAMPER]. If it is necessary to find every path possible between 494 two Nodes, Paris-traceroute provides "exhaustive" mode while scamper 495 provides "tracelb" (stands for traceroute load balance). 497 The Type-P of packets used could be ICMP (as in the original 498 traceroute), UDP or TCP. The later are used when a particular 499 characteristic needs to be to verified, such as filtering or traffic 500 shaping on specific ports (i.e., services). [SCAMPER] supports IPv6 501 traceroute measurements, keeping the FlowLable constant in all 502 packets. 504 The advanced route assessment methods used in Paris-traceroute [PT] 505 keep the critical fields constant for every packet to maintain the 506 appearance of the same flow. Since route assessment can be conducted 507 using TCP, UDP or ICMP packets, this method REQUIRES the Diffserv 508 field, the protocol number, IP source and destination addresses, and 509 the port settings for TCP or UDP kept constant. For ICMP probes, the 510 method additionally REQUIRES keeping the type, code, and ICMP 511 checksum constant; which occupy the corresponding positions in the 512 header of an IP packet, e.g., bytes 20 to 23 when the header IP has 513 no options. 515 Maintaining a constant checksum in ICMP is most challenging because 516 the ICMP Sequence Number is part of the calculation. The advanced 517 traceroute method requires calculations using the IP Sequence Number 518 Field and the Identifier Field, yielding a constant ICMP checksum in 519 successive packets. For an example of calculations to maintain a 520 constant checksum, see Appendix A of [RFC7820], where revision of a 521 timestamp field is complemented by modifying the 2 octet checksum 522 complement field (these fields take the roles of the ICMP Sequence 523 Number and Identifier Fields, respectively). 525 For TCP and UDP packets, the checksum must also be kept constant. 526 Therefore, the first four bytes of UDP (or TCP) data field are 527 modified to compensate for fields that change from packet to packet. 529 @@@@ Note: other variants of advanced traceroute are planned be 530 described. 532 Finally, the return path is also important to check. Taking into 533 account that it is an ICMP time exceeded (during transit) packet, the 534 source and destination IP are constant for every reply. Then, we 535 should consider the fields in the first 32 bits of the protocol on 536 the top of IP: the type and code of ICMP packet, and its checksum. 537 Again, to maintain the ICMP checksum constant for the returning 538 packets, we need to consider the whole ICMP message. It contains the 539 IP header of the discarded packet plus the first 8 bytes of the IP 540 payload; that is some of the fields of TCP header, the UDP header 541 plus four data bytes, the ICMP header plus four bytes. Therefore, 542 for UDP case the data field is used to maintain the ICMP checksum 543 constant in the returning packet. For the ICMP case, the identifier 544 and sequence fields of the sent ICMP probe are manipulated to be 545 constant. The TCP case presents no problem because its first eight 546 bytes will be the same for every packet probe. 548 Formally, to maintain the same flow in the measurements to a certain 549 hop, the Type-P-Route-Ensemble-Method-Variant packets should be[PT]: 551 o TCP case: Fields Src, Dst, port-Src, port_Dst, and Diffserv Field 552 should be the same. 554 o UDP case: Fields Src, Dst, port-Src, port-Dst, and Diffserv Field 555 should be the same, the UDP-checksum should change to maintain 556 constant the IP checksum of the ICMP time exceeded reply. Then, 557 the data length should be fixed, and the data field is used to 558 fixing it (consider that ICMP checksum uses its data field, which 559 contains the original IP header plus 8 bytes of UDP, where TTL, IP 560 identification, IP checksum, and UDP checksum changes). 562 o ICMP case: The Data field should compensate variations on TTL, IP 563 identification, and IP checksum for every packet. 565 Then, the way to identify different hops and attempts of the same 566 flow is: 568 o TCP case: The IP identification field. 570 o UDP case: The IP identification field. 572 o ICMP case: The IP identification field, and ICMP Sequence number. 574 4.1.1. Temporal Composition for Route Metrics 576 The Active Route Assessment Methods described above have the ability 577 to discover portions of a path where ECMP load balancing is present, 578 observed as two or more unique Member Routes having one or more 579 distinct Hops which are part of the Route Ensemble. Likewise, 580 attempts to deliberately vary the flow characteristics to discover 581 all Member Routes will reveal portions of the path which are flow- 582 invariant. 584 Section 9.2 of [RFC2330] describes Temporal Composition of metrics, 585 and introduces the possibility of a relationship between earlier 586 measurement results and the results for measurement at the current 587 time (for a given metric). There is value in establishing a Temporal 588 Composition relationship for Route Metrics. However, this 589 relationship does not represent a forecast of future route conditions 590 in any way. 592 For Route Metric measurements, the value of Temporal Composition is 593 to reduce the measurement iterations required with repeated 594 measurements. Reduced iterations are possible by inferring that 595 current measurements using fixed and previously measured flow 596 characteristics: 598 o will have many common hops with previous measurements. 600 o will have relatively time-stable results at the ingress and egress 601 portions of the path when measured from user locations, as opposed 602 to measurements of backbone networks and across inter-domain 603 gateways. 605 o may have greater potential for time-variation in path portions 606 where ECMP load balancing is observed (because increasing or 607 decreasing the pool of links changes the hash calculations). 609 Optionally, measurement systems may take advantage of the inferences 610 above when seeking to reduce measurement iterations, after exhaustive 611 measurements indicate that the time-stable properties are present. 612 Repetitive Active Route measurement systems: 614 1. SHOULD occasionally check path portions which have exhibited 615 stable results over time, particularly ingress and egress 616 portions of the path. 618 2. SHOULD continue testing portions of the path that have previously 619 exhibited ECMP load balancing. 621 3. SHALL trigger re-assessment of the complete path and Route 622 Ensemble, if any change in hops is observed for a specific (and 623 previously tested) flow. 625 @@@@ Comments on this material are very welcome! 627 4.1.2. Routing Class C Identification 629 There is an opportunity to apply the [RFC2330] notion of equal 630 treatment for a class of packets, "...very useful to know if a given 631 Internet component treats equally a class C of different types of 632 packets", as it applies to Route measurements. Knowledge of "class 633 C" parameters (unrelated to address classes of the past) on a path 634 potentially reduces the number of flows required for a given method 635 to assess a Route Ensemble over time. 637 First, recognize that each Member Route of a Route Ensemble will have 638 a corresponding Routing Class C. Class C can be discovered by 639 testing with multiple flows, all of which traverse the unique set of 640 hops that comprise a specific Member Route. 642 Second, recognize that the different Routing Classes depend primarily 643 on the hash functions used at each instance of ECMP load balancing on 644 the path. 646 Third, recognize the synergy with Temporal Composition methods 647 (described above) where evaluation intends to discover time-stable 648 portions of each Member Route so that more emphasis can be placed on 649 ECMP portions that also determine Class C. 651 The methods to assess the various Routing Class C characteristics 652 benefit from the following measurement capabilities: 654 o flows designed to determine which n-tuple header fields are 655 considered by a given hash function and ECMP hop on the path, and 656 which are not. This operation immediately narrows the search 657 space, where possible, and partially defines a Routing Class C. 659 o a priori knowledge of the possible types of hash functions in use 660 also helps to design the flows for testing (major router vendors 661 publish information about these hash functions, examples are here 662 https://www.researchgate.net/ 663 publication/281571413_COMPARISON_OF_HASH_STRATEGIES_FOR_FLOW- 664 BASED_LOAD_BALANCING ). 666 o ability to direct the emphasis of current measurements on ECMP 667 portions of the path, based on recent past measurement results 668 (the Routing Class C of some portions of the path is essentially 669 "all packets"). 671 @@@@ Comments on this material are very welcome! Especially 672 suggestions for tools that might lend themselves to support these 673 measurements. 675 4.1.3. Intermediate Observation Point Route Measurement 677 There are many examples where passive monitoring of a flow at an 678 Observation Point within the network can detect unexpected Round Trip 679 Delay or Delay Variation. But how can the cause of the anomolous 680 dely be investigated further --from the Observation Point -- possibly 681 located at an intermediate point on the path? 683 In this case, knowledge that the flow of interest belongs to a 684 specific Routing Class C will enable mesurement of the route where 685 anomolous delay has been observed. Specifically, Round Trip Delay 686 assessment to each Hop on the path between the Observation Point and 687 the Destination for the flow of interest may discover high or 688 variable delay on a specific link and Hop combination. 690 The determination of a Routing Class C which includes the flow of 691 interest is as described in the section above, aided by computation 692 of the relevant hash function output as the target. 694 @@@@ Comments on this new material are very welcome! 696 4.2. Hybrid Methodologies 698 The Hybrid Type I methods provide an alternative method for Route 699 Member assessment. As mentioned in the Scope section, 700 [I-D.ietf-ippm-ioam-data] provides a possible set of data fields that 701 would support route identification. 703 In general, nodes in the measured domain would be equipped with 704 specific abilities: 706 o Support of the "Loopback" Flag (L-bit), where a copy of the packet 707 is returned to the source, and the packet is processed like any 708 other IOAM packet on the return transfer. 710 In addition to node identity, nodes may also identify the ingress and 711 egress interfaces utilized by the tracing packet, the time of day 712 when the packet was processed, and other generic data (as described 713 in section 4 of [I-D.ietf-ippm-ioam-data]). 715 4.3. Combining Different Methods 717 In principle, there are advantages if the entity conducting Route 718 measurements can utilize both forms of advanced methods (active and 719 hybrid), and combine the results. For example, if there are Nodes 720 involved in the path that qualify as Cooperating Nodes, but not as 721 Discoverable Nodes, then a more complete view of hops on the path is 722 possible when a hybrid method (or interrogation protocol) is applied 723 and the results are combined with the active method results collected 724 across all other domains. 726 In order to combine the results of active and hybrid/interrogation 727 methods, the network Nodes that are part of a domain supporting an 728 interrogation protocol have the following attributes: 730 1. Nodes at the ingress to the domain SHOULD be both Discoverable 731 and Cooperating, and SHOULD reveal the same Node Identity in 732 response to both active and hybrid methods. 734 2. Any Nodes within the domain that are both Discoverable and 735 Cooperating SHOULD reveal the same Node Identity in response to 736 both active and hybrid methods. 738 3. Nodes at the egress to the domain SHOULD be both Discoverable and 739 Cooperating, and SHOULD reveal the same Node Identity in response 740 to both active and hybrid methods. 742 When Nodes follow these requirements, it becomes a simple matter to 743 match single domain measurements with the overlapping results from a 744 multidomain measurement. 746 In practice, Internet users do not typically have the ability to 747 utilize the OAM capabilities of networks that their packets traverse, 748 so the results from a remote domain supporting an interrogation 749 protocol would not normally be accessible. However, a network 750 operator could combine interrogation results from their access domain 751 with other measurements revealing the path outside their domain. 753 5. Background on Round-Trip Delay Measurement Goals 755 The aim of this method is to use packet probes to unveil the paths 756 between any two end-Nodes of the network. Moreover, information 757 derived from RTD measurements might be meaningful to identify: 759 1. Intercontinental submarine links 761 2. Satellite communications 763 3. Congestion 765 4. Inter-domain paths 767 This categorization is widely accepted in the literature and among 768 operators alike, and it can be trusted with empirical data and 769 several sources as ground of truth (e.g., [RTTSub] ) but it is an 770 inference measurement nonetheless [bdrmap][IDCong]. 772 The first two categories correspond to the physical distance 773 dependency on Round Trip Delay (RTD) while the last one binds RTD 774 with queueing delay on routers. Due to the significant contribution 775 of propagation delay in long distance hops, RTD will be on the order 776 of 100ms on transatlantic hops, depending on the geolocation of the 777 vantage points. Moreover, RTD is typically greater than 480ms when 778 two hops are connected using geostationary satellite technology 779 (i.e., their orbit is at 36000km). Detecting congestion with latency 780 implies deeper mathematical understanding since network traffic load 781 is not stationary. Nonetheless, as the first approach, a link seems 782 to be congested if after sending several traceroute probes, it is 783 possible to detect congestion observing different statistics 784 parameters (e.g., see [IDCong]). 786 6. Tools to Measure Delays in the Internet 788 Internet routing is complex because it depends on the policies of 789 thousands Autonomous Systems (AS). While most of the routers perform 790 load balancing on flows using Equal Cost Multiple Path (ECMP), a few 791 still divide the workload through packet-based techniques. The 792 former scenario is defined according to [RFC2991] while the latter 793 generates a round-robin scheme to deliver every new outgoing packet. 794 ECMP keeps flow state in the router to ensure every packet of a flow 795 is delivered by the same path, and this avoids increasing the packet 796 delay variation and possibly producing overwhelming packet reordering 797 in TCP flows. 799 Taking into account that Internet protocol was designed under the 800 "end-to-end" principle, the IP payload and its header do not provide 801 any information about the routes or path necessary to reach some 802 destination. For this reason, the well-known tool traceroute was 803 developed to gather the IP addresses of each hop along a path using 804 the ICMP protocol [RFC0792]. Besides, traceroute adds the measured 805 RTD from each hop. However, the growing complexity of the Internet 806 makes it more challenging to develop accurate traceroute 807 implementation. For instance, the early traceroute tools would be 808 inaccurate in the current network, mainly because they were not 809 designed to retain flow state. However, evolved traceroute tools, 810 such as Paris-traceroute [PT] [MLB] and Scamper [SCAMPER], expect to 811 encounter ECMP and achieve more accurate results when they do. 813 Paris-traceroute-like tools operate in the following way: every 814 packet should follow the same path because the sensitive fields of 815 the header are controlled to appear as the same flow. This means 816 that source and destination IP addresses, source and destination port 817 numbers are the same in every packet. Additionally, Differentiated 818 Services Code Point (DSCP), checksum and ICMP code should remain 819 constant since they may affect the path selection. 821 Today's traceroute tools can send either UDP, TCP or ICMP packet 822 probes. Since ICMP header does not include transport layer 823 information, there are no fields for source and destination port 824 numbers. For this reason, these tools keep constant ICMP type, code, 825 and checksum fields to generate a kind of flow. However, the 826 checksum may vary in every packet, therefore when probes use ICMP 827 packets, ICMP Identifier and Sequence Number are manipulated to 828 maintain constant checksum in every packet. On the other hand, when 829 UDP probes are generated, the expected variation in the checksum of 830 each packet is again compensated by manipulating the payload. 832 Paris-traceroute allows its users to measure RTD in every hop of the 833 path for a particular flow. Furthermore, either Paris-traceroute or 834 Scamper is capable of unveiling the many available paths between a 835 source and destination (which are visible to this method). This task 836 is accomplished by repeating complete traceroute measurements with 837 different flow parameters for each measurement. The Framework for IP 838 Performance Metrics (IPPM) ([RFC2330] updated by[RFC7312]) has the 839 flexibility to require that the round-trip delay measurement 840 [RFC2681] uses packets with the constraints to assure that all 841 packets in a single measurement appear as the same flow. This 842 flexibility covers ICMP, UDP, and TCP. The accompanying methodology 843 of [RFC2681] needs to be expanded to report the sequential hop 844 identifiers along with RTD measurements, but no new metric definition 845 is needed. 847 7. RTD Measurements Statistics 849 Several articles have shown that network traffic presents a self- 850 similar nature [SSNT] [MLRM] which is accountable for filling the 851 queues of the routers. Moreover, router queues are designed to 852 handle traffic bursts, which is one of the most remarkable features 853 of self-similarity. Naturally, while queue length increases, the 854 delay to traverse the queue increases as well and leads to an 855 increase on RTD. Due to traffic bursts generate short-term overflow 856 on buffers (spiky patterns), every RTD only depicts the queueing 857 status on the instant when that packet probe was in transit. For 858 this reason, several RTD measurements during a time window could 859 begin to describe the random behavior of latency. Loss must also be 860 accounted for in the methodology. 862 To understand the ongoing process, examining the quartiles provides a 863 non-parametric way of analysis. Quartiles are defined by five 864 values: minimum RTD (m), RTD value of the 25% of the Empirical 865 Cumulative Distribution Function (ECDF) (Q1), the median value (Q2), 866 the RTD value of the 75% of the ECDF (Q3) and the maximum RTD (M). 867 Congestion can be inferred when RTD measurements are spread apart, 868 and consequently, the Inter-Quartile Range (IQR), the distance 869 between Q3 and Q1, increases its value. 871 This procedure requires to compute quartile values "on the fly" using 872 the algorithm presented in [P2]. 874 This procedure allow us to update the quartiles value whenever a new 875 measurement arrives, which is radically different from classic 876 methods of computing quartiles because they need to use the whole 877 dataset to compute the values. This way of calculus provides savings 878 in memory and computing time. 880 To sum up, the proposed measurement procedure consists in performing 881 traceroutes several times to obtain samples of the RTD in every hop 882 from a path, during a time window (W) and compute the quantiles for 883 every hop. This could be done for a single path flow or for every 884 detected path flow. 886 Even though a particular hop may be understood as the amount of hops 887 away from the source, a more detailed classification could be used. 888 For example, a possible classification may be identify ICMP Time 889 Exceeded packets coming from the same routers to those who have the 890 same hop distance, IP address of the router which is replying and TTL 891 value of the received ICMP packet. 893 Thus, the proposed methodology is based on this algorithm: 895 ================================================================ 896 1 input: W (window time of the measurement) 897 2 i_t (time between two measurements) 898 3 E (True: exhaustive, False: a single path) 899 4 Dst (destination IP address) 900 5 output: Qs (quartiles for every hop and alt in the path(s) to Dst) 901 ---------------------------------------------------------------- 902 6 T . 1021 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1022 Communication Layers", STD 3, RFC 1122, 1023 DOI 10.17487/RFC1122, October 1989, 1024 . 1026 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 1027 RFC 1812, DOI 10.17487/RFC1812, June 1995, 1028 . 1030 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1031 Requirement Levels", BCP 14, RFC 2119, 1032 DOI 10.17487/RFC2119, March 1997, 1033 . 1035 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1036 "Framework for IP Performance Metrics", RFC 2330, 1037 DOI 10.17487/RFC2330, May 1998, 1038 . 1040 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1041 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1042 December 1998, . 1044 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1045 RFC 2675, DOI 10.17487/RFC2675, August 1999, 1046 . 1048 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1049 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1050 September 1999, . 1052 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 1053 Multicast Next-Hop Selection", RFC 2991, 1054 DOI 10.17487/RFC2991, November 2000, 1055 . 1057 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 1058 Algorithm and Its Use with IPsec", RFC 4494, 1059 DOI 10.17487/RFC4494, June 2006, 1060 . 1062 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1063 Zekauskas, "A One-way Active Measurement Protocol 1064 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 1065 . 1067 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1068 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1069 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1070 . 1072 [RFC5388] Niccolini, S., Tartarelli, S., Quittek, J., Dietz, T., and 1073 M. Swany, "Information Model and XML Data Model for 1074 Traceroute Measurements", RFC 5388, DOI 10.17487/RFC5388, 1075 December 2008, . 1077 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 1078 Metrics (IPPM): Spatial and Multicast", RFC 5644, 1079 DOI 10.17487/RFC5644, October 2009, 1080 . 1082 [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for 1083 Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 1084 2010, . 1086 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 1087 N., and JR. Rivers, "Extending ICMP for Interface and 1088 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 1089 April 2010, . 1091 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1092 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1093 DOI 10.17487/RFC6282, September 2011, 1094 . 1096 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1097 "IPv6 Flow Label Specification", RFC 6437, 1098 DOI 10.17487/RFC6437, November 2011, 1099 . 1101 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1102 for Equal Cost Multipath Routing and Link Aggregation in 1103 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1104 . 1106 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 1107 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 1108 RFC 6564, DOI 10.17487/RFC6564, April 2012, 1109 . 1111 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 1112 DOI 10.17487/RFC6673, August 2012, 1113 . 1115 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1116 of IPv6 Extension Headers", RFC 7045, 1117 DOI 10.17487/RFC7045, December 2013, 1118 . 1120 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 1121 Framework for IP Performance Metrics (IPPM)", RFC 7312, 1122 DOI 10.17487/RFC7312, August 2014, 1123 . 1125 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1126 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1127 May 2016, . 1129 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 1130 Active Measurement Protocol (OWAMP) and Two-Way Active 1131 Measurement Protocol (TWAMP)", RFC 7820, 1132 DOI 10.17487/RFC7820, March 2016, 1133 . 1135 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1136 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1137 Switched (MPLS) Data-Plane Failures", RFC 8029, 1138 DOI 10.17487/RFC8029, March 2017, 1139 . 1141 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1142 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1143 May 2017, . 1145 13.2. Informative References 1147 [bdrmap] Luckie, M., Dhamdhere, A., Huffaker, B., Clark, D., and 1148 KC. Claffy, "bdrmap: Inference of Borders Between IP 1149 Networks", In Proceedings of the 2016 ACM on Internet 1150 Measurement Conference, pp. 381-396. ACM, 2016. 1152 [IDCong] Luckie, M., Dhamdhere, A., Clark, D., and B. Huffaker, 1153 "Challenges in inferring Internet interdomain 1154 congestion", In Proceedings of the 2014 Conference on 1155 Internet Measurement Conference, pp. 15-22. ACM, 2014. 1157 [MLB] Augustin, B., Friedman, T., and R. Teixeira, "Measuring 1158 load-balanced paths in the Internet", Proceedings of the 1159 7th ACM SIGCOMM conference on Internet measurement, pp. 1160 149-160. ACM, 2007., 2007. 1162 [MLRM] Fontugne, R., Mazel, J., and K. Fukuda, "An empirical 1163 mixture model for large-scale RTT measurements", 2015 1164 IEEE Conference on Computer Communications (INFOCOM), pp. 1165 2470-2478. IEEE, 2015., 2015. 1167 [P2] Jain, R. and I. Chlamtac, "The P 2 algorithm for dynamic 1168 calculation of quantiles and histograms without storing 1169 observations", Communications of the ACM 28.10 (1985): 1170 1076-1085, 2015. 1172 [PT] Augustin, B., Cuvellier, X., Orgogozo, B., Viger, F., 1173 Friedman, T., Latapy, M., Magnien, C., and R. Teixeira, 1174 "Avoiding traceroute anomalies with Paris traceroute", 1175 Proceedings of the 6th ACM SIGCOMM conference on Internet 1176 measurement, pp. 153-158. ACM, 2006., 2006. 1178 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 1179 and C. Pignataro, "MPLS Forwarding Compliance and 1180 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 1181 August 2014, . 1183 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1184 Aitken, P., and A. Akhter, "A Framework for Large-Scale 1185 Measurement of Broadband Performance (LMAP)", RFC 7594, 1186 DOI 10.17487/RFC7594, September 2015, 1187 . 1189 [RTTSub] Bischof, Z., Rula, J., and F. Bustamante, "In and out of 1190 Cuba: Characterizing Cuba's connectivity", In Proceedings 1191 of the 2015 ACM Conference on Internet Measurement 1192 Conference, pp. 487-493. ACM, 2015. 1194 [SCAMPER] Matthew Luckie, M., "Scamper: a scalable and extensible 1195 packet prober for active measurement of the 1196 Internet", Proceedings of the 10th ACM SIGCOMM conference 1197 on Internet measurement, pp. 239-245. ACM, 2010., 2010. 1199 [SSNT] Park, K. and W. Willinger, "Self-Similar Network Traffic 1200 and Performance Evaluation (1st ed.)", John Wiley & Sons, 1201 Inc., New York, NY, USA, 2000. 1203 Authors' Addresses 1205 Jose Ignacio Alvarez-Hamelin 1206 Universidad de Buenos Aires 1207 Av. Paseo Colon 850 1208 Buenos Aires C1063ACV 1209 Argentine 1211 Phone: +54 11 5285-0716 1212 Email: ihameli@cnet.fi.uba.ar 1213 URI: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ 1215 Al Morton 1216 AT&T Labs 1217 200 Laurel Avenue South 1218 Middletown, NJ 07748 1219 USA 1221 Phone: +1 732 420 1571 1222 Fax: +1 732 368 1192 1223 Email: acm@research.att.com 1224 Joachim Fabini 1225 TU Wien 1226 Gusshausstrasse 25/E389 1227 Vienna 1040 1228 Austria 1230 Phone: +43 1 58801 38813 1231 Fax: +43 1 58801 38898 1232 Email: Joachim.Fabini@tuwien.ac.at 1233 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 1235 Carlos Pignataro 1236 Cisco Systems, Inc. 1237 7200-11 Kit Creek Road 1238 Research Triangle Park, NC 27709 1239 USA 1241 Email: cpignata@cisco.com 1243 Ruediger Geib 1244 Deutsche Telekom 1245 Heinrich Hertz Str. 3-7 1246 Darmstadt 64295 1247 Germany 1249 Phone: +49 6151 5812747 1250 Email: Ruediger.Geib@telekom.de