- The first section about stochastic metrics has been rewritten (thanks to Brian Carpenter & Jeff Sedayao).
- A section added on "Internet Addresses vs. Hosts", about the need to usually think in terms of IP addresses rather than hosts.
- "Packet of Type T" is now "Packet of Type P", because in working on the connectivity metric we immediately ran into the problem that using Type T clashes with wanting to use T to talk about a point in time.
- "Host A" and "Host B" are now "Src" and "Dst" (suggested by Matt Mathis), and are in terms of addresses instead of hosts, as mentioned above.
As before, comments welcomed.
Vern
Avoiding Stochastic Metrics ---------------------------
When defining metrics applying to a path, subpath, cloud, or other network element, we in general do not define them in stochastic terms (probabilities). We instead prefer a deterministic definition. So, for example, rather than defining a metric about a "packet loss probability between A and B", we would define a metric about a "packet loss rate between A and B". (A measurement given by the first definition might be "0.73", and by the second "73 packets out of 100".)
The reason for this distinction is as follows. When definitions are made in terms of probabilities, there are often hidden assumptions in the definition about a stochastic model of the behavior being measured. The fundamental goal with avoiding probabilities in our metric definitions is to avoid biasing our definitions by these hidden assumptions.
For example, an easy hidden assumption to make is that packet loss in a network component due to queueing overflows can be described as something that happens to any given packet with a particular probability. Usually, however, queueing drops are actually *deterministic*, and assuming that they should be described probabilistically can obscure crucial correlations between queueing drops among a set of packets. So it's better to explicitly note stochastic assumptions, rather than have them sneak into our definitions implicitly.
This does *not* mean that we abandon stochastic models for understanding network performance!, only that when defining IP metrics we avoid terms such as "probability" for terms like "proportion" or "rate". We will still use, for example, random sampling in order to estimate probabilities used by stochastic models related to the IP metrics. We also do not rule out the possibility of stochastic metrics when they are truly appropriate (for example, perhaps to model transmission errors caused by certain types of line noise).
Internet Addresses vs. Hosts ----------------------------
When considering a metric for some path through the Internet, it is often natural to think about it as being for the path from Internet host H1 to host H2. A definition in these terms, though, can be ambiguous, because Internet hosts can be attached to more than one network. In this case, the result of the metric will depend on which of these networks is actually used.
Because of this ambiguitiy, usually such definitions should instead be defined in terms of Internet IP addresses. For the common case of a unidirectional path through the Internet, we will use the term "Src" to denote the IP address of the beginning of the path, and "Dst" to denote the IP address of the end.
"Instantaneous" Measurement ---------------------------
Often we will find ourselves wishing to define a metric as some Internet property's value at time T. This may occasionally make sense; however, because of the finite speed at which packets propagate through the network, much more often we must instead define the metric as the property's value over an *interval* [T, T+dT] for dT > 0.
This switch in thinking is invaluable because it highlights a very important point: over a non-zero interval of time, there is not necessarily a single route between Internet addresses Src and Dst. Since many IP metrics will reflect properties of the particular routers and links traversed, defining metrics in terms of intervals stresses that the metric may have a fundamental elusiveness to it that we should not ignore.
We will use the term "virtual path from Src to Dst" to denote the abstraction of a single network-layer forwarding path from address Src to address Dst. This term is preferable to "path" or "route" because the latter often imply a single series of routers and links, whereas "virtual path", usually used in the context of an interval of time, allows for multiple routes during the interval. Thus, rather than defining "loss rate along the route from Src to Dst over [T, T+dT]", we would define "loss rate along the virtual path from Src to Dst over [T, T+dT]", since the latter is well-defined and the former is not.
A further issue concerning measurements over an interval is combining or summarizing multiple measurements made over a (possibly large) interval in a meaningful way. We do not yet attempt to address this issue, as we expect that it is best to wait on doing so until we have acquired experience with informal summaries of sets of well-defined single measurements.
Packets of Type P -----------------
A fundamental property of many Internet metrics is that the value of the metric depends on the type of IP packet(s) used to make the measurement. Consider an IP-connectivity metric: one obtains different results depending on whether one is interested in connectivity for packets destined for well-known TCP ports or unreserved UDP ports, or those with invalid IP checksums, or those with TTL's of 16, for example. In some circumstances these distinctions will be highly interesting (for example, in the presence of firewalls, or RSVP reservations).
Because of this distinction, we introduce the generic notion of a "packet of type P", where in some contexts P will be explicitly defined (i.e., exactly what type of packet we mean), partially defined (e.g., "with a payload of B bits"), or left generic. Thus we may talk about generic IP-type-P-connectivity or more specific IP-port-HTTP-connectivity. Some metrics and methodologies may be fruitfully defined using generic type P definitions which are then made specific when performing actual measurements.
Whenever a metric's value depends on the type of the packets involved in the metric, the metric's name will include either a specific type or a phrase such as "type-P". Thus we will not define an "IP-connectivity" metric but instead an "IP-type-P-connectivity" metric and/or perhaps an "IP-port-HTTP-connectivity" metric. This serves as an important reminder that one must be conscious of the exact type of traffic being measured.
A final note: it would be very useful to know if a given Internet component treats equally a class C of different types of packets. If so, then any one of those types of packets can be used for subsequent measurement of the component. This suggests we devise a metric or suite of metrics that attempt to determine C.
Well-Formed Packets -------------------
Unless otherwise stated, all metric definitions that concern IP packets include an implicit assumption that the packet is *well formed*. A packet is well formed if it meets all of the following criteria:
- Its length as given in the IP header corresponds to the size of the IP header plus the size of the payload.
- It includes a valid IP header: the version field is 4 (later, we will expand this to include 6); the header length is >= 5; the checksum is correct.
- It is not an IP fragment.
- The source and destination addresses correspond to the addresses in question.
- The packet possesses sufficient TTL to travel from the source to the destination if the TTL is decremented by one at each hop. (Or: it possesses the maximum TTL of 255.)
- It does not contain IP options unless explicitly noted.
- If a transport header is present, it too contains a valid checksum and other valid fields.
We further require that if a packet is described as having a "length of B bits", then B is >= 0, <= 65535*8, and a multiple of 8; and if B is the payload length in bits, then B <= (65535-IP header size in octets) * 8.
So, for example, one might imagine defining an IP connectivity metric as "IP-type-P-connectivity for well-formed packets with the IP TOS field set to 0", or, more succinctly, "IP-type-P-connectivity with the IP TOS field set to 0", since well-formed is already implied.
A particular type of well-formed packet often useful to consider is the "minimal IP packet from Src to Dst" - this is an IP packet with the following properties:
- It is well-formed. - Its data payload is 0 octets. - It contains no options. - Its protocol field is 4 (IP) ??? 0 (reserved) ???
When defining IP metrics we keep in mind that no packet smaller or simpler than this can be transmitted over a correctly operating IP network.