idnits 2.17.1 draft-ietf-ippm-connectivity-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 108 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 353: '...port-unreachable MUST treat it the sa...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '... Drafts are ...' == Line 11 has weird spacing: '...cuments of t...' == Line 12 has weird spacing: '...ups may also ...' == Line 20 has weird spacing: '...e check the...' == Line 21 has weird spacing: '...listing conta...' == (103 more instances...) -- 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 (October 1998) is 9318 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) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Mahdavi, Pittsburgh Supercomputer Center 2 Internet Draft V. Paxson, Lawrence Berkeley National Laboratory 3 Expiration Date: April 1999 October 1998 5 IPPM Metrics for Measuring Connectivity 6 8 1. Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months, and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet Drafts as reference 18 material or to cite them other than as ``work in progress''. 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 23 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 24 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 This memo provides information for the Internet community. This memo 27 does not specify an Internet standard of any kind. Distribution of 28 this memo is unlimited. 30 2. Introduction 32 Connectivity is the basic stuff from which the Internet is made. 33 Therefore, metrics determining whether pairs of hosts (IP addresses) 34 can reach each other must form the base of a measurement suite. We 35 define several such metrics, some of which serve mainly as building 36 blocks for the others. 38 This memo defines a series of metrics for connectivity between a pair 39 of Internet hosts. It builds on notions introduced and discussed in 40 RFC 2330, the IPPM framework document. The reader is assumed to be 41 familiar with that document. 43 The structure of the memo is as follows: 45 ID IPPM Metrics for Measuring Connectivity October 1998 47 + An analytic metric, called Type-P-Instantaneous-Unidirectional- 48 Connectivity, will be introduced to define one-way connectivity at 49 one moment in time. 50 + Using this metric, another analytic metric, called Type-P- 51 Instantaneous-Bidirectional-Connectivity, will be introduced to 52 define two-way connectivity at one moment in time. 53 + Using these metrics, corresponding one- and two-way analytic 54 metrics are defined for connectivity over an interval of time. 55 + Using these metrics, an analytic metric, called Type-P1-P2- 56 Interval-Temporal-Connectivity, will be introduced to define a 57 useful notion of two-way connectivity between two hosts over an 58 interval of time. 59 + Methodologies are then presented and discussed for estimating 60 Type-P1-P2-Interval-Temporal-Connectivity in a variety of 61 settings. 62 Careful definition of Type-P1-P2-Interval-Temporal-Connectivity and 63 the discussion of the metric and the methodologies for estimating it 64 are the two chief contributions of the memo. 66 3. Instantaneous One-way Connectivity 68 3.1. Metric Name: 70 Type-P-Instantaneous-Unidirectional-Connectivity 72 3.2. Metric Parameters: 73 + Src, the IP address of a host 74 + Dst, the IP address of a host 75 + T, a time 77 3.3. Metric Units: 79 Boolean. 81 3.4. Definition: 83 Src has *Type-P-Instantaneous-Unidirectional-Connectivity* to Dst at 84 time T if a type-P packet transmitted from Src to Dst at time T will 85 arrive at Dst. 87 ID IPPM Metrics for Measuring Connectivity October 1998 89 3.5. Discussion: 91 For most applications (e.g., any TCP connection) bidirectional 92 connectivity is considerably more germane than unidirectional 93 connectivity, although unidirectional connectivity can be of interest 94 for some security applications (e.g., testing whether a firewall 95 correctly filters out a "ping of death"). Most applications also 96 require connectivity over an interval, while this metric is 97 instantaneous, though, again, for some security applications 98 instantaneous connectivity remains of interest. Finally, one might 99 not have instantaneous connectivity due to a transient event such as 100 a full queue at a router, even if at nearby instants in time one does 101 have connectivity. These points are addressed below, with this 102 metric serving as a building block. 104 Note also that we have not explicitly defined *when* the packet 105 arrives at Dst. The TTL field in IP packets is meant to limit IP 106 packet lifetimes to 255 seconds (RFC 791). In practice the TTL field 107 can be strictly a hop count (RFC 1812), with most Internet hops being 108 much shorter than one second. This means that most packets will have 109 nowhere near the 255 second lifetime. In principle, however, it is 110 also possible that packets might survive longer than 255 seconds. 111 Consideration of packet lifetimes must be taken into account in 112 attempts to measure the value of this metric. 114 Finally, one might assume that unidirectional connectivity is 115 difficult to measure in the absence of connectivity in the reverse 116 direction. Consider, however, the possibility that a process on 117 Dst's host notes when it receives packets from Src and reports this 118 fact either using an external channel, or later in time when Dst does 119 have connectivity to Src. Such a methodology could reliably measure 120 the unidirectional connectivity defined in this metric. 122 4. Instantaneous Two-way Connectivity 124 4.1. Metric Name: 126 Type-P-Instantaneous-Bidirectional-Connectivity 128 4.2. Metric Parameters: 130 ID IPPM Metrics for Measuring Connectivity October 1998 132 + A1, the IP address of a host 133 + A2, the IP address of a host 134 + T, a time 136 4.3. Metric Units: 138 Boolean. 140 4.4. Definition: 142 Addresses A1 and A2 have *Type-P-Instantaneous-Bidirectional- 143 Connectivity* at time T if address A1 has Type-P-Instantaneous- 144 Unidirectional-Connectivity to address A2 and address A2 has Type-P- 145 Instantaneous-Unidirectional-Connectivity to address A1. 147 4.5. Discussion: 149 An alternative definition would be that at A1 and A2 are fully 150 connected if at time T address A1 has instantaneous connectivity to 151 address A2, and at time T+dT address A2 has instantaneous 152 connectivity to A1, where T+dT is when the packet sent from A1 153 arrives at A2. This definition is more useful for measurement, 154 because the measurement can use a reply from A2 to A1 in order to 155 assess full connectivity. It is a more complex definition, however, 156 because it breaks the symmetry between A1 and A2, and requires a 157 notion of quantifying how long a particular packet from A1 takes to 158 reach A2. We postpone discussion of this distinction until the 159 development of interval-connectivity metrics below. 161 5. One-way Connectivity 163 5.1. Metric Name: 165 Type-P-Interval-Unidirectional-Connectivity 167 5.2. Metric Parameters: 168 + Src, the IP address of a host 170 ID IPPM Metrics for Measuring Connectivity October 1998 172 + Dst, the IP address of a host 173 + T, a time 174 + dT, a duration 175 {Comment: Thus, the closed interval [T, T+dT] denotes a time 176 interval.} 178 5.3. Metric Units: 180 Boolean. 182 5.4. Definition: 184 Address Src has *Type-P-Interval-Unidirectional-Connectivity* to 185 address Dst during the interval [T, T+dT] if for some T' within [T, 186 T+dT] it has Type-P-instantaneous-connectivity to Dst. 188 6. Two-way Connectivity 190 6.1. Metric Name: 192 Type-P-Interval-Bidirectional-Connectivity 194 6.2. Metric Parameters: 195 + A1, the IP address of a host 196 + A2, the IP address of a host 197 + T, a time 198 + dT, a duration 199 {Comment: Thus, the closed interval [T, T+dT] denotes a time 200 interval.} 202 6.3. Metric Units: 204 Boolean. 206 6.4. Definition: 208 Addresses A1 and A2 have *Type-P-Interval-Bidirectional-Connectivity* 209 between them during the interval [T, T+dT] if address A1 has Type-P- 210 Interval-Unidirectional-Connectivity to address A2 during the 211 interval and address A2 has Type-P-Interval-Unidirectional- 212 Connectivity to address A1 during the interval. 214 ID IPPM Metrics for Measuring Connectivity October 1998 216 6.5. Discussion: 218 This metric is not quite what's needed for defining "generally 219 useful" connectivity - that requires the notion that a packet sent 220 from A1 to A2 can elicit a response from A2 that will reach A1. With 221 this definition, it could be that A1 and A2 have full-connectivity 222 but only, for example, at at time T1 early enough in the interval [T, 223 T+dT] that A1 and A2 cannot reply to packets sent by the other. This 224 deficiency motivates the next metric. 226 7. Two-way Temporal Connectivity 228 7.1. Metric Name: 230 Type-P1-P2-Interval-Temporal-Connectivity 232 7.2. Metric Parameters: 233 + Src, the IP address of a host 234 + Dst, the IP address of a host 235 + T, a time 236 + dT, a duration 237 {Comment: Thus, the closed interval [T, T+dT] denotes a time 238 interval.} 240 7.3. Metric Units: 242 Boolean. 244 7.4. Definition: 246 Address Src has *Type-P1-P2-Interval-Temporal-Connectivity* to 247 address Dst during the interval [T, T+dT] if there exist times T1 and 248 T2, and time intervals dT1 and dT2, such that: 249 + T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT]. 250 + T1+dT1 <= T2. 251 + At time T1, Src has Type-P1 instantanous connectivity to Dst. 252 + At time T2, Dst has Type-P2 instantanous connectivity to Src. 253 + dT1 is the time taken for a Type-P1 packet sent by Src at time T1 254 to arrive at Dst. 256 ID IPPM Metrics for Measuring Connectivity October 1998 258 + dT2 is the time taken for a Type-P2 packet sent by Dst at time T2 259 to arrive at Src. 261 7.5. Discussion: 263 This metric defines "generally useful" connectivity -- Src can send a 264 packet to Dst that elicits a response. Because many applications 265 utilize different types of packets for forward and reverse traffic, 266 it is possible (and likely) that the desired responses to a Type-P1 267 packet will be of a different type Type-P2. Therefore, in this 268 metric we allow for different types of packets in the forward and 269 reverse directions. 271 7.6. Methodologies: 273 Here we sketch a class of methodologies for estimating Type-P1-P2- 274 Interval-Temporal-Connectivity. It is a class rather than a single 275 methodology because the particulars will depend on the types P1 and 276 P2. 278 7.6.1. Inputs: 279 + Types P1 and P2, addresses A1 and A2, interval [T, T+dT]. 280 + N, the number of packets to send as probes for determining 281 connectivity. 282 + W, the "waiting time", which bounds for how long it is useful to 283 wait for a reply to a packet. 284 Required: W <= 255, dT > W. 286 7.6.2. Recommended values: 288 dT = 60 seconds. 289 W = 10 seconds. 290 N = 20 packets. 292 7.6.3. Algorithm: 294 + Compute N *sending-times* that are randomly, uniformly distributed 295 over [T, T+dT-W]. 297 ID IPPM Metrics for Measuring Connectivity October 1998 299 + At each sending time, transmit from A1 a well-formed packet of 300 type P1 to A2. 301 + Inspect incoming network traffic to A1 to determine if a 302 successful reply is received. The particulars of doing so are 303 dependent on types P1 & P2, discussed below. If a successful 304 reply is received, the value of the measurement is "true". 305 + If no successful replies are received by time T+dT, the value of 306 the measurement is "false". 308 7.6.4. Discussion: 310 The algorithm is inexact because it does not (and cannot) probe 311 temporal connectivity at every instant in time between [T, T+dT]. 312 The value of N trades off measurement precision against network 313 measurement load. The state-of-the-art in Internet research does not 314 yet offer solid guidance for picking N. The values given above are 315 just guidelines. 317 7.6.5. Specific methodology for TCP: 319 A TCP-port-N1-port-N2 methodology sends TCP SYN packets with source 320 port N1 and dest port N2 at address A2. Network traffic incoming to 321 A1 is interpreted as follows: 322 + A SYN-ack packet from A2 to A1 with the proper acknowledgement 323 fields and ports indicates temporal connectivity. The measurement 324 terminates immediately with a value of "true". {Comment: if, as a 325 side effect of the methodology, a full TCP connection has been 326 established between A1 and A2 -- that is, if A1's TCP stack 327 acknowledges A2's SYN-ack packet, completing the three-way 328 handshake -- then the connection now established between A1 and A2 329 is best torn down using the usual FIN handshake, and not using a 330 RST packet, because RST packets are not reliably delivered. If 331 the three-way handshake is not completed, however, which will 332 occur if the measurement tool on A1 synthesizes its own initial 333 SYN packet rather than going through A1's TCP stack, then A1's TCP 334 stack will automatically terminate the connection in a reliable 335 fashion as A2 continues transmitting the SYN-ack in an attempt to 336 establish the connection. Finally, we note that using A1's TCP 337 stack to conduct the measurement complicates the methodology in 338 that the stack may retransmit the initial SYN packet, altering the 339 number of probe packets sent.} 341 ID IPPM Metrics for Measuring Connectivity October 1998 343 + A RST packet from A2 to A1 with the proper ports indicates 344 temporal connectivity between the addresses (and a *lack* of 345 service connectivity for TCP-port-N1-port-N2 - something that 346 probably should be addressed with another metric). 347 + An ICMP port-unreachable from A2 to A1 indicates temporal 348 connectivity between the addresses (and again a *lack* of service 349 connectivity for TCP-port-N1-port-N2). {Comment: TCP 350 implementations generally do not need to send ICMP port- 351 unreachable messages because a separate mechanism is available 352 (sending a RST). However, RFC 1122 states that a TCP receiving an 353 ICMP port-unreachable MUST treat it the same as the equivalent 354 transport-level mechanism (for TCP, a RST).} 355 + An ICMP host-unreachable or network-unreachable to A1 (not 356 necessarily from A2) with an enclosed IP header matching that sent 357 from A1 to A2 *suggests* a lack of temporal connectivity. If by 358 time T+dT no evidence of temporal connectivity has been gathered, 359 then the receipt of the ICMP can be used as additional information 360 to the measurement value of "false". 362 {Comment: Similar methodologies are needed for ICMP Echo, UDP, etc.} 364 8. Acknowledgments 366 The comments of Guy Almes, Martin Horneffer, Jeff Sedayao, and Sean 367 Shapira are appreciated. 369 9. Security Considerations 371 As noted in RFC 2330, active measurement techniques, such as those 372 defined in this document, can be abused for denial-of-service attacks 373 disguised as legitimate measurement activity. Furthermore, testing 374 for connectivity can be used to probe firewalls and other security 375 mechnisms for weak spots. 377 10. References 379 F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June 380 1995. 382 R. Braden, "Requirements for Internet hosts - communication layers", 383 RFC 1122, October 1989. 385 V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, Paxson, "Framework 386 for IP Performance Metrics", RFC 2330, May 1998. 388 ID IPPM Metrics for Measuring Connectivity October 1998 390 J. Postel, "Internet Protocol", RFC 791, September 1981. 392 11. Authors' Addresses 394 Jamshid Mahdavi 395 Pittsburgh Supercomputing Center 396 4400 5th Avenue 397 Pittsburgh, PA 15213 398 USA 400 Vern Paxson 401 MS 50A-3111 402 Lawrence Berkeley National Laboratory 403 University of California 404 Berkeley, CA 94720 405 USA 406 Phone: +1 510/486-7504