draft-ietf-dime-overload-reqs-04.txt   draft-ietf-dime-overload-reqs-05.txt 
Network Working Group E. McMurry Network Working Group E. McMurry
Internet-Draft B. Campbell Internet-Draft B. Campbell
Intended status: Standards Track Tekelec Intended status: Standards Track Tekelec
Expires: August 26, 2013 February 22, 2013 Expires: August 29, 2013 February 25, 2013
Diameter Overload Control Requirements Diameter Overload Control Requirements
draft-ietf-dime-overload-reqs-04 draft-ietf-dime-overload-reqs-05
Abstract Abstract
When a Diameter server or agent becomes overloaded, it needs to be When a Diameter server or agent becomes overloaded, it needs to be
able to gracefully reduce its load, typically by informing clients to able to gracefully reduce its load, typically by informing clients to
reduce sending traffic for some period of time. Otherwise, it must reduce sending traffic for some period of time. Otherwise, it must
continue to expend resources parsing and responding to Diameter continue to expend resources parsing and responding to Diameter
messages, possibly resulting in congestion collapse. The existing messages, possibly resulting in congestion collapse. The existing
Diameter mechanisms, listed in Section 3 are not sufficient for this Diameter mechanisms, listed in Section 3 are not sufficient for this
purpose. This document describes the limitations of the existing purpose. This document describes the limitations of the existing
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 19, line 49 skipping to change at page 19, line 49
example, it is better to allow peers to advertise or example, it is better to allow peers to advertise or
negotiate support for the mechanism, rather than to require negotiate support for the mechanism, rather than to require
this knowledge to be configured at each node. this knowledge to be configured at each node.
REQ 7: The overload control mechanism and any associated default REQ 7: The overload control mechanism and any associated default
algorithm(s) MUST ensure that the system remains stable. At algorithm(s) MUST ensure that the system remains stable. At
some point after an overload condition has ended, the some point after an overload condition has ended, the
mechanism MUST enable capacity to stabilize and become equal mechanism MUST enable capacity to stabilize and become equal
to what it would be in the absence of an overload condition. to what it would be in the absence of an overload condition.
Note that this also requires that the mechanism MUST allow Note that this also requires that the mechanism MUST allow
nodes to shed load without introducing oscillations during nodes to shed load without introducing non converging
or after an overload condition. oscillations during or after an overload condition.
REQ 8: Supporting nodes MUST be able to distinguish current REQ 8: Supporting nodes MUST be able to distinguish current
overload information from stale information, and SHOULD make overload information from stale information, and SHOULD make
decisions using the most currently available information. decisions using the most currently available information.
REQ 9: The mechanism MUST function across fully loaded as well as REQ 9: The mechanism MUST function across fully loaded as well as
quiescent transport connections. This is partially derived quiescent transport connections. This is partially derived
from the requirement for stability in REQ 7. from the requirement for stability in REQ 7.
REQ 10: Consumers of overload information MUST be able to determine REQ 10: Consumers of overload information MUST be able to determine
skipping to change at page 21, line 24 skipping to change at page 21, line 24
treating elements that do not support overload control in a treating elements that do not support overload control in a
equitable fashion relative to those that do. users and equitable fashion relative to those that do. users and
operators of nodes that do not support the mechanism MUST operators of nodes that do not support the mechanism MUST
NOT unfairly benefit from the mechanism. The mechanism NOT unfairly benefit from the mechanism. The mechanism
specification SHOULD provide guidance to implementors for specification SHOULD provide guidance to implementors for
dealing with elements not supporting overload control. dealing with elements not supporting overload control.
REQ 19: It MUST be possible to use the mechanism between nodes in REQ 19: It MUST be possible to use the mechanism between nodes in
different realms and in different administrative domains. different realms and in different administrative domains.
REQ 20: Any explicit overload indication MUST distinguish between REQ 20: Any explicit overload indication MUST be clearly
actual overload, as opposed to other, non-overload related distinguishable from other errors reported via Diameter.
failures.
REQ 21: In cases where a network node fails, is so overloaded that REQ 21: In cases where a network node fails, is so overloaded that
it cannot process messages, or cannot communicate due to a it cannot process messages, or cannot communicate due to a
network failure, it may not be able to provide explicit network failure, it may not be able to provide explicit
indications of the nature of the failure or its levels of indications of the nature of the failure or its levels of
congestion. The mechanism MUST result in at least as much congestion. The mechanism MUST result in at least as much
useful throughput as would have resulted if the overload useful throughput as would have resulted if the overload
control mechanism was not in place. control mechanism was not in place.
REQ 22: The mechanism MUST provide a way for an node to throttle the REQ 22: The mechanism MUST provide a way for an node to throttle the
 End of changes. 5 change blocks. 
8 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/