Internet DRAFT - draft-asveren-dime-cong
draft-asveren-dime-cong
Network Working Group T. Asveren
Internet-Draft Sonus Networks
Intended status: Informational V. Fajardo
Expires: January 16, 2009 Toshiba America Research Inc.
July 15, 2008
Diameter Congestion Signaling
draft-asveren-dime-cong-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2009.
Abstract
Diameter base protocol defines the network layer functionality to be
used by applications. This document adds hop-to-hop congestion
notification mechanism to that functionality.
Asveren & Fajardo Expires January 16, 2009 [Page 1]
Internet-Draft Diameter Congestion Signaling July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Congestion of Intermediaries . . . . . . . . . . . . . . . 4
3.2. Multiple Applications On the Same Node . . . . . . . . . . 4
3.3. Congestion Detection Time . . . . . . . . . . . . . . . . 4
3.4. Notification of Congestion Abatement . . . . . . . . . . . 5
3.5. Multiple Congestion Levels . . . . . . . . . . . . . . . . 5
3.6. Shortcomings of Transport Layer Congestion Indications . . 5
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Hop-To-Hop Congestion Notification Mechanism . . . . . . . . . 6
5.1. Congestion Level Signaling Procedures . . . . . . . . . . 6
5.1.1. Sending Congestion Information . . . . . . . . . . . . 6
5.1.2. Receiving Congestion Information . . . . . . . . . . . 7
5.1.3. Local Congestion Level Determination Guidelines . . . 7
5.1.4. Preventing Unnecessary Retransmission . . . . . . . . 8
5.2. Congestion-Level AVP . . . . . . . . . . . . . . . . . . . 9
5.3. Error Answers . . . . . . . . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Providing Hysteresis for Local Congestion Level
Decision . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Congestion Level Used For Loadsharing . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Asveren & Fajardo Expires January 16, 2009 [Page 2]
Internet-Draft Diameter Congestion Signaling July 2008
1. Introduction
Diameter base protocol defines the network layer functionality to be
used by applications. Requests are routed based on Destination-Host
AVP, Destination-Realm AVP, Application-Id values and the status of
Diameter connections to neighboring peers.
This document defines a new AVP to be used by peers to notify their
neighbors about their congestion status, so that this information can
be used while routing requests. It is left up to the implementation
to decide for local congestion levels but some guidelines are
provided to prevent undesirable situations like oscilliation.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The following terms defines the functionality used in describing
entities in this document.
Congestion
The situation on a Diameter node, where the current load is above
the normal operational limits and effects processing of messages.
A node which suffers from congestion should not be sent certain
messages depending on the severity of congestion to prevent it to
be overloaded further.
Congestion level
A numeric value used to quantify the severity of congestion on a
Diameter node. This value is generalized in this document and not
meant to be an exhaustive indicator of all possible variables that
can define congestion. The possible numeric values for congestion
level is defined in Section 5.2.
Congestion state
Congestion state pertains to the congestion level and other
relevant information that a Diameter node keeps about each of its
neighboring peers.
Asveren & Fajardo Expires January 16, 2009 [Page 3]
Internet-Draft Diameter Congestion Signaling July 2008
3. Motivation
When routing Diameter messages, it is preferable to consider the
congestion status of peers to increase the response time of answers
and to prevent overloading of nodes. A method of signaling the
congestion state among adjacent peers independent of any applications
will allow for a more real-time, self correcting method of reducing
and or distributing load among Diameter neighbors.
There are several scenarios where relying on an application level
result code is not efficient to notify peers about congestion status
changes. The succeeding sections provides applicability scenarios
for requiring per hop congestion status signaling.
3.1. Congestion of Intermediaries
In a Diameter network, intermediate nodes such as relay agents,
proxies, may be present. Such nodes may get congested and it is
desirable to consider their congestion status when selecting the next
hop node.
Intermediate nodes do not host the application logic to process a
request completely and do not generate answers except routing
failures for the requests they receive. Generating a result code of
"TOO_BUSY_HERE" to notify about intermediate congestion is not
appropriate because it indicates congestion of the server specified
in the Destination-Host AVP or in general the logical application
service identified by Destination-Realm AVP and Application-Id. It
is therefore limited to Diameter application end-points and does not
consider the congestion state of intermediaries and other application
traffic routed through them.
3.2. Multiple Applications On the Same Node
A Diameter node may host multiple applications simultaneously.
Although it is possible to aggregate congestion status of the node on
application logic level, it may be preferable to do this on a
centralized logical entity like the Diameter base protocol in a
layered architecture. A hop-to-hop message generated and consumed by
base protocol layer would be more suitable for such a task split
between different layers.
3.3. Congestion Detection Time
Relying on congestion notification via application level result code
is inherently a reactive mechanism. This requires that an
application level request needs to be received for congestion
notification to be sent on the answer.
Asveren & Fajardo Expires January 16, 2009 [Page 4]
Internet-Draft Diameter Congestion Signaling July 2008
This problem can be aggravated in configurations such as Diameter
servers which are communicating with multiple peers. A highly
congested server can signal its congestion state to other peers only
when those peers send a request to the server.
3.4. Notification of Congestion Abatement
Currently, there is no existing method of to signal end of
congestion. Peers may probe the congested node periodically with new
requests and can decide based on the result code of the corresponding
answer whether congestion has abated. However, such method is not
effective if peers have no application level request to send and
therefore suffers the same drawbacks as Section 3.3. A hop-to-hop
congestion indication message could provide notification of
congestion abatement immediately.
3.5. Multiple Congestion Levels
A congestion result code provides only a single congestion level of
"congested." For certain configurations it may be desirable to
provide multiple congestion levels. Especially for the cases where
load information is to be used for loadsharing purposes, multiple
levels are desirable.
3.6. Shortcomings of Transport Layer Congestion Indications
Diameter uses TCP and SCTP as transport protocols between adjacent
entities. Although the concept of receiver congestion is present in
those protocols there are some reasons, which make their use
unsuitable for Diameter congestion detection purposes:
o It is not straightforward to learn the current status of receiver
windows with sockets API, which is the defacto standard for
applications to access services of TCP and SCTP in common
operating systems. For TCP, applications can be aware of
congestion only when the receiver window is full. For SCTP,
application need to poll the status of receiver window, there is
no trigger mechanism present.
o Propogation of congestion may take longer than desired.
Congestion will be visible on sender side only after it propogated
to transport protocol layer, which may require multiple queues to
be filled first on receiver side.
o When congested node has multiple connections, the receiver window
for each connection needs to be full, i.e. if a node does not send
messages to the congested node, it won't be able to learn about
its congestion status or not before sending enough messages to
Asveren & Fajardo Expires January 16, 2009 [Page 5]
Internet-Draft Diameter Congestion Signaling July 2008
fill the receiver window.
4. Scope
This document defines mechanisms to communicate congestion
information in a hop-by-hop fashion. This information can be used to
protect overloaded nodes against further traffic being sent to them
and to loadshare requests among multiple endpoints. Although the
strategy mainly relies on hop-by-hop communication, it also defines
new result codes to be used in an end-to-end fashion to prevent
unnecessary request retransmission on base protocol level in case of
congested nodes/services.
5. Hop-To-Hop Congestion Notification Mechanism
5.1. Congestion Level Signaling Procedures
5.1.1. Sending Congestion Information
A Diameter node sends a Congestion-Level AVP in a Device Watchdog
Request message to its adjacent neighbors to indicate its current
congestion level.
A node's congestion level SHOULD fall into one of the congestion
levels defined in Section 5.2. A Diameter node SHOULD send a DWR to
its neighboring peers as soon as it determines that its congestion
level changes. Sending the DWR message with Congestion-Level AVP as
soon as congestion level changes is important so that adjacent nodes
can stop sending new requests to the congested node to prevent it to
get further overloaded.
In the case where a new peer attempts to connect to an existing node
supporting congestion control signaling, the Congestion-Level AVP
Section 5.2 may also be sent by the node in the CEA message to
immediately indicate to the new peer of the nodes congestion state.
This is in the case where the existing peer is already experiencing
high levels of congestion and would want to notify any new peer
immediately rather than sending a DWR which has an inherent latency.
When a node receives a request and the node already notified its
neighbors that it is unable to handle new requests, the node MAY
silently drop the request or MAY send back an error answer with
result code DIAMETER_CONGESTED.
Asveren & Fajardo Expires January 16, 2009 [Page 6]
Internet-Draft Diameter Congestion Signaling July 2008
5.1.2. Receiving Congestion Information
A peer receiving a Congestion-Level AVP in a DWR SHOULD create and
maintain congestion state for the sender of the DWR if it has not
already done so. The congestion state should at least contain the
currently advertised congestion state of the peer.
The receiver of the DWR should react according to the congestion
level information provided by the Congestion-Level AVP, i.e. it
SHOULD NOT send messages which are not allowed by the corresponding
congestion level.
It SHOULD be expected that Nodes MAY advertise congestion levels non-
sequentially, e.g. a node may first advertise CONGESTION_LEVEL_1 and
then CONGESTION_LEVEL_3.
In the case where a peer does not support congestion level based
request routing, it SHOULD ignore the presence of Congestion-Level
AVP in DWR, CER and CEA messages. Considering that M-bit is not set
for Congestion-Level AVP, this behavior is guaranteed by nodes
compliant to Diameter Base Protocol.
5.1.3. Local Congestion Level Determination Guidelines
Considering the vast amount of criteria which may be used as metrics
when determining congestion levels and different architectures, this
document does not mandate a mechanism to decide for different
congestion levels.
For sender of the Congestion-Level AVP, it is left up to the
implementation on determining the current congestion level of a
Diameter node. The implementation may rely on the traffic rate,
processing load, backend call latency, storage/resource availability
etc. or any such combinations to determine the appropriate congestion
level. Deciding when congestion level changes on a node is also
implementation dependent but nodes SHOULD provide hysteresis between
onset and abatement values of the congestion levels. Note that
schemes to determine congestion level changes should not be very
sensitive so as not to trigger sending many DWR message causing
congestion control flapping among neighboring peers.
It is recommended that triggering of onset and abatement levels
should be deterministic. It should be noted that nodes MAY also
choose to use only a subset of the defined congestion level values,
e.g. a node MAY use only CONGESTION_LEVEL_0 and CONGESTION_LEVEL_3
values to indicate a binary state of congested or not congested.
Diameter nodes SHOULD NOT send DWR messages with Congestion-Level AVP
Asveren & Fajardo Expires January 16, 2009 [Page 7]
Internet-Draft Diameter Congestion Signaling July 2008
very frequently, for example more than once a second. Frequent DWR
transmissions has the adverse side effect of triggering false
disconnection indication if the receiver is highly congested and
cannot send a DWA within the appropriate time. In the case that a
disconnection indication does occur due to failed DWR/DWA exchanges
even if the DWR transmissions are set to an acceptable frequency,
then the peers should follow the normal disconnection process
specified in RFC3588.
It is RECOMMENDED that nodes change their congestion state and notify
their neighbors before congestion gets severe enough to cause
significant problems for the processing of pending and on the flight
requests.
5.1.4. Preventing Unnecessary Retransmission
If an adjacent node to an endpoint, e.g. a relay agent or a proxy, is
notified that the endpoint is unable to handle new requests, there is
no need that the same request is retransmited via an alternate route
as shown in Figure 1. In such a situation, the adjacent node SHOULD
reply back with an error answer with result code
DIAMETER_ENDPOINT_CONGESTED. The Origin-Host AVP MUST be populated
with the identity of the congested endpoint and Error-Reporting-Host
AVP MUST contain the identity of the error reporting host.
(3)----REQ1----->
(4)<-ANS1(UNABLE)-
TO DELIVER)
+--------+(1) <--DWR(Level2)-
| |
+--------+ +-------+ Relay +-----+
| +--+ | Agent 1| | +--------+
| Client | +--------+ | | |
| +--+ +--------+ +-----+ Server |
+--------+ | | | +-----+ |
+-------+ Relay | | +--------+
| Agent 2+-----+
(5)----REQ1-----> +--------+(2) <--DWR(Level2)-
(6)<-ANS1(UNABLE)-
TO DELIVER)
Figure 1: Unnecessary message retransmission during congestion
Similarly if a node adjacent to all endpoints providing service for a
specific application in a realm has received congestion level updates
from all of them indicating that they are unable to handle new
Asveren & Fajardo Expires January 16, 2009 [Page 8]
Internet-Draft Diameter Congestion Signaling July 2008
requests, the node SHOULD reply back with an
DIAMETER_SERVICE_CONGESTED error answer, if it receives a request
without Destination-Host AVP. The Origin-Host AVP MUST be populated
with the identity of the error reporting host. It should be noted
that nodes should generate this error answer if and only if they are
sure that they have a connection to all of the endpoints providing
the service for the corresponding realm. Otherwise an error answer
with result code "UNABLE_TO_DELIVER" SHOULD be returned.
5.2. Congestion-Level AVP
Congestion-Level AVP is of type Enumerated and indicates the
congestion level of a node. The following values are defined for
Congestion-Level AVP:
CONGESTION_LEVEL_0 0
This value indicates that the load on the sender node is below the
manageable limit and the node is ready to handle new messages.
CONGESTION_LEVEL_1 1
This value indicates that the load on the sender node is below the
manageable limit but requests for new sessions SHOULD be sent
preferrably to other nodes.
CONGESTION_LEVEL_2 2
This value indicates that no requests for new sessions SHOULD be
sent to the node. A node in this state MAY drop request messages
for new sessions. However, requests for existing sessions and
answer messages still SHOULD be sent to the node.
CONGESTION_LEVEL_3 3
This value indicates that no new requests SHOULD be sent to the
node even if they are requests for existing sessions. A node in
this state MAY drop received request messages.
CONGESTION_LEVEL_4 4
This value indicates that no new messages (neither requests nor
answers) SHOULD be sent to the node. A node in this state MAY
drop any received message.
Asveren & Fajardo Expires January 16, 2009 [Page 9]
Internet-Draft Diameter Congestion Signaling July 2008
5.3. Error Answers
This document defines a new result code of protocol error class:
DIAMETER_CONGESTED 3011 A request has been received and the
congestion state of the receiver node is not suitable to process
the request.
DIAMETER_ENDPOINT_CONGESTED 3012 A request with a Destination-Host
AVP is received, the destination of the request is an adjacent
node and already declared that it is unable to handle new
requests.
DIAMETER_APPLICATION_CONGESTED 3013 A request without a Destination-
Host AVP is received, it is known that all potential endpoints for
the request declared that they are unable to handle a new request.
6. Examples
6.1. Providing Hysteresis for Local Congestion Level Decision
This example assumes a local congestion level decision policy based
on the number of messages in an incoming queue. The node decides for
a maximum number of 1024 pending requests. This number could be
based on the processing power of the node, the nature of the
application and the expected message rate. The following figure
displays possible onset/abatement values for different congestion
levels.
+----+ 1023
|----|
|----|
|----|
|----|768 <--- Congestion Level4 Onset
|----|
|----|640 <--- Congestion Level4 Abatement
|----|576 <--- Congestion Level3 Onset
|----|
|----|448 <--- Congestion Level3 Abatement
|----|384 <--- Congestion Level2 Onset
|----|
|----|256 <--- Congestion Level2 Abatement
|----|192 <--- Congestion Level1 Onset
|----|
|----| 64 <--- Congestion Level1 Abatement
+----+ 0
Asveren & Fajardo Expires January 16, 2009 [Page 10]
Internet-Draft Diameter Congestion Signaling July 2008
Figure 2: Congestion Onset/Abatement Levels
The difference between onset and abatement levels for the same
congestion level is necessary to provide hysteresis so that
congestion level does not change frequently between two levels.
6.2. Congestion Level Used For Loadsharing
The following scenario assumes a configration, where a relay agent is
distributing traffic to two servers. It is assumed that the service
consists of a single transaction, i.e. all requests belong to
different sessions.
After Server2 declares that if there is some other server present, it
should be preferred for new requests, relay agent stops loadsharing
new requests among Server1 and Server2 and sends all new requests to
Server1. When congestion state on Server2 is back to normal, Relay
Agent continues to loadshare new requests among both servers.
Asveren & Fajardo Expires January 16, 2009 [Page 11]
Internet-Draft Diameter Congestion Signaling July 2008
Relay
Agent Server1 Server2
| | |
| | |
|------REQ1------>| |
| | |
|<-----ANS1-------| |
| | |
|------------REQ2------------->|
| | |
|<-----------ANS2--------------|
| | |
|<-----DWR(Cong. Level 1)------|
| | |
|-----------DWA--------------->|
| | |
|-----REQ3------->| |
| | |
|<----ANS3--------| |
| | |
|-----REQ4------->| |
| | |
|<----ANS4--------| |
| | |
|<----DWR(Cong. Level 0)-------|
| | |
|----------DWA---------------->|
| | |
|-----------REQ5-------------->|
| | |
|<----------ANS5---------------|
| | |
| | |
Figure 3: Congestion Level 1 Being Used in Loadsharing
7. IANA Considerations
IANA is to assign new AVP codes for Congestion-Level AVP defined in
Section 5.2.
8. Security Considerations
This document does not contain a security protocol; it describes
extensions to the existing Diameter protocol. All security issues of
Asveren & Fajardo Expires January 16, 2009 [Page 12]
Internet-Draft Diameter Congestion Signaling July 2008
DIAMETER protocol must be considered in implementing this
specification. This extension does not add any unique concerns.
9. Acknowledgments
The authors wish to thank Bernard Aboba for his invaluable comments.
10. Normative References
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Tolga Asveren
Sonus Networks
4400 Route 9 South
Freehold, NJ, 07728
USA
Email: tasveren@sonusnet.com
Victor Fajardo
Toshiba America Research Inc.
One Telcordia Drive
Piscataway, NJ 08854
USA
Email: vfajardo@tari.toshiba.com
Asveren & Fajardo Expires January 16, 2009 [Page 13]
Internet-Draft Diameter Congestion Signaling July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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 procedures with respect to rights in RFC 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.
Asveren & Fajardo Expires January 16, 2009 [Page 14]
