Download
1 / 4
40 likes | 162 Views
draft-asveren-dime-cong-02 tasveren@sonusnet.com ; vfajardo@toshiba.com 4 December 2007. Why do we need overload information?. Preventing aggravation of overload condition Load balancing Another parameter in routing decision
E N D
draft-asveren-dime-cong-02tasveren@sonusnet.com ; vfajardo@toshiba.com4 December 2007
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.
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
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
