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.

Slides:

Advertisements

Similar presentations

Diameter Bulk Signaling draft-liebsch-dime-diameter-bulksig-00.txt M. Liebsch, G. Punz IETF81, Quebec Diameter Maintenance and Extensions (DIME) WG 28.

Advertisements

EAP Channel Bindings Charles Clancy Katrin Hoeper IETF 76 Hiroshima, Japan November 08-13, 2009.

Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks draft-farrel-interconnected-te-info-exchange-03.txt.

Draft-ietf-dime-agent-overload- 01.txt. Agenda Extensions to DOIC Questions Review of representative use cases.

1 Improved DNS Server Selection for Multi-Homed Nodes draft-savolainen-mif-dns-server-selection-04 Teemu Savolainen (Nokia) Jun-ya Kato (NTT) MIF WG meeting.

SDN and Openflow.

OSI and TCP Reference Models RD-CSY  To understand  Basic definitions  Protocol  Application  Understand communication process using Reference.

WNT Client/Server SDK Tony Vaccaro CS699 Project Presentation.

ACE – Design Considerations Corinna Schmitt IETF ACE WG meeting July 23,

Proxy Cache Leonid Romanovsky Olga Fomenko Winter 2003 Instructor: Konstantin Sinyuk.

Session Policy Framework using EAP draft-mccann-session-policy-framework-using-eap-00.doc IETF 76 – Hiroshima Stephen McCann, Mike Montemurro.

Overview SAP Basis Functions. SAP Technical Overview Learning Objectives What the Basis system is How does SAP handle a transaction request Differentiating.

Diameter Agent Overload IETF 88 - Vancouver 1. Goal Get consensus from the working group that Agent overload needs to be addressed If so, get guidance.

Client/Server Architectures

A. Dworak BE-CO-IN, CERN. Agenda 228th June 2012  Sum up of the previous report  Middleware prototyping  Transport  Serialization  Design concepts.

Securing Microsoft® Exchange Server 2010

Institute of Computer and Communication Network Engineering OFC/NFOEC, 6-10 March 2011, Los Angeles, CA Lessons Learned From Implementing a Path Computation.

Protocol Architectures. Simple Protocol Architecture Not an actual architecture, but a model for how they work Similar to “pseudocode,” used for teaching.

Draft-campbell-dime-load- considerations-01 IETF 92 DIME Working Group Meeting Dallas, Texas.

This document is for informational purposes only, and Tekelec reserves the right to change any aspect of the products, features or functionality described.

Statistics Monitor of SPMSII Warrior Team Pu Su Heng Tan Kening Zhang.

Page  1 A practical investigation of billing for next generation services. Name: Moses T Nkhumeleni Supervisors: Professor Alfredo Terzoli and Mr Mosiuoa.

Optimal Client-Server Assignment for Internet Distributed Systems.

(Preliminary) Gap Analysis Hannes Tschofenig. Goal of this Presentation The IETF has developed a number of security technologies that are applicable to.

Introduction of PRO WG activities Group Name: TP Source: Shingo Fujimoto, FUJITSU, Meeting Date: Agenda Item:

Web Security : Secure Socket Layer Secure Electronic Transaction.

Framework & Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks ANCP WG IETF 71 – Philadelphia draft-ietf-ancp-framework-05.txt.

Prefix Delegation Protocol Selection T.J. Kniveton MEXT Working Group IETF 70 - December ’07 - Vancouver.

(Business) Process Centric Exchanges

Authentication Mechanism for Port Control Protocol (PCP) draft-wasserman-pcp-authentication-01.txt Margaret Wasserman Sam Hartman Painless Security Dacheng.

Windows Network Programming ms-help://MS.MSDNQTR.2004JAN.1033/winsock/winsock/windows_sockets_start_page_2.htm 井民全.

M337 Standards Based Video Interop Interoperability modelling for Video Skype for Business Video Interoperability Server (VIS)

Middleware for Secure Environments Presented by Kemal Altıntaş Hümeyra Topcu-Altıntaş Osman Şen.

NFD Tunnel Authentication Junxiao Shi,

1 TCP/IP based TML (Transport Mapping Layer) for ForCES Protocol Hormuzd Khosravi Shuchi Chawla Furquan Ansari Jon Maloy 62 nd IETF Meeting, Minneapolis.

Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.

World Wide Web “WWW”, "Web" or "W3". World Wide Web “WWW”, "Web" or "W3"

Framework & Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks IETF 66 - ANCP WG July 9-14, 2006 draft-ooghe-ancp-framework-00.txt.

IETF67 DIME WG Towards the specification of a Diameter Resource Control Application Dong Sun IETF 67, San Diego, Nov 2006 draft-sun-dime-diameter-resource-control-requirements-00.txt.

PwC New Technologies New Risks. PricewaterhouseCoopers Technology and Security Evolution Mainframe Technology –Single host –Limited Trusted users Security.

Submission doc.: IEEE ai May 2012 Lei Wang, InterDigital CommunicationsSlide 1 Proposed SFD Text for ai AP/STA Initiated FILS Optimizations.

Diameter Overload Control Design Team Report DIME WG – IETF88 draft-docdt-dime-ovli-01 Design Team Report.

Security Architecture of qmail and Postfix Authors: Munawar Hafiz Ralph E. Johnson Prepared by Geoffrey Foote CSC 593 Secure Software Engineering Seminar.

Data Communications and Networks Chapter 9 – Distributed Systems ICT-BVF8.1- Data Communications and Network Trainer: Dr. Abbes Sebihi.

IETF66 DIME WG John Loughney, Hannes Tschofenig and Victor Fajardo 3588-bis: Current Issues.

PCE 64 th IETF PCE Policy Architecture draft-berger-pce-policy-architecture-00.txt Lou Berger Igor Bryskin Dimitri Papadimitriou.

CSC 480 Software Engineering Lecture 17 Nov 4, 2002.

DOC Use Case Analysis Client to server use cases 1.

1 Chapter 7 WEB Security. 2 Outline Web Security Considerations Secure Socket Layer (SSL) and Transport Layer Security (TLS) Secure Electronic Transaction.

Partial Notifications IETF 56 SIMPLE WG draft-lonnfors-simple-presinfo-deliv-reqs-00 draft-lonnfors-simple-partial-notify-00 Mikko Lönnfors

DIME WG IETF 84 Diameter Design Guidelines draft-ietf-dime-app-design-guide-15 Tuesday, July 31, 2012 Lionel Morand.

IETF68 DIME WG Diameter Applications Design Guidelines Document (draft-fajardo-dime-app-design-guide-00.txt)

Diameter General Purpose Session draft-liebsch-dime-diameter-gps-01.txt M. Liebsch, G. Punz IETF79, Beijing Diameter Extensions (DIME) WG 11 th November.

DOTS Requirements Andrew Mortensen November 2015 IETF 94 1.

DECADE Requirements draft-gu-decade-reqs-05 Yingjie Gu, David A. Bryan, Y. Richard Yang, Richard Alimi IETF-78 Maastricht, DECADE Session.

SIP wg Items Jonathan Rosenberg dynamicsoft Caller Preferences: Changes Discussion of Redirects –Previous draft only proxy –Nothing different for redirect.

Jonathan Rosenberg Volker Hilt Daryl Malas

draft-asveren-dime-cong-02 com ;

IETF80, Prague Diameter Maintenance and Extensions (DIME) WG

Visit for more Learning Resources

Distribution and components

CSC 480 Software Engineering

The 66th IETF meeting in Montreal, Canada

Charles Shen, Henning Schulzrinne, Arata Koike

Open Forum th November 2015.

call completion services

Presentation transcript:

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 Explores different design than Diameter OVL and Tekelec solution.Diameter OVLTekelec solution Set of documents: The Diameter Load Balancing Application Diameter Overload Architecture and Information Model arch-00.txthttp://tools.ietf.org/id/draft-tschofenig-dime-overload- arch-00.txt Diameter Overload Piggybacking piggybacking-00http://tools.ietf.org/html/draft-tschofenig-dime-overload- piggybacking-00

Complexity

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

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

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

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

Overload Communication Basic Design Options 1.Piggyback payloads on applicable Diameter application layer messages 2.Communicated with separate Diameter applications 3.Piggyback in any Diameter message

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?

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