draft-ietf-ippm-connectivity-03.txt   draft-ietf-ippm-connectivity-04.txt 
Network Working Group J. Mahdavi, Pittsburgh Supercomputer Center Network Working Group J. Mahdavi, Pittsburgh Supercomputer Center
Internet Draft V. Paxson, Lawrence Berkeley National Laboratory Internet Draft V. Paxson, Lawrence Berkeley National Laboratory
Expiration Date: April 1999 October 1998 Expiration Date: May 1999 November 1998
IPPM Metrics for Measuring Connectivity IPPM Metrics for Measuring Connectivity
<draft-ietf-ippm-connectivity-03.txt> <draft-ietf-ippm-connectivity-04.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents months, and may be updated, replaced, or obsoleted by other documents
skipping to change at page 2, line 5 skipping to change at page 2, line 5
define several such metrics, some of which serve mainly as building define several such metrics, some of which serve mainly as building
blocks for the others. blocks for the others.
This memo defines a series of metrics for connectivity between a pair This memo defines a series of metrics for connectivity between a pair
of Internet hosts. It builds on notions introduced and discussed in of Internet hosts. It builds on notions introduced and discussed in
RFC 2330, the IPPM framework document. The reader is assumed to be RFC 2330, the IPPM framework document. The reader is assumed to be
familiar with that document. familiar with that document.
The structure of the memo is as follows: The structure of the memo is as follows:
ID IPPM Metrics for Measuring Connectivity October 1998 ID IPPM Metrics for Measuring Connectivity November 1998
+ An analytic metric, called Type-P-Instantaneous-Unidirectional- + An analytic metric, called Type-P-Instantaneous-Unidirectional-
Connectivity, will be introduced to define one-way connectivity at Connectivity, will be introduced to define one-way connectivity at
one moment in time. one moment in time.
+ Using this metric, another analytic metric, called Type-P- + Using this metric, another analytic metric, called Type-P-
Instantaneous-Bidirectional-Connectivity, will be introduced to Instantaneous-Bidirectional-Connectivity, will be introduced to
define two-way connectivity at one moment in time. define two-way connectivity at one moment in time.
+ Using these metrics, corresponding one- and two-way analytic + Using these metrics, corresponding one- and two-way analytic
metrics are defined for connectivity over an interval of time. metrics are defined for connectivity over an interval of time.
+ Using these metrics, an analytic metric, called Type-P1-P2- + Using these metrics, an analytic metric, called Type-P1-P2-
skipping to change at page 3, line 5 skipping to change at page 3, line 5
3.3. Metric Units: 3.3. Metric Units:
Boolean. Boolean.
3.4. Definition: 3.4. Definition:
Src has *Type-P-Instantaneous-Unidirectional-Connectivity* to Dst at 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 time T if a type-P packet transmitted from Src to Dst at time T will
arrive at Dst. arrive at Dst.
ID IPPM Metrics for Measuring Connectivity October 1998 ID IPPM Metrics for Measuring Connectivity November 1998
3.5. Discussion: 3.5. Discussion:
For most applications (e.g., any TCP connection) bidirectional For most applications (e.g., any TCP connection) bidirectional
connectivity is considerably more germane than unidirectional connectivity is considerably more germane than unidirectional
connectivity, although unidirectional connectivity can be of interest connectivity, although unidirectional connectivity can be of interest
for some security applications (e.g., testing whether a firewall for some security applications (e.g., testing whether a firewall
correctly filters out a "ping of death"). Most applications also correctly filters out a "ping of death"). Most applications also
require connectivity over an interval, while this metric is require connectivity over an interval, while this metric is
instantaneous, though, again, for some security applications instantaneous, though, again, for some security applications
skipping to change at page 4, line 5 skipping to change at page 4, line 5
the unidirectional connectivity defined in this metric. the unidirectional connectivity defined in this metric.
4. Instantaneous Two-way Connectivity 4. Instantaneous Two-way Connectivity
4.1. Metric Name: 4.1. Metric Name:
Type-P-Instantaneous-Bidirectional-Connectivity Type-P-Instantaneous-Bidirectional-Connectivity
4.2. Metric Parameters: 4.2. Metric Parameters:
ID IPPM Metrics for Measuring Connectivity October 1998 ID IPPM Metrics for Measuring Connectivity November 1998
+ A1, the IP address of a host + A1, the IP address of a host
+ A2, the IP address of a host + A2, the IP address of a host
+ T, a time + T, a time
4.3. Metric Units: 4.3. Metric Units:
Boolean. Boolean.
4.4. Definition: 4.4. Definition:
Addresses A1 and A2 have *Type-P-Instantaneous-Bidirectional- Addresses A1 and A2 have *Type-P-Instantaneous-Bidirectional-
Connectivity* at time T if address A1 has Type-P-Instantaneous- Connectivity* at time T if address A1 has Type-P-Instantaneous-
Unidirectional-Connectivity to address A2 and address A2 has Type-P- Unidirectional-Connectivity to address A2 and address A2 has Type-P-
Instantaneous-Unidirectional-Connectivity to address A1. Instantaneous-Unidirectional-Connectivity to address A1.
4.5. Discussion: 4.5. Discussion:
An alternative definition would be that at A1 and A2 are fully An alternative definition would be that A1 and A2 are fully connected
connected if at time T address A1 has instantaneous connectivity to if at time T address A1 has instantaneous connectivity to address A2,
address A2, and at time T+dT address A2 has instantaneous and at time T+dT address A2 has instantaneous connectivity to A1,
connectivity to A1, where T+dT is when the packet sent from A1 where T+dT is when the packet sent from A1 arrives at A2. This
arrives at A2. This definition is more useful for measurement, definition is more useful for measurement, because the measurement
because the measurement can use a reply from A2 to A1 in order to can use a reply from A2 to A1 in order to assess full connectivity.
assess full connectivity. It is a more complex definition, however, It is a more complex definition, however, because it breaks the
because it breaks the symmetry between A1 and A2, and requires a symmetry between A1 and A2, and requires a notion of quantifying how
notion of quantifying how long a particular packet from A1 takes to long a particular packet from A1 takes to reach A2. We postpone
reach A2. We postpone discussion of this distinction until the discussion of this distinction until the development of interval-
development of interval-connectivity metrics below. connectivity metrics below.
5. One-way Connectivity 5. One-way Connectivity
5.1. Metric Name: 5.1. Metric Name:
Type-P-Interval-Unidirectional-Connectivity Type-P-Interval-Unidirectional-Connectivity
5.2. Metric Parameters: 5.2. Metric Parameters:
+ Src, the IP address of a host + Src, the IP address of a host
ID IPPM Metrics for Measuring Connectivity October 1998 ID IPPM Metrics for Measuring Connectivity November 1998
+ Dst, the IP address of a host + Dst, the IP address of a host
+ T, a time + T, a time
+ dT, a duration + dT, a duration
{Comment: Thus, the closed interval [T, T+dT] denotes a time {Comment: Thus, the closed interval [T, T+dT] denotes a time
interval.} interval.}
5.3. Metric Units: 5.3. Metric Units:
Boolean. Boolean.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
Boolean. Boolean.
6.4. Definition: 6.4. Definition:
Addresses A1 and A2 have *Type-P-Interval-Bidirectional-Connectivity* Addresses A1 and A2 have *Type-P-Interval-Bidirectional-Connectivity*
between them during the interval [T, T+dT] if address A1 has Type-P- between them during the interval [T, T+dT] if address A1 has Type-P-
Interval-Unidirectional-Connectivity to address A2 during the Interval-Unidirectional-Connectivity to address A2 during the
interval and address A2 has Type-P-Interval-Unidirectional- interval and address A2 has Type-P-Interval-Unidirectional-
Connectivity to address A1 during the interval. Connectivity to address A1 during the interval.
ID IPPM Metrics for Measuring Connectivity October 1998 ID IPPM Metrics for Measuring Connectivity November 1998
6.5. Discussion: 6.5. Discussion:
This metric is not quite what's needed for defining "generally This metric is not quite what's needed for defining "generally
useful" connectivity - that requires the notion that a packet sent useful" connectivity - that requires the notion that a packet sent
from A1 to A2 can elicit a response from A2 that will reach A1. With from A1 to A2 can elicit a response from A2 that will reach A1. With
this definition, it could be that A1 and A2 have full-connectivity this definition, it could be that A1 and A2 have full-connectivity
but only, for example, at at time T1 early enough in the interval [T, but only, for example, at time T1 early enough in the interval [T,
T+dT] that A1 and A2 cannot reply to packets sent by the other. This T+dT] that A1 and A2 cannot reply to packets sent by the other. This
deficiency motivates the next metric. deficiency motivates the next metric.
7. Two-way Temporal Connectivity 7. Two-way Temporal Connectivity
7.1. Metric Name: 7.1. Metric Name:
Type-P1-P2-Interval-Temporal-Connectivity Type-P1-P2-Interval-Temporal-Connectivity
7.2. Metric Parameters: 7.2. Metric Parameters:
skipping to change at page 7, line 5 skipping to change at page 7, line 5
Address Src has *Type-P1-P2-Interval-Temporal-Connectivity* to Address Src has *Type-P1-P2-Interval-Temporal-Connectivity* to
address Dst during the interval [T, T+dT] if there exist times T1 and address Dst during the interval [T, T+dT] if there exist times T1 and
T2, and time intervals dT1 and dT2, such that: T2, and time intervals dT1 and dT2, such that:
+ T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT]. + T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT].
+ T1+dT1 <= T2. + T1+dT1 <= T2.
+ At time T1, Src has Type-P1 instantanous connectivity to Dst. + At time T1, Src has Type-P1 instantanous connectivity to Dst.
+ At time T2, Dst has Type-P2 instantanous connectivity to Src. + 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 + dT1 is the time taken for a Type-P1 packet sent by Src at time T1
to arrive at Dst. to arrive at Dst.
ID IPPM Metrics for Measuring Connectivity October 1998 ID IPPM Metrics for Measuring Connectivity November 1998
+ dT2 is the time taken for a Type-P2 packet sent by Dst at time T2 + dT2 is the time taken for a Type-P2 packet sent by Dst at time T2
to arrive at Src. to arrive at Src.
7.5. Discussion: 7.5. Discussion:
This metric defines "generally useful" connectivity -- Src can send a This metric defines "generally useful" connectivity -- Src can send a
packet to Dst that elicits a response. Because many applications packet to Dst that elicits a response. Because many applications
utilize different types of packets for forward and reverse traffic, utilize different types of packets for forward and reverse traffic,
it is possible (and likely) that the desired responses to a Type-P1 it is possible (and likely) that the desired responses to a Type-P1
skipping to change at page 8, line 5 skipping to change at page 8, line 5
dT = 60 seconds. dT = 60 seconds.
W = 10 seconds. W = 10 seconds.
N = 20 packets. N = 20 packets.
7.6.3. Algorithm: 7.6.3. Algorithm:
+ Compute N *sending-times* that are randomly, uniformly distributed + Compute N *sending-times* that are randomly, uniformly distributed
over [T, T+dT-W]. over [T, T+dT-W].
ID IPPM Metrics for Measuring Connectivity October 1998 ID IPPM Metrics for Measuring Connectivity November 1998
+ At each sending time, transmit from A1 a well-formed packet of + At each sending time, transmit from A1 a well-formed packet of
type P1 to A2. type P1 to A2.
+ Inspect incoming network traffic to A1 to determine if a + Inspect incoming network traffic to A1 to determine if a
successful reply is received. The particulars of doing so are successful reply is received. The particulars of doing so are
dependent on types P1 & P2, discussed below. If a successful dependent on types P1 & P2, discussed below. If any successful
reply is received, the value of the measurement is "true". 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 + If no successful replies are received by time T+dT, the value of
the measurement is "false". the measurement is "false".
7.6.4. Discussion: 7.6.4. Discussion:
The algorithm is inexact because it does not (and cannot) probe The algorithm is inexact because it does not (and cannot) probe
temporal connectivity at every instant in time between [T, T+dT]. temporal connectivity at every instant in time between [T, T+dT].
The value of N trades off measurement precision against network The value of N trades off measurement precision against network
measurement load. The state-of-the-art in Internet research does not measurement load. The state-of-the-art in Internet research does not
yet offer solid guidance for picking N. The values given above are yet offer solid guidance for picking N. The values given above are
skipping to change at page 9, line 5 skipping to change at page 9, line 5
the three-way handshake is not completed, however, which will the three-way handshake is not completed, however, which will
occur if the measurement tool on A1 synthesizes its own initial occur if the measurement tool on A1 synthesizes its own initial
SYN packet rather than going through A1's TCP stack, then A1's TCP SYN packet rather than going through A1's TCP stack, then A1's TCP
stack will automatically terminate the connection in a reliable stack will automatically terminate the connection in a reliable
fashion as A2 continues transmitting the SYN-ack in an attempt to fashion as A2 continues transmitting the SYN-ack in an attempt to
establish the connection. Finally, we note that using A1's TCP establish the connection. Finally, we note that using A1's TCP
stack to conduct the measurement complicates the methodology in stack to conduct the measurement complicates the methodology in
that the stack may retransmit the initial SYN packet, altering the that the stack may retransmit the initial SYN packet, altering the
number of probe packets sent.} number of probe packets sent.}
ID IPPM Metrics for Measuring Connectivity October 1998 ID IPPM Metrics for Measuring Connectivity November 1998
+ A RST packet from A2 to A1 with the proper ports indicates + A RST packet from A2 to A1 with the proper ports indicates
temporal connectivity between the addresses (and a *lack* of temporal connectivity between the addresses (and a *lack* of
service connectivity for TCP-port-N1-port-N2 - something that service connectivity for TCP-port-N1-port-N2 - something that
probably should be addressed with another metric). probably should be addressed with another metric).
+ An ICMP port-unreachable from A2 to A1 indicates temporal + An ICMP port-unreachable from A2 to A1 indicates temporal
connectivity between the addresses (and again a *lack* of service connectivity between the addresses (and again a *lack* of service
connectivity for TCP-port-N1-port-N2). {Comment: TCP connectivity for TCP-port-N1-port-N2). {Comment: TCP
implementations generally do not need to send ICMP port- implementations generally do not need to send ICMP port-
unreachable messages because a separate mechanism is available unreachable messages because a separate mechanism is available
skipping to change at page 9, line 43 skipping to change at page 9, line 43
9. Security Considerations 9. Security Considerations
As noted in RFC 2330, active measurement techniques, such as those As noted in RFC 2330, active measurement techniques, such as those
defined in this document, can be abused for denial-of-service attacks defined in this document, can be abused for denial-of-service attacks
disguised as legitimate measurement activity. Furthermore, testing disguised as legitimate measurement activity. Furthermore, testing
for connectivity can be used to probe firewalls and other security for connectivity can be used to probe firewalls and other security
mechnisms for weak spots. mechnisms for weak spots.
10. References 10. References
F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June [RFC1812]
1995. F. Baker, "Requirements for IP Version 4 Routers", June 1995.
R. Braden, "Requirements for Internet hosts - communication layers", [RFC1122]
RFC 1122, October 1989. R. Braden, Editor, "Requirements for Internet Hosts -- Communi-
cation Layers," Oct. 1989.
V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, Paxson, "Framework [RFC2330]
for IP Performance Metrics", RFC 2330, May 1998.
ID IPPM Metrics for Measuring Connectivity October 1998 ID IPPM Metrics for Measuring Connectivity November 1998
J. Postel, "Internet Protocol", RFC 791, September 1981. V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for
IP Performance Metrics", May 1998.
[RFC791]
J. Postel, "Internet Protocol", September 1981.
11. Authors' Addresses 11. Authors' Addresses
Jamshid Mahdavi <mahdavi@psc.edu> Jamshid Mahdavi <mahdavi@psc.edu>
Pittsburgh Supercomputing Center Pittsburgh Supercomputing Center
4400 5th Avenue 4400 5th Avenue
Pittsburgh, PA 15213 Pittsburgh, PA 15213
USA USA
Vern Paxson <vern@ee.lbl.gov> Vern Paxson <vern@ee.lbl.gov>
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/