idnits 2.17.1 draft-ietf-bmwg-benchres-term-04.txt: ** The Abstract section seems to be numbered 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 the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == 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. 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.) -- The document date (February 2004) is 7376 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: '11' is defined on line 780, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '3') == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-fw (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' == Outdated reference: A later version (-05) exists of draft-ietf-nsis-signalling-analysis-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-signalling-analysis (ref. '10') Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Benchmarking Working Group Gabor Feher, BUTE 2 INTERNET-DRAFT Krisztian Nemeth, BUTE 3 Expiration Date: August 2004 Andras Korn, BUTE 4 Istvan Cselenyi, TeliaSonera 6 February 2004 8 Benchmarking Terminology for Routers Supporting Resource Reservation 9 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft shadow directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This memo provides information for the Internet community. This memo 33 does not specify an Internet standard of any kind. Distribution of 34 this memo is unlimited. 36 2. Table of contents 38 1. Status of this Memo.............................................1 39 2. Table of contents...............................................1 40 3. Abstract........................................................2 41 4. Introduction....................................................2 42 5. Existing definitions............................................3 43 6. Definition of Terms.............................................3 44 6.1 Traffic Flow Types..........................................3 45 6.1.1 Data Flow..............................................3 46 6.1.2 Distinguished Data Flow................................4 47 6.1.3 Best-Effort Data Flow..................................4 48 6.2 Resource Reservation Protocol Basics........................5 49 6.2.1 QoS Session............................................5 50 6.2.2 Resource Reservation Protocol..........................6 51 6.2.3 Resource Reservation Capable Router....................6 52 6.2.4 Reservation State......................................6 53 6.2.5 Resource Reservation Protocol Orientation..............7 54 6.3 Router Load Factors.........................................8 55 6.3.1 Best-Effort Traffic Load Factor........................8 56 6.3.2 Distinguished Traffic Load Factor......................9 57 6.3.3 Session Load Factor....................................9 58 6.3.4 Signaling Intensity Load Factor.......................10 59 6.3.5 Signaling Burst Load Factor...........................10 60 6.4 Performance Metrics........................................11 61 6.4.1 Signaling Message Handling Time.......................11 62 6.4.2 Distinguished Traffic Delay...........................12 63 6.4.3 Best-effort Traffic Delay.............................12 64 6.4.4 Signaling Message Loss................................13 65 6.4.5 Session Maintenance Capacity..........................13 66 6.5 Scalability Limit..........................................14 67 7. Security Considerations........................................15 68 8. Acknowledgements...............................................15 69 9. References.....................................................15 71 3. Abstract 73 The purpose of this document is to define terminology specific to the 74 benchmarking of resource reservation signaling of IntServ IP routers. 75 These terms can be used in additional documents that define 76 benchmarking methodologies for routers that support resource 77 reservation or reporting formats for the benchmarking measurements. 79 4. Introduction 81 Signaling based resource reservation (e.g. via RSVP [1]) is an 82 important part of the different QoS provisioning approaches. 83 Therefore network operators who are planning to deploy signaling 84 based resource reservation may want to scrutinize the scalability 85 limitations of reservation capable routers and the impact of 86 signaling on their data forwarding performance. 88 An objective way of quantifying the scalability constraints of QoS 89 signaling is to perform measurements on routers that are capable of 90 resource reservation. This document defines terminology for a 91 specific set of tests that vendors or network operators can carry out 92 to measure and report the signaling performance characteristics of 93 router devices that support resource reservation protocols. The 94 results of these tests provide comparable data for different 95 products, and thus support the decision process before purchase. 96 Moreover, these measurements provide input characteristics for the 97 dimensioning of a network in which resources are provisioned 98 dynamically by signaling. Finally, the tests are applicable for 99 characterizing the impact of the resource reservation signaling on 100 the forwarding performance of the routers. 102 This benchmarking terminology document is based on the knowledge 103 gained by examination of (and experimentation with) different 104 resource reservation protocols: the IETF standard RSVP [1] and 105 several experimental ones, such as YESSIR [5], ST2+ [6], SDP [7], 106 Boomerang [8] and Ticket [9]. Some of these protocols are also 107 analyzed in an IETF NSIS working group draft [10]. Although at the 108 moment the authors are only aware of resource reservation capable 109 router products that interpret RSVP, this document defines terms that 110 are valid in general and not restricted to any of the above listed 111 protocols. 113 In order to avoid any confusion we would like to emphasize that this 114 terminology considers only signaling protocols that provide IntServ 115 resource reservation; the DiffServ world, for example, is out of our 116 scope. 118 5. Existing definitions 120 RFC 1242 "Benchmarking Terminology for Network Interconnect 121 Devices" [2] and RFC 2285 "Benchmarking Terminology for LAN Switching 122 Devices" [3] contain discussions and definitions for a number of 123 terms relevant to the benchmarking of signaling performance of 124 reservation capable routers and should be consulted before attempting 125 to make use of this document. 127 Additionally, this document defines terminology in a way that is 128 consistent with the terms used by Next Steps in Signaling working 129 group laid out in [4]. 131 For the sake of clarity and continuity this document adopts the 132 template for definitions set out in Section 2 of RFC 1242. 133 Definitions are indexed and grouped together into different sections 134 for ease of reference. 136 6. Definition of Terms 138 6.1 Traffic Flow Types 140 This group of definitions describes traffic flow types forwarded by 141 resource reservation capable routers. 143 6.1.1 Data Flow 145 Definition: 146 A data flow is a stream of data packets from one sender to one or 147 more receivers, where each packet has a flow identifier unique to 148 the flow. 150 Discussion: 151 The flow identifier can be an arbitrary subset of the packet 152 header fields that uniquely distinguishes the flow from others. 153 For example, the 5-tuple "source address; source port; destination 154 address; destination port; protocol number" is commonly used for 155 this purpose (where port number are applicable). For more comment 156 on flow identification refer to [4]. 158 The flow identification can be time- and/or resource-consuming, 159 but this can sometimes be avoided as routers do not necessarily 160 have to classify each packet. Instead, packets that should be 161 classified by routers can be marked with special flags that 162 routers understand. One existing marking approach is to use the 163 ToS field of the IP header. Naturally, unmarked packets are not 164 classified by routers and this way valuable resources can be 165 saved. 167 6.1.2 Distinguished Data Flow 169 Definition: 170 Distinguished data flows are flows that resource reservation 171 capable routers intentionally treat better or worse than 172 "ordinary" data flows, according to a QoS agreement defined for 173 the distinguished flow. 175 Discussion: 176 Packets of distinguished data flows are marked so that the routers 177 that forward them know they require differentiated treatment. 178 Routers classify these incoming packets and identify the data flow 179 they belong to. 181 The most common usage of the distinguished data flow is to get 182 higher priority treatment than that of best-effort data flows (see 183 the next definition). In these cases, a distinguished data flow is 184 sometimes referred to as a "premium data flow". Nevertheless 185 theoretically it is possible to require worse treatment than that 186 of best-effort flows. 188 6.1.3 Best-Effort Data Flow 190 Definition: 191 Best-effort data flows are flows that are not treated in any 192 special manner by resource reservation capable routers; thus, 193 their packets are served (forwarded) in some default way. 195 Discussion: 196 "Best-effort" means that the router makes its best effort to 197 forward the data packet quickly and safely, but does not guarantee 198 anything (e.g. delay or loss probability). This type of traffic is 199 the most common in today's Internet. 201 The packets belonging to the best-effort data flows are not 202 specially marked and thus they are not classified by the routers. 204 6.2 Resource Reservation Protocol Basics 206 This group of definitions applies to signaling based resource 207 reservation protocols implemented by IP router devices. 209 6.2.1 QoS Session 211 Definition: 212 A QoS session is an application layer concept, shared between a 213 set of network nodes, that pertains to a specific set of data 214 flows. The information associated with the session includes the 215 data required to identify the set of data flows in addition to a 216 specification of the QoS treatment they require. 218 Discussion: 219 A QoS session is an end-to-end relationship. Whenever end-nodes 220 decide to obtain special QoS treatment for their data 221 communication, they set up a QoS session; as part of the process, 222 they or their proxies make a QoS agreement with the network, 223 specifying their data flows and the QoS treatment that the flows 224 require. 226 It is possible for the same QoS session to span multiple network 227 domains that have different resource provisioning architectures. 228 In this document, however, we only deal with the case where the 229 QoS session is realized over an IntServ architecture. It is 230 assumed that sessions will be established using signaling messages 231 of a resource reservation protocol. 233 QoS sessions must have unique identifiers; it must be possible to 234 determine which QoS session a given signaling message pertains to. 235 Therefore, each signaling message should include the identifier of 236 its corresponding session. As an example, in the case of RSVP, the 237 "session specification" identifies the QoS session plus refers to 238 the data flow; the "flowspec" specifies the desired QoS treatment 239 and the "filter spec" defines the subset of data packets in the 240 data flow that receive the QoS defined by the flowspec. 242 QoS sessions can be unicast or multicast depending on the number 243 of participants. In a multicast group there can be several data 244 traffic sources and destinations. Here the QoS agreement does not 245 have to be the same for each branch of the multicast tree 246 forwarding the data flow of the group. Instead, a dedicated 247 network resource in a router can be shared among many traffic 248 sources from the same multicast group (c.f. multicast reservation 249 styles in the case of RSVP). 251 Issues: 252 Even though QoS sessions are considered to be unique, resource 253 reservation capable routers might aggregate them and allocate 254 network resources to these aggregated sessions at once. The 255 aggregation can be based on similar data flow attributes (e.g. 257 similar destination addresses) or it can combine arbitrary 258 sessions as well. While reservation aggregation significantly 259 lightens the signaling processing task of a resource reservation 260 capable router, it also requires the administration of the 261 aggregated QoS sessions and might also lead to the violation of 262 the quality guaranties referring to individual data flows within 263 an aggregation [12]. 265 6.2.2 Resource Reservation Protocol 267 Definition: 268 Resource reservation protocols define signaling messages and 269 message processing rules used to control resource allocation in 270 IntServ architectures. 272 Discussion: 273 It is the signaling messages of a resource reservation protocol 274 that carry the information related to QoS sessions. This 275 information includes a session identifier, the actual QoS 276 parameters, and possibly flow descriptors. 278 The message processing rules of the signaling protocols ensure 279 that signaling messages reach all network nodes concerned. Some 280 resource reservation protocols (e.g. RSVP) are only concerned with 281 this, i.e. carrying the QoS-related information to all the 282 appropriate network nodes, without being aware of its content. 283 This latter approach allows changing the way the QoS parameters 284 are described, and different kind of provisioning can be realized 285 without the need to change the protocol itself. 287 6.2.3 Resource Reservation Capable Router 289 Definition: 290 A router is resource reservation capable (it supports resource 291 reservation) if it is able to interpret signaling messages of a 292 resource reservation protocol, and based on these messages is able 293 to adjust the management of its flow classifiers and network 294 resources so as to conform with the content of the messages. 296 Discussion: 297 Routers capture signaling messages and manipulate reservation 298 states and/or reserved network resources according to the content 299 of the messages. This ensures that the flows are treated as their 300 specified QoS requirements indicate. 302 6.2.4 Reservation State 304 Definition: 305 A reservation state is the set of entries in the router�s memory 306 that contain all relevant information about a given QoS session 307 registered with the router. 309 Discussion: 310 States are needed because IntServ related resource reservation 311 protocols require the routers to keep track of QoS session and 312 data-flow-related metadata. The reservation state includes the 313 parameters of the QoS treatment; the description of how and where 314 to forward the incoming signaling messages; refresh timing 315 information; etc. 317 Based on how reservation states are stored in a reservation 318 capable router, the routers can be categorized into two classes: 320 Hard-state resource reservation protocols (e.g. ST2 [6]) require 321 routers to store the reservation states permanently, established 322 by a set-up signaling primitive, until the router is explicitly 323 informed that the QoS session is canceled. 325 There are also soft-state resource reservation capable routers, 326 where there are no permanent reservation states, and each state 327 has to be regularly refreshed by appropriate refresh signaling 328 messages. If no refresh signaling message arrives during a certain 329 period then the router stops the maintenance of the QoS session 330 assuming that the end-points do not intend to keep the session up 331 any longer or the communication lines are broken somewhere along 332 the data path. This feature makes soft-state resource reservation 333 capable routers more robust than hard-state routers, since no 334 failures can cause resources to stay permanently stuck in the 335 routers. (Note, it is still possible to have an explicit teardown 336 message in soft-state protocols for quicker resource release.) 338 Issues: 339 Based on the initiating point of the refresh messages, soft-state 340 resource reservation protocols can be divided into two groups. 341 First, there are protocols where it is the responsibility of the 342 end-points or their proxies to initiate refresh messages. These 343 messages are forwarded along the path of the data flow refreshing 344 the corresponding reservation states in each router affected by 345 the flow. Secondly, there are other protocols, where routers and 346 end-points have their own schedule for the reservation state 347 refreshes and they signal these refreshes to the neighboring 348 routers. 350 6.2.5 Resource Reservation Protocol Orientation 352 Definition: 353 The orientation of a resource reservation protocol tells which end 354 of the protocol communication initiates the allocation of the 355 network resources. Thus, the protocol can be sender or receiver 356 initiated, depending on the location of the data flow source 357 (sender) and destination (receiver) compared to the reservation 358 initiator. 360 Discussion: 361 In the case of sender-initiated protocols the resource reservation 362 propagates the same directions as of the data flow. Consequently, 363 in the case of receiver-initiated protocols the signaling messages 364 reserving resources are forwarded backward on the path of the data 365 flow. Due to the asymmetric routing nature of the Internet, in 366 this latter case, the path of the desired data flow should be 367 known before the reservation initiator would be able to send the 368 resource allocation messages. For example in the case of RSVP, the 369 RSVP PATH message, traveling from the data flow sources towards 370 the destinations, first marks the path of the data flow on which 371 the resource allocation messages will travel backward. 373 This definition considers only protocols that reserve resources 374 for just one data flow between the end-nodes. The reservation 375 orientation of protocols reserving more than one data flow is not 376 defined here. 378 Issues: 379 The location of the reservation initiator affects the basics of 380 the resource reservation protocols and therefore it is an 381 important design decision. In the case of multicast QoS sessions, 382 the sender-oriented protocols require the traffic sources to 383 maintain a list of receivers and send their allocation messages 384 considering the different requirements of the receivers. Using 385 multicast QoS sessions, the receiver-oriented protocols give the 386 chance to the receivers to manage their own resource allocation 387 requests and thus ease the task of the sources. 389 6.3 Router Load Factors 391 The router load expressing the utilization of the device naturally 392 affects the performance of the router. During the benchmarking 393 process several load conditions have to be examined. 395 This group of definitions describes different load components that 396 impact only a specific part of the resource reservation capable 397 router. 399 6.3.1 Best-Effort Traffic Load Factor 401 Definition: 402 The best-effort traffic load factor is defined as the volume of 403 the best-effort data traffic that traverses the router in a 404 second. 406 Discussion: 407 Forwarding the best-effort data packets, which requires obtaining 408 the routing information and transferring the data packet between 409 network interfaces, requires processing power, which is related to 410 this load factor. 412 Issues: 413 The same amount of data segmented into differently sized packets 414 causes different amounts of load on the router, which has to be 415 considered during the benchmarking measurements. 417 Measurement unit: 418 bits per second (bps) 420 6.3.2 Distinguished Traffic Load Factor 422 Definition: 423 The distinguished traffic load factor is defined as the volume of 424 the distinguished data traffic that traverses the router in a 425 second. 427 Discussion: 428 Similarly to the best-effort data, forwarding the distinguished 429 data packets requires obtaining the routing information and 430 transferring the data packet between network interfaces. However, 431 in this case packets have to be classified as well, which requires 432 additional processing capacity. 434 Issues: 435 Just as in the best-effort case, the same amount of data segmented 436 into differently sized packets causes different amounts of load on 437 the router, which has to be considered during the benchmarking 438 measurements. 440 Measurement unit: 441 bits per second (bps) 443 6.3.3 Session Load Factor 445 Definition: 446 The session load factor is the number of QoS sessions the router 447 is keeping track of. 449 Discussion: 450 Resource reservation capable routers maintain reservation states 451 keeping track of the QoS sessions. Obviously, the more reservation 452 states are registered with the router, the more complex the 453 traffic classification becomes, and the longer time it takes to 454 look up the corresponding resource reservation sate. Moreover, not 455 only the traffic flows, but also the signaling messages that 456 control the reservation states have to be identified first, before 457 taking any other action, and this kind of classification also 458 means extra work for the router. 460 In the case of soft-state resource reservation protocols, the 461 session load also affects reservation state maintenance. For 462 example, the supervision of timers that watchdog the reservation 463 state refreshes may cause further load on the router. 465 Measurement unit: 466 This factor is measured by the number of QoS sessions impacting 467 the router, thus it has no unit. 469 6.3.4 Signaling Intensity Load Factor 471 Definition: 472 The signaling intensity load factor is defined as the number of 473 signaling messages that hit the router during one second. 475 Discussion: 476 The processing of signaling messages requires processor power that 477 raises the load on the control plane of the router. 479 In routers where the control plane and the data plane are not 480 totally independent (e.g. certain parts of the tasks are served by 481 the same processor; or the architecture has common memory buffers, 482 transfer buses or any other resources) the signaling load can have 483 an impact on the router's packet forwarding performance as well. 485 Naturally, just as everywhere else in this document, the term 486 "signaling messages" refer only to the resource reservation 487 protocol related primitives. 489 Issues: 490 Most of the resource reservation protocols have several protocol 491 primitives realized by different signaling message types. Each of 492 these message types may require a different amount of processing 493 power from the router. This fact has to be considered during the 494 benchmarking measurements. 496 Measurement unit: 497 The unit of this factor is 1/second. 499 6.3.5 Signaling Burst Load Factor 501 Definition: 502 The signaling burst load factor is defined as the number of 503 signaling messages that arrive to one input port of the router 504 back-to-back ([2]), causing persistent load on the signaling 505 message handler. 507 Discussion: 508 The definition focuses on one input port only and does not 509 consider the traffic arriving at the other input ports. 510 As a consequence, a set of messages arriving at different ports, 511 but with such a timing that would be a burst if the messages 512 arrived at the same port, is not considered to be a burst. The 513 reason for this is that it is not guaranteed at a black-box test 514 that this would have the same effect on the router as a burst 515 (incoming at the same interface) has. 517 This definition conforms to the burst definition given in [3]. 519 Issues: 520 Most of the resource reservation protocols have several protocol 521 primitives realized by different signaling message types. Bursts 522 built up of different messages may have a different effect on the 523 router. Consequently, during measurements the content of the burst 524 has to be considered as well. 526 Measurement unit: 527 This load factor is measured by the number of messages in the 528 burst, thus it has no unit. 530 6.4 Performance Metrics 532 This group of definitions is a collection of measurable quantities 533 that describe the impact the different load components have on the 534 router. 536 6.4.1 Signaling Message Handling Time 538 Definition: 539 The signaling message handling time (or, in short, signal handling 540 time) is the latency ([2]) of a signaling message passing through 541 the router. 543 Discussion: 544 The router interprets the signaling messages, acts based on their 545 content and usually forwards them in an unmodified or modified 546 form. Thus the message handling time is usually longer than the 547 forwarding time of data packets of the same size. 549 There might be signaling message primitives, however, that are 550 drained or generated by the router, like certain refresh messages. 551 In this case the signal handling time is immeasurable, therefore 552 it is not defined for such messages. 554 In the case of signaling messages that carry information 555 pertaining to multicast flows, the router might issue multiple 556 signaling messages after processing them. In this case, by 557 definition, the signal handling time is the latency between the 558 incoming signaling message and the last outgoing signaling message 559 related to the received one. 561 The signal handling time is an important characteristic as it 562 directly affects the setup time of a QoS session. 564 Issues: 565 The signal handling time may be dependent on the type of the 566 signaling message. For example, it usually takes a shorter time 567 for the router to remove a reservation state than to set it up. 568 This fact has to be considered during the benchmarking process. 570 Measurement unit: 571 The unit of the signaling message handling time is the second. 573 6.4.2 Distinguished Traffic Delay 575 Definition: 576 Distinguished traffic delay is the latency ([2]) of a 577 distinguished data packet passing through the tested router 578 device. 580 Discussion: 581 Distinguished traffic packets must be classified first in order to 582 assign the network resources dedicated to the flow. The time of 583 the classification is added to the usual forwarding time 584 (including the queuing) that a router would spend on the packet 585 without any resource reservation capability. This classification 586 procedure might be quite time consuming in routers with vast 587 amounts of reservation states. 589 There are routers where the processing power is shared between the 590 control plane and the data plane. This means that the processing 591 of signaling messages may have an impact on the data forwarding 592 performance of the router. In this case the distinguished traffic 593 delay metric also indicates the influence the two planes have on 594 each other. 596 Issues: 597 Queuing of the incoming data packets in routers can bias this 598 metric, so the measurement procedures have to consider this 599 effect. 601 Measurement unit: 602 The unit of the distinguished traffic delay is the second. 604 6.4.3 Best-effort Traffic Delay 606 Definition: 607 Best-effort traffic delay is the latency of a best-effort data 608 packet traversing the tested router device. 610 Discussion: 611 If the processing power of the router is shared between the 612 control and data plane, then the processing of signaling messages 613 may have an impact on the data forwarding performance of the 614 router. In this case the best-effort traffic delay metric is an 615 indicator of the influence the two planes have on each other. 617 Issues: 618 Queuing of the incoming data packets in routers can bias this 619 metric as well, so measurement procedures have to consider this 620 effect. 622 Measurement unit: 623 The unit of the best-effort traffic delay is the second. 625 6.4.4 Signaling Message Loss 627 Definition: 628 Signaling message loss is the ratio of the actual and the expected 629 number of signaling messages leaving a resource reservation 630 capable router, subtracted from one. 632 Discussion: 633 This definition gives the same value as the ratio of the lost and 634 the expected messages. The reason for choosing the given 635 definition is that the number of lost messages cannot be measured 636 directly. 638 There are certain types of signaling messages that are required to 639 be forwarded by reservation capable routers as soon as their 640 processing is finished. However, due to the high router load or 641 for other reasons, the forwarding or even the processing of these 642 signaling messages might be canceled. There are other kinds of 643 signaling messages, that should have been generated by the router, 644 without any corresponding incoming message. In case of high router 645 load, it is possible that such a message never leaves the router. 646 To characterize these situations we introduce the signaling 647 message loss metric expressing the ratio of the signaling messages 648 that actually have left the router and those ones that were 649 expected to leave the router. 651 Since the most frequent reason for signaling message loss is high 652 router load, this metric is suitable for sounding out the 653 scalability limits of resource reservation capable routers. 655 During the measurements one must be able to determine whether a 656 signaling message is still in the queues of the router or if it 657 has already been dropped. For this reason we define a signaling 658 message as lost if no forwarded signaling message is emitted 659 within a reasonably long time period. This period is defined along 660 with the benchmarking methodology. 662 Measurement unit: 663 This measure has no unit; it is expressed as a real number, which 664 is between zero and one, including the limits. 666 6.4.5 Session Maintenance Capacity 668 Definition: 669 The session maintenance capacity metric is used in the case of 670 soft-state resource reservation protocols only. It is defined as 671 the ratio of the number of QoS sessions actually maintained and 672 the number of QoS sessions that should have been maintained during 673 one refresh period. 675 Discussion: 676 For soft-state protocols maintaining a QoS session means 677 refreshing the reservation states associated with it. 679 When a soft-state resource reservation capable router is 680 overloaded, it may happen that the router is not able to refresh 681 all the registered reservation states, because it does not have 682 the time to run the state refresh task. In this case sooner or 683 later some QoS sessions will be lost even if the endpoints still 684 require their maintenance. 686 The session maintenance capacity sounds out the maximal number of 687 QoS sessions that the router is capable of maintaining. 689 Issues: 690 The actual process of session maintenance is protocol and 691 implementation dependent, so is the method to examine that a 692 session is maintained or not. 694 In the case of soft-state resource reservation protocols a router 695 that fails to maintain a QoS session may not emit refresh 696 signaling messages either. This has direct consequences on the 697 signaling message loss metric. 699 Measurement unit: 700 This measure has no unit; it is expressed as a real number, which 701 is between zero and one (including the limits). 703 6.5 Scalability Limit 705 Definition: 706 The scalability limit of the router is the critical load 707 condition, when the router is still in the steady state but the 708 smallest amount of additional load would drive it to the 709 overloaded state. 711 Discussion: 712 All existing routers have finite buffer memory and finite 713 processing power. In the steady state of the router, the buffer 714 memories are not fully utilized and the processing power is enough 715 to cope with all tasks running on the router. As the router load 716 increases the buffers are starting to fill up and/or the router 717 has to postpone more and more tasks. However, there is a certain 718 point where no more buffer memory is available, or a task cannot 719 be postponed any longer; thus the router is forced to drop a 720 packet or an activity. This is the overloaded state of the 721 resource reservation capable router, which can be recognized by 722 the fact that some kind of data (signaling or packet) or task 723 (e.g. QoS session maintenance) loss occurs. 725 7. Security Considerations 727 As this document only provides terminology and describes neither a 728 protocol nor an implementation or a procedure, there are no security 729 considerations associated with it. 731 8. Acknowledgements 733 We would like to thank the following individuals for their help in 734 the research and development work, which contributed to form this 735 document: Joakim Bergkvist and Norbert Vegh from Telia Research AB, 736 Sweden; Balazs Szabo, Gabor Kovacs and Peter Vary from the High Speed 737 Networks Laboratory, Budapest University of Technology and Economics, 738 Hungary. 740 9. References 742 [1] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) - 743 Version 1 Functional Specification", RFC 2205, September 1997. 745 [2] S. Bradner, "Benchmarking Terminology for Network 746 Interconnection Devices", RFC 1242, July 1991 748 [3] R. Mandeville, "Benchmarking Terminology for LAN Switching 749 Devices", RFC 2285, February 1998 751 [4] R. Hancock (ed.), et. al., "Next Steps in Signaling: Framework", 752 IETF draft: draft-ietf-nsis-fw-05.txt (work in progress), 753 October 2003 755 [5] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism 756 for the Internet", Computer Communication Review, on-line 757 version, volume 29, number 2, April 1999 759 [6] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 760 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 761 1995 763 [7] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated 764 Reservation in the Internet", Journal on High Speed Networks, 765 Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998 767 [8] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I. 768 Csel�nyi, M. Maliosz, "Boomerang : A Simple Protocol for 769 Resource Reservation in IP Networks", Vancouver, IEEE Real-Time 770 Technology and Applications Symposium, June 1999 772 [9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight 773 Resource Reservation for Unicast IP Traffic", International WS 774 on QoS'98, IWQoS'98, May 18-20, 1998 776 [10] J. Manner (ed.), X. Fu, Ping Pan, "Analysis of Existing Quality 777 of Service Signaling Protocols", IETF draft: draft-ietf-nsis- 778 signalling-analysis-03.txt (work in progress), October 2003 780 [11] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", 781 RFC 2210, September 1997 783 [12] F. Baker,C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of 784 RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001 786 Authors' Addresses 788 Gabor Feher 789 Budapest University of Technology and Economics 790 Department of Telecommunications and Mediainformatics 791 Magyar Tudosok krt. 2, H-1117, Budapest, Hungary 792 Phone: +36 1 463-1538 793 Email: Gabor.Feher@tmit.bme.hu 795 Krisztian Nemeth 796 Budapest University of Technology and Economics 797 Department of Telecommunications and Mediainformatics 798 Magyar Tudosok krt. 2, H-1117, Budapest, Hungary 799 Phone: +36 1 463-1565 800 Email: Krisztian.Nemeth@tmit.bme.hu 802 Andras Korn 803 Budapest University of Technology and Economics 804 Institute of Mathematics, Department of Analysis 805 Egry Jozsef u. 2, H-1111 Budapest, Hungary 806 Phone: +36 1 463-2475 807 Email: Korn@math.bme.hu 809 Istvan Cselenyi 810 TeliaSonera International Carrier 811 Vaci ut 22-24, H-1132 Budapest, Hungary 812 Phone: +36 1 412-2705 813 Email: Istvan.Cselenyi@teliasonera.com