RFC 2498

IPPM Metrics for Measuring Connectivity

📅 published January 1999, from ietf

🎀 RFC 2498: IPPM Metrics for Measuring Connectivity 🎀

  • Series: Network Working Group
  • Number and title: RFC 2498, IPPM Metrics for Measuring Connectivity 💅
  • Authors: J. Mahdavi (Pittsburgh Supercomputing Center) and V. Paxson (Lawrence Berkeley National Laboratory) 🫶
  • Category: Experimental 🧪
  • Date: January 1999 🌸
  • Obsoletes and updates: This document doesn't list any RFCs that it obsoletes or updates. ✨

Status of This Memo

okay so this memo defines an Experimental Protocol for the Internet community 🧪. It is NOT an Internet standard of any kind, bestie. Discussion and suggestions for improvement are requested 💖, so send your thoughts! Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (1999). All Rights Reserved. 📜

1. Introduction ✨

Connectivity is literally the basic stuff the Internet is made of 🌐. So metrics that figure out whether pairs of hosts (IP addresses) can reach each other have to be the foundation of any measurement suite 🫶. This memo defines several of these metrics, and some of them mainly exist as building blocks for the rest 🧱.

This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on ideas introduced in RFC 2330, the IPPM framework document 💜. The reader is assumed to already know that document, so go read it first if you haven't 🙈.

Here's how the memo is structured, lowkey a little roadmap 🗺️:

  • An analytic metric, called Type-P-Instantaneous-Unidirectional-Connectivity, is introduced to define one-way connectivity at one moment in time ⏱️.
  • Using that metric, another analytic metric, called Type-P-Instantaneous-Bidirectional-Connectivity, is introduced to define two-way connectivity at one moment in time 🔁.
  • Using these metrics, corresponding one-way and two-way analytic metrics are defined for connectivity over an interval of time 📆.
  • Using these metrics, an analytic metric, called Type-P1-P2-Interval-Temporal-Connectivity, is introduced to define a useful notion of two-way connectivity between two hosts over an interval of time 👑.
  • Methodologies are then presented and discussed for estimating Type-P1-P2-Interval-Temporal-Connectivity in a variety of settings 🔥.

Careful definition of Type-P1-P2-Interval-Temporal-Connectivity, plus the discussion of the metric and the methodologies for estimating it, are the two chief contributions of this memo 🏆. Iconic, honestly 💅.

2. Instantaneous One-way Connectivity

2.1. Metric Name:

Type-P-Instantaneous-Unidirectional-Connectivity 🦋

2.2. Metric Parameters:

  • Src, the IP address of a host 🖥️
  • Dst, the IP address of a host 🖥️
  • T, a time ⏰

2.3. Metric Units:

Boolean. ✅

2.4. Definition:

Src has Type-P-Instantaneous-Unidirectional-Connectivity to Dst at time T if a type-P packet transmitted from Src to Dst at time T will arrive at Dst 📬.

2.5. Discussion:

For most applications (for example, any TCP connection), bidirectional connectivity is way more germane than unidirectional connectivity 💀. Unidirectional connectivity can still be of interest for some security applications, though. For example, you could test whether a firewall correctly filters out a "ping of death" 🛡️🙅‍♀️.

Most applications also need connectivity over an interval, but this metric is instantaneous 😤. Again, for some security applications, instantaneous connectivity still matters 🔐. And finally, you might not have instantaneous connectivity because of a transient event, like a full queue at a router, even if you do have connectivity at nearby instants in time 🚦. These points get addressed below, with this metric acting as a building block 🧱.

Note also that we have not explicitly defined when the packet arrives at Dst. The TTL field in IP packets is meant to limit IP packet lifetimes to 255 seconds (RFC 791) ⏳. In practice, the TTL field can be strictly a hop count (RFC 1812), with most Internet hops being much shorter than one second 🏃‍♀️. This means that most packets will have nowhere near the 255 second lifetime 😌. In principle, though, packets might also survive longer than 255 seconds 😳. Consideration of packet lifetimes must be taken into account when you try to measure the value of this metric 📏.

Finally, you might assume that unidirectional connectivity is difficult to measure without connectivity in the reverse direction 🙃. Consider, however, this possibility: a process on Dst's host notes when it receives packets from Src, then reports that fact either using an external channel, or later in time when Dst does have connectivity to Src 💌. Such a methodology could reliably measure the unidirectional connectivity defined in this metric 🎯. Big brain move 🧠✨.

3. Instantaneous Two-way Connectivity

3.1. Metric Name:

Type-P-Instantaneous-Bidirectional-Connectivity 🦋

3.2. Metric Parameters:

  • A1, the IP address of a host 🖥️
  • A2, the IP address of a host 🖥️
  • T, a time ⏰

3.3. Metric Units:

Boolean. ✅

3.4. Definition:

Addresses A1 and A2 have Type-P-Instantaneous-Bidirectional-Connectivity at time T if address A1 has Type-P-Instantaneous-Unidirectional-Connectivity to address A2, and address A2 has Type-P-Instantaneous-Unidirectional-Connectivity to address A1 🫂.

3.5. Discussion:

There's an alternative definition, and it's giving "more complicated but useful" 🤓. Here, A1 and A2 are fully connected if at time T address A1 has instantaneous connectivity to address A2, and at time T+dT address A2 has instantaneous connectivity to A1. Here, T+dT is when the packet sent from A1 arrives at A2 📦.

This definition is more useful for measurement, because the measurement can use a reply from A2 to A1 to assess full connectivity 📡. It is more complex, though, because it breaks the symmetry between A1 and A2, and it requires a notion of quantifying how long a particular packet from A1 takes to reach A2 ⌛. We'll postpone discussion of this distinction until we develop the interval-connectivity metrics below 🥹.

4. One-way Connectivity

4.1. Metric Name:

Type-P-Interval-Unidirectional-Connectivity 🦋

4.2. Metric Parameters:

  • Src, the IP address of a host 🖥️
  • Dst, the IP address of a host 🖥️
  • T, a time ⏰
  • dT, a duration ⏳

{Comment: Thus, the closed interval [T, T+dT] denotes a time interval.}

4.3. Metric Units:

Boolean. ✅

4.4. Definition:

Address Src has Type-P-Interval-Unidirectional-Connectivity to address Dst during the interval [T, T+dT] if, for some T' within [T, T+dT], it has Type-P-instantaneous-connectivity to Dst 🎀.

5. Two-way Connectivity

5.1. Metric Name:

Type-P-Interval-Bidirectional-Connectivity 🦋

5.2. Metric Parameters:

  • A1, the IP address of a host 🖥️
  • A2, the IP address of a host 🖥️
  • T, a time ⏰
  • dT, a duration ⏳

{Comment: Thus, the closed interval [T, T+dT] denotes a time interval.}

5.3. Metric Units:

Boolean. ✅

5.4. Definition:

Addresses A1 and A2 have Type-P-Interval-Bidirectional-Connectivity between them during the interval [T, T+dT] if address A1 has Type-P-Interval-Unidirectional-Connectivity to address A2 during the interval, and address A2 has Type-P-Interval-Unidirectional-Connectivity to address A1 during the interval 🤝.

5.5. Discussion:

Okay, this metric isn't quite what we need for defining "generally useful" connectivity 😬. That requires the idea that a packet sent from A1 to A2 can trigger a response from A2 that reaches A1 📨. With this definition, A1 and A2 could have full connectivity, but only, for example, at time T1 early enough in the interval [T, T+dT] that A1 and A2 can't reply to packets sent by the other 🙃. That gap is the reason we need the next metric 🫠.

6. Two-way Temporal Connectivity

6.1. Metric Name:

Type-P1-P2-Interval-Temporal-Connectivity 👑

6.2. Metric Parameters:

  • Src, the IP address of a host 🖥️
  • Dst, the IP address of a host 🖥️
  • T, a time ⏰
  • dT, a duration ⏳

{Comment: Thus, the closed interval [T, T+dT] denotes a time interval.}

6.3. Metric Units:

Boolean. ✅

6.4. Definition:

Address Src has Type-P1-P2-Interval-Temporal-Connectivity to address Dst during the interval [T, T+dT] if there exist times T1 and T2, and time intervals dT1 and dT2, such that:

  • T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT].
  • T1+dT1 <= T2.
  • At time T1, Src has Type-P1 instantanous connectivity to Dst.
  • At time T2, Dst has Type-P2 instantanous connectivity to Src.
  • dT1 is the time taken for a Type-P1 packet sent by Src at time T1 to arrive at Dst.
  • dT2 is the time taken for a Type-P2 packet sent by Dst at time T2 to arrive at Src.

6.5. Discussion:

This metric defines "generally useful" connectivity, meaning Src can send a packet to Dst that elicits a response 🙌. Many applications use different types of packets for forward and reverse traffic, so it's possible (and likely!) that the desired responses to a Type-P1 packet will be of a different type, Type-P2 🔄. That's why this metric lets us use different types of packets in the forward and reverse directions 💖.

6.6. Methodologies:

Here we sketch a class of methodologies for estimating Type-P1-P2-Interval-Temporal-Connectivity. It's a class rather than a single methodology, because the particulars depend on the types P1 and P2 🧩.

6.6.1. Inputs:

  • Types P1 and P2, addresses A1 and A2, interval [T, T+dT].
  • N, the number of packets to send as probes for determining connectivity 📮.
  • W, the "waiting time", which bounds how long it's useful to wait for a reply to a packet ⏱️.

Required: W <= 255, dT > W.

  • dT = 60 seconds.
  • W = 10 seconds.
  • N = 20 packets.

6.6.3. Algorithm:

  • Compute N sending-times that are randomly and uniformly distributed over [T, T+dT-W] 🎲.
  • At each sending time, transmit from A1 a well-formed packet of type P1 to A2 🚀.
  • Inspect incoming network traffic to A1 to determine whether a successful reply is received. The particulars of doing so depend on types P1 and P2, which we'll get into below 🔍. If any successful reply is received, the value of the measurement is "true". At this point, the measurement can terminate 🛑.
  • If no successful replies are received by time T+dT, the value of the measurement is "false" ❌.

6.6.4. Discussion:

The algorithm is inexact, because it does not (and cannot) probe temporal connectivity at every instant in time between [T, T+dT] 🫣. The value of N trades off measurement precision against network measurement load ⚖️. The state-of-the-art in Internet research doesn't yet offer solid guidance for picking N 🤷‍♀️. The values given above are just guidelines, not rules, so you do you 💅✨.

6.6.5. Specific methodology for TCP 🌸

okay bestie, this is the TCP one and it's a whole vibe 🎀 the TCP-port-N1-port-N2 methodology sends TCP SYN packets with source port N1 and dest port N2 at address A2. Then we just watch what comes back to A1 and read the signs ✨

  • A SYN-ack from A2 to A1 with the right acknowledgement fields and ports means there's temporal connectivity 💖 The measurement ends right away with a value of true. 🦋
💬 ok so if the methodology ends up with a full TCP connection between A1 and A2 (aka A1's stack ACKs the SYN-ack and finishes the three-way handshake), then that connection should be closed with the usual FIN handshake, NOT a RST, because RST packets aren't reliably delivered 🙅‍♀️ but if the handshake never completes, which happens when the measurement tool on A1 makes its own SYN instead of going through A1's TCP stack, then A1's stack will close the connection reliably on its own while A2 keeps resending the SYN-ack trying to connect 💅 and last but not least, using A1's stack for this makes things messier, since the stack might retransmit the first SYN and change how many probe packets get sent 😭
  • A RST from A2 to A1 with the right ports means there's temporal connectivity between the addresses, but also a lack of service connectivity for TCP-port-N1-port-N2 💀 (this is something that probably deserves its own metric, bestie 🧚)
  • An ICMP port-unreachable from A2 to A1 also means temporal connectivity between the addresses, and again a lack of service connectivity for TCP-port-N1-port-N2 🌈
💬 TCP doesn't usually need to send ICMP port-unreachable messages because it already has its own tool for this, which is sending a RST 💖 but RFC 1122 says that a TCP receiving an ICMP port-unreachable MUST treat it the same as the matching transport-level mechanism (for TCP, that's a RST) 🫶
  • An ICMP host-unreachable or network-unreachable to A1 (it doesn't have to come from A2) with an enclosed IP header that matches the one sent from A1 to A2 suggests a lack of temporal connectivity 👀 If no evidence of temporal connectivity has shown up by time T+dT, then the ICMP can be used as extra info to back up a measurement value of false. 🙈
💬 similar methodologies are needed for ICMP Echo, UDP, etc. 🍓 (the people need more, periodt)

7. Acknowledgments 🫶

the comments from Guy Almes, Martin Horneffer, Jeff Sedayao, and Sean Shapira were so helpful, and we're forever grateful 💜

8. Security Considerations 🔥

⚠️ this part is serious, bestie 😭 As noted in RFC 2330, active measurement techniques like the ones in this document can be abused for denial-of-service attacks that are disguised as legit measurement activity. 💀 And testing for connectivity can also be used to poke at firewalls and other security mechanisms to find weak spots. 🙅‍♀️

9. References ✨

[RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
           1812, June 1995.

[RFC1122]  Braden, R., Editor, "Requirements for Internet Hosts --
           Communication Layers", STD, 3, RFC 1122,  October 1989.

[RFC2330]  Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
           "Framework for IP Performance Metrics", RFC 2330, May
           1998.

[RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
           1981.

10. Authors' Addresses 🦋

Jamshid Mahdavi
Pittsburgh Supercomputing Center
4400 5th Avenue
Pittsburgh, PA  15213
USA

EMail: mahdavi@psc.edu


Vern Paxson
MS 50A-3111
Lawrence Berkeley National Laboratory
University of California
Berkeley, CA  94720
USA

Phone: +1 510/486-7504
EMail: vern@ee.lbl.gov

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🌈✨

📦 where this page comes from