[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group        J. Mahdavi, Pittsburgh Supercomputer Center
Internet Draft          V. Paxson, Lawrence Berkeley National Laboratory
Expiration Date: May 1997                                  November 1996


1. Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working doc-
   uments  of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing documents as Internet Drafts.

   Internet  Drafts  are  draft  documents  valid  for  a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as ``work in progress''.

   To learn the current status of any Internet Draft, please  check  the
   ``1id-abstracts.txt'' listing contained in the Internet Drafts shadow
   directories  on  ftp.is.co.za   (Africa),   nic.nordu.net   (Europe),
   munnari.oz.au  (Pacific  Rim),  ds.internic.net  (US  East Coast), or
   ftp.isi.edu (US West Coast).

   This memo provides information for the Internet community.  This memo
   does  not  specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

2. Introduction

   Connectivity is the basic stuff from  which  the  Internet  is  made.
   Therefore,  metrics determining whether pairs of hosts (IP addresses)
   can reach each other must form the base of a measurement  suite.   We
   define  several  such metrics, some of which serve mainly as building
   blocks for the others.

   This memo defines a series of metrics for connectivity between a pair
   of  Internet hosts.  It builds on notions introduced and discussed in
   the revised IPPM Framework document (currently <draft-ietf-bmwg-ippm-
   framework-00.txt>);  the  reader  is assumed to be familiar with that

   The structure of the memo is as follows:

Mahdavi and Paxson                                              [Page 1]

ID                            Connectivity                 November 1996

 +    An analytic  metric,  called  Type-P-Instantaneous-Unidirectional-
      Connectivity, will be introduced to define one-way connectivity at
      one moment in time.
 +    Using  this  metric,  another  analytic  metric,  called   Type-P-
      Instantaneous-Bidirectional-Connectivity,  will  be  introduced to
      define two-way connectivity at one moment in time.
 +    Using these metrics, corresponding one- and two-way analytic  met-
      rics are defined for connectivity over an interval of time.
 +    Using   these   metrics,   an   analytic   metric,   called  Type-
      P1-P2-Interval-Causal-Connectivity, will be 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-Causal-Connectivity  in a variety of settings.
   Careful definition of Type-P1-P2-Interval-Causal-Connectivity and the
   discussion  of the metric and the methodologies for estimating it are
   the two chief contributions of the memo.

3. Instantaneous One-way Connectivity

3.1. Metric Name:


3.2. Metric Parameters:
 +    Src, the IP address of a host
 +    Dst, the IP address of a host
 +    T, a time

3.3. Metric Units:


3.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.

Mahdavi and Paxson                                              [Page 2]

ID                            Connectivity                 November 1996

3.5. Discussion:

   This metric is probably not directly useful, because it is  instanta-
   neous  and unidirectional.  For most applications, bidirectional con-
   nectivity is considerably more germane (e.g.,  any  TCP  connection).
   Most   applications  also  require  connectivity  over  an  interval.
   Finally, one might not have instantaneous connectivity due to a tran-
   sient  event  such  as  a  full  queue at a router, even if at nearby
   instants in time  one  does  have  connectivity.   These  points  are
   addressed below, with this metric serving 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, however,  it  is
   also  possible  that  packets  might survive longer than 255 seconds.
   Consideration of packet lifetimes  must  be  taken  into  account  in
   attempts to measure the value of this metric.

   Finally,  one might assume that unidirectional connectivity is diffi-
   cult to measure in the absence of connectivity in the reverse  direc-
   tion.   Consider,  however,  the  possibility that a process on Dst's
   host notes when it receives packets from Src and  reports  this  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.

4. Instantaneous Two-way Connectivity

4.1. Metric Name:


4.2. Metric Parameters:
 +    A1, the IP address of a host
 +    A2, the IP address of a host
 +    T, a time

Mahdavi and Paxson                                              [Page 3]

ID                            Connectivity                 November 1996

4.3. Metric Units:


4.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.

4.5. Discussion:

   An alternative definition would be that at A1 and A2 are  fully  con-
   nected  if  at  time  T  address A1 has instantaneous connectivity to
   address A2, and at time T+dT address A2 has instantaneous  connectiv-
   ity  to A1, where T+dT is when the packet sent from A1 arrives at A2.
   This definition is more useful for measurement, because the  measure-
   ment can use a reply from A2 to A1 in order to assess full connectiv-
   ity.  It is a more complex definition, however, because it breaks the
   symmetry  between A1 and A2, and requires a notion of quantifying how
   long a particular packet from A1 takes to reach A2.  We postpone dis-
   cussion  of  this  distinction  until  the  development  of interval-
   connectivity metrics below.

5. One-way Connectivity

5.1. Metric Name:


5.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  inter-

Mahdavi and Paxson                                              [Page 4]

ID                            Connectivity                 November 1996

5.3. Metric Units:


5.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.

6. Two-way Connectivity

6.1. Metric Name:


6.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 inter-

6.3. Metric Units:


6.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  inter-
   val and address A2 has Type-P-Interval-Unidirectional-Connectivity to
   address A1 during the interval.

Mahdavi and Paxson                                              [Page 5]

ID                            Connectivity                 November 1996

6.5. Discussion:

   This metric is not quite what's needed for defining "useful"  connec-
   tivity  -  that  requires the notion that a packet sent from A1 to A2
   can elicit a response from A2 that will reach A1.  With this  defini-
   tion, it could be that A1 and A2 have full-connectivity but only, for
   example, at at time T1 early enough in the interval [T, T+dT] that A1
   and  A2  cannot  reply to packets sent by the other.  This deficiency
   motivates the next metric.

7. Two-way Causal Connectivity

7.1. Metric Name:


7.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  inter-

7.3. Metric Units:


7.4. Definition:

   Address  Src has *Type-P1-P2-Interval-Causal-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 packet sent by Src at time T1 to
      arrive at Dst.

Mahdavi and Paxson                                              [Page 6]

ID                            Connectivity                 November 1996

 +    dT2 is the time taken for a packet sent  by  Dst  at  time  T2  to
      arrive at Src.

7.5. Discussion:

   This metric defines "useful" connectivity -- Src can send a packet to
   Dst that elicits a response.  Because many applications utilize  dif-
   ferent types of packets for forward and reverse traffic, it is possi-
   ble (and likely) that the desired responses to a Type-P1 packet  will
   be  of  a different type Type-P2.  Therefore, in this metric we allow
   for different types of packets in the forward and reverse directions.

7.6. Methodologies:

   Here  we  sketch  a  class  of  methodologies  for  estimating  Type-
   P1-P2-Interval-Causal-Connectivity.  It is a class rather than a sin-
   gle  methodology  because the particulars will depend on the types P1
   and P2.

7.6.1. Inputs:
 +    Types P1 and P2, addresses A1 and A2, interval [T, T+dT], and
 +    N, the number of packets to send as probes for determining connec-
 +    W,  the  "waiting time", which bounds for how long it is useful to
      wait for a reply to a packet.
   Required: W <= 255, dT > W.

7.6.2. Recommended values:

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

7.6.3. Algorithm:

 +    Compute N *sending-times* that are randomly, uniformly distributed
      over [T, T+dT-W].
 +    At  each  sending  time,  transmit from A1 a well-formed packet of
      type P1 to A2.

Mahdavi and Paxson                                              [Page 7]

ID                            Connectivity                 November 1996

 +    Inspect incoming network traffic to A1 to determine if a  success-
      ful reply is received.   The particulars of doing so are dependent
      on types P1 & P2, discussed  below.   If  a  successful  reply  is
      received, the value of the measurement is "true".
 +    If  no  successful replies are received by time T+dT, the value of
      the measurement is "false".

7.6.4. Discussion:

   The algorithm is inexact because  it  does  not  (and  cannot)  probe
   causal  connectivity at every instant in time between [T, T+dT].  The
   value of N trades off measurement precision against network  measure-
   ment  load.   The  state-of-the-art in Internet research does not yet
   offer solid guidance for picking N.  The values given above are  just

7.6.5. Specific methodology for TCP:

   A  TCP-port-N1-port-N2  methodology sends TCP SYN packets with source
   port N1 and dest port N2 at address A2.  Incoming network traffic  is
   interpreted as follows:
 +    A  SYN-ack  packet  from  A2 to A1 with the proper acknowledgement
      fields and ports on A1 indicates causal  connectivity.   The  mea-
      surement terminates immediately with a value of "true".  {Comment:
      the connection now established between A1 and A2 should  be  prop-
      erly  torn  down using the usual FIN handshake (not by using a RST
      packet, as these are not transmitted reliably).}
 +    A RST packet from A2 to A1 with the proper ports on  A1  indicates
      causal connectivity between the addresses (and a *lack* of service
      connectivity for TCP-port-N1-port-N2  -  something  that  probably
      should be addressed with another metric).
 +    An ICMP port-unreachable from A2 to A1 indicates causal connectiv-
      ity between the addresses (and again a *lack* of  service  connec-
      tivity  for  TCP-port-N1-port-N2).  {Comment: Are there TCP imple-
      mentations that generate ICMP's instead of RST's?   Do  the  RFC's
      allow  this?   Certainly  they  do  for  UDP,  so the notion makes
 +    An ICMP host-unreachable or network-unreachable to A1 (not  neces-
      sarily from A2) with an enclosed IP header matching that sent from
      A1 to A2 *suggests* a lack of causal  connectivity.   If  by  time
      T+dT  no  evidence  of causal connectivity has been gathered, then
      the receipt of the ICMP can be used as additional  information  to
      the measurement value of "false".

   {Comment: Similar methodologies are needed for ICMP Echo, UDP, etc.}

Mahdavi and Paxson                                              [Page 8]

ID                            Connectivity                 November 1996

8. Security Considerations

   This memo raises no security issues.

9. References

   G.  Almes, W. Cerveny, P. Krishnaswamy, J. Mahdavi, M. Mathis, and V.
   Paxson, "Framework for IP Provider Metrics", Internet  Draft  <draft-
   ietf-bmwg-ippm-framework-00.txt>, November 1996.

   J. Postel, "Internet Protocol", RFC 791, September 1981.

   F.  Baker,  "Requirements  for  IP Version 4 Routers", RFC 1812, June

10. Authors' Addresses

   Jamshid Mahdavi <mahdavi@psc.edu>
   Pittsburgh Supercomputing Center
   4400 5th Avenue
   Pittsburgh, PA  15213

   Vern Paxson <vern@ee.lbl.gov>
   MS 50B/2239
   Lawrence Berkeley National Laboratory
   University of California
   Berkeley, CA  94720
   Phone: +1 510/486-7504

Mahdavi and Paxson                                              [Page 9]

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/