draft-ietf-bmwg-benchres-term-04.txt   draft-ietf-bmwg-benchres-term-05.txt 
Benchmarking Working Group Gabor Feher, BUTE Benchmarking Working Group Gabor Feher, BUTE
INTERNET-DRAFT Krisztian Nemeth, BUTE INTERNET-DRAFT Krisztian Nemeth, BUTE
Expiration Date: August 2004 Andras Korn, BUTE Expiration Date: July 2005 Andras Korn, BUTE
Istvan Cselenyi, TeliaSonera Istvan Cselenyi, TeliaSonera
February 2004 January 2005
Benchmarking Terminology for Routers Supporting Resource Reservation Benchmarking Terminology for Routers Supporting Resource Reservation
<draft-ietf-bmwg-benchres-term-04.txt> <draft-ietf-bmwg-benchres-term-05.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with Status of this Memo
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft shadow directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This memo provides information for the Internet community. This memo By submitting this Internet-Draft, I certify that any applicable
does not specify an Internet standard of any kind. Distribution of patent or other IPR claims of which I am aware have been disclosed,
this memo is unlimited. or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
2. Table of contents
1. Status of this Memo.............................................1
2. Table of contents...............................................1
3. Abstract........................................................2
4. Introduction....................................................2
5. Existing definitions............................................3
6. Definition of Terms.............................................3
6.1 Traffic Flow Types..........................................3
6.1.1 Data Flow..............................................3
6.1.2 Distinguished Data Flow................................4
6.1.3 Best-Effort Data Flow..................................4
6.2 Resource Reservation Protocol Basics........................5
6.2.1 QoS Session............................................5
6.2.2 Resource Reservation Protocol..........................6
6.2.3 Resource Reservation Capable Router....................6
6.2.4 Reservation State......................................6
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 1] Table of contents
6.2.5 Resource Reservation Protocol Orientation..............7
6.3 Router Load Factors.........................................8
6.3.1 Best-Effort Traffic Load Factor........................8
6.3.2 Distinguished Traffic Load Factor......................9
6.3.3 Session Load Factor....................................9
6.3.4 Signaling Intensity Load Factor.......................10
6.3.5 Signaling Burst Load Factor...........................10
6.4 Performance Metrics........................................11
6.4.1 Signaling Message Handling Time.......................11
6.4.2 Distinguished Traffic Delay...........................12
6.4.3 Best-effort Traffic Delay.............................12
6.4.4 Signaling Message Loss................................13
6.4.5 Session Maintenance Capacity..........................13
6.5 Scalability Limit..........................................14
7. Security Considerations........................................15
8. Acknowledgements...............................................15
9. References.....................................................15
3. Abstract Abstract...........................................................2
1. Introduction....................................................3
2. Existing definitions............................................3
3. Definition of Terms.............................................4
3.1 Traffic Flow Types..........................................4
3.1.1 Data Flow..............................................4
3.1.2 Distinguished Data Flow................................4
3.1.3 Best-Effort Data Flow..................................5
3.2 Resource Reservation Protocol Basics........................5
3.2.1 QoS Session............................................5
3.2.2 Resource Reservation Protocol..........................6
3.2.3 Resource Reservation Capable Router....................7
3.2.4 Reservation State......................................7
3.2.5 Resource Reservation Protocol Orientation..............8
3.3 Router Load Factors.........................................9
3.3.1 Best-Effort Traffic Load Factor........................9
3.3.2 Distinguished Traffic Load Factor......................9
3.3.3 Session Load Factor...................................10
3.3.4 Signaling Intensity Load Factor.......................10
3.3.5 Signaling Burst Load Factor...........................11
3.4 Performance Metrics........................................11
3.4.1 Signaling Message Handling Time.......................11
3.4.2 Distinguished Traffic Delay...........................12
3.4.3 Best-effort Traffic Delay.............................13
3.4.4 Signaling Message Loss................................13
3.4.5 Session Maintenance Capacity..........................14
3.5 Scalability Limit..........................................15
4. Security Considerations........................................16
5. IANA Considerations............................................16
6. Acknowledgements...............................................16
7. References.....................................................16
7.1 Normative References.......................................16
7.2 Informative References.....................................16
Authors' Addresses................................................17
Disclaimer of Validity............................................17
Copyright Notice..................................................18
Disclaimer........................................................18
The purpose of this document is to define terminology specific to the Abstract
benchmarking of resource reservation signaling of IntServ IP routers. The purpose of this document is to define terminology specific to
These terms can be used in additional documents that define the benchmarking of resource reservation signaling of Integrated
benchmarking methodologies for routers that support resource Services IP routers. These terms can be used in additional documents
reservation or reporting formats for the benchmarking measurements. that define benchmarking methodologies for routers that support
resource reservation or reporting formats for the benchmarking
measurements.
4. Introduction 1. Introduction
Signaling based resource reservation (e.g. via RSVP [1]) is an Signaling based resource reservation (e.g. via RSVP [3]) is an
important part of the different QoS provisioning approaches. important part of the different QoS provisioning approaches.
Therefore network operators who are planning to deploy signaling Therefore network operators who are planning to deploy signaling
based resource reservation may want to scrutinize the scalability based resource reservation may want to scrutinize the scalability
limitations of reservation capable routers and the impact of limitations of reservation capable routers and the impact of
signaling on their data forwarding performance. signaling on their data forwarding performance.
An objective way of quantifying the scalability constraints of QoS An objective way of quantifying the scalability constraints of QoS
signaling is to perform measurements on routers that are capable of signaling is to perform measurements on routers that are capable of
resource reservation. This document defines terminology for a resource reservation. This document defines terminology for a
specific set of tests that vendors or network operators can carry out specific set of tests that vendors or network operators can carry
to measure and report the signaling performance characteristics of out to measure and report the signaling performance characteristics
router devices that support resource reservation protocols. The of router devices that support resource reservation protocols. The
results of these tests provide comparable data for different results of these tests provide comparable data for different
products, and thus support the decision process before purchase. products, and thus support the decision process before purchase.
Moreover, these measurements provide input characteristics for the Moreover, these measurements provide input characteristics for the
dimensioning of a network in which resources are provisioned dimensioning of a network in which resources are provisioned
dynamically by signaling. Finally, the tests are applicable for dynamically by signaling. Finally, the tests are applicable for
characterizing the impact of the resource reservation signaling on characterizing the impact of the resource reservation signaling on
the forwarding performance of the routers. the forwarding performance of the routers.
This benchmarking terminology document is based on the knowledge This benchmarking terminology document is based on the knowledge
gained by examination of (and experimentation with) different gained by examination of (and experimentation with) different
resource reservation protocols: the IETF standard RSVP [1] and resource reservation protocols: the IETF standard RSVP [3] and
several experimental ones, such as YESSIR [5], ST2+ [6], SDP [7], several experimental ones, such as YESSIR [5], ST2+ [6], SDP [7],
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 2]
Boomerang [8] and Ticket [9]. Some of these protocols are also Boomerang [8] and Ticket [9]. Some of these protocols are also
analyzed in an IETF NSIS working group draft [10]. Although at the analyzed in an IETF NSIS working group draft [10]. Although at the
moment the authors are only aware of resource reservation capable moment the authors are only aware of resource reservation capable
router products that interpret RSVP, this document defines terms that router products that interpret RSVP, this document defines terms
are valid in general and not restricted to any of the above listed that are valid in general and not restricted to any of the above
protocols. listed protocols.
In order to avoid any confusion we would like to emphasize that this In order to avoid any confusion we would like to emphasize that this
terminology considers only signaling protocols that provide IntServ terminology considers only signaling protocols that provide IntServ
resource reservation; the DiffServ world, for example, is out of our resource reservation; the DiffServ world, for example, is out of our
scope. scope.
5. Existing definitions 2. Existing definitions
RFC 1242 "Benchmarking Terminology for Network Interconnect RFC 1242 "Benchmarking Terminology for Network Interconnect
Devices" [2] and RFC 2285 "Benchmarking Terminology for LAN Switching Devices" [1] and RFC 2285 "Benchmarking Terminology for LAN
Devices" [3] contain discussions and definitions for a number of Switching Devices" [2] contain discussions and definitions for a
terms relevant to the benchmarking of signaling performance of number of terms relevant to the benchmarking of signaling
reservation capable routers and should be consulted before attempting performance of reservation capable routers and should be consulted
to make use of this document. before attempting to make use of this document.
Additionally, this document defines terminology in a way that is Additionally, this document defines terminology in a way that is
consistent with the terms used by Next Steps in Signaling working consistent with the terms used by Next Steps in Signaling working
group laid out in [4]. group laid out in [4].
For the sake of clarity and continuity this document adopts the For the sake of clarity and continuity this document adopts the
template for definitions set out in Section 2 of RFC 1242. template for definitions set out in Section 2 of RFC 1242.
Definitions are indexed and grouped together into different sections Definitions are indexed and grouped together into different sections
for ease of reference. for ease of reference.
6. Definition of Terms 3. Definition of Terms
6.1 Traffic Flow Types 3.1 Traffic Flow Types
This group of definitions describes traffic flow types forwarded by This group of definitions describes traffic flow types forwarded by
resource reservation capable routers. resource reservation capable routers.
6.1.1 Data Flow 3.1.1 Data Flow
Definition: Definition:
A data flow is a stream of data packets from one sender to one or A data flow is a stream of data packets from one sender to one or
more receivers, where each packet has a flow identifier unique to more receivers, where each packet has a flow identifier unique to
the flow. the flow.
Discussion: Discussion:
The flow identifier can be an arbitrary subset of the packet The flow identifier can be an arbitrary subset of the packet
header fields that uniquely distinguishes the flow from others. header fields that uniquely distinguishes the flow from others.
For example, the 5-tuple "source address; source port; destination For example, the 5-tuple "source address; source port; destination
address; destination port; protocol number" is commonly used for address; destination port; protocol number" is commonly used for
this purpose (where port number are applicable). For more comment this purpose (where port number are applicable). It is also
on flow identification refer to [4]. possible to take advantage of the Flow Label field of IPv6
packets. For more comment on flow identification refer to [4].
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 3]
The flow identification can be time- and/or resource-consuming, The flow identification can be time- and/or resource-consuming,
but this can sometimes be avoided as routers do not necessarily but this can sometimes be avoided as routers do not necessarily
have to classify each packet. Instead, packets that should be have to classify each packet. Instead, packets that should be
classified by routers can be marked with special flags that classified by routers can be marked with special flags that
routers understand. One existing marking approach is to use the routers understand. One existing marking approach is to use the
ToS field of the IP header. Naturally, unmarked packets are not Type of Service (IPv4)/Traffic Class (IPv6) field of the IP
classified by routers and this way valuable resources can be header. Naturally, unmarked packets are not classified by routers
saved. and this way valuable resources can be saved.
6.1.2 Distinguished Data Flow 3.1.2 Distinguished Data Flow
Definition: Definition:
Distinguished data flows are flows that resource reservation Distinguished data flows are flows that resource reservation
capable routers intentionally treat better or worse than capable routers intentionally treat better or worse than
"ordinary" data flows, according to a QoS agreement defined for "ordinary" data flows, according to a QoS agreement defined for
the distinguished flow. the distinguished flow.
Discussion: Discussion:
Packets of distinguished data flows are marked so that the routers Packets of distinguished data flows are marked so that the routers
that forward them know they require differentiated treatment. that forward them know they require differentiated treatment.
Routers classify these incoming packets and identify the data flow Routers classify these incoming packets and identify the data flow
they belong to. they belong to.
The most common usage of the distinguished data flow is to get The most common usage of the distinguished data flow is to get
higher priority treatment than that of best-effort data flows (see higher priority treatment than that of best-effort data flows (see
the next definition). In these cases, a distinguished data flow is the next definition). In these cases, a distinguished data flow is
sometimes referred to as a "premium data flow". Nevertheless sometimes referred to as a "premium data flow". Nevertheless
theoretically it is possible to require worse treatment than that theoretically it is possible to require worse treatment than that
of best-effort flows. of best-effort flows.
6.1.3 Best-Effort Data Flow 3.1.3 Best-Effort Data Flow
Definition: Definition:
Best-effort data flows are flows that are not treated in any Best-effort data flows are flows that are not treated in any
special manner by resource reservation capable routers; thus, special manner by resource reservation capable routers; thus,
their packets are served (forwarded) in some default way. their packets are served (forwarded) in some default way.
Discussion: Discussion:
"Best-effort" means that the router makes its best effort to "Best-effort" means that the router makes its best effort to
forward the data packet quickly and safely, but does not guarantee forward the data packet quickly and safely, but does not guarantee
anything (e.g. delay or loss probability). This type of traffic is anything (e.g. delay or loss probability). This type of traffic is
the most common in today's Internet. the most common in today's Internet.
The packets belonging to the best-effort data flows are not The packets belonging to the best-effort data flows are not
specially marked and thus they are not classified by the routers. specially marked and thus they are not classified by the routers.
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 4] 3.2 Resource Reservation Protocol Basics
6.2 Resource Reservation Protocol Basics
This group of definitions applies to signaling based resource This group of definitions applies to signaling based resource
reservation protocols implemented by IP router devices. reservation protocols implemented by IP router devices.
6.2.1 QoS Session 3.2.1 QoS Session
Definition: Definition:
A QoS session is an application layer concept, shared between a A QoS session is an application layer concept, shared between a
set of network nodes, that pertains to a specific set of data set of network nodes, that pertains to a specific set of data
flows. The information associated with the session includes the flows. The information associated with the session includes the
data required to identify the set of data flows in addition to a data required to identify the set of data flows in addition to a
specification of the QoS treatment they require. specification of the QoS treatment they require.
Discussion: Discussion:
A QoS session is an end-to-end relationship. Whenever end-nodes A QoS session is an end-to-end relationship. Whenever end-nodes
skipping to change at page 16, line ? skipping to change at page 6, line 35
forwarding the data flow of the group. Instead, a dedicated forwarding the data flow of the group. Instead, a dedicated
network resource in a router can be shared among many traffic network resource in a router can be shared among many traffic
sources from the same multicast group (c.f. multicast reservation sources from the same multicast group (c.f. multicast reservation
styles in the case of RSVP). styles in the case of RSVP).
Issues: Issues:
Even though QoS sessions are considered to be unique, resource Even though QoS sessions are considered to be unique, resource
reservation capable routers might aggregate them and allocate reservation capable routers might aggregate them and allocate
network resources to these aggregated sessions at once. The network resources to these aggregated sessions at once. The
aggregation can be based on similar data flow attributes (e.g. aggregation can be based on similar data flow attributes (e.g.
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 5]
similar destination addresses) or it can combine arbitrary similar destination addresses) or it can combine arbitrary
sessions as well. While reservation aggregation significantly sessions as well. While reservation aggregation significantly
lightens the signaling processing task of a resource reservation lightens the signaling processing task of a resource reservation
capable router, it also requires the administration of the capable router, it also requires the administration of the
aggregated QoS sessions and might also lead to the violation of aggregated QoS sessions and might also lead to the violation of
the quality guaranties referring to individual data flows within the quality guaranties referring to individual data flows within
an aggregation [12]. an aggregation [11].
6.2.2 Resource Reservation Protocol 3.2.2 Resource Reservation Protocol
Definition: Definition:
Resource reservation protocols define signaling messages and Resource reservation protocols define signaling messages and
message processing rules used to control resource allocation in message processing rules used to control resource allocation in
IntServ architectures. IntServ architectures.
Discussion: Discussion:
It is the signaling messages of a resource reservation protocol It is the signaling messages of a resource reservation protocol
that carry the information related to QoS sessions. This that carry the information related to QoS sessions. This
information includes a session identifier, the actual QoS information includes a session identifier, the actual QoS
skipping to change at page 16, line ? skipping to change at page 7, line 11
The message processing rules of the signaling protocols ensure The message processing rules of the signaling protocols ensure
that signaling messages reach all network nodes concerned. Some that signaling messages reach all network nodes concerned. Some
resource reservation protocols (e.g. RSVP) are only concerned with resource reservation protocols (e.g. RSVP) are only concerned with
this, i.e. carrying the QoS-related information to all the this, i.e. carrying the QoS-related information to all the
appropriate network nodes, without being aware of its content. appropriate network nodes, without being aware of its content.
This latter approach allows changing the way the QoS parameters This latter approach allows changing the way the QoS parameters
are described, and different kind of provisioning can be realized are described, and different kind of provisioning can be realized
without the need to change the protocol itself. without the need to change the protocol itself.
6.2.3 Resource Reservation Capable Router 3.2.3 Resource Reservation Capable Router
Definition: Definition:
A router is resource reservation capable (it supports resource A router is resource reservation capable (it supports resource
reservation) if it is able to interpret signaling messages of a reservation) if it is able to interpret signaling messages of a
resource reservation protocol, and based on these messages is able resource reservation protocol, and based on these messages is able
to adjust the management of its flow classifiers and network to adjust the management of its flow classifiers and network
resources so as to conform with the content of the messages. resources so as to conform with the content of the messages.
Discussion: Discussion:
Routers capture signaling messages and manipulate reservation Routers capture signaling messages and manipulate reservation
states and/or reserved network resources according to the content states and/or reserved network resources according to the content
of the messages. This ensures that the flows are treated as their of the messages. This ensures that the flows are treated as their
specified QoS requirements indicate. specified QoS requirements indicate.
6.2.4 Reservation State 3.2.4 Reservation State
Definition: Definition:
A reservation state is the set of entries in the routers memory A reservation state is the set of entries in the router's memory
that contain all relevant information about a given QoS session that contain all relevant information about a given QoS session
registered with the router. registered with the router.
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 6]
Discussion: Discussion:
States are needed because IntServ related resource reservation States are needed because IntServ related resource reservation
protocols require the routers to keep track of QoS session and protocols require the routers to keep track of QoS session and
data-flow-related metadata. The reservation state includes the data-flow-related metadata. The reservation state includes the
parameters of the QoS treatment; the description of how and where parameters of the QoS treatment; the description of how and where
to forward the incoming signaling messages; refresh timing to forward the incoming signaling messages; refresh timing
information; etc. information; etc.
Based on how reservation states are stored in a reservation Based on how reservation states are stored in a reservation
capable router, the routers can be categorized into two classes: capable router, the routers can be categorized into two classes:
skipping to change at page 16, line ? skipping to change at page 8, line 21
resource reservation protocols can be divided into two groups. resource reservation protocols can be divided into two groups.
First, there are protocols where it is the responsibility of the First, there are protocols where it is the responsibility of the
end-points or their proxies to initiate refresh messages. These end-points or their proxies to initiate refresh messages. These
messages are forwarded along the path of the data flow refreshing messages are forwarded along the path of the data flow refreshing
the corresponding reservation states in each router affected by the corresponding reservation states in each router affected by
the flow. Secondly, there are other protocols, where routers and the flow. Secondly, there are other protocols, where routers and
end-points have their own schedule for the reservation state end-points have their own schedule for the reservation state
refreshes and they signal these refreshes to the neighboring refreshes and they signal these refreshes to the neighboring
routers. routers.
6.2.5 Resource Reservation Protocol Orientation 3.2.5 Resource Reservation Protocol Orientation
Definition: Definition:
The orientation of a resource reservation protocol tells which end The orientation of a resource reservation protocol tells which end
of the protocol communication initiates the allocation of the of the protocol communication initiates the allocation of the
network resources. Thus, the protocol can be sender or receiver network resources. Thus, the protocol can be sender or receiver
initiated, depending on the location of the data flow source initiated, depending on the location of the data flow source
(sender) and destination (receiver) compared to the reservation (sender) and destination (receiver) compared to the reservation
initiator. initiator.
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 7]
Discussion: Discussion:
In the case of sender-initiated protocols the resource reservation In the case of sender-initiated protocols the resource reservation
propagates the same directions as of the data flow. Consequently, propagates the same directions as of the data flow. Consequently,
in the case of receiver-initiated protocols the signaling messages in the case of receiver-initiated protocols the signaling messages
reserving resources are forwarded backward on the path of the data reserving resources are forwarded backward on the path of the data
flow. Due to the asymmetric routing nature of the Internet, in flow. Due to the asymmetric routing nature of the Internet, in
this latter case, the path of the desired data flow should be this latter case, the path of the desired data flow should be
known before the reservation initiator would be able to send the known before the reservation initiator would be able to send the
resource allocation messages. For example in the case of RSVP, the resource allocation messages. For example in the case of RSVP, the
RSVP PATH message, traveling from the data flow sources towards RSVP PATH message, traveling from the data flow sources towards
skipping to change at page 16, line ? skipping to change at page 9, line 7
The location of the reservation initiator affects the basics of The location of the reservation initiator affects the basics of
the resource reservation protocols and therefore it is an the resource reservation protocols and therefore it is an
important design decision. In the case of multicast QoS sessions, important design decision. In the case of multicast QoS sessions,
the sender-oriented protocols require the traffic sources to the sender-oriented protocols require the traffic sources to
maintain a list of receivers and send their allocation messages maintain a list of receivers and send their allocation messages
considering the different requirements of the receivers. Using considering the different requirements of the receivers. Using
multicast QoS sessions, the receiver-oriented protocols give the multicast QoS sessions, the receiver-oriented protocols give the
chance to the receivers to manage their own resource allocation chance to the receivers to manage their own resource allocation
requests and thus ease the task of the sources. requests and thus ease the task of the sources.
6.3 Router Load Factors 3.3 Router Load Factors
The router load expressing the utilization of the device naturally The router load expressing the utilization of the device naturally
affects the performance of the router. During the benchmarking affects the performance of the router. During the benchmarking
process several load conditions have to be examined. process several load conditions have to be examined.
This group of definitions describes different load components that This group of definitions describes different load components that
impact only a specific part of the resource reservation capable impact only a specific part of the resource reservation capable
router. router.
6.3.1 Best-Effort Traffic Load Factor 3.3.1 Best-Effort Traffic Load Factor
Definition: Definition:
The best-effort traffic load factor is defined as the volume of The best-effort traffic load factor is defined as the volume of
the best-effort data traffic that traverses the router in a the best-effort data traffic that traverses the router in a
second. second.
Discussion: Discussion:
Forwarding the best-effort data packets, which requires obtaining Forwarding the best-effort data packets, which requires obtaining
the routing information and transferring the data packet between the routing information and transferring the data packet between
network interfaces, requires processing power, which is related to network interfaces, requires processing power, which is related to
this load factor. this load factor.
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 8]
Issues: Issues:
The same amount of data segmented into differently sized packets The same amount of data segmented into differently sized packets
causes different amounts of load on the router, which has to be causes different amounts of load on the router, which has to be
considered during the benchmarking measurements. considered during the benchmarking measurements.
Measurement unit: Measurement unit:
bits per second (bps) bits per second (bps)
6.3.2 Distinguished Traffic Load Factor 3.3.2 Distinguished Traffic Load Factor
Definition: Definition:
The distinguished traffic load factor is defined as the volume of The distinguished traffic load factor is defined as the volume of
the distinguished data traffic that traverses the router in a the distinguished data traffic that traverses the router in a
second. second.
Discussion: Discussion:
Similarly to the best-effort data, forwarding the distinguished Similarly to the best-effort data, forwarding the distinguished
data packets requires obtaining the routing information and data packets requires obtaining the routing information and
transferring the data packet between network interfaces. However, transferring the data packet between network interfaces. However,
skipping to change at page 16, line ? skipping to change at page 10, line 8
Issues: Issues:
Just as in the best-effort case, the same amount of data segmented Just as in the best-effort case, the same amount of data segmented
into differently sized packets causes different amounts of load on into differently sized packets causes different amounts of load on
the router, which has to be considered during the benchmarking the router, which has to be considered during the benchmarking
measurements. measurements.
Measurement unit: Measurement unit:
bits per second (bps) bits per second (bps)
6.3.3 Session Load Factor 3.3.3 Session Load Factor
Definition: Definition:
The session load factor is the number of QoS sessions the router The session load factor is the number of QoS sessions the router
is keeping track of. is keeping track of.
Discussion: Discussion:
Resource reservation capable routers maintain reservation states Resource reservation capable routers maintain reservation states
keeping track of the QoS sessions. Obviously, the more reservation keeping track of the QoS sessions. Obviously, the more reservation
states are registered with the router, the more complex the states are registered with the router, the more complex the
traffic classification becomes, and the longer time it takes to traffic classification becomes, and the longer time it takes to
skipping to change at page 16, line ? skipping to change at page 10, line 30
only the traffic flows, but also the signaling messages that only the traffic flows, but also the signaling messages that
control the reservation states have to be identified first, before control the reservation states have to be identified first, before
taking any other action, and this kind of classification also taking any other action, and this kind of classification also
means extra work for the router. means extra work for the router.
In the case of soft-state resource reservation protocols, the In the case of soft-state resource reservation protocols, the
session load also affects reservation state maintenance. For session load also affects reservation state maintenance. For
example, the supervision of timers that watchdog the reservation example, the supervision of timers that watchdog the reservation
state refreshes may cause further load on the router. state refreshes may cause further load on the router.
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 9]
Measurement unit: Measurement unit:
This factor is measured by the number of QoS sessions impacting This factor is measured by the number of QoS sessions impacting
the router, thus it has no unit. the router, thus it has no unit.
6.3.4 Signaling Intensity Load Factor 3.3.4 Signaling Intensity Load Factor
Definition: Definition:
The signaling intensity load factor is defined as the number of The signaling intensity load factor is defined as the number of
signaling messages that hit the router during one second. signaling messages that hit the router during one second.
Discussion: Discussion:
The processing of signaling messages requires processor power that The processing of signaling messages requires processor power that
raises the load on the control plane of the router. raises the load on the control plane of the router.
In routers where the control plane and the data plane are not In routers where the control plane and the data plane are not
skipping to change at page 16, line ? skipping to change at page 11, line 11
Issues: Issues:
Most of the resource reservation protocols have several protocol Most of the resource reservation protocols have several protocol
primitives realized by different signaling message types. Each of primitives realized by different signaling message types. Each of
these message types may require a different amount of processing these message types may require a different amount of processing
power from the router. This fact has to be considered during the power from the router. This fact has to be considered during the
benchmarking measurements. benchmarking measurements.
Measurement unit: Measurement unit:
The unit of this factor is 1/second. The unit of this factor is 1/second.
6.3.5 Signaling Burst Load Factor 3.3.5 Signaling Burst Load Factor
Definition: Definition:
The signaling burst load factor is defined as the number of The signaling burst load factor is defined as the number of
signaling messages that arrive to one input port of the router signaling messages that arrive to one input port of the router
back-to-back ([2]), causing persistent load on the signaling back-to-back ([1]), causing persistent load on the signaling
message handler. message handler.
Discussion: Discussion:
The definition focuses on one input port only and does not The definition focuses on one input port only and does not
consider the traffic arriving at the other input ports. consider the traffic arriving at the other input ports.
As a consequence, a set of messages arriving at different ports, As a consequence, a set of messages arriving at different ports,
but with such a timing that would be a burst if the messages but with such a timing that would be a burst if the messages
arrived at the same port, is not considered to be a burst. The arrived at the same port, is not considered to be a burst. The
reason for this is that it is not guaranteed at a black-box test reason for this is that it is not guaranteed at a black-box test
that this would have the same effect on the router as a burst that this would have the same effect on the router as a burst
(incoming at the same interface) has. (incoming at the same interface) has.
This definition conforms to the burst definition given in [3]. This definition conforms to the burst definition given in [2].
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 10]
Issues: Issues:
Most of the resource reservation protocols have several protocol Most of the resource reservation protocols have several protocol
primitives realized by different signaling message types. Bursts primitives realized by different signaling message types. Bursts
built up of different messages may have a different effect on the built up of different messages may have a different effect on the
router. Consequently, during measurements the content of the burst router. Consequently, during measurements the content of the burst
has to be considered as well. has to be considered as well.
Measurement unit: Measurement unit:
This load factor is measured by the number of messages in the This load factor is measured by the number of messages in the
burst, thus it has no unit. burst, thus it has no unit.
6.4 Performance Metrics 3.4 Performance Metrics
This group of definitions is a collection of measurable quantities This group of definitions is a collection of measurable quantities
that describe the impact the different load components have on the that describe the impact the different load components have on the
router. router.
6.4.1 Signaling Message Handling Time 3.4.1 Signaling Message Handling Time
Definition: Definition:
The signaling message handling time (or, in short, signal handling The signaling message handling time (or, in short, signal handling
time) is the latency ([2]) of a signaling message passing through time) is the latency ([1]) of a signaling message passing through
the router. the router.
Discussion: Discussion:
The router interprets the signaling messages, acts based on their The router interprets the signaling messages, acts based on their
content and usually forwards them in an unmodified or modified content and usually forwards them in an unmodified or modified
form. Thus the message handling time is usually longer than the form. Thus the message handling time is usually longer than the
forwarding time of data packets of the same size. forwarding time of data packets of the same size.
There might be signaling message primitives, however, that are There might be signaling message primitives, however, that are
drained or generated by the router, like certain refresh messages. drained or generated by the router, like certain refresh messages.
skipping to change at page 16, line ? skipping to change at page 12, line 32
The signal handling time is an important characteristic as it The signal handling time is an important characteristic as it
directly affects the setup time of a QoS session. directly affects the setup time of a QoS session.
Issues: Issues:
The signal handling time may be dependent on the type of the The signal handling time may be dependent on the type of the
signaling message. For example, it usually takes a shorter time signaling message. For example, it usually takes a shorter time
for the router to remove a reservation state than to set it up. for the router to remove a reservation state than to set it up.
This fact has to be considered during the benchmarking process. This fact has to be considered during the benchmarking process.
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 11]
Measurement unit: Measurement unit:
The unit of the signaling message handling time is the second. The unit of the signaling message handling time is the second.
6.4.2 Distinguished Traffic Delay 3.4.2 Distinguished Traffic Delay
Definition: Definition:
Distinguished traffic delay is the latency ([2]) of a Distinguished traffic delay is the latency ([1]) of a
distinguished data packet passing through the tested router distinguished data packet passing through the tested router
device. device.
Discussion: Discussion:
Distinguished traffic packets must be classified first in order to Distinguished traffic packets must be classified first in order to
assign the network resources dedicated to the flow. The time of assign the network resources dedicated to the flow. The time of
the classification is added to the usual forwarding time the classification is added to the usual forwarding time
(including the queuing) that a router would spend on the packet (including the queuing) that a router would spend on the packet
without any resource reservation capability. This classification without any resource reservation capability. This classification
procedure might be quite time consuming in routers with vast procedure might be quite time consuming in routers with vast
skipping to change at page 16, line ? skipping to change at page 13, line 13
each other. each other.
Issues: Issues:
Queuing of the incoming data packets in routers can bias this Queuing of the incoming data packets in routers can bias this
metric, so the measurement procedures have to consider this metric, so the measurement procedures have to consider this
effect. effect.
Measurement unit: Measurement unit:
The unit of the distinguished traffic delay is the second. The unit of the distinguished traffic delay is the second.
6.4.3 Best-effort Traffic Delay 3.4.3 Best-effort Traffic Delay
Definition: Definition:
Best-effort traffic delay is the latency of a best-effort data Best-effort traffic delay is the latency of a best-effort data
packet traversing the tested router device. packet traversing the tested router device.
Discussion: Discussion:
If the processing power of the router is shared between the If the processing power of the router is shared between the
control and data plane, then the processing of signaling messages control and data plane, then the processing of signaling messages
may have an impact on the data forwarding performance of the may have an impact on the data forwarding performance of the
router. In this case the best-effort traffic delay metric is an router. In this case the best-effort traffic delay metric is an
indicator of the influence the two planes have on each other. indicator of the influence the two planes have on each other.
Issues: Issues:
Queuing of the incoming data packets in routers can bias this Queuing of the incoming data packets in routers can bias this
metric as well, so measurement procedures have to consider this metric as well, so measurement procedures have to consider this
effect. effect.
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 12]
Measurement unit: Measurement unit:
The unit of the best-effort traffic delay is the second. The unit of the best-effort traffic delay is the second.
6.4.4 Signaling Message Loss 3.4.4 Signaling Message Loss
Definition: Definition:
Signaling message loss is the ratio of the actual and the expected Signaling message loss is the ratio of the actual and the expected
number of signaling messages leaving a resource reservation number of signaling messages leaving a resource reservation
capable router, subtracted from one. capable router, subtracted from one.
Discussion: Discussion:
This definition gives the same value as the ratio of the lost and This definition gives the same value as the ratio of the lost and
the expected messages. The reason for choosing the given the expected messages. The reason for choosing the given
definition is that the number of lost messages cannot be measured definition is that the number of lost messages cannot be measured
skipping to change at page 16, line ? skipping to change at page 14, line 22
signaling message is still in the queues of the router or if it signaling message is still in the queues of the router or if it
has already been dropped. For this reason we define a signaling has already been dropped. For this reason we define a signaling
message as lost if no forwarded signaling message is emitted message as lost if no forwarded signaling message is emitted
within a reasonably long time period. This period is defined along within a reasonably long time period. This period is defined along
with the benchmarking methodology. with the benchmarking methodology.
Measurement unit: Measurement unit:
This measure has no unit; it is expressed as a real number, which This measure has no unit; it is expressed as a real number, which
is between zero and one, including the limits. is between zero and one, including the limits.
6.4.5 Session Maintenance Capacity 3.4.5 Session Maintenance Capacity
Definition: Definition:
The session maintenance capacity metric is used in the case of The session maintenance capacity metric is used in the case of
soft-state resource reservation protocols only. It is defined as soft-state resource reservation protocols only. It is defined as
the ratio of the number of QoS sessions actually maintained and the ratio of the number of QoS sessions actually maintained and
the number of QoS sessions that should have been maintained during the number of QoS sessions that should have been maintained during
one refresh period. one refresh period.
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 13]
Discussion: Discussion:
For soft-state protocols maintaining a QoS session means For soft-state protocols maintaining a QoS session means
refreshing the reservation states associated with it. refreshing the reservation states associated with it.
When a soft-state resource reservation capable router is When a soft-state resource reservation capable router is
overloaded, it may happen that the router is not able to refresh overloaded, it may happen that the router is not able to refresh
all the registered reservation states, because it does not have all the registered reservation states, because it does not have
the time to run the state refresh task. In this case sooner or the time to run the state refresh task. In this case sooner or
later some QoS sessions will be lost even if the endpoints still later some QoS sessions will be lost even if the endpoints still
require their maintenance. require their maintenance.
skipping to change at page 16, line ? skipping to change at page 15, line 9
In the case of soft-state resource reservation protocols a router In the case of soft-state resource reservation protocols a router
that fails to maintain a QoS session may not emit refresh that fails to maintain a QoS session may not emit refresh
signaling messages either. This has direct consequences on the signaling messages either. This has direct consequences on the
signaling message loss metric. signaling message loss metric.
Measurement unit: Measurement unit:
This measure has no unit; it is expressed as a real number, which This measure has no unit; it is expressed as a real number, which
is between zero and one (including the limits). is between zero and one (including the limits).
6.5 Scalability Limit 3.5 Scalability Limit
Definition: Definition:
The scalability limit of the router is the critical load The scalability limit of the router is the critical load
condition, when the router is still in the steady state but the condition, when the router is still in the steady state but the
smallest amount of additional load would drive it to the smallest amount of additional load would drive it to the
overloaded state. overloaded state.
Discussion: Discussion:
All existing routers have finite buffer memory and finite All existing routers have finite buffer memory and finite
processing power. In the steady state of the router, the buffer processing power. In the steady state of the router, the buffer
skipping to change at page 16, line ? skipping to change at page 16, line 5
to cope with all tasks running on the router. As the router load to cope with all tasks running on the router. As the router load
increases the buffers are starting to fill up and/or the router increases the buffers are starting to fill up and/or the router
has to postpone more and more tasks. However, there is a certain has to postpone more and more tasks. However, there is a certain
point where no more buffer memory is available, or a task cannot point where no more buffer memory is available, or a task cannot
be postponed any longer; thus the router is forced to drop a be postponed any longer; thus the router is forced to drop a
packet or an activity. This is the overloaded state of the packet or an activity. This is the overloaded state of the
resource reservation capable router, which can be recognized by resource reservation capable router, which can be recognized by
the fact that some kind of data (signaling or packet) or task the fact that some kind of data (signaling or packet) or task
(e.g. QoS session maintenance) loss occurs. (e.g. QoS session maintenance) loss occurs.
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 14] 4. Security Considerations
7. Security Considerations
As this document only provides terminology and describes neither a As this document only provides terminology and describes neither a
protocol nor an implementation or a procedure, there are no security protocol nor an implementation or a procedure, there are no security
considerations associated with it. considerations associated with it.
8. Acknowledgements 5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgements
We would like to thank the following individuals for their help in We would like to thank the following individuals for their help in
the research and development work, which contributed to form this the research and development work, which contributed to form this
document: Joakim Bergkvist and Norbert Vegh from Telia Research AB, document: Joakim Bergkvist and Norbert Vegh from Telia Research AB,
Sweden; Balazs Szabo, Gabor Kovacs and Peter Vary from the High Speed Sweden; Balazs Szabo, Gabor Kovacs and Peter Vary from the High
Networks Laboratory, Budapest University of Technology and Economics, Speed Networks Laboratory, Budapest University of Technology and
Hungary. Economics, Hungary.
9. References 7. References
[1] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) - 7.1 Normative References
Version 1 Functional Specification", RFC 2205, September 1997.
[2] S. Bradner, "Benchmarking Terminology for Network [1] S. Bradner, "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991 Interconnection Devices", RFC 1242, July 1991
[3] R. Mandeville, "Benchmarking Terminology for LAN Switching [2] R. Mandeville, "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998 Devices", RFC 2285, February 1998
[4] R. Hancock (ed.), et. al., "Next Steps in Signaling: Framework", 7.2 Informative References
IETF draft: draft-ietf-nsis-fw-05.txt (work in progress),
October 2003 [3] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP)
- Version 1 Functional Specification", RFC 2205, September
1997.
[4] R. Hancock, et al., "Next Steps in Signaling: Framework"
(draft-ietf-nsis-fw-07.txt) (Internet draft: work in progress),
November 2004
[5] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism [5] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism
for the Internet", Computer Communication Review, on-line for the Internet", Computer Communication Review, on-line
version, volume 29, number 2, April 1999 version, volume 29, number 2, April 1999
[6] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 [6] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2
(ST2) Protocol Specification - Version ST2+", RFC 1819, August (ST2) Protocol Specification - Version ST2+", RFC 1819, August
1995 1995
[7] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated [7] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated
skipping to change at page 16, line ? skipping to change at page 17, line 4
for the Internet", Computer Communication Review, on-line for the Internet", Computer Communication Review, on-line
version, volume 29, number 2, April 1999 version, volume 29, number 2, April 1999
[6] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 [6] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2
(ST2) Protocol Specification - Version ST2+", RFC 1819, August (ST2) Protocol Specification - Version ST2+", RFC 1819, August
1995 1995
[7] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated [7] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated
Reservation in the Internet", Journal on High Speed Networks, Reservation in the Internet", Journal on High Speed Networks,
Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998 Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998
[8] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I. [8] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I.
Cselnyi, M. Maliosz, "Boomerang : A Simple Protocol for Cselenyi, M. Maliosz, "Boomerang : A Simple Protocol for
Resource Reservation in IP Networks", Vancouver, IEEE Real-Time Resource Reservation in IP Networks", Vancouver, IEEE Real-Time
Technology and Applications Symposium, June 1999 Technology and Applications Symposium, June 1999
[9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight [9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight
Resource Reservation for Unicast IP Traffic", International WS Resource Reservation for Unicast IP Traffic", International WS
on QoS'98, IWQoS'98, May 18-20, 1998 on QoS'98, IWQoS'98, May 18-20, 1998
Feher, Nemeth, Korn, Cselenyi Expires August 2004 [Page 15] [10] J. Manner, X. Fu, "Analysis of Existing Quality of Service
[10] J. Manner (ed.), X. Fu, Ping Pan, "Analysis of Existing Quality Signaling Protocols" (draft-ietf-nsis-signalling-analysis-
of Service Signaling Protocols", IETF draft: draft-ietf-nsis- 05.txt) (Internet draft: work in progress), December 2004
signalling-analysis-03.txt (work in progress), October 2003
[11] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997
[12] F. Baker,C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of [11] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation
RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001 of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September
2001
Authors' Addresses Authors' Addresses
Gabor Feher Gabor Feher
Budapest University of Technology and Economics Budapest University of Technology and Economics
Department of Telecommunications and Mediainformatics Department of Telecommunications and Mediainformatics
Magyar Tudosok krt. 2, H-1117, Budapest, Hungary Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
Phone: +36 1 463-1538 Phone: +36 1 463-1538
Email: Gabor.Feher@tmit.bme.hu Email: Gabor.Feher@tmit.bme.hu
skipping to change at line 833 skipping to change at page 17, line 49
Institute of Mathematics, Department of Analysis Institute of Mathematics, Department of Analysis
Egry Jozsef u. 2, H-1111 Budapest, Hungary Egry Jozsef u. 2, H-1111 Budapest, Hungary
Phone: +36 1 463-2475 Phone: +36 1 463-2475
Email: Korn@math.bme.hu Email: Korn@math.bme.hu
Istvan Cselenyi Istvan Cselenyi
TeliaSonera International Carrier TeliaSonera International Carrier
Vaci ut 22-24, H-1132 Budapest, Hungary Vaci ut 22-24, H-1132 Budapest, Hungary
Phone: +36 1 412-2705 Phone: +36 1 412-2705
Email: Istvan.Cselenyi@teliasonera.com Email: Istvan.Cselenyi@teliasonera.com
Disclaimer of Validity
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 IETF's procedures with respect to
rights in IETF 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.
Copyright Notice
Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Disclaimer
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 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.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/