idnits 2.17.1 draft-ietf-bmwg-ippm-connect-00.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-25) 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 80 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '... uments of th...' == Line 16 has weird spacing: '... Drafts are ...' == Line 21 has weird spacing: '... please check...' == Line 23 has weird spacing: '...ctories on f...' == Line 28 has weird spacing: '... does not ...' == (75 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 1996) is 10023 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: 10 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 1997 November 1996 6 Connectivity 7 9 1. Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing 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 1996 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 met- 56 rics are defined for connectivity over an interval of time. 57 + Using these metrics, an analytic metric, called Type- 58 P1-P2-Interval-Causal-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-Causal-Connectivity in a variety of settings. 63 Careful definition of Type-P1-P2-Interval-Causal-Connectivity and the 64 discussion of the metric and the methodologies for estimating it are 65 the two chief contributions of the memo. 67 3. Instantaneous One-way Connectivity 69 3.1. Metric Name: 71 Type-P-Instantaneous-Unidirectional-Connectivity 73 3.2. Metric Parameters: 74 + Src, the IP address of a host 75 + Dst, the IP address of a host 76 + T, a time 78 3.3. Metric Units: 80 Boolean. 82 3.4. Definition: 84 Src has *Type-P-Instantaneous-Unidirectional-Connectivity* to Dst at 85 time T if a type-P packet transmitted from Src to Dst at time T will 86 arrive at Dst. 88 ID Connectivity November 1996 90 3.5. Discussion: 92 This metric is probably not directly useful, because it is instanta- 93 neous and unidirectional. For most applications, bidirectional con- 94 nectivity is considerably more germane (e.g., any TCP connection). 95 Most applications also require connectivity over an interval. 96 Finally, one might not have instantaneous connectivity due to a tran- 97 sient event such as a full queue at a router, even if at nearby 98 instants in time one does have connectivity. These points are 99 addressed below, with this metric serving as a building block. 101 Note also that we have not explicitly defined *when* the packet 102 arrives at Dst. The TTL field in IP packets is meant to limit IP 103 packet lifetimes to 255 seconds (RFC 791). In practice the TTL field 104 can be strictly a hop count (RFC 1812), with most Internet hops being 105 much shorter than one second. This means that most packets will have 106 nowhere near the 255 second lifetime. In principle, however, it is 107 also possible that packets might survive longer than 255 seconds. 108 Consideration of packet lifetimes must be taken into account in 109 attempts to measure the value of this metric. 111 Finally, one might assume that unidirectional connectivity is diffi- 112 cult to measure in the absence of connectivity in the reverse direc- 113 tion. Consider, however, the possibility that a process on Dst's 114 host notes when it receives packets from Src and reports this fact 115 either using an external channel, or later in time when Dst does have 116 connectivity to Src. Such a methodology could reliably measure the 117 unidirectional connectivity defined in this metric. 119 4. Instantaneous Two-way Connectivity 121 4.1. Metric Name: 123 Type-P-Instantaneous-Bidirectional-Connectivity 125 4.2. Metric Parameters: 126 + A1, the IP address of a host 127 + A2, the IP address of a host 128 + T, a time 130 ID Connectivity November 1996 132 4.3. Metric Units: 134 Boolean. 136 4.4. Definition: 138 Addresses A1 and A2 have *Type-P-Instantaneous-Bidirectional- 139 Connectivity* at time T if address A1 has Type-P-Instantaneous- 140 Unidirectional-Connectivity to address A2 and address A2 has Type-P- 141 Instantaneous-Unidirectional-Connectivity to address A1. 143 4.5. Discussion: 145 An alternative definition would be that at A1 and A2 are fully con- 146 nected if at time T address A1 has instantaneous connectivity to 147 address A2, and at time T+dT address A2 has instantaneous connectiv- 148 ity to A1, where T+dT is when the packet sent from A1 arrives at A2. 149 This definition is more useful for measurement, because the measure- 150 ment can use a reply from A2 to A1 in order to assess full connectiv- 151 ity. It is a more complex definition, however, because it breaks the 152 symmetry between A1 and A2, and requires a notion of quantifying how 153 long a particular packet from A1 takes to reach A2. We postpone dis- 154 cussion of this distinction until the development of interval- 155 connectivity metrics below. 157 5. One-way Connectivity 159 5.1. Metric Name: 161 Type-P-Interval-Unidirectional-Connectivity 163 5.2. Metric Parameters: 164 + Src, the IP address of a host 165 + Dst, the IP address of a host 166 + T, a time 167 + dT, a duration 168 {Comment: Thus, the closed interval [T, T+dT] denotes a time inter- 169 val.} 171 ID Connectivity November 1996 173 5.3. Metric Units: 175 Boolean. 177 5.4. Definition: 179 Address Src has *Type-P-Interval-Unidirectional-Connectivity* to 180 address Dst during the interval [T, T+dT] if for some T' within [T, 181 T+dT] it has Type-P-instantaneous-connectivity to Dst. 183 6. Two-way Connectivity 185 6.1. Metric Name: 187 Type-P-Interval-Bidirectional-Connectivity 189 6.2. Metric Parameters: 190 + A1, the IP address of a host 191 + A2, the IP address of a host 192 + T, a time 193 + dT, a duration 194 {Comment: Thus, the closed interval [T, T+dT] denotes a time inter- 195 val.} 197 6.3. Metric Units: 199 Boolean. 201 6.4. Definition: 203 Addresses A1 and A2 have *Type-P-Interval-Bidirectional-Connectivity* 204 between them during the interval [T, T+dT] if address A1 has Type-P- 205 Interval-Unidirectional-Connectivity to address A2 during the inter- 206 val and address A2 has Type-P-Interval-Unidirectional-Connectivity to 207 address A1 during the interval. 209 ID Connectivity November 1996 211 6.5. Discussion: 213 This metric is not quite what's needed for defining "useful" connec- 214 tivity - that requires the notion that a packet sent from A1 to A2 215 can elicit a response from A2 that will reach A1. With this defini- 216 tion, it could be that A1 and A2 have full-connectivity but only, for 217 example, at at time T1 early enough in the interval [T, T+dT] that A1 218 and A2 cannot reply to packets sent by the other. This deficiency 219 motivates the next metric. 221 7. Two-way Causal Connectivity 223 7.1. Metric Name: 225 Type-P1-P2-Interval-Causal-Connectivity 227 7.2. Metric Parameters: 228 + Src, the IP address of a host 229 + Dst, the IP address of a host 230 + T, a time 231 + dT, a duration 232 {Comment: Thus, the closed interval [T, T+dT] denotes a time inter- 233 val.} 235 7.3. Metric Units: 237 Boolean. 239 7.4. Definition: 241 Address Src has *Type-P1-P2-Interval-Causal-Connectivity* to address 242 Dst during the interval [T, T+dT] if there exist times T1 and T2, and 243 time intervals dT1 and dT2, such that: 244 + T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT]. 245 + T1+dT1 <= T2. 246 + At time T1, Src has Type-P1 instantanous connectivity to Dst. 247 + At time T2, Dst has Type-P2 instantanous connectivity to Src. 248 + dT1 is the time taken for a packet sent by Src at time T1 to 249 arrive at Dst. 251 ID Connectivity November 1996 253 + dT2 is the time taken for a packet sent by Dst at time T2 to 254 arrive at Src. 256 7.5. Discussion: 258 This metric defines "useful" connectivity -- Src can send a packet to 259 Dst that elicits a response. Because many applications utilize dif- 260 ferent types of packets for forward and reverse traffic, it is possi- 261 ble (and likely) that the desired responses to a Type-P1 packet will 262 be of a different type Type-P2. Therefore, in this metric we allow 263 for different types of packets in the forward and reverse directions. 265 7.6. Methodologies: 267 Here we sketch a class of methodologies for estimating Type- 268 P1-P2-Interval-Causal-Connectivity. It is a class rather than a sin- 269 gle methodology because the particulars will depend on the types P1 270 and P2. 272 7.6.1. Inputs: 273 + Types P1 and P2, addresses A1 and A2, interval [T, T+dT], and 274 + N, the number of packets to send as probes for determining connec- 275 tivity. 276 + W, the "waiting time", which bounds for how long it is useful to 277 wait for a reply to a packet. 278 Required: W <= 255, dT > W. 280 7.6.2. Recommended values: 282 dT = 60 seconds. 283 W = 10 seconds. 284 N = 20 packets. 286 7.6.3. Algorithm: 288 + Compute N *sending-times* that are randomly, uniformly distributed 289 over [T, T+dT-W]. 290 + At each sending time, transmit from A1 a well-formed packet of 291 type P1 to A2. 293 ID Connectivity November 1996 295 + Inspect incoming network traffic to A1 to determine if a success- 296 ful reply is received. The particulars of doing so are dependent 297 on types P1 & P2, discussed below. If a successful reply is 298 received, the value of the measurement is "true". 299 + If no successful replies are received by time T+dT, the value of 300 the measurement is "false". 302 7.6.4. Discussion: 304 The algorithm is inexact because it does not (and cannot) probe 305 causal connectivity at every instant in time between [T, T+dT]. The 306 value of N trades off measurement precision against network measure- 307 ment load. The state-of-the-art in Internet research does not yet 308 offer solid guidance for picking N. The values given above are just 309 guidelines. 311 7.6.5. Specific methodology for TCP: 313 A TCP-port-N1-port-N2 methodology sends TCP SYN packets with source 314 port N1 and dest port N2 at address A2. Incoming network traffic is 315 interpreted as follows: 316 + A SYN-ack packet from A2 to A1 with the proper acknowledgement 317 fields and ports on A1 indicates causal connectivity. The mea- 318 surement terminates immediately with a value of "true". {Comment: 319 the connection now established between A1 and A2 should be prop- 320 erly torn down using the usual FIN handshake (not by using a RST 321 packet, as these are not transmitted reliably).} 322 + A RST packet from A2 to A1 with the proper ports on A1 indicates 323 causal connectivity between the addresses (and a *lack* of service 324 connectivity for TCP-port-N1-port-N2 - something that probably 325 should be addressed with another metric). 326 + An ICMP port-unreachable from A2 to A1 indicates causal connectiv- 327 ity between the addresses (and again a *lack* of service connec- 328 tivity for TCP-port-N1-port-N2). {Comment: Are there TCP imple- 329 mentations that generate ICMP's instead of RST's? Do the RFC's 330 allow this? Certainly they do for UDP, so the notion makes 331 sense.} 332 + An ICMP host-unreachable or network-unreachable to A1 (not neces- 333 sarily from A2) with an enclosed IP header matching that sent from 334 A1 to A2 *suggests* a lack of causal connectivity. If by time 335 T+dT no evidence of causal connectivity has been gathered, then 336 the receipt of the ICMP can be used as additional information to 337 the measurement value of "false". 339 {Comment: Similar methodologies are needed for ICMP Echo, UDP, etc.} 341 ID Connectivity November 1996 343 8. Security Considerations 345 This memo raises no security issues. 347 9. References 349 G. Almes, W. Cerveny, P. Krishnaswamy, J. Mahdavi, M. Mathis, and V. 350 Paxson, "Framework for IP Provider Metrics", Internet Draft , November 1996. 353 J. Postel, "Internet Protocol", RFC 791, September 1981. 355 F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June 356 1995. 358 10. Authors' Addresses 360 Jamshid Mahdavi 361 Pittsburgh Supercomputing Center 362 4400 5th Avenue 363 Pittsburgh, PA 15213 364 USA 366 Vern Paxson 367 MS 50B/2239 368 Lawrence Berkeley National Laboratory 369 University of California 370 Berkeley, CA 94720 371 USA 372 Phone: +1 510/486-7504