1 / 11

Diameter Overload

Diameter Overload. DIME WG IETF 87 July, 2013. Starting Point. DIAMETER_TOO_BUSY provides little guidance on what a Diameter client should do when it receives such an error message. How much functionality do we need to add?. New Proposal.

jack
Download Presentation

Diameter Overload

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. Diameter Overload DIME WG IETF 87 July, 2013

  2. Starting Point • DIAMETER_TOO_BUSY provides little guidance on what a Diameter client should do when it receives such an error message. • How much functionality do we need to add?

  3. New Proposal • Explores different design than Diameter OVL and Tekelec solution. • Set of documents: • The Diameter Load Balancing Application • http://tools.ietf.org/html/draft-tschofenig-dime-dlba-00 • Diameter Overload Architecture and Information Model • http://tools.ietf.org/id/draft-tschofenig-dime-overload-arch-00.txt • Diameter Overload Piggybacking • http://tools.ietf.org/html/draft-tschofenig-dime-overload-piggybacking-00

  4. Complexity

  5. Principles • Avoid premature optimizations • Focus on real-world problems • Overload conditions are rare events • Consider advances in information technology • Load balancing and rejecting requests (for overload) is different. • Delegation rejection policies create a lot of complexity.

  6. Overload Signal • Overload + Rejection • Information Policies • +-------+ +***************************************+ • | End | * * • | Point | * * • +-------+ * Capability Indication * • ^ * +------------------------+ * • | * | | * • | v | v * • |Front-End +------------+ Diameter Msg +------------+ • |Protocol | Diameter | Exchanges | Diameter | • +--------->| Client |<----------------->| Server | • +------------+ +------------+

  7. Load Balancing • Exchange of Load Info • \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\+ • + | • +---v------+ | • | Diameter | | • | Server A <--+ Diameter +-----v--+ Incoming • +----------+ | Exchanges |Load | Diameter Requests • +----------+ +--------------+Balancer|<<<------------------ • | Diameter | | +-----^--+ • | Server B <--+ | • +----^-----+ | • + | • //////////////////////////////+ • Exchange of Load Info

  8. Information Model • Overload • How long is the overload period expected to last? • How much should the sending rate be reduced? • To what does the rejection policy refer to? • Load • Information about the load situation of a server. • To what resource does it refer it? • Additionally needed: capability negotiation

  9. Overload CommunicationBasic Design Options • Piggyback payloads on applicable Diameter application layer messages • Communicated with separate Diameter applications • Piggyback in any Diameter message

  10. Getting Implementation Experience • Running code would help us to verify specification ideas. • Software architecture matters for how to communicate load and overload information. • Examples: • Single-threaded architecture (e.g., freeDiameter) • Multi-threaded architecture (e.g., freeRADIUS, Apache) • Example question to investigate: Is input queue a good measure for load?

  11. Next Steps • Explore implementation specific aspects in more detail. • Detailed examples.

More Related