draft-ietf-bmwg-benchres-term-06.txt   draft-ietf-bmwg-benchres-term-07.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: January 2006 Andras Korn, BUTE Expiration Date: August 2006 Andras Korn, BUTE
Istvan Cselenyi, TeliaSonera Istvan Cselenyi, TeliaSonera
July 2005 February 2006
Benchmarking Terminology for Resource Reservation Capable Routers Benchmarking Terminology for Resource Reservation Capable Routers
<draft-ietf-bmwg-benchres-term-06.txt> <draft-ietf-bmwg-benchres-term-07.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 45 skipping to change at page 1, line 46
Table of contents Table of contents
Abstract...........................................................2 Abstract...........................................................2
1. Introduction....................................................2 1. Introduction....................................................2
2. Existing definitions............................................3 2. Existing definitions............................................3
3. Definition of Terms.............................................3 3. Definition of Terms.............................................3
3.1 Traffic Flow Types..........................................3 3.1 Traffic Flow Types..........................................3
3.1.1 Data Flow..............................................3 3.1.1 Data Flow..............................................3
3.1.2 Distinguished Data Flow................................4 3.1.2 Distinguished Data Flow................................4
3.1.3 Best-Effort Data Flow..................................4 3.1.3 Best-Effort Data Flow..................................4
3.2 Resource Reservation Protocol Basics........................5 3.2 Resource Reservation Protocol Basics........................4
3.2.1 QoS Session............................................5 3.2.1 QoS Session............................................5
3.2.2 Resource Reservation Protocol..........................6 3.2.2 Resource Reservation Protocol..........................6
3.2.3 Resource Reservation Capable Router....................6 3.2.3 Resource Reservation Capable Router....................6
3.2.4 Reservation State......................................6 3.2.4 Reservation State......................................6
3.2.5 Resource Reservation Protocol Orientation..............7 3.2.5 Resource Reservation Protocol Orientation..............7
3.3 Router Load Factors.........................................9 3.3 Router Load Factors.........................................8
3.3.1 Best-Effort Traffic Load Factor........................9 3.3.1 Best-Effort Traffic Load Factor........................9
3.3.2 Distinguished Traffic Load Factor.....................10 3.3.2 Distinguished Traffic Load Factor......................9
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 1]
3.3.3 Session Load Factor...................................10 3.3.3 Session Load Factor...................................10
3.3.4 Signaling Intensity Load Factor.......................11 3.3.4 Signaling Intensity Load Factor.......................10
3.3.5 Signaling Burst Load Factor...........................11 3.3.5 Signaling Burst Load Factor...........................11
3.4 Performance Metrics........................................12 3.4 Performance Metrics........................................12
3.4.1 Signaling Message Handling Time.......................12 3.4.1 Signaling Message Handling Time.......................12
3.4.2 Distinguished Traffic Delay...........................13 3.4.2 Distinguished Traffic Delay...........................13
3.4.3 Best-effort Traffic Delay.............................14 3.4.3 Best-effort Traffic Delay.............................13
3.4.4 Signaling Message Deficit.............................14 3.4.4 Signaling Message Deficit.............................14
3.4.5 Session Maintenance Capacity..........................15 3.4.5 Session Maintenance Capacity..........................15
3.5 Router Load Conditions and Scalability Limit...............16 3.5 Router Load Conditions and Scalability Limit...............15
3.5.1 Loss-Free Condition...................................16 3.5.1 Loss-Free Condition...................................15
3.5.2 Lossy Condition.......................................17 3.5.2 Lossy Condition.......................................16
3.5.3 Scalability Limit.....................................17 3.5.3 Scalability Limit.....................................17
4. Security Considerations........................................19 4. Security Considerations........................................17
5. IANA Considerations............................................19 5. IANA Considerations............................................17
6. Acknowledgements...............................................19 6. Acknowledgements...............................................18
7. References.....................................................19 7. References.....................................................18
7.1 Normative References.......................................19 7.1 Normative References.......................................18
7.2 Informative References.....................................19 7.2 Informative References.....................................18
Authors' Addresses................................................20 Authors' Addresses................................................19
Disclaimer of Validity............................................20 Disclaimer of Validity............................................19
Copyright Notice..................................................21 Copyright Notice..................................................20
Disclaimer........................................................21 Disclaimer........................................................20
Abstract Abstract
The primary purpose of this document is to define terminology The primary purpose of this document is to define terminology
specific to the benchmarking of resource reservation signaling of specific to the benchmarking of resource reservation signaling of
Integrated Services IP routers. These terms can be used in Integrated Services IP routers. These terms can be used in
additional documents that define benchmarking methodologies for additional documents that define benchmarking methodologies for
routers that support resource reservation or reporting formats for routers that support resource reservation or reporting formats for
the benchmarking measurements. the benchmarking measurements.
skipping to change at line 109 skipping to change at page 3, line 4
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 specific set of tests that vendors or network operators can carry
out to measure and report the signaling performance characteristics out to measure and report the signaling performance characteristics
of 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-making process before products, and thus support the decision-making process before
purchase. Moreover, these measurements provide input characteristics purchase. Moreover, these measurements provide input characteristics
for the dimensioning of a network in which resources are provisioned for the 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
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 2]
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 [3] 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],
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
skipping to change at line 162 skipping to change at page 4, line 5
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.
3.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.
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 3]
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 numbers are applicable). It is also this purpose (where port numbers are applicable). It is also
possible to take advantage of the Flow Label field of IPv6 possible to take advantage of the Flow Label field of IPv6
packets. For more comment on flow identification refer to [4]. packets. For more comment on flow identification refer to [4].
3.1.2 Distinguished Data Flow 3.1.2 Distinguished Data Flow
skipping to change at line 209 skipping to change at page 4, line 51
"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.
Packets that belong to best-effort data flows need not be Packets that belong to best-effort data flows need not be
classified by the routers; that is, the routers don't need to find classified by the routers; that is, the routers don't need to find
a related reservation session in order to find out what treatment a related reservation session in order to find out what treatment
the packet is entitled to. the packet is entitled to.
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 4]
3.2 Resource Reservation Protocol Basics 3.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.
3.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
skipping to change at line 264 skipping to change at page 5, line 53
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.
similar destination addresses) or it can combine arbitrary similar destination addresses) or it can combine arbitrary
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 5]
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 [11]. an aggregation [11].
3.2.2 Resource Reservation Protocol 3.2.2 Resource Reservation Protocol
Definition: Definition:
skipping to change at line 318 skipping to change at page 6, line 52
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.
3.2.4 Reservation State 3.2.4 Reservation State
Definition: Definition:
A reservation state is the set of entries in the router's 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 January 2006 [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 line 371 skipping to change at page 7, line 51
3.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 January 2006 [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 line 401 skipping to change at page 8, line 27
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 is an important the resource reservation protocols and therefore is an important
aspect of characterization. Most importantly, in the case of aspect of characterization. Most importantly, in the case of
multicast QoS sessions, the sender-oriented protocols require the multicast QoS sessions, the sender-oriented protocols require the
traffic sources to maintain a list of receivers and send their traffic sources to maintain a list of receivers and send their
allocation messages considering the different requirements of the allocation messages considering the different requirements of the
receivers. Using multicast QoS sessions, the receiver-oriented receivers. Using multicast QoS sessions, the receiver-oriented
protocols enable the receivers to manage their own resource protocols enable the receivers to manage their own resource
allocation requests and thus ease the task of the sources. allocation requests and thus ease the task of the sources.
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 8]
3.3 Router Load Factors 3.3 Router Load Factors
When a router is under "load", it means that there are tasks its When a router is under "load", it means that there are tasks its
CPU(s) must attend to; and/or that its memory contains data it must CPU(s) must attend to; and/or that its memory contains data it must
keep track of; and/or that its interface buffers are utilized to keep track of; and/or that its interface buffers are utilized to
some extent; etc. Unfortunately, we cannot assume that the full some extent; etc. Unfortunately, we cannot assume that the full
internal state of a router can be monitored during a benchmark; internal state of a router can be monitored during a benchmark;
rather, we must consider the router to be a black box. rather, we must consider the router to be a black box.
We need to look at router "load" in a way that makes this "load" We need to look at router "load" in a way that makes this "load"
skipping to change at line 454 skipping to change at page 9, line 30
possible to specify traffic with varying packet sizes as a possible to specify traffic with varying packet sizes as a
superposition of multiple best-effort traffic flows as they are superposition of multiple best-effort traffic flows as they are
defined here. defined here.
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 benchmarking measurements. The measurement unit considered during benchmarking measurements. The measurement unit
of this load factor reflects this as well. of this load factor reflects this as well.
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 9]
Measurement unit: Measurement unit:
This load factor has a composite unit of [packets per second This load factor has a composite unit of [packets per second
(pps); bytes]. For example, [5 pps; 100 bytes] means five pieces (pps); bytes]. For example, [5 pps; 100 bytes] means five pieces
of one-hundred-byte packets per second. of one-hundred-byte packets per second.
3.3.2 Distinguished Traffic Load Factor 3.3.2 Distinguished Traffic Load Factor
Definition: Definition:
The distinguished traffic load factor is defined as the number and The distinguished traffic load factor is defined as the number and
length of the distinguished data packets that traverses the router length of the distinguished data packets that traverses the router
skipping to change at line 509 skipping to change at page 10, line 30
Resource reservation capable routers maintain reservation states Resource reservation capable routers maintain reservation states
to keep track of QoS sessions. Obviously, the more reservation to keep track of 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 more time it takes to look traffic classification becomes, and the more time it takes to look
up the corresponding resource reservation state. Moreover, not up the corresponding resource reservation state. Moreover, not
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.
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 10]
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.
This load factor utilizes the CPU(s), the main memory and the This load factor utilizes the CPU(s), the main memory and the
session management logic (e.g. content addressable memory), if session management logic (e.g. content addressable memory), if
any, of the resource reservation capable router. any, of the resource reservation capable router.
Measurement unit: Measurement unit:
skipping to change at line 562 skipping to change at page 11, line 29
The unit of this factor is signaling messages/second. The unit of this factor is signaling messages/second.
3.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 ([1]), causing persistent load on the signaling back-to-back ([1]), causing persistent load on the signaling
message handler. message handler.
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 11]
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 in a black-box test reason for this is that it is not guaranteed in 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.
skipping to change at line 615 skipping to change at page 12, line 31
The signaling message handling time (or, in short, signal handling The signaling message handling time (or, in short, signal handling
time) is the latency ([1], for store-and-forward devices) of a time) is the latency ([1], for store-and-forward devices) of a
signaling message passing through the router. signaling message passing through 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.
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 12]
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.
In this case the signal handling time is not necessarily In this case the signal handling time is not necessarily
measureable, therefore it is not defined for such messages. measureable, therefore it is not defined for such messages.
In the case of signaling messages that carry information In the case of signaling messages that carry information
pertaining to multicast flows, the router might issue multiple pertaining to multicast flows, the router might issue multiple
signaling messages after processing them. In this case, by signaling messages after processing them. In this case, by
definition, the signal handling time is the latency between the definition, the signal handling time is the latency between the
incoming signaling message and the last outgoing signaling message incoming signaling message and the last outgoing signaling message
skipping to change at line 670 skipping to change at page 13, line 31
procedure might be quite time consuming in routers with vast procedure might be quite time consuming in routers with vast
amounts of reservation states. amounts of reservation states.
There are routers where the processing power is shared between the There are routers where the processing power is shared between the
control plane and the data plane. This means that the processing control plane and the data plane. This means that the processing
of signaling messages may have an impact on the data forwarding of signaling messages may have an impact on the data forwarding
performance of the router. In this case the distinguished traffic performance of the router. In this case the distinguished traffic
delay metric also indicates the influence the two planes have on delay metric also indicates the influence the two planes have on
each other. each other.
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 13]
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.
3.4.3 Best-effort Traffic Delay 3.4.3 Best-effort Traffic Delay
skipping to change at line 724 skipping to change at page 14, line 32
capable routers are required to forward as soon as their capable routers are required to forward as soon as their
processing is finished. However, due to lack of resources or other processing is finished. However, due to lack of resources or other
reasons, the forwarding or even the processing of these signaling reasons, the forwarding or even the processing of these signaling
messages might not take place. messages might not take place.
Certain other kinds of signaling messages must be generated by the Certain other kinds of signaling messages must be generated by the
router in the absence of any corresponding incoming message. It is router in the absence of any corresponding incoming message. It is
possible that an overloaded router does not have the resources possible that an overloaded router does not have the resources
necessary to generate such a message. necessary to generate such a message.
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 14]
To characterize these situations we introduce the signaling To characterize these situations we introduce the signaling
message deficit metric that expresses the ratio of the signaling message deficit metric that expresses the ratio of the signaling
messages that have actually left the router and those ones that messages that have actually left the router and those ones that
were expected to leave the router. We subtract this ratio from one were expected to leave the router. We subtract this ratio from one
in order to obtain a loss-type metric instead of a "message in order to obtain a loss-type metric instead of a "message
survival metric". survival metric".
Since the most frequent reason for signaling message deficit is Since the most frequent reason for signaling message deficit is
high router load, this metric is suitable for sounding out the high router load, this metric is suitable for sounding out the
scalability limits of resource reservation capable routers. scalability limits of resource reservation capable routers.
skipping to change at line 777 skipping to change at page 15, line 35
The session maintenance capacity sounds out the maximal number of The session maintenance capacity sounds out the maximal number of
QoS sessions that the router is capable of maintaining. QoS sessions that the router is capable of maintaining.
Issues: Issues:
The actual process of session maintenance is protocol and The actual process of session maintenance is protocol and
implementation dependent, thus so is the method to examine whether implementation dependent, thus so is the method to examine whether
a session is maintained or not. a session is maintained or not.
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
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 15]
signaling messages either. This has direct consequences on the signaling messages either. This has direct consequences on the
signaling message deficit metric. signaling message deficit 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).
3.5 Router Load Conditions and Scalability Limit 3.5 Router Load Conditions and Scalability Limit
Depending mainly, but not exclusively, on the overall load of a Depending mainly, but not exclusively, on the overall load of a
skipping to change at line 831 skipping to change at page 16, line 36
specifications or in "reasonable time"; if it is not high load but specifications or in "reasonable time"; if it is not high load but
-- for example -- an implementation error that causes the device -- for example -- an implementation error that causes the device
to perform inadequately, it still cannot be said to be in a loss- to perform inadequately, it still cannot be said to be in a loss-
free state. The same applies to the random early dropping of free state. The same applies to the random early dropping of
packets in order to prevent congestion. In a black-box measurement packets in order to prevent congestion. In a black-box measurement
it is impossible to determine whether a packet was dropped as part it is impossible to determine whether a packet was dropped as part
of a congestion control mechanism or because the router was unable of a congestion control mechanism or because the router was unable
to forward it; therefore, if packet loss is observed, the router to forward it; therefore, if packet loss is observed, the router
is by definition in lossy state (lossy condition). is by definition in lossy state (lossy condition).
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 16]
Related definitions: Related definitions:
Lossy Condition Lossy Condition
Scalability Limit Scalability Limit
3.5.2 Lossy Condition 3.5.2 Lossy Condition
Definition: Definition:
A router is in lossy condition, or lossy state, if it cannot A router is in lossy condition, or lossy state, if it cannot
perform its duties adequately for some reason; that is, if it perform its duties adequately for some reason; that is, if it
doesn't meet protocol specifications, or -- if time-related doesn't meet protocol specifications, or -- if time-related
skipping to change at line 884 skipping to change at page 17, line 35
and more utilized. There is a certain point where the router and more utilized. There is a certain point where the router
leaves the loss-free state and enters the lossy state. Note that leaves the loss-free state and enters the lossy state. Note that
such a point may be impossible to reach in some cases (for such a point may be impossible to reach in some cases (for
example, the bandwidth of the physical medium prevents increasing example, the bandwidth of the physical medium prevents increasing
the traffic load any further). the traffic load any further).
A particular load condition can be identified by the corresponding A particular load condition can be identified by the corresponding
values of the load factors (as defined in 3.3 Router Load Factors) values of the load factors (as defined in 3.3 Router Load Factors)
impacting the router. These values can be represented as a 7-tuple impacting the router. These values can be represented as a 7-tuple
of numbers (5 is the number of load factors, but two of them have of numbers (5 is the number of load factors, but two of them have
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 17]
composite units and thus require two numbers each to express). We composite units and thus require two numbers each to express). We
can think of these tuples as vectors that correspond either to can think of these tuples as vectors that correspond either to
loss-free state or to lossy state. The scalability limit of the loss-free state or to lossy state. The scalability limit of the
router is, then, the boundary between the sets of vectors router is, then, the boundary between the sets of vectors
corresponding to loss-free and lossy states. Finding these corresponding to loss-free and lossy states. Finding these
boundary points if one of the objectives of benchmarking. boundary points if one of the objectives of benchmarking.
Related definitions: Related definitions:
Loss-Free Condition Loss-Free Condition
Lossy Condition Lossy Condition
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 18]
4. Security Considerations 4. 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.
5. IANA Considerations 5. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
skipping to change at line 950 skipping to change at page 18, line 46
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
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 19]
[8] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I. [8] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I.
Cselenyi, 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
[10] J. Manner, X. Fu, "Analysis of Existing Quality of Service [10] J. Manner, X. Fu, "Analysis of Existing Quality of Service
skipping to change at line 1004 skipping to change at page 19, line 45
Email: Istvan.Cselenyi@teliasonera.com Email: Istvan.Cselenyi@teliasonera.com
Disclaimer of Validity Disclaimer of Validity
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 20]
such rights. Information on the procedures with respect to such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79. rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). This document is Copyright (C) The Internet Society (2006).
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their This document is subject to the rights, licenses and restrictions
rights. contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Disclaimer Disclaimer
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
Feher, Nemeth, Korn, Cselenyi Expires January 2006 [Page 21]
 End of changes. 31 change blocks. 
54 lines changed or deleted 26 lines changed or added

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