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.

Slides:



Advertisements
Similar presentations
DOIC Restructuring. Restructuring Purpose Improve readability Separate informative from normative text Isolate loss abatement algorithm behavior into.
Advertisements

Internetworking II: MPLS, Security, and Traffic Engineering
Draft-ietf-dime-agent-overload- 01.txt. Agenda Extensions to DOIC Questions Review of representative use cases.
IPv6 Multihoming Support in the Mobile Internet Presented by Paul Swenson CMSC 681, Fall 2007 Article by M. Bagnulo et. al. and published in the October.
HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Slide title :32-35pt Color: R153 G0 B0 Corporate Font : FrutigerNext LT Medium Font to be used by customers.
An Innovative Approach to Content Search Across P2P Inter-Networks Potharaju S.R.P Saradhi Mohmed Nazuruddin Shaik Potharaju S R Aditya Under The Guidance.
DOIC Status and Issues IETF #89 1. Summary 36 Issues Opened 6 closed in issue tracker 18 resolved on list 12 open in various stages of resolution 2.
DOIC Status. Restructuring complete – Some cleanup in to be in -04 version 13 open issue remaining.
HYDRO: A Hybrid Routing Protocol for Lossy and Low Power Networks draft-tavakoli-hydro-01 Stephen Dawson-Haggerty, Jonathan Hui, Arsalan Tavakoli.
Scalable Content-aware Request Distribution in Cluster-based Network Servers Jianbin Wei 10/4/2001.
Distributed Systems Fall 2010 Replication Fall 20105DV0203 Outline Group communication Fault-tolerant services –Passive and active replication Highly.
ZIGZAG A Peer-to-Peer Architecture for Media Streaming By Duc A. Tran, Kien A. Hua and Tai T. Do Appear on “Journal On Selected Areas in Communications,
1 Denial-of-Service Resilience in P2P File Sharing Systems Dan Dumitriu (EPFL) Ed Knightly (Rice) Aleksandar Kuzmanovic (Northwestern) Ion Stoica (Berkeley)
Chapter 13 Physical Architecture Layer Design
Internet Routing Instability Labovitz et al. Sigcomm 1997 Largely adopted from Ion Stoica’s slide at UCB.
WPDRTS ’05 1 Workshop on Parallel and Distributed Real-Time Systems 2005 April 4th and 5th, 2005, Denver, Colorado Challenge Problem Session Detection.
CS335 Networking & Network Administration Tuesday, April 20, 2010.
Lesson 1: Configuring Network Load Balancing
(ITI310) By Eng. BASSEM ALSAID SESSIONS 8: Network Load Balancing (NLB)
1 3 Web Proxies Web Protocols and Practice. 2 Topics Web Protocols and Practice WEB PROXIES  Web Proxy Definition  Three of the Most Common Intermediaries.
Framework & Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks ANCP WG IETF 70 – Vancouver draft-ietf-ancp-framework-04.txt.
Multiple Links Failover Mechanism for RPR Interconnected Rings IEEE WG Orlando, Florida USA March 11~16, 2007.
Draft-campbell-dime-load- considerations-01 IETF 92 DIME Working Group Meeting Dallas, Texas.
1 CMPT 471 Networking II DHCP Failover and multiple servers © Janice Regan,
Req1 - Separability Old: –An RO scheme MUST have the ability to be bypassed by traffic types that desire to use bidirectional tunnels through an HA. New:
All the components of network are connected to the central device called “hub” which may be a hub, a router or a switch. There is no direct traffic between.
Backdrop Particle Paintings created by artist Tom Kemp September Grid Information and Monitoring System using XML-RPC and Instant.
Framework & Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks ANCP WG IETF 71 – Philadelphia draft-ietf-ancp-framework-05.txt.
CSCI 465 D ata Communications and Networks Lecture 15 Martin van Bommel CSCI 465 Data Communications & Networks 1.
OSI Model. Switches point to point bridges two types store & forward = entire frame received the decision made, and can handle frames with errors cut-through.
SIPREC draft-ietf-siprec-req-02 Requirements for Media Recording using SIP Draft authors: K. Rehor, A. Hutton, L. Portman, R. Jain, H. Lum IETF 78.5 Interim.
1 Peer-to-Peer Technologies Seminar by: Kunal Goswami (05IT6006) School of Information Technology Guided by: Prof. C.R.Mandal, School of Information Technology.
1 IETF- 56 – TE WG- SAN FRANCISCO Inter-AS MPLS Traffic Engineering draft-vasseur-inter-AS-TE-00.txt Jean-Philippe Vasseur – Cisco Systems Raymond Zhang.
RFC 4477 DHCP: Dual-Stack Issues Speaker: Ching-Chen Chang Date:
RTCWEB Considerations for NATs, Firewalls and HTTP proxies draft-hutton-rtcweb-nat-firewall- considerations A. Hutton, T. Stach, J. Uberti.
TURN extension to convey flow characteristics draft-wing-tsvwg-turn-flowdata-00 July 2014, IETF 90 Meeting Authors: Dan Wing, Tiru Reddy, Brandon Williams,
The Client-Server Model And the Socket API. Client-Server (1) The datagram service does not require cooperation between the peer applications but such.
Agent Based Transaction System CS790: Dr. Bruce Land Sanish Mondkar Sandeep Chakravarty.
Chapter 5 : The Internet: Addressing & Services Business Data Communications, 4e.
Diameter Overload Control Design Team Report DIME WG – IETF88 draft-docdt-dime-ovli-01 Design Team Report.
Load Balance for Distributed Home Agents in Mobile IPv6 draft-deng-mip6-ha-loadbalance-02.txt Hui Deng Hitachi (China) Brian HaleyHewlett-Packard Company.
PCE 64 th IETF PCE Policy Architecture draft-berger-pce-policy-architecture-00.txt Lou Berger Igor Bryskin Dimitri Papadimitriou.
Diameter Overload DIME WG IETF 87 July, Starting Point DIAMETER_TOO_BUSY provides little guidance on what a Diameter client should do when it receives.
DOC Use Case Analysis Client to server use cases 1.
March 2014 doc.: IEEE Submission Jaehwan Kim (ETRI) Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Dynamic Allocation of Shared IPv4 Addresses draft-ietf-dhc-dynamic-shared-v4allocation-01 Q. Sun, Y. Cui, I. Farrer, Y. Lee, Q. Sun, M. Boucadair IETF.
Partial Notifications IETF 56 SIMPLE WG draft-lonnfors-simple-presinfo-deliv-reqs-00 draft-lonnfors-simple-partial-notify-00 Mikko Lönnfors
Netprog: Chat1 Chat Issues and Ideas for Service Design Refs: RFC 1459 (IRC)
A SIP Load Control Event Package draft-shen-sipping-load-control-event-package-00.txt Charles Shen, Henning Schulzrinne, Arata Koike IETF 72, Dublin Ireland.
SIP Overload Control draft-hilt-sipping-overload-00 Volker Hilt Daryl Malas Indra Widjaja
Volker Hilt Bell Labs/Alcatel-Lucent SIP Overload Control IETF Design Team Status.
1 Traffic Engineering By Kavitha Ganapa. 2 Introduction Traffic engineering is concerned with the issue of performance evaluation and optimization of.
Seminar On Rain Technology
DOTS Requirements Andrew Mortensen November 2015 IETF 94 1.
PERFORMANCE MANAGEMENT IMPROVING PERFORMANCE TECHNIQUES Network management system 1.
Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
Scaling Network Load Balancing Clusters
draft-asveren-dime-cong-02 com ;
Network Load Balancing Functionality
Network Load Balancing
Load Weighting and Priority
Open Forum th November 2016.
Distributed Mobility Management (DMM) WG DMM Work Item: Forwarding Path & Signaling Management (FPSM) draft-ietf-dmm-fpc-cpdp-01.txt IETF93, Prague.
An Introduction to Computer Networking
Chat Refs: RFC 1459 (IRC).
Charles Shen, Henning Schulzrinne, Arata Koike
Open Forum th November 2015.
draft-ietf-p2psip-base-03
Network management system
Presentation transcript:

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 on the best path forward 2

Background DOC-DT decided to not address handling of overloaded agents in base DOIC specification. 3

Assertion A complete solution to handling Diameter overload requires addressing overload of all nodes in a Diameter network, including agents. 4

Requirements – An agent is a Diameter node. REQ 1: The solution MUST provide a communication method for Diameter nodes to exchange load and overload information. REQ 12: When a single network node fails, goes into overload, or suffers from reduced processing capacity, the solution MUST make it possible to limit the impact of this on other nodes in the network. This helps to prevent a small-scale failure from becoming a widespread outage. Other requirements also apply. 5

Question 1 Do we agree that we need to address the handling of Agent Overload? 6

Behavior Minimal new behavior required in clients – Behavior for a client is the same as the case where there is a direct connection between the client and multiple servers and the client gets a realm overload report from one of the servers. Overload abatement is handled by peer on a hop- by-hop basis. – Agents are required to inspect overload reports and act on those from peer agents. No change in loss abatement algorithm for throttled requests. 7

Question 2 How should agent overload handling be specified? – Option 1 – As an extension – Option 2 – As part of the base DOIC specification 8

BACKUP SLIDES 9

Use Cases Single Agent Redundant Agents Agent Chains Interaction between agent overload and end- point overload 10

Agent Overload Multiple Agents Client Agent 1 Architecture Server Agent 2 Client has active connection to both agent 1 and agent 2 Client shares the load between the two agents The load distribution mechanism is local policy to the client 11

Agent Overload Multiple Agents Client Agent 1 Server xxR x% xxA Client sends x percent of traffic through agent 1 Agent 2 No overload xxR y%Client sends y percent of traffic through agent 2 x + y = 100% xxA 12

Agent Overload Multiple Agents Client Agent 1 Server xxR xxA OLR (A1, R=20%) Agent OVL report contains requested reduction Agent 2 xxR y%+20% xxA Agent1 becomes overloaded xxR x%-20% Client adjusts distribution of load between agents based on the agent overload report xxA 13

Agent Overload Multiple Agents Client Agent 1 Server xxR xxA OLR (A1, R=60%) Agent OVL report contains requested reduction Agent 2 Agent1 becomes 60% overloaded xxR Throttle at (x% *.6) + (y% *.6)) At this point the combined agent overload requires throttling to a level the agents are able to handle xxR xxA OLR (A2, R=60%) Agent OVL report contains requested reduction Agent2 becomes 60% overloaded 14

Agent Overload UC4 Agent Chain Client Agent 1 Architecture Agent 2-2 Server 1 Agent

Agent Overload Agent Chain Agent 1 Agent 2-1 Server xxR xxA OLR (A1, R=60%) Agent OVL report contains requested reduction Agent 1 acts on the report and removes it from the message Agent 2-2 Agent1 becomes 60% overloaded xxR Throttle at (x% *.6) + (y% *.6)) At this point the combined agent overload requires throttling to a level the agents are able to handle xxR xxA OLR (A2, R=60%) Agent OVL report contains requested reduction Agent 1 acts on the report and removes it from the message Agent2 becomes 60% overloaded Client xxR xxA 16