From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5166.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc5166.txt (limited to 'doc/rfc/rfc5166.txt') diff --git a/doc/rfc/rfc5166.txt b/doc/rfc/rfc5166.txt new file mode 100644 index 0000000..0126f4f --- /dev/null +++ b/doc/rfc/rfc5166.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group S. Floyd, Ed. +Request for Comments: 5166 March 2008 +Category: Informational + + + Metrics for the Evaluation of Congestion Control Mechanisms + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +IESG Note + + This document is not an IETF Internet Standard. It represents the + individual opinion(s) of one or more members of the TMRG Research + Group of the Internet Research Task Force. It may be considered for + standardization by the IETF or adoption as an IRTF Research Group + consensus document in the future. + +Abstract + + This document discusses the metrics to be considered in an evaluation + of new or modified congestion control mechanisms for the Internet. + These include metrics for the evaluation of new transport protocols, + of proposed modifications to TCP, of application-level congestion + control, and of Active Queue Management (AQM) mechanisms in the + router. This document is the first in a series of documents aimed at + improving the models that we use in the evaluation of transport + protocols. + + This document is a product of the Transport Modeling Research Group + (TMRG), and has received detailed feedback from many members of the + Research Group (RG). As the document tries to make clear, there is + not necessarily a consensus within the research community (or the + IETF community, the vendor community, the operations community, or + any other community) about the metrics that congestion control + mechanisms should be designed to optimize, in terms of trade-offs + between throughput and delay, fairness between competing flows, and + the like. However, we believe that there is a clear consensus that + congestion control mechanisms should be evaluated in terms of trade- + offs between a range of metrics, rather than in terms of optimizing + for a single metric. + + + + + + + +Floyd Informational [Page 1] + +RFC 5166 TMRG, METRICS March 2008 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Metrics .........................................................3 + 2.1. Throughput, Delay, and Loss Rates ..........................4 + 2.1.1. Throughput ..........................................5 + 2.1.2. Delay ...............................................6 + 2.1.3. Packet Loss Rates ...................................6 + 2.2. Response Times and Minimizing Oscillations .................7 + 2.2.1. Response to Changes .................................7 + 2.2.2. Minimizing Oscillations .............................8 + 2.3. Fairness and Convergence ...................................9 + 2.3.1. Metrics for Fairness between Flows .................10 + 2.3.2. Metrics for Fairness between Flows with + Different Resource Requirements ....................10 + 2.3.3. Comments on Fairness ...............................12 + 2.4. Robustness for Challenging Environments ...................13 + 2.5. Robustness to Failures and to Misbehaving Users ...........14 + 2.6. Deployability .............................................14 + 2.7. Metrics for Specific Types of Transport ...................15 + 2.8. User-Based Metrics ........................................15 + 3. Metrics in the IP Performance Metrics (IPPM) Working Group .....15 + 4. Comments on Methodology ........................................16 + 5. Security Considerations ........................................16 + 6. Acknowledgements ...............................................16 + 7. Informative References .........................................17 + +1. Introduction + + As a step towards improving our methodologies for evaluating + congestion control mechanisms, in this document we discuss some of + the metrics to be considered. We also consider the relationship + between metrics, e.g., the well-known trade-off between throughput + and delay. This document doesn't attempt to specify every metric + that a study might consider; for example, there are domain-specific + metrics that researchers might consider that are over and above the + metrics laid out here. + + We consider metrics for aggregate traffic (taking into account the + effect of flows on competing traffic in the network) as well as the + heterogeneous goals of different applications or transport protocols + (e.g., of high throughput for bulk data transfer, and of low delay + for interactive voice or video). Different transport protocols or + AQM mechanisms might have goals of optimizing different sets of + metrics, with one transport protocol optimized for per-flow + throughput and another optimized for robustness over wireless links, + and with different degrees of attention to fairness with competing + traffic. We hope this document will be used as a step in evaluating + + + +Floyd Informational [Page 2] + +RFC 5166 TMRG, METRICS March 2008 + + + proposed congestion control mechanisms for a wide range of metrics, + for example, noting that Mechanism X is good at optimizing Metric A, + but pays the price with poor performance for Metric B. The goal + would be to have a broad view of both the strengths and weaknesses of + newly proposed congestion control mechanisms. + + Subsequent documents are planned to present sets of simulation and + testbed scenarios for the evaluation of transport protocols and of + congestion control mechanisms, based on the best current practice of + the research community. These are not intended to be complete or + final benchmark test suites, but simply to be one step of many to be + used by researchers in evaluating congestion control mechanisms. + Subsequent documents are also planned on the methodologies in using + these sets of scenarios. + + This document is a product of the Transport Modeling Research Group + (TMRG), and has received detailed feedback from many members of the + Research Group (RG). As the document tries to make clear, there is + not necessarily a consensus within the research community (or the + IETF community, the vendor community, the operations community, or + any other community) about the metrics that congestion control + mechanisms should be designed to optimize, in terms of trade-offs + between throughput and delay, fairness between competing flows, and + the like. However, we believe that there is a clear consensus that + congestion control mechanisms should be evaluated in terms of + trade-offs between a range of metrics, rather than in terms of + optimizing for a single metric. + +2. Metrics + + The metrics that we discuss are the following: + + o Throughput; + + o Delay; + + o Packet loss rates; + + o Response to sudden changes or to transient events; + + o Minimizing oscillations in throughput or in delay; + + o Fairness and convergence times; + + o Robustness for challenging environments; + + o Robustness to failures and to misbehaving users; + + + + +Floyd Informational [Page 3] + +RFC 5166 TMRG, METRICS March 2008 + + + o Deployability; + + o Metrics for specific types of transport; + + o User-based metrics. + + We consider each of these below. Many of the metrics have + network-based, flow-based, and user-based interpretations. For + example, network-based metrics can consider aggregate bandwidth and + aggregate drop rates, flow-based metrics can consider end-to-end + transfer times for file transfers or end-to-end delay and packet drop + rates for interactive traffic, and user-based metrics can consider + user wait time or user satisfaction with the multimedia experience. + Our main goal in this document is to explain the set of metrics that + can be relevant, and not to legislate on the most appropriate + methodology for using each general metric. + + For some of the metrics, such as fairness, there is not a clear + agreement in the network community about the desired goals. In these + cases, the document attempts to present the range of approaches. + +2.1. Throughput, Delay, and Loss Rates + + Because of the clear trade-offs between throughput, delay, and loss + rates, it can be useful to consider these three metrics together. + The trade-offs are most clear in terms of queue management at the + router; is the queue configured to maximize aggregate throughput, to + minimize delay and loss rates, or some compromise between the two? + An alternative would be to consider a separate metric such as power, + defined in this context as throughput over delay, that combines + throughput and delay. However, we do not propose in this document a + clear target in terms of the trade-offs between throughput and delay; + we are simply proposing that the evaluation of transport protocols + include an exploration of the competing metrics. + + Using flow-based metrics instead of router-based metrics, the + relationship between per-flow throughput, delay, and loss rates can + often be given by the transport protocol itself. For example, in + TCP, the sending rate s in packets per second is given as: + + s = 1.2/(RTT*sqrt(p)), + + for the round-trip time RTT and loss rate p [FF99]. + + + + + + + + +Floyd Informational [Page 4] + +RFC 5166 TMRG, METRICS March 2008 + + +2.1.1. Throughput + + Throughput can be measured as a router-based metric of aggregate link + utilization, as a flow-based metric of per-connection transfer times, + and as user-based metrics of utility functions or user wait times. + It is a clear goal of most congestion control mechanisms to maximize + throughput, subject to application demand and to the constraints of + the other metrics. + + Throughput is sometimes distinguished from goodput, where throughput + is the link utilization or flow rate in bytes per second; goodput, + also measured in bytes per second, is the subset of throughput + consisting of useful traffic. That is, 'goodput' excludes duplicate + packets, packets that will be dropped downstream, packet fragments or + ATM cells that are dropped at the receiver because they can't be + re-assembled into complete packets, and the like. In general, this + document doesn't distinguish between throughput and goodput, and uses + the general term "throughput". + + We note that maximizing throughput is of concern in a wide range of + environments, from highly-congested networks to under-utilized ones, + and from long-lived flows to very short ones. As an example, + throughput has been used as one of the metrics for evaluating + Quick-Start, a proposal to allow flows to start up faster than + slow-start, where throughput has been evaluated in terms of the + transfer times for connections with a range of transfer sizes + [RFC4782] [SAF06]. + + In some contexts, it might be sufficient to consider the aggregate + throughput or the mean per-flow throughput [DM06], while in other + contexts it might be necessary to consider the distribution of + per-flow throughput. Some researchers evaluate transport protocols + in terms of maximizing the aggregate user utility, where a user's + utility is generally defined as a function of the user's throughput + [KMT98]. + + Individual applications can have application-specific needs in terms + of throughput. For example, real-time video traffic can have highly + variable bandwidth demands; Voice over IP (VoIP) traffic is sensitive + to the amount of bandwidth received immediately after idle periods. + Thus, user metrics for throughput can be more complex than simply the + per-connection transfer time. + + + + + + + + + +Floyd Informational [Page 5] + +RFC 5166 TMRG, METRICS March 2008 + + +2.1.2. Delay + + Like throughput, delay can be measured as a router-based metric of + queueing delay over time, or as a flow-based metric in terms of + per-packet transfer times. Per-packet delay can also include delay + at the sender waiting for the transport protocol to send the packet. + For reliable transfer, the per-packet transfer time seen by the + application includes the possible delay of retransmitting a lost + packet. + + Users of bulk data transfer applications might care about per-packet + transfer times only in so far as they affect the per-connection + transfer time. On the other end of the spectrum, for users of + streaming media, per-packet delay can be a significant concern. Note + that in some cases the average delay might not capture the metric of + interest to the users; for example, some users might care about the + worst-case delay, or about the tail of the delay distribution. + + Note that queueing delay at a router is shared by all flows at a FIFO + (First-In First-Out) queue. Thus, the router-based queueing delay + induced by bulk data transfers can be important even if the bulk data + transfers themselves are not concerned with per-packet transfer + times. + +2.1.3. Packet Loss Rates + + Packet loss rates can be measured as a network-based or as a + flow-based metric. + + When evaluating the effect of packet losses or ECN marks (Explicit + Congestion Notification) [RFC3168] on the performance of a congestion + control mechanism for an individual flow, researchers often use both + the packet loss/mark rate for that connection and the congestion + event rate (also called the loss event rate), where a congestion + event or loss event consists of one or more lost or marked packets in + one round-trip time [RFC3448]. + + Some users might care about the packet loss rate only in so far as it + affects per-connection transfer times, while other users might care + about packet loss rates directly. RFC 3611, RTP Control Protocol + Extended Reports, describes a VoIP performance-reporting standard + called RTP Control Protocol Extended Reports (RTCP XR), which + includes a set of burst metrics. In RFC 3611, a burst is defined as + the maximal sequence starting and ending with a lost packet, and not + including a sequence of Gmin or more packets that are not lost + [RFC3611]. The burst metrics in RFC 3611 consist of the burst + density (the fraction of packets in bursts), gap density (the + fraction of packets in the gaps between bursts), burst duration (the + + + +Floyd Informational [Page 6] + +RFC 5166 TMRG, METRICS March 2008 + + + mean duration of bursts in seconds), and gap duration (the mean + duration of gaps in seconds). RFC 3357 derives metrics for "loss + distance" and "loss period", along with statistics that capture loss + patterns experienced by packet streams on the Internet [RFC3357]. + + In some cases, it is useful to distinguish between packets dropped at + routers due to congestion and packets lost in the network due to + corruption. + + One network-related reason to avoid high steady-state packet loss + rates is to avoid congestion collapse in environments containing + paths with multiple congested links. In such environments, high + packet loss rates could result in congested links wasting scarce + bandwidth by carrying packets that will only be dropped downstream + before being delivered to the receiver [RFC2914]. We also note that + in some cases, the retransmit rate can be high, and the goodput + correspondingly low, even with a low packet drop rate [AEO03]. + +2.2. Response Times and Minimizing Oscillations + + In this section, we consider response times and oscillations + together, as there are well-known trade-offs between improving + response times and minimizing oscillations. In addition, the + scenarios that illustrate the dangers of poor response times are + often quite different from the scenarios that illustrate the dangers + of unnecessary oscillations. + +2.2.1. Response to Changes + + One of the key concerns in the design of congestion control + mechanisms has been the response times to sudden congestion in the + network. On the one hand, congestion control mechanisms should + respond reasonably promptly to sudden congestion from routing or + bandwidth changes or from a burst of competing traffic. At the same + time, congestion control mechanisms should not respond too severely + to transient changes, e.g., to a sudden increase in delay that will + dissipate in less than the connection's round-trip time. + + Congestion control mechanisms also have to contend with sudden + changes in the bandwidth-delay product due to mobility. Such + bandwidth-delay product changes are expected to become more frequent + and to have greater impact than path changes today. As a result of + both mobility and of the heterogeneity of wireless access types + (802.11b,a,g, WIMAX, WCDMA, HS-WCDMA, E-GPRS, Bluetooth, etc.), both + the bandwidth and the round-trip delay can change suddenly, sometimes + by several orders of magnitude. + + + + + +Floyd Informational [Page 7] + +RFC 5166 TMRG, METRICS March 2008 + + + Evaluating the response to sudden or transient changes can be of + particular concern for slowly responding congestion control + mechanisms such as equation-based congestion control [RFC3448] and + AIMD (Additive Increase Multiplicative Decrease) or for related + mechanisms using parameters that make them more slowly-responding + than TCP [BB01] [BBFS01]. + + In addition to the responsiveness and smoothness of aggregate + traffic, one can consider the trade-offs between responsiveness, + smoothness, and aggressiveness for an individual connection [FHP00] + [YKL01]. In this case, smoothness can be defined by the largest + reduction in the sending rate in one round-trip time, in a + deterministic environment with a packet drop exactly every 1/p + packets. The responsiveness is defined as the number of round-trip + times of sustained congestion required for the sender to halve the + sending rate; aggressiveness is defined as the maximum increase in + the sending rate in one round-trip time, in packets per second, in + the absence of congestion. This aggressiveness can be a function of + the mode of the transport protocol; for TCP, the aggressiveness of + slow-start is quite different from the aggressiveness of congestion + avoidance mode. + +2.2.2. Minimizing Oscillations + + One goal is that of stability, in terms of minimizing oscillations of + queueing delay or of throughput. In practice, stability is + frequently associated with rate fluctuations or variance. Rate + variations can result in fluctuations in router queue size and + therefore of queue overflows. These queue overflows can cause loss + synchronizations across coexisting flows and periodic + under-utilization of link capacity, both of which are considered to + be general signs of network instability. Thus, measuring the rate + variations of flows is often used to measure the stability of + transport protocols. To measure rate variations, [JWL04], [RX05], + and [FHPW00] use the coefficient of variation (CoV) of per-flow + transmission rates, and [WCL05] suggests the use of standard + deviations of per-flow rates. Since rate variations are a function + of time scales, it makes sense to measure these rate variations over + various time scales. + + Measuring per-flow rate variations, however, is only one aspect of + transport protocol stability. A realistic experimental setting + always involves multiple flows of the transport protocol being + observed, along with a significant amount of cross traffic, with + rates varying over time on both the forward and reverse paths. As a + congestion control protocol must adapt its rate to the varying rates + of competing traffic, just measuring the per-flow statistics of a + subset of the traffic could be misleading because it measures the + + + +Floyd Informational [Page 8] + +RFC 5166 TMRG, METRICS March 2008 + + + rate fluctuations due in part to the adaptation to competing traffic + on the path. Thus, per-flow statistics are most meaningful if they + are accompanied by the statistics measured at the network level. As + a complementary metric to the per-flow statistics, [HKLRX06] uses + measurements of the rate variations of the aggregate flows observed + in bottleneck routers over various time scales. + + Minimizing oscillations in queueing delay or throughput has related + per-flow metrics of minimizing jitter in round-trip times and loss + rates. + + An orthogonal goal for some congestion control mechanisms, e.g., for + equation-based congestion control, is to minimize the oscillations in + the sending rate for an individual connection, given an environment + with a fixed, steady-state packet drop rate. (As is well known, TCP + congestion control is characterized by a pronounced oscillation in + the sending rate, with the sender halving the sending rate in + response to congestion.) One metric for the level of oscillations is + the smoothness metric given in Section 2.2.1 above. + + As discussed in [FK07], the synchronization of loss events can also + affect convergence times, throughput, and delay. + +2.3. Fairness and Convergence + + Another set of metrics is that of fairness and convergence times. + Fairness can be considered between flows of the same protocol and + between flows using different protocols (e.g., TCP-friendliness, + referring to fairness between TCP and a new transport protocol). + Fairness can also be considered between sessions, between users, or + between other entities. + + There are a number of different fairness measures. These include + max-min fairness [HG86], proportional fairness [KMT98] [K01], the + fairness index proposed in [JCH84], and the product measure, a + variant of network power [BJ81]. + + + + + + + + + + + + + + + +Floyd Informational [Page 9] + +RFC 5166 TMRG, METRICS March 2008 + + +2.3.1. Metrics for Fairness between Flows + + This section discusses fairness metrics that consider the fairness + between flows, but that don't take into account different + characteristics of flows (e.g., the number of links in the path or + the round-trip time). For the discussion of fairness metrics, let + x_i be the throughput for the i-th connection. + + Jain's fairness index: The fairness index in [JCH84] is: + + (( sum_i x_i )^2) / (n * sum_i ( (x_i)^2 )), + + where there are n users. This fairness index ranges from 0 to 1, and + it is maximum when all users receive the same allocation. This index + is k/n when k users equally share the resource, and the other n-k + users receive zero allocation. + + The product measure: The product measure: + + product_i x_i , + + the product of the throughput of the individual connections, is also + used as a measure of fairness. (In some contexts x_i is taken as the + power of the i-th connection, and the product measure is referred to + as network power.) The product measure is particularly sensitive to + segregation; the product measure is zero if any connection receives + zero throughput. In [MS91], it is shown that for a network with many + connections and one shared gateway, the product measure is maximized + when all connections receive the same throughput. + + Epsilon-fairness: A rate allocation is defined as epsilon-fair if + + (min_i x_i) / (max_i x_i) >= 1 - epsilon. + + Epsilon-fairness measures the worst-case ratio between any two + throughput rates [ZKL04]. Epsilon-fairness is related to max-min + fairness, defined later in this document. + +2.3.2. Metrics for Fairness between Flows with Different Resource + Requirements + + This section discusses metrics for fairness between flows with + different resource requirements, that is, with different utility + functions, round-trip times, or number of links on the path. Many of + these metrics can be described as solutions to utility maximization + problems [K01]; the total utility quantifies both the fairness and + the throughput. + + + + +Floyd Informational [Page 10] + +RFC 5166 TMRG, METRICS March 2008 + + + Max-min fairness: In order to satisfy the max-min fairness criteria, + the smallest throughput rate must be as large as possible. Given + this condition, the next-smallest throughput rate must be as large as + possible, and so on. Thus, the max-min fairness gives absolute + priority to the smallest flows. (Max-min fairness can be explained + by the progressive filling algorithm, where all flow rates start at + zero, and the rates all grow at the same pace. Each flow rate stops + growing only when one or more links on the path reach link capacity.) + + Proportional fairness: In contrast, a feasible allocation, x, is + defined as proportionally fair if, for any other feasible allocation + x*, the aggregate of proportional changes is zero or negative: + + sum_i ( (x*_i - x_i)/x_i ) <= 0. + + "This criterion favours smaller flows, but less emphatically than + max-min fairness" [K01]. (Using the language of utility functions, + proportional fairness can be achieved by using logarithmic utility + functions, and maximizing the sum of the per-flow utility functions; + see [KMT98] for a fuller explanation.) + + Minimum potential delay fairness: Minimum potential delay fairness + has been shown to model TCP [KS03], and is a compromise between + max-min fairness and proportional fairness. An allocation, x, is + defined as having minimum potential delay fairness if: + + sum_i (1/x_i) + + is smaller than for any other feasible allocation. That is, it would + minimize the average download time if each flow was an equal-sized + file. + + In [CRM05], Colussi, et al. propose a new definition of TCP fairness, + that "a set of TCP fair flows do not cause more congestion than a set + of TCP flows would cause", where congestion is defined in terms of + queueing delay, queueing delay variation, the congestion event rate + [e.g., loss event rate], and the packet loss rate. + + Chiu and Tan in [CT06] argue for redefining the notion of fairness + when studying traffic controls for inelastic traffic, proposing that + inelastic flows adopt other traffic controls such as admission + control. + + The usefulness of flow-rate fairness has been challenged in [B07] by + Briscoe, and defended in [FA08] by Floyd and Allman. In [B07], + Briscoe argues that flow-rate fairness should not be a desired goal, + and that instead "we should judge fairness mechanisms on how they + share out the 'cost' of each user's actions on others". Floyd and + + + +Floyd Informational [Page 11] + +RFC 5166 TMRG, METRICS March 2008 + + + Allman in [FA08] argue that the current system based on TCP + congestion control and flow-rate fairness has been useful in the real + world, posing minimal demands on network and economic infrastructure + and enabling users to get a share of the network resources. + +2.3.3. Comments on Fairness + + Trade-offs between fairness and throughput: The fairness measures in + the section above generally measure both fairness and throughput, + giving different weights to each. Potential trade-offs between + fairness and throughput are also discussed by Tang, et al. in + [TWL06], for a framework where max-min fairness is defined as the + most fair. In particular, [TWL06] shows that in some topologies, + throughput is proportional to fairness, while in other topologies, + throughput is inversely proportional to fairness. + + Fairness and the number of congested links: Some of these fairness + metrics are discussed in more detail in [F91]. We note that there is + not a clear consensus for the fairness goals, in particular for + fairness between flows that traverse different numbers of congested + links [F91]. Utility maximization provides one framework for + describing this trade-off in fairness. + + Fairness and round-trip times: One goal cited in a number of new + transport protocols has been that of fairness between flows with + different round-trip times [KHR02] [XHR04]. We note that there is + not a consensus in the networking community about the desirability of + this goal, or about the implications and interactions between this + goal and other metrics [FJ92] (Section 3.3). One common argument + against the goal of fairness between flows with different round-trip + times has been that flows with long round-trip times consume more + resources; this aspect is covered by the previous paragraph. + Researchers have also noted the difference between the RTT-unfairness + of standard TCP, and the greater RTT-unfairness of some proposed + modifications to TCP [LLS05]. + + Fairness and packet size: One fairness issue is that of the relative + fairness for flows with different packet sizes. Many file transfer + applications will use the maximum packet size possible; in contrast, + low-bandwidth VoIP flows are likely to send small packets, sending a + new packet every 10 to 40 ms., to limit delay. Should a small-packet + VoIP connection receive the same sending rate in *bytes* per second + as a large-packet TCP connection in the same environment, or should + it receive the same sending rate in *packets* per second? This + fairness issue has been discussed in more detail in [RFC3714], with + [RFC4828] also describing the ways that packet size can affect the + packet drop rate experienced by a flow. + + + + +Floyd Informational [Page 12] + +RFC 5166 TMRG, METRICS March 2008 + + + Convergence times: Convergence times concern the time for convergence + to fairness between an existing flow and a newly starting one, and + are a special concern for environments with high-bandwidth long-delay + flows. Convergence times also concern the time for convergence to + fairness after a sudden change such as a change in the network path, + the competing cross-traffic, or the characteristics of a wireless + link. As with fairness, convergence times can matter both between + flows of the same protocol, and between flows using different + protocols [SLFK03]. One metric used for convergence times is the + delta-fair convergence time, defined as the time taken for two flows + with the same round-trip time to go from shares of 100/101-th and + 1/101-th of the link bandwidth, to having close to fair sharing with + shares of (1+delta)/2 and (1-delta)/2 of the link bandwidth [BBFS01]. + A similar metric for convergence times measures the convergence time + as the number of round-trip times for two flows to reach epsilon- + fairness, when starting from a maximally-unfair state [ZKL04]. + +2.4. Robustness for Challenging Environments + + While congestion control mechanisms are generally evaluated first + over environments with static routing in a network of two-way + point-to-point links, some environments bring up more challenging + problems (e.g., corrupted packets, reordering, variable bandwidth, + and mobility) as well as new metrics to be considered (e.g., energy + consumption). + + Robustness for challenging environments: Robustness needs to be + explored for paths with reordering, corruption, variable bandwidth, + asymmetric routing, router configuration changes, mobility, and the + like [GF04]. In general, the Internet architecture has valued + robustness over efficiency, e.g., when there are trade-offs between + robustness and the throughput, delay, and fairness metrics described + above. + + Energy consumption: In mobile environments, the energy consumption + for the mobile end-node can be a key metric that is affected by the + transport protocol [TM02]. + + The goodput ratio: For wireless networks, the goodput ratio can be a + useful metric, where the goodput ratio can be defined as the useful + data delivered to users as a fraction of the total amount of data + transmitted on the network. A high goodput ratio indicates an + efficient use of the radio spectrum and lower interference with other + users. + + + + + + + +Floyd Informational [Page 13] + +RFC 5166 TMRG, METRICS March 2008 + + +2.5. Robustness to Failures and to Misbehaving Users + + One goal is for congestion control mechanisms to be robust to + misbehaving users, such as receivers that 'lie' to data senders about + the congestion experienced along the path or otherwise attempt to + bypass the congestion control mechanisms of the sender [SCWA99]. + Another goal is for congestion control mechanisms to be as robust as + possible to failures, such as failures of routers in using explicit + feedback to end-nodes or failures of end-nodes to follow the + prescribed protocols. + +2.6. Deployability + + One metric for congestion control mechanisms is their deployability + in the current Internet. Metrics related to deployability include + the ease of failure diagnosis and the overhead in terms of packet + header size or added complexity at end-nodes or routers. + + One key aspect of deployability concerns the range of deployment + needed for a new congestion control mechanism. Consider the + following possible deployment requirements: + + * Only at the sender (e.g., NewReno in TCP [RFC3782]); + + * Only at the receiver (e.g., delayed acknowledgements in TCP); + + * Both the sender and receiver (e.g., Selective Acknowledgment + (SACK) TCP [RFC2018]); + + * At a single router (e.g., Random Early Detection (RED) [FJ93]); + + * All of the routers along the end-to-end path; + + * Both end-nodes and all routers along the path (e.g., Explicit + Control Protocol (XCP) [KHR02]). + + Some congestion control mechanisms (e.g., XCP [KHR02], Quick-Start + [RFC4782]) may also have deployment issues with IPsec, IP in IP, + MPLS, other tunnels, or with non-router queues such as those in + Ethernet switches. + + + + + + + + + + + +Floyd Informational [Page 14] + +RFC 5166 TMRG, METRICS March 2008 + + + Another deployability issue concerns the complexity of the code. How + complex is the code required to implement the mechanism in software? + Is floating point math required? How much new state must be kept to + implement the new mechanism, and who holds that state, the routers or + the end-nodes? We note that we don't suggest these questions as ways + to reduce the deployability metric to a single number; we suggest + them as issues that could be considered in evaluating the + deployability of a proposed congestion control mechanism. + +2.7. Metrics for Specific Types of Transport + + In some cases, modified metrics are needed for evaluating transport + protocols intended for quality-of-service (QoS)-enabled environments + or for below-best-effort traffic [VKD02] [KK03]. + +2.8. User-Based Metrics + + An alternate approach that has been proposed for the evaluation of + congestion control mechanisms would be to evaluate in terms of user + metrics, such as user satisfaction or in terms of + application-specific utility functions. Such an approach would + require the definition of a range of user metrics or of + application-specific utility functions for the range of applications + under consideration (e.g., FTP, HTTP, VoIP). + +3. Metrics in the IP Performance Metrics (IPPM) Working Group + + The IPPM Working Group [IPPM] was established to define performance + metrics to be used by network operators, end users, or independent + testing groups. The metrics include metrics for connectivity + [RFC2678], delay and loss [RFC2679], [RFC2680], and [RFC2681], delay + variation [RFC3393], loss patterns [RFC3357], packet reordering + [RFC4737], bulk transfer capacity [RFC3148], and link capacity + [RFC5136]. The IPPM documents give concrete, well-defined metrics, + along with a methodology for measuring the metric. The metrics + discussed in this document have a different purpose from the IPPM + metrics; in this document, we are discussing metrics as used in + analysis, simulations, and experiments for the evaluation of + congestion control mechanisms. Further, we are discussing these + metrics in a general sense, rather than looking for specific concrete + definitions for each metric. However, there are many cases where the + metric definitions from IPPM could be useful, for specific issues of + how to measure these metrics in simulations, or in testbeds, and for + providing common definitions for talking about these metrics. + + + + + + + +Floyd Informational [Page 15] + +RFC 5166 TMRG, METRICS March 2008 + + +4. Comments on Methodology + + The types of scenarios that are used to test specific metrics, and + the range of parameters that it is useful to consider, will be + discussed in separate documents, e.g., along with specific scenarios + for use in evaluating congestion control mechanisms. + + We note that it can be important to evaluate metrics over a wide + range of environments, with a range of link bandwidths, congestion + levels, and levels of statistical multiplexing. It is also important + to evaluate congestion control mechanisms in a range of scenarios, + including typical ranges of connection sizes and round-trip times + [FK02]. It is also useful to compare metrics for new or modified + transport protocols with those of the current standards for TCP. + + As an example from the literature on evaluating transport protocols, + Li, et al. in "Experimental Evaluation of TCP Protocols for High- + Speed Networks" [LLS05] focus on the performance of TCP in high- + speed networks, and consider metrics for aggregate throughput, loss + rates, fairness (including fairness between flows with different + round-trip times), response times (including convergence times), and + incremental deployment. More general references on methodology + include [J91]. Papers that discuss the range of metrics for + evaluating congestion control include [MTZ04]. + +5. Security Considerations + + Section 2.5 discusses the robustness of congestion control mechanisms + to failures and to misbehaving users. Transport protocols also have + other security concerns that are unrelated to congestion control + mechanisms; these are not discussed in this document. + +6. Acknowledgements + + Thanks to Lachlan Andrew, Mark Allman, Armando Caro, Dah Ming Chiu, + Eric Coe, Dado Colussi, Wesley Eddy, Aaron Falk, Nelson Fonseca, + Janardhan Iyengar, Doug Leith, Sara Landstrom, Tony Li, Saverio + Mascolo, Sean Moore, Injong Rhee, David Ros, Juergen Schoenwaelder, + Andras Veres, Michael Welzl, and Damon Wischik, and members of the + Transport Modeling Research Group for feedback and contributions. + + + + + + + + + + + +Floyd Informational [Page 16] + +RFC 5166 TMRG, METRICS March 2008 + + +7. Informative References + + [AEO03] M. Allman, W. Eddy, and S. Ostermann, Estimating Loss Rates + With TCP, ACM Performance Evaluation Review, 31(3), + December 2003. + + [BB01] D. Bansal and H. Balakrishnan, Binomial Congestion Control + Algorithms, IEEE Infocom, April 2001. + + [BBFS01] D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker, + Dynamic Behavior of Slowly-Responsive Congestion Control + Algorithms, SIGCOMM 2001. + + [BJ81] K. Bharath-Kumar and J. Jeffrey, A New Approach to + Performance-Oriented Flow Control, IEEE Transactions on + Communications, Vol.29 N.4, April 1981. + + [B07] B. Briscoe, "Flow Rate Fairness: Dismantling a Religion", + Computer Communications Review, V.37 N.2, April 2007. + + [CRM05] D. Colussi, A New Approach to TCP-Fairness, Report C-2005- + 49, University of Helsinki, Finland, 2005. + + [CT06] D. Chiu and A. Tam, Redefining Fairness in the Study of + TCP-friendly Traffic Controls, Technical Report, 2006. + + [DM06] N. Dukkipati and N. McKeown, Why Flow-Completion Time is + the Right Metric for Congestion Control, ACM SIGCOMM, + January 2006. + + [F91] S. Floyd, Connections with Multiple Congested Gateways in + Packet-Switched Networks Part 1: One-way Traffic, Computer + Communication Review, Vol.21 No.5, October 1991, p. 30-47. + + [FA08] S. Floyd and M. Allman, Comments on the Usefulness of + Simple Best-Effort Traffic, Work in Progress, January 2007. + + [FF99] Floyd, S., and Fall, K., "Promoting the Use of End-to-End + Congestion Control in the Internet", IEEE/ACM Transactions + on Networking, August 1999. + + [FHP00] S. Floyd, M. Handley, and J. Padhye, A Comparison of + Equation-Based and AIMD Congestion Control, May 2000. URL + http://www.icir.org/tfrc/. + + [FHPW00] S. Floyd, M. Handley, J. Padhye, and J. Widmer, Equation- + Based Congestion Control for Unicast Applications, SIGCOMM + 2000, August 2000. + + + +Floyd Informational [Page 17] + +RFC 5166 TMRG, METRICS March 2008 + + + [FJ92] S. Floyd and V. Jacobson, On Traffic Phase Effects in + Packet-Switched Gateways, Internetworking: Research and + Experience, V.3 N.3, September 1992, p.115-156. + + [FJ93] S. Floyd and V. Jacobson, Random Early Detection gateways + for Congestion Avoidance, IEEE/ACM Transactions on + Networking, V.1 N.4, August 1993, + + [FK02] S. Floyd and E. Kohler, Internet Research Needs Better + Models, Hotnets-I. October 2002. + + [FK07] S. Floyd and E. Kohler, "Tools for the Evaluation of + Simulation and Testbed Scenarios", Work in Progress, + February 2008. + + [GF04] A. Gurtov and S. Floyd, Modeling Wireless Links for + Transport Protocols, ACM CCR, 34(2):85-96, April 2004. + + [HKLRX06] S. Ha, Y. Kim, L. Le, I. Rhee, and L. Xu, A Step Toward + Realistic Evaluation of High-speed TCP Protocols, technical + report, North Carolina State University, January 2006. + + [HG86] E. Hahne and R. Gallager, Round Robin Scheduling for Fair + Flow Control in Data Communications Networks, IEEE + International Conference on Communications, June 1986. + + [IPPM] IP Performance Metrics (IPPM) Working Group, URL + http://www.ietf.org/html.charters/ippm-charter.html. + + [J91] R. Jain, The Art of Computer Systems Performance Analysis: + Techniques for Experimental Design, Measurement, + Simulation, and Modeling, John Wiley & Sons, 1991. + + [JCH84] R. Jain, D.M. Chiu, and W. Hawe, A Quantitative Measure of + Fairness and Discrimination for Resource Allocation in + Shared Systems, DEC TR-301, Littleton, MA: Digital + Equipment Corporation, 1984. + + [JWL04] C. Jin, D. Wei, and S. Low, FAST TCP: Motivation, + Architecture, Algorithms, Performance, IEEE INFOCOM, March + 2004. + + [K01] F. Kelly, Mathematical Modelling of the Internet, + "Mathematics Unlimited - 2001 and Beyond" (Editors B. + Engquist and W. Schmid), Springer-Verlag, Berlin, pp. + 685-702, 2001. + + + + + +Floyd Informational [Page 18] + +RFC 5166 TMRG, METRICS March 2008 + + + [KHR02] D. Katabi, M. Handley, and C. Rohrs, Congestion Control for + High Bandwidth-Delay Product Networks, ACM Sigcomm, 2002. + + [KK03] A. Kuzmanovic and E. W. Knightly, TCP-LP: A Distributed + Algorithm for Low Priority Data Transfer, IEEE INFOCOM + 2003, April 2003. + + [KMT98] F. Kelly, A. Maulloo and D. Tan, Rate Control in + Communication Networks: Shadow Prices, Proportional + Fairness and Stability. Journal of the Operational + Research Society 49, pp. 237-252, 1998. + + [KS03] S. Kunniyur and R. Srikant, End-to-end Congestion Control + Schemes: Utility Functions, Random Losses and ECN Marks, + IEEE/ACM Transactions on Networking, 11(5):689-702, October + 2003. + + [LLS05] Y-T. Li, D. Leith, and R. Shorten, Experimental Evaluation + of TCP Protocols for High-Speed Networks, Hamilton + Institute, 2005. URL + http://www.hamilton.ie/net/eval/results_HI2005.pdf. + + [MS91] D. Mitra and J. Seery, Dynamic Adaptive Windows for High + Speed Data Networks with Multiple Paths and Propagation + Delays, INFOCOM '91, pp 39-48. + + [MTZ04] L. Mamatas, V. Tsaoussidis, and C. Zhang, Approaches to + Congestion Control in Packet Networks, 2004. + + [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP + Selective Acknowledgment Options", RFC 2018, October 1996. + + [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way + Packet Loss Metric for IPPM", RFC 2680, September 1999. + + [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring + Connectivity", RFC 2678, September 1999. + + [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way + Delay Metric for IPPM", RFC 2679, September 1999. + + [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip + Delay Metric for IPPM", RFC 2681, September 1999. + + [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC + 2914, September 2000. + + + + + +Floyd Informational [Page 19] + +RFC 5166 TMRG, METRICS March 2008 + + + [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining + Empirical Bulk Transfer Capacity Metrics", RFC 3148, July + 2001. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of + Explicit Congestion Notification (ECN) to IP", RFC 3168, + September 2001. + + [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample + Metrics", RFC 3357, August 2002. + + [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation + Metric for IP Performance Metrics (IPPM)", RFC 3393, + November 2002. + + [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP + Friendly Rate Control (TFRC): Protocol Specification", RFC + 3448, January 2003. + + [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., + "RTP Control Protocol Extended Reports (RTCP XR)", RFC + 3611, November 2003. + + [RFC3714] Floyd, S., Ed., and J. Kempf, Ed., "IAB Concerns Regarding + Congestion Control for Voice Traffic in the Internet", RFC + 3714, March 2004. + + [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno + Modification to TCP's Fast Recovery Algorithm", RFC 3782, + April 2004. + + [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., + and J. Perser, "Packet Reordering Metrics", RFC 4737, + November 2006. + + [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- + Start for TCP and IP", RFC 4782, January 2007. + + [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): + The Small-Packet (SP) Variant", RFC 4828, April 2007. + + [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC + 5136, February 2008. + + [RX05] I. Rhee and L. Xu, CUBIC: A New TCP-Friendly High-Speed TCP + Variant, PFLDnet 2005. + + + + + +Floyd Informational [Page 20] + +RFC 5166 TMRG, METRICS March 2008 + + + [SAF06] P. Sarolahti, M. Allman, and S. Floyd, Determining an + Appropriate Sending Rate Over an Underutilized Network + Path, Computer Networks, September 2006. + + [SLFK03] R.N. Shorten, D.J. Leith, J. Foy, and R. Kilduff, Analysis + and Design of Congestion Control in Synchronised + Communication Networks. Proc. 12th Yale Workshop on + Adaptive & Learning Systems, May 2003. + + [SCWA99] S. Savage, N. Cardwell, D. Wetherall, and T. Anderson, TCP + Congestion Control with a Misbehaving Receiver, ACM + Computer Communications Review, October 1999. + + [TM02] V. Tsaoussidis and I. Matta, Open Issues of TCP for Mobile + Computing, Journal of Wireless Communications and Mobile + Computing: Special Issue on Reliable Transport Protocols + for Mobile Computing, February 2002. + + [TWL06] A. Tang, J. Wang and S. H. Low. Counter-Intuitive + Throughput Behaviors in Networks Under End-to-End Control, + IEEE/ACM Transactions on Networking, 14(2):355-368, April + 2006. + + [WCL05] D. X. Wei, P. Cao and S. H. Low, Time for a TCP Benchmark + Suite?, Technical Report, Caltech CS, Stanford EAS, + Caltech, 2005. + + [VKD02] A. Venkataramani, R. Kokku, and M. Dahlin, TCP Nice: A + Mechanism for Background Transfers, Fifth USENIX Symposium + on Operating System Design and Implementation (OSDI), 2002. + + [XHR04] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion + Control for Fast, Long Distance Networks, Infocom 2004. + + [YKL01] Y. Yang, M. Kim, and S. Lam, Transient Behaviors of TCP- + friendly Congestion Control Protocols, Infocom 2001. + + [ZKL04] Y. Zhang, S.-R. Kang, and D. Loguinov, Delayed Stability + and Performance of Distributed Congestion Control, ACM + SIGCOMM, August 2004. + + + + + + + + + + + +Floyd Informational [Page 21] + +RFC 5166 TMRG, METRICS March 2008 + + +Author's Address + + Sally Floyd + ICSI Center for Internet Research + 1947 Center Street, Suite 600 + Berkeley, CA 94704 + USA + + EMail: floyd@icir.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Floyd Informational [Page 22] + +RFC 5166 TMRG, METRICS March 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, + and except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Floyd Informational [Page 23] + -- cgit v1.2.3