idnits 2.17.1 draft-almes-ippm-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 are 213 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '... uments of th...' == Line 19 has weird spacing: '... Drafts are ...' == Line 24 has weird spacing: '... please check...' == Line 26 has weird spacing: '...ctories on f...' == Line 31 has weird spacing: '... does not ...' == (208 more instances...) -- 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.) -- The document date (July 1996) is 10146 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 562, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Almes, Advanced Network & Services 2 Internet Draft W. Cerveny, Advanced Network & Services 3 P. Krishnaswamy, BellCore 4 J. Mahdavi, Pittsburgh Supercomputer Center 5 M. Mathis, Pittsburgh Supercomputer Center 6 V. Paxson, Lawrence Berkeley Labs 7 Expiration Date: January 1997 July 1996 9 Framework for IP Provider Metrics 10 12 1. Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working doc- 15 uments of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute work- 17 ing documents as 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 reference 22 material or to cite them other than as ``work in progress''. 24 To learn the current status of any Internet Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet Drafts shadow 26 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 This memo provides information for the Internet community. This memo 31 does not specify an Internet standard of any kind. Distribution of 32 this memo is unlimited. 34 2. Introduction 36 The purpose of this memo is to define a general framework for partic- 37 ular metrics to be developed by the IP Provider Metrics (IPPM) effort 38 within the Benchmarking Methodology Working Group (BMWG) of the Oper- 39 ational Requirements Area (OR) of the IETF. 41 We begin by laying out several criteria for the metrics that we 42 adopt. These criteria are designed to promote an IPPM effort that 43 will maximise an accurate common understanding by Internet users and 44 Internet providers of the performance and reliability both of end-to- 45 end paths through the Internet and of specific 'IP clouds' that 47 ID Framework for IP Provider Metrics July 1996 49 comprise portions of those paths. 51 We next define some Internet vocabulary that will allow us to speak 52 clearly about Internet components such as routers, paths, and clouds. 54 We next define three fundamental concepts, metrics, measurement 55 methodology, and uncertainties/errors, that will allow us to speak 56 clearly about specific metrics. Given these concepts, we proceed to 57 discuss how they relate to the analytical framework shared by many 58 aspects of the Internet engineering discipline. We then introduce 59 the notion of empirically defined metrics, and continue to discuss 60 two forms of composition. 62 In some sections of the memo, we will surround some commentary text 63 with the brackets {Comment: ... }. We stress that this commentary is 64 only commentary, and is not itself part of the framework document or 65 a proposal of particular metrics. In some cases this commentary will 66 discuss some of the properties of metrics that might be envisioned, 67 but the reader should assume that any such discussion is intended 68 only to shed light on points made in the framework document, and not 69 to suggest any specific metrics. 71 3. Criteria for IP Provider Metrics 73 The overarching goal of the IP Provider Metrics effort is to achieve 74 a situation in which users and providers of Internet transport ser- 75 vice have an accurate common understanding of the performance and 76 reliability of the Internet component 'clouds' that they 77 user/provide. 79 To achieve this, performance and reliability metrics for paths 80 through the Internet must be developed. In several meetings of the 81 BMWG criteria for these metrics have been specified: 82 + The metrics must be concrete and well-defined, 83 + A methodology for a metric should have the property that it is 84 repeatable: if the methodology is used multiple times under iden- 85 tical conditions, the same measurements should result in the same 86 measurements. 87 + The metrics must exhibit no bias for IP clouds implemented with 88 identical technology, 89 + The metrics must exhibit understood and fair bias for IP clouds 90 implemented with non-identical technology, 92 ID Framework for IP Provider Metrics July 1996 94 + The metrics must be useful to users and providers in understanding 95 the performance they experience or provide, 96 + The metrics must avoid inducing artificial performance goals. 98 4. Terminology for Paths and Clouds 100 The following list defines terms that need to be precise in the 101 development of path metrics. We proceed from low-level notions of 102 host, router, and link, then proceed to define the notions of path 103 and notions of IP cloud and exchange that allow us to segment a path 104 into relevant pieces. 106 host A computer capable of communicating using the Internet protocols; 107 includes "routers". 109 link A single link-level connection between two (or more) hosts; 110 includes leased lines, ethernets, frame relay clouds, etc. 112 router 113 A host which facilitates network-level communication between hosts 114 by forwarding IP packets. 116 path A sequence of the form < h0, l1, h1, ..., ln, hn >, where n >= 0, 117 each hi is a host, each li is a link between hi-1 and hi, each 118 h1...hn-1 is a router. In an appropriate operational configura- 119 tion, the links and routers in the path facilitate network-layer 120 communication of packets from h0 to hn. Note that path is a unidi- 121 rectional concept. 123 subpath 124 Given a path, a subpath is any subsequence of the given path which 125 is itself a path. (Thus, the first and last element of a subpath 126 is a host.) 128 cloud 129 An undirected (possibly cyclic) graph whose vertices are routers 130 and whose edges are links that connect pairs of routers. Formally, 131 ethernets, frame relay clouds, and other links that connect more 132 than two routers are modelled as fully-connected meshes of graph 133 edges. Note that to connect to a cloud means to connect to a 134 router of the cloud over a link; this link is not itself part of 135 the cloud. 137 exchange 138 A special case of a link, an exchange directly connects either a 139 host to a cloud and/or one cloud to another cloud. 141 ID Framework for IP Provider Metrics July 1996 143 cloud subpath 144 A subpath of a given path, all of whose hosts are routers of a 145 given cloud. 147 path digest 148 A sequence of the form < h0, e1, C1, ..., en, hn >, where n >= 0, 149 h0 and hn are hosts, each e1 ... en is an exchange, and each C1 ... 150 Cn-1 is a cloud subpath. 152 5. Three Fundamental Concepts 154 5.1. Metrics 156 In the operational Internet, there are several quantities related to 157 the performance and reliability of the Internet that we'd like to 158 know the value of. When such a quantity is carefully specified, we 159 term the quantity a metric. We anticipate that there will be sepa- 160 rate RFCs for each metric (or for each closely related group of met- 161 rics). 163 In some cases, there might be no obvious means to effectively measure 164 the metric; this is allowed, and even understood to be very useful in 165 some cases. It is required, however, that the specification of the 166 metric be as clear as possible about what quantity is being speci- 167 fied. Thus, difficulty in practical measurement is sometimes 168 allowed, but ambiguity in meaning is not. 170 Each metric will be defined in terms of standard units of measure- 171 ment. The international metric system will be used, with the follow- 172 ing points specifically noted: 173 + When a unit is expressed in simple meters (for distance/length) or 174 seconds (for duration), appropriate related units based on thou- 175 sands or thousandths of acceptable units are acceptable. Thus, 176 distances expressed in kilometers (Km), durations expressed in 177 milliseconds (msec), or microseconds (usec) are allowed, but not 178 centimeters (because the prefix is not in terms of thousands or 179 thousandths). 180 + When a unit is expressed in a combination of units, appropriate 181 related units based on thousands or thousandths of acceptable 182 units are acceptable, but all such thousands/thousandths must be 183 grouped at the beginning. Thus, kilo-meters per second (Km/sec) 184 is allowed, but meters per millisecond is not. 186 ID Framework for IP Provider Metrics July 1996 188 + The unit of information is the bit. 189 + When metric prefixes are used with bits or with combinations 190 including bits, those prefixes will have their metric meaning 191 (related to decimal 1000), and not the meaning conventional with 192 computer storage (related to decimal 1024). In any RFC that 193 defines a metric whose units include bits, this convention will be 194 followed and will be repeated to ensure clarity for the reader. 195 + When a time is given, it will be taken in UTC. 196 Note that these points apply to the specifications for metrics and 197 not, for example, to packet formats where octets will likely be used 198 in preference/addition to bits. 200 Finally, we note that some metrics may be defined purely in terms of 201 other metrics; such metrics are call 'derived metrics'. 203 5.2. Measurement Methodology 205 For a given set of well-defined metrics, a number of distinct mea- 206 surement methodologies may exist. A partial list includes: 207 + Direct measurement of a performance metric using injected test 208 traffic. Example: measurement of the round-trip delay of an IP 209 packet of a given size over a given route at a given time. 210 + Projection of a metric from lower-level measurements. Example: 211 given accurate measurements of propagation delay and bandwidth for 212 each step along a path, projection of the complete delay for the 213 path for an IP packet of a given size. 214 + Estimation of a consituent metric from a set of more aggregated 215 measurements. Example: given accurate measurements of delay for a 216 given one-hop path for IP packets of different sizes, estimation 217 of propagation delay for the link of that one-hop path. 218 + Estimation of a given metric at one time from a set of related 219 metrics at other times. Example: given an accurate measurement of 220 flow capacity at a past time, together with a set of accurate 221 delay measurements for that past time and the current time, and 222 given a model of flow dynamics, estimate the flow capacity that 223 would be observed at the current time. 224 This list is by no means exhaustive. The purpose is to point out the 225 variety of measurement techniques. 227 When a given metric is specified, a given measurement approach might 228 be noted and discussed. That approach, however, is not formally part 229 of the specification. 231 A methodology for a metric should have the property that it is 232 repeatable: if the methodology is used multiple times under identical 233 conditions, it should result in consistent measurements. 235 ID Framework for IP Provider Metrics July 1996 237 Backing off a little from the word 'identical' in the previous para- 238 graph, we could more accurately use the word 'continuity' to describe 239 a property of a given methodology: a methodology for a given metric 240 exhibits continuity if, for small variations in conditions, it 241 results in small variations in the resulting measurements. Slightly 242 more precisely, for every positive epsilon, there exists a positive 243 delta, such that if two sets of conditions are within delta of each 244 other, then the resulting measurements will be within epsilon of each 245 other. At this point, this should be taken as a heuristic driving 246 our intuition about one kind of robustness property rather than as a 247 precise notion. 249 A metric that has at least one methodology that exhibits continuity 250 is said itself to exhibit continuity. 252 Note that some metrics, such as hop-count along a path, are integer- 253 valued and therefore cannot exhibit continuity in quite the sense 254 given above. 256 Note further that, in practice, it may not be practical to know (or 257 be able to quantify) the conditions relevant to a measurement at a 258 given time. For example, since the instantaneous load (in packets to 259 be served) at a given router in a high-speed wide-area network can 260 vary widely over relatively brief periods and will be very hard for 261 an external observer to quantify, various statistics of a given met- 262 ric may be more repeatable, or may better exhibit continuity. In 263 that case those particular statistics should be specified when the 264 metric is specified. 266 Finally, some measurement methodologies may be 'conservative' in the 267 sense that a measurement that may themselves modify the value of the 268 performance metric they attempt to measure. {Comment: for example, 269 in a wide-are high-speed network under modest load, a test using sev- 270 eral small 'ping' packets to measure delay would likely not interfere 271 (much) with the delay properties of that network as observed by oth- 272 ers. The corresponding statement about tests using a large flow to 273 measure flow capacity would likely fail.} 275 5.3. Measurements, Uncertainties, and Errors 277 Even the very best measurement methodologies for the very most well 278 behaved metrics will exhibit errors. Those who develop such measure- 279 ment methodologies, however, should strive to: 281 ID Framework for IP Provider Metrics July 1996 283 + minimise their uncertainties/errors, 284 + understand and document the sources of uncertainty/error, and 285 + quantify the amounts of uncertainty/error. 286 by doing so, the measurement community will work together to improve 287 our ability to understand the performance and reliability of the 288 Internet. 290 For example, when developing a method for measuring delay, understand 291 how any errors in your clocks introduce errors into your delay mea- 292 surement, and quantify this effect as well as you can. In some 293 cases, this will result in a requirement that a clock be at least up 294 to a certain quality if it is to be used to make a certain measure- 295 ment. 297 As a second example, consider the timing error due to measurement 298 overheads within computer making the measurement, as opposed to 299 delays due to the Internet component being measured. The former is a 300 measurement error, while the latter reflects the metric of interest. 301 Note that one technique that can help avoid this overhead is the use 302 of a packet filter/sniffer, running on a separate computer that 303 records network packets and timestamps them accurately. The result- 304 ing trace can then be analysed to assess the test traffic, minimising 305 the effect of measurement host delays, or at least allowing those 306 delays to be accounted for. 308 Finally, we note that derived metrics (defined above) or metrics that 309 exhibit spatial or temporal composition (defined below) offer occa- 310 sion for the analysis of measurement uncertainty of related measure- 311 ments to be themselves related. 313 6. Metrics and the Analytical Framework 315 As the Internet has evolved from the early packet-switching studies 316 of the 1960s, the Internet engineering community has evolved a common 317 analytical framework of concepts. This analytical framework, or A- 318 frame, used by designers and implementers of protocols, by those 319 involved in measurement, and by those who study computer network per- 320 formance using the tools of simulation and analysis, has great advan- 321 tage to our work. A major objective here is to generate network 322 characterisations that are consistent in both analytical and practi- 323 cal settings, since this will maximise the chances that non-empirical 324 network study can be better correlated with, and used to further our 325 understanding of, real network behavior. 327 Whenever possible, therefore, we would like to develop and leverage 328 the A-frame. Thus, whenever a metric to be specified is understood 329 to be closely related to concepts (such as the Internet components 331 ID Framework for IP Provider Metrics July 1996 333 defined above) within the A-frame, we will attempt to specify the 334 metric in the A-frame's terms. In such a specification we will 335 develop the A-frame by precisely defining the concepts needed for the 336 metric, then leverage the A-frame by defining the metric in terms of 337 those concepts. 339 Such a metric will be called an 'analytically specified metric' or, 340 more simply an analytical metric. 342 {Comment: Examples of such analytical metrics might include: 344 propagation time of a link 345 The time, in seconds, required by a single bit to travel from the 346 output port on one Internet host across a single link to another 347 Internet host. 349 bandwidth of a link for packets of size k 350 The capacity, in bits/second, where only those bits of the IP 351 packet are counted, for a packet of size k bytes. 353 route 354 The path, as defined in Section 4, from A to B at a given time. 356 hop count of a route 357 The value 'n' of the route path. 358 } 360 Note that we make no a priori list of just what A-frame concepts 361 will emerge in these specifications, but we do encourage their use 362 and urge that they be carefully specified so that, as our set of 363 metrics develops, so will a specified set of A-frame concepts tech- 364 nically consistent with each other and consonent with the common 365 understanding of those concepts within the general Internet commu- 366 nity. 368 These A-frame concepts will be intended to abstract from actual 369 Internet components in such a way that: 370 + the essential function of the component is retained, 371 + properties of the component relevant to the metrics we aim to cre- 372 ate are retained, 373 + a subset of these component properties are defined as analytical 374 metrics, and 375 + those properties of actual Internet components not relevant to 376 defining the metrics we aim to create are dropped. 378 {Comment: for example, when considering a router in the context of 379 packet forwarding, we might model the router as a component that 380 receives packets on an input link, queues them on a FIFO packet queue 382 ID Framework for IP Provider Metrics July 1996 384 of finite size, employs tail-drop when the packet queue is full, and 385 forwards them on an output link. The transmission speed (in 386 bits/second) of the input and output links, the latency in the router 387 (in seconds), and the maximum size of the packet queue (in bits) are 388 relevant analytical metrics.} 390 In some cases, such analytical metrics used in relation to a router 391 will be very closely related to specific metrics of the performance 392 of Internet paths. For example, an obvious formula (L + P/B) involv- 393 ing the latency in the router (L), the packet size (in bits) (P), and 394 the transmission speed of the output link (B) might closely approxi- 395 mate the increase in packet delay due to the insertion of a given 396 router along a path. 398 We stress, however, that well-chosen and well-specified A-frame con- 399 cepts and their analytical metrics will support more general metric 400 creation effort in less obvious ways. 402 {Comment: for example, when considering the flow capacity of a path, 403 it may be of real value to be able to model each of the routers along 404 the path as packet forwarders as above. Techniques for estimating 405 the flow capacity of a path might use the maximum packet queue size 406 as a parameter in decidedly non-obvious ways. For example, as the 407 maximum queue size increases, so will the ability of the router to 408 continuously move traffic along an output link despite fluctuations 409 in traffic from an input link. Estimating this increase, however, 410 remains a research topic.} 412 The key role of these concepts is to abstract the properties of the 413 Internet components relevant to given metrics. Judgement is required 414 to avoid making assumptions that bias the modeling and metric effort 415 toward one kind of design. 417 {Comment: for example, routers might not use tail-drop, even though 418 tail-drop might be easier to model analytically.} 420 Note that, when we specify A-frame concepts and analytical metrics, 421 we will inevitably make simplifying assumptions. Further, as noted 422 above, judgement is required in making these assumptions in order to 423 make them best suit our purposes. 425 Finally, note that different elements of the A-frame might well make 426 different simplifying assumptions. For example, the abstraction of a 427 router used to further the definition of delay might treat the 428 router's packet queue as a single FIFO queue, but the abstraction of 429 a router used to further the definition of the handling of an RSVP- 430 enabled packet might treat the router's packet queue to support 431 bounded delay -- a contradictory assumption. This is not to say that 433 ID Framework for IP Provider Metrics July 1996 435 we make contradictory assumptions at the same time, but that two dif- 436 ferent parts of our work might refine the simpler base concept in two 437 divergent ways for different purposes. 439 7. Empirically Specified Metrics 441 There are useful performance and reliability metrics that do not fit 442 so neatly into the A-frame, usually because the A-frame lacks the 443 complexity or power for dealing with them. For example, "the best 444 flow capacity achievable along a path using an RFC-1122-compliant 445 TCP" would be good to be able to measure, but we have no analytical 446 framework of sufficient complexity to allow us to cast that flow 447 capacity as an analytical metric. 449 These notions can still be well specified by instead describing a 450 reference methodology for measuring them. 452 Such a metric will be called an 'empirically specified metric', or 453 more simply, an empirical metric. 455 Such empirical metrics should have three properties: 456 + we should have a clear definition for each in terms of real-world 457 Internet components, 458 + we should have at least one effective means to measure them, and 459 + to the extent possible, we should have an (necessarily incomplete) 460 understanding of the metric in terms of the A-frame so that we can 461 use our measurements to reason about the performance and reliabil- 462 ity of A-frame components and of aggregations of A-frame compo- 463 nents. 465 8. Two Forms of Composition 467 8.1. Spatial Composition of Metrics 469 In some cases, it may be realistic and useful to define metrics in 470 such a fashion that they exhibit spatial composition. 472 By spatial composition, we mean a characteristic of some path met- 473 rics, in which the metric as applied to a (complete) path can also be 474 defined for various subpaths (cf. definition above), and in which the 475 appropriate A-frame concepts for the metric suggest useful relation- 476 ships between the metric applied to these various subpaths (including 477 the complete path, the various cloud subpaths of a given path digest, 478 and even single routers along the path). The effectiveness of spa- 479 tial composition depends: 481 ID Framework for IP Provider Metrics July 1996 483 + on the usefulness in analysis of these relationships as applied to 484 the relevant A-frame components, and 485 + on the practical use of the corresponding relationships as applied 486 to metrics and to measurement methodologies. 488 {Comment: for example, consider some metric for delay of a 100-byte 489 packet across a path P, and consider further a path digest of P. The definition of such a metric might include 491 a conjecture that the delay across P is very nearly the sum of the 492 corresponding metric across the exhanges (ei) and clouds (Ci) of the 493 given path digest. The definition would further include a note on 494 how a corresponding relation applies to relevant A-frame components, 495 both for the path P and for the exchanges and clouds of the path 496 digest.} 498 When the definition of a metric includes a conjecture that the metric 499 across the path is related to the metric across the subpaths of the 500 path, that conjecture constitutes a claim that the metric exhibits 501 spatial composition. The definition should then include: 502 + the specific conjecture applied to the metric, 503 + a justification of the practical utility of the composition in 504 terms of making accurate measurements of the metric on the path, 505 and 506 + a justification of the usefulness of the composition in terms of 507 making analysis of the path using A-frame concepts more effective. 509 8.2. Temporal Composition of Formal Models and Empirical Metrics 511 In some cases, it may be realistic and useful to define metrics in 512 such a fashion that they exhibit temporal composition. 514 By temporal composition, we mean a characteristic of some path met- 515 rics, in which the metric as applied to a path at a given time T is 516 also defined for various times t0 < t1 < ... < tn < T, and in which 517 the appropriate A-frame concepts for the metric suggests useful rela- 518 tionships between the metric applied at times t0, ..., tn and the 519 metric applied at time T. The effectiveness of temporal composition 520 depends: 521 + on the usefulness in analysis of these relationships as applied to 522 the relevant A-frame components, and 523 + on the practical use of the corresponding relationships as applied 524 to metrics and to measurement methodologies. 526 {Comment: for example, consider some metric for the expected flow 527 capacity across a path P during the five-minute period surrounding 528 the time T, and suppose further that we have the corresponding values 529 for each of the four previous five-minute periods t0, t1, t2, and t3. 531 ID Framework for IP Provider Metrics July 1996 533 The definition of such a metric might include a conjecture that the 534 flow capacity at time T can be estimated from a certain kind of 535 extrapolation from the values of t0, ..., t3. The definition would 536 further include a note on how a corresponding relation applies to 537 relevant A-frame components. 539 Note: any (spatial or temporal) compositions involving flow capacity 540 are likely to be subtle, and temporal compositions are generally more 541 subtle than spatial compositions, so the reader should understand 542 that the foregoing example is intentionally naive.} 544 When the definition of a metric includes a conjecture that the metric 545 across the path at a given time T is related to the metric across the 546 path for a set of other times, that conjecture constitutes a claim 547 that the metric exhibits temporal composition. The definition should 548 then include: 549 + the specific conjecture applied to the metric, 550 + a justification of the practical utility of the composition in 551 terms of making accurate measurements of the metric on the path, 552 and 553 + a justification of the usefulness of the composition in terms of 554 making analysis of the path using A-frame concepts more effective. 556 9. Security Considerations 558 This memo raises no security issues. 560 10. References 562 [1] Vern Paxson, ftp://ftp.ee.lbl.gov/papers/metrics-framework- 563 INET96.ps.Z 565 11. Authors' Addresses 567 Guy Almes 568 Advanced Network & Services, Inc. 569 200 Business Park Drive 570 Armonk, NY 10504 571 USA 572 Phone: +1 914/273-7863 574 Bill Cerveny 575 Advanced Network & Services, Inc. 576 200 Business Park Drive 578 ID Framework for IP Provider Metrics July 1996 580 Armonk, NY 10504 581 USA 583 Padma Krishnaswamy 584 Bell Communications Research 585 445 South Street 586 Morristown, NJ 07960 587 USA 589 Jamshid Mahdavi 590 Pittsburgh Supercomputing Center 591 4400 5th Avenue 592 Pittsburgh, PA 15213 593 USA 595 Matt Mathis 596 Pittsburgh Supercomputing Center 597 4400 5th Avenue 598 Pittsburgh, PA 15213 599 USA 601 Vern Paxson 602 MS 50B/2239 603 Lawrence Berkeley National Laboratory 604 University of California 605 Berkeley, CA 94720 606 USA 607 Phone: +1 510/486-7504