1. draft-asveren-dime-cong-02 tasveren@sonusnet. com ; vfajardo@toshiba
draft-asveren-dime-cong-02 ; 4 December 2007

2. Why do we need overload information?
Preventing aggravation of overload condition
Load balancing
Another parameter in routing decision
Currently only up/down status of a Diameter connection is considered
This draft focuses initially on hop-by-hop congestion but could be extended for end-to-end congestion as well.

3. Why are existing mechanisms not enough?
DIAMETER_TOO_BUSY error answer
Only for servers, intermediaries may need to signal overload as well
A reactive mechanism, needs to receive a request to send the answer
Can’t inform about abatement of overload
Can’t support multiple levels (important to prevent cascaded collapse, loadbalancing, efficient resource utilization)
TCP/SCTP receiver window
Practical issues about accessing receiver window value
Propagation of congestion takes time
Each peer will observe only its own receiver window and won’t know whether a node is in overload because of messages sent by another peer

4. Solution Approach
Signal congestion information to neighbors with a new congestion AVP
Alternative is to use a new command
Congestion AVP can be piggybacked to any message including DWR/DWA
DWR can be sent whenever congestion state of the node changes
Dampening can be applied between onset and abatement of overload to prevent oscillation or flapping
Possible context:
Overload indications affects entire node
Overload indications is per application