idnits 2.17.1 draft-ietf-ippm-btc-cap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 20 instances of lines with control characters in the document. ** The abstract seems to contain references ([MA00]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1122' is mentioned on line 169, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'All01' ** Downref: Normative reference to an Informational draft: draft-ietf-ippm-btc-framework (ref. 'MA00') ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Mark Allman 2 INTERNET DRAFT BBN/NASA GRC 3 File: draft-ietf-ippm-btc-cap-00.txt February, 2001 4 Expires: August, 2001 6 A Bulk Transfer Capacity Methodology for 7 Cooperating Hosts 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet- Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document specifies a specific Bulk Transfer Capacity (BTC) 33 metric based on the BTC framework outlined in [MA00]. 35 1 Introduction 37 This document specifies a methodology that performs Bulk Transfer 38 Capacity (BTC) measurements based on the BTC framework outlined in 39 [MA00]. This particular methodology assumes cooperating processes 40 on the sender and receiver. As outlined in [MA00], there are a 41 number of considerations that need to be made when writing a 42 particular BTC metric. This document specifies these items for a 43 BTC methodology that uses cooperating processes on the sender and 44 receiver. 46 Readers are assumed to be familiar with [MA00] and [RFC2581]. The 47 terminology used to describe the congestion control algorithms in 48 this document is taken from [RFC2581]. 50 We implemented this methodology in two programs, cap and capd. The 51 discussion in this document is conducted in terms of these two 52 programs. However, alternate programs can be written that conform 53 to this BTC methodology. 55 2 Congestion Control Algorithm Specifications 57 As specified in section 2 of [MA00], each BTC document must tightly 58 specify several details of the congestion control algorithms that 59 are not tightly specified in [RFC2581]. The following is the 60 specification of those details for the sender's behavior in the 61 defined methodology: 63 * Window Increase During Congestion Avoidance: During congestion 64 avoidance, cap counts the number of packets that are 65 acknowledged (ACKed) by the cumulative acknowledgment, denoted 66 SA. When SA becomes greater than or equal to the current value 67 of the congestion window (cwnd), SA is decreased by the current 68 value of cwnd and cwnd is increased by 1 segment unless the 69 increase is not possible due to the configured advertised window 70 size. 72 * When To Enter Congestion Avoidance. [RFC2581] allows TCP to 73 use either slow start or congestion avoidance when cwnd equals 74 ssthresh. Cap uses congestion avoidance. 76 * Cap uses a segment size of 1500 bytes by default. The segment 77 size can be changed using a command-line option. Cap does not 78 use Path MTU Discovery [RFC1191]. 80 * By default, cap assumes 40 bytes of header are prepended to 81 each segment (default TCP and IP headers). When using 82 timestamps [RFC1323] the header size is increased by 12 bytes. 83 Additionally, when using selective acknowledgments (SACKs) 84 [RFC2018] the header size on returning ACKs depends on the 85 number of SACK blocks being returned (per [RFC2018]). 87 * The algorithm for calculating the retransmission timeout (RTO) 88 is similar to the algorithm outlined in [RFC2988]. The 89 algorithm is fully specified in section 3. 91 [MA00] recommends each BTC take a number of ancillary metrics, in 92 addition to a simple BTC measurement. Cap does not perform any of 93 these ancillary metrics, but can produce a segment trace which may 94 be used to derive these metrics via post-processing. 96 3 Calculating the Retransmission Timeout 98 The RTO used in this BTC methodology is generally outlined in 99 [RFC2988]. The following is a sketch of the initial conditions, as 100 well as a discussion of how our estimator differs from the one 101 outlined in [RFC2988]. The reader is assumed familiar with 102 [RFC2988]. 104 Cap takes high-precision round-trip time (RTT) measurements and 105 converts these into a retransmission timeout (RTO) based on a clock 106 with a given granularity. The RTO is initialized as follows: 108 * The default clock granularity, G, is 500 ms. However, the clock 109 granularity may be changed via a command-line option. 111 * The initial RTO in clock ticks is: (int)(3 seconds / G). 113 * When cap is started, the first heartbeat is determined by 114 generating a uniform random number between 0-G and subtracting 115 the obtained value from the current time. The time of the first 116 heartbeat is denoted HB_FIRST. 118 * We define bounds on the RTO, as follows: 120 MIN_TICKS = ceil (1.0 / G) 121 MAX_TICKS = ceil (64.0 / G) 123 The RTO is calculated based on RTT measurements. We derive RTT 124 measurements in one of two ways. When the timestamp option is 125 enabled by the user, we use the timestamps in incoming ACKs to take 126 RTT measurements. Otherwise, we time one segment and its 127 corresponding ACK per RTT, as outlined in [RFC2988]. We update the 128 SRTT and RTTVAR upon taking each sample as defined in [RFC2988]. 130 The timer is armed in the situations outlined in [RFC2988]. Each 131 time we are the timer the following algorithm is used to convert the 132 fine-grained SRTT and RTTVAR values to a course-grained RTO 133 estimate. 135 now = get_current_time; 136 if (!SRTT) 137 ticks = 3.0 / G 138 else 139 rto = SRTT + (4 * RTTVAR) 140 ticks = ceil (rto / G) 141 ticks *= BACKOFF 142 if (ticks < MIN_TICKS) 143 ticks = MIN_TICKS 144 else if (ticks > MAX_TICKS) 145 ticks = MAX_TICKS 146 so_far = now - HB_FIRST; 147 so_far_ticks = (int)(so_far / G) 148 gone = so_far - (so_far_ticks * G) 149 partial = G - gone; 150 full = (ticks - 1) * G 151 real_rto = full + partial 152 arm_timer (real_rto) 154 4 Receiver Specification 156 The receiving process, capd, sends ``ACKs'', UDP datagrams, to 157 the sender with the following properties. 159 * Each ACK contains a cumulative sequence number, as done in TCP. 161 * The default size of an ACK is 40 bytes. 163 * In the case when capd echoes the timestamp sent by cap the ACK 164 consists of 52 bytes. 166 * By default ACKs are sent in response to every incoming data 167 segment. 169 * The user may enable the use of delayed ACKs [RFC1122,RFC2581] 170 via a command-line option. 172 5 Conclusion 174 This document specifies a BTC methodology involving two processes 175 based on the framework outlined in [MA00]. This methodology has 176 been shown to accurately gauge the BTC of a given network path over 177 various network conditions [All01]. 179 6 Security Considerations 181 The BTC methodology outlined in this document does not pose security 182 problems beyond those expressed in the BTC framework document [MA00]. 184 Acknowledgments 186 Thanks to Vern Paxson for encouraging the development of cap. 188 References 190 [All01] Mark Allman Measuring End-to-End Bulk Transfer Capacity, 191 February 2001. Under review. 193 [MA00] Matt Mathis, Mark Allman. A Framework for Defining Empirical 194 Bulk Transfer Capacity Metrics, February 2001. Internet-Draft 195 draft-ietf-ippm-btc-framework-05.txt (work in progress). 197 [RFC1191] Jeff Mogul, Steve Deering, "Path MTU Discovery", RFC 1191, 198 November 1990. 200 [RFC1323] Van Jacobson, Robert Braden, David Borman, "TCP Extensions 201 for High Performance", RFC 1323, May 1992. 203 [RFC2018] Matt Mathis, Jamshid Mahdavi, Sally Floyd, Allyn Romanow, 204 "TCP Selective Acknowledgment Options", RFC 2018, 1996. 206 [RFC2581] Mark Allman, Vern Paxson, W. Richard Stevens, "TCP 207 Congestion Control", RFC 2581, April 1999. 209 [RFC2988] Vern Paxson, Mark Allman, "Computing TCP's Retransmission 210 Timer", RFC 2988, November 2000. 212 Author's Address: 214 Mark Allman 215 BBN Technologies/NASA Glenn Research Center 216 Lewis Field 217 21000 Brookpark Rd. MS 54-5 218 Cleveland, OH 44135 219 Phone: 216-433-6586 220 Fax: 216-433-8705 221 mallman@bbn.com 222 http://roland.grc.nasa.gov/~mallman