idnits 2.17.1 draft-ietf-ippm-connectivity-01.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-03-28) 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 8 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 9 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 94 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 334: '...port-unreachable MUST treat it the sa...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '... Drafts are ...' == Line 12 has weird spacing: '...cuments of t...' == Line 13 has weird spacing: '...ups may also ...' == Line 21 has weird spacing: '... please check...' == Line 23 has weird spacing: '...ctories on f...' == (89 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 (November 1997) is 9630 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. -------------------------------------------------------------------------------- 2 Network Working Group J. Mahdavi, Pittsburgh Supercomputer Center 3 Internet Draft V. Paxson, Lawrence Berkeley National Laboratory 4 Expiration Date: May 1998 November 1997 6 Connectivity 7 9 1. Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet Drafts as reference 19 material or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet Drafts shadow 23 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 This memo provides information for the Internet community. This memo 28 does not specify an Internet standard of any kind. Distribution of 29 this memo is unlimited. 31 2. Introduction 33 Connectivity is the basic stuff from which the Internet is made. 34 Therefore, metrics determining whether pairs of hosts (IP addresses) 35 can reach each other must form the base of a measurement suite. We 36 define several such metrics, some of which serve mainly as building 37 blocks for the others. 39 This memo defines a series of metrics for connectivity between a pair 40 of Internet hosts. It builds on notions introduced and discussed in 41 the revised IPPM Framework document (currently ); the reader is assumed to be familiar with that 43 document. 45 The structure of the memo is as follows: 47 ID Connectivity November 1997 49 + An analytic metric, called Type-P-Instantaneous-Unidirectional- 50 Connectivity, will be introduced to define one-way connectivity at 51 one moment in time. 52 + Using this metric, another analytic metric, called Type-P- 53 Instantaneous-Bidirectional-Connectivity, will be introduced to 54 define two-way connectivity at one moment in time. 55 + Using these metrics, corresponding one- and two-way analytic 56 metrics are defined for connectivity over an interval of time. 57 + Using these metrics, an analytic metric, called Type-P1-P2- 58 Interval-Temporal-Connectivity, will be introduced to define a 59 useful notion of two-way connectivity between two hosts over an 60 interval of time. 61 + Methodologies are then presented and discussed for estimating 62 Type-P1-P2-Interval-Temporal-Connectivity in a variety of 63 settings. 64 Careful definition of Type-P1-P2-Interval-Temporal-Connectivity and 65 the discussion of the metric and the methodologies for estimating it 66 are the two chief contributions of the memo. 68 3. Instantaneous One-way Connectivity 70 3.1. Metric Name: 72 Type-P-Instantaneous-Unidirectional-Connectivity 74 3.2. Metric Parameters: 75 + Src, the IP address of a host 76 + Dst, the IP address of a host 77 + T, a time 79 3.3. Metric Units: 81 Boolean. 83 3.4. Definition: 85 Src has *Type-P-Instantaneous-Unidirectional-Connectivity* to Dst at 86 time T if a type-P packet transmitted from Src to Dst at time T will 87 arrive at Dst. 89 ID Connectivity November 1997 91 3.5. Discussion: 93 This metric is probably not directly useful, because it is 94 instantaneous and unidirectional. For most applications, 95 bidirectional connectivity is considerably more germane (e.g., any 96 TCP connection). Most applications also require connectivity over an 97 interval. Finally, one might not have instantaneous connectivity due 98 to a transient event such as a full queue at a router, even if at 99 nearby instants in time one does have connectivity. These points are 100 addressed below, with this metric serving as a building block. 102 Note also that we have not explicitly defined *when* the packet 103 arrives at Dst. The TTL field in IP packets is meant to limit IP 104 packet lifetimes to 255 seconds (RFC 791). In practice the TTL field 105 can be strictly a hop count (RFC 1812), with most Internet hops being 106 much shorter than one second. This means that most packets will have 107 nowhere near the 255 second lifetime. In principle, however, it is 108 also possible that packets might survive longer than 255 seconds. 109 Consideration of packet lifetimes must be taken into account in 110 attempts to measure the value of this metric. 112 Finally, one might assume that unidirectional connectivity is 113 difficult to measure in the absence of connectivity in the reverse 114 direction. Consider, however, the possibility that a process on 115 Dst's host notes when it receives packets from Src and reports this 116 fact either using an external channel, or later in time when Dst does 117 have connectivity to Src. Such a methodology could reliably measure 118 the unidirectional connectivity defined in this metric. 120 4. Instantaneous Two-way Connectivity 122 4.1. Metric Name: 124 Type-P-Instantaneous-Bidirectional-Connectivity 126 4.2. Metric Parameters: 127 + A1, the IP address of a host 128 + A2, the IP address of a host 129 + T, a time 131 ID Connectivity November 1997 133 4.3. Metric Units: 135 Boolean. 137 4.4. Definition: 139 Addresses A1 and A2 have *Type-P-Instantaneous-Bidirectional- 140 Connectivity* at time T if address A1 has Type-P-Instantaneous- 141 Unidirectional-Connectivity to address A2 and address A2 has Type-P- 142 Instantaneous-Unidirectional-Connectivity to address A1. 144 4.5. Discussion: 146 An alternative definition would be that at A1 and A2 are fully 147 connected if at time T address A1 has instantaneous connectivity to 148 address A2, and at time T+dT address A2 has instantaneous 149 connectivity to A1, where T+dT is when the packet sent from A1 150 arrives at A2. This definition is more useful for measurement, 151 because the measurement can use a reply from A2 to A1 in order to 152 assess full connectivity. It is a more complex definition, however, 153 because it breaks the symmetry between A1 and A2, and requires a 154 notion of quantifying how long a particular packet from A1 takes to 155 reach A2. We postpone discussion of this distinction until the 156 development of interval-connectivity metrics below. 158 5. One-way Connectivity 160 5.1. Metric Name: 162 Type-P-Interval-Unidirectional-Connectivity 164 5.2. Metric Parameters: 165 + Src, the IP address of a host 166 + Dst, the IP address of a host 167 + T, a time 168 + dT, a duration 169 {Comment: Thus, the closed interval [T, T+dT] denotes a time 170 interval.} 172 ID Connectivity November 1997 174 5.3. Metric Units: 176 Boolean. 178 5.4. Definition: 180 Address Src has *Type-P-Interval-Unidirectional-Connectivity* to 181 address Dst during the interval [T, T+dT] if for some T' within [T, 182 T+dT] it has Type-P-instantaneous-connectivity to Dst. 184 6. Two-way Connectivity 186 6.1. Metric Name: 188 Type-P-Interval-Bidirectional-Connectivity 190 6.2. Metric Parameters: 191 + A1, the IP address of a host 192 + A2, the IP address of a host 193 + T, a time 194 + dT, a duration 195 {Comment: Thus, the closed interval [T, T+dT] denotes a time 196 interval.} 198 6.3. Metric Units: 200 Boolean. 202 6.4. Definition: 204 Addresses A1 and A2 have *Type-P-Interval-Bidirectional-Connectivity* 205 between them during the interval [T, T+dT] if address A1 has Type-P- 206 Interval-Unidirectional-Connectivity to address A2 during the 207 interval and address A2 has Type-P-Interval-Unidirectional- 208 Connectivity to address A1 during the interval. 210 ID Connectivity November 1997 212 6.5. Discussion: 214 This metric is not quite what's needed for defining "useful" 215 connectivity - that requires the notion that a packet sent from A1 to 216 A2 can elicit a response from A2 that will reach A1. With this 217 definition, it could be that A1 and A2 have full-connectivity but 218 only, for example, at at time T1 early enough in the interval [T, 219 T+dT] that A1 and A2 cannot reply to packets sent by the other. This 220 deficiency motivates the next metric. 222 7. Two-way Temporal Connectivity 224 7.1. Metric Name: 226 Type-P1-P2-Interval-Temporal-Connectivity 228 7.2. Metric Parameters: 229 + Src, the IP address of a host 230 + Dst, the IP address of a host 231 + T, a time 232 + dT, a duration 233 {Comment: Thus, the closed interval [T, T+dT] denotes a time 234 interval.} 236 7.3. Metric Units: 238 Boolean. 240 7.4. Definition: 242 Address Src has *Type-P1-P2-Interval-Temporal-Connectivity* to 243 address Dst during the interval [T, T+dT] if there exist times T1 and 244 T2, and time intervals dT1 and dT2, such that: 245 + T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT]. 246 + T1+dT1 <= T2. 247 + At time T1, Src has Type-P1 instantanous connectivity to Dst. 248 + At time T2, Dst has Type-P2 instantanous connectivity to Src. 249 + dT1 is the time taken for a Type-P1 packet sent by Src at time T1 250 to arrive at Dst. 252 ID Connectivity November 1997 254 + dT2 is the time taken for a Type-P2 packet sent by Dst at time T2 255 to arrive at Src. 257 7.5. Discussion: 259 This metric defines "useful" connectivity -- Src can send a packet to 260 Dst that elicits a response. Because many applications utilize 261 different types of packets for forward and reverse traffic, it is 262 possible (and likely) that the desired responses to a Type-P1 packet 263 will be of a different type Type-P2. Therefore, in this metric we 264 allow for different types of packets in the forward and reverse 265 directions. 267 7.6. Methodologies: 269 Here we sketch a class of methodologies for estimating Type-P1-P2- 270 Interval-Temporal-Connectivity. It is a class rather than a single 271 methodology because the particulars will depend on the types P1 and 272 P2. 274 7.6.1. Inputs: 275 + Types P1 and P2, addresses A1 and A2, interval [T, T+dT]. 276 + N, the number of packets to send as probes for determining 277 connectivity. 278 + W, the "waiting time", which bounds for how long it is useful to 279 wait for a reply to a packet. 280 Required: W <= 255, dT > W. 282 7.6.2. Recommended values: 284 dT = 60 seconds. 285 W = 10 seconds. 286 N = 20 packets. 288 7.6.3. Algorithm: 290 + Compute N *sending-times* that are randomly, uniformly distributed 291 over [T, T+dT-W]. 293 ID Connectivity November 1997 295 + At each sending time, transmit from A1 a well-formed packet of 296 type P1 to A2. 297 + Inspect incoming network traffic to A1 to determine if a 298 successful reply is received. The particulars of doing so are 299 dependent on types P1 & P2, discussed below. If a successful 300 reply is received, the value of the measurement is "true". 301 + If no successful replies are received by time T+dT, the value of 302 the measurement is "false". 304 7.6.4. Discussion: 306 The algorithm is inexact because it does not (and cannot) probe 307 temporal connectivity at every instant in time between [T, T+dT]. 308 The value of N trades off measurement precision against network 309 measurement load. The state-of-the-art in Internet research does not 310 yet offer solid guidance for picking N. The values given above are 311 just guidelines. 313 7.6.5. Specific methodology for TCP: 315 A TCP-port-N1-port-N2 methodology sends TCP SYN packets with source 316 port N1 and dest port N2 at address A2. Network traffic incoming to 317 A1 is interpreted as follows: 318 + A SYN-ack packet from A2 to A1 with the proper acknowledgement 319 fields and ports indicates temporal connectivity. The measurement 320 terminates immediately with a value of "true". {Comment: the 321 connection now established between A1 and A2 should be properly 322 torn down using the usual FIN handshake (not by using a RST 323 packet, as these are not transmitted reliably).} 324 + A RST packet from A2 to A1 with the proper ports indicates 325 temporal connectivity between the addresses (and a *lack* of 326 service connectivity for TCP-port-N1-port-N2 - something that 327 probably should be addressed with another metric). 328 + An ICMP port-unreachable from A2 to A1 indicates temporal 329 connectivity between the addresses (and again a *lack* of service 330 connectivity for TCP-port-N1-port-N2). {Comment: TCP 331 implementations generally do not need to send ICMP port- 332 unreachable messages because a separate mechanism is available 333 (sending a RST). However, RFC 1122 states that a TCP receiving an 334 ICMP port-unreachable MUST treat it the same as the equivalent 335 transport-level mechanism (for TCP, a RST).} 337 ID Connectivity November 1997 339 + An ICMP host-unreachable or network-unreachable to A1 (not 340 necessarily from A2) with an enclosed IP header matching that sent 341 from A1 to A2 *suggests* a lack of temporal connectivity. If by 342 time T+dT no evidence of temporal connectivity has been gathered, 343 then the receipt of the ICMP can be used as additional information 344 to the measurement value of "false". 346 {Comment: Similar methodologies are needed for ICMP Echo, UDP, etc.} 348 8. Security Considerations 350 This memo raises no security issues. 352 9. References 354 F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June 355 1995. 357 R. Braden, "Requirements for Internet hosts - communication layers", 358 RFC 1122, October 1989. 360 V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, Paxson, "Framework 361 for IP Performance Metrics", Internet Draft , November 1996. 364 J. Postel, "Internet Protocol", RFC 791, September 1981. 366 10. Authors' Addresses 368 Jamshid Mahdavi 369 Pittsburgh Supercomputing Center 370 4400 5th Avenue 371 Pittsburgh, PA 15213 372 USA 374 Vern Paxson 375 MS 50B/2239 376 Lawrence Berkeley National Laboratory 377 University of California 378 Berkeley, CA 94720 379 USA 380 Phone: +1 510/486-7504