1 / 4

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

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

roland
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-asveren-dime-cong-02tasveren@sonusnet.com ; vfajardo@toshiba.com4 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

More Related