From internet-drafts@ietf.org Mon May 7 00:34:18 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D0921F84F3; Mon, 7 May 2012 00:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBE4Uci8YM3v; Mon, 7 May 2012 00:34:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D709A21F84DF; Mon, 7 May 2012 00:34:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507073416.27677.93850.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 00:34:16 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc3588bis-33.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 07:34:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Base Protocol Author(s) : Victor Fajardo Jari Arkko John Loughney Glen Zorn Filename : draft-ietf-dime-rfc3588bis-33.txt Pages : 154 Date : 2012-05-07 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719 and must be supported by all new Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-33.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-33.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ From iesg-secretary@ietf.org Mon May 7 09:20:36 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943E321F8631; Mon, 7 May 2012 09:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+cumtlCItKQ; Mon, 7 May 2012 09:20:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49C721F8643; Mon, 7 May 2012 09:20:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507162034.26611.11975.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 09:20:34 -0700 Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Base Protocol' to Proposed Standard (draft-ietf-dime-rfc3588bis-33.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 16:20:36 -0000 The IESG has approved the following document: - 'Diameter Base Protocol' (draft-ietf-dime-rfc3588bis-33.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ Technical Summary The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and must be supported by all new Diameter implementations. Working Group Summary The document spent almost four years in the WG, which is unreasonably long time. This was not a result of large controversy, but rather ensuring nothing important breaks in backwards compatibility. At IETF-79 the WG decided to include in this version of Diameter support for Diameter over SCTP and asked for the document to be updated and brought up again to the WG and IETF consensus before it is submitted to IESG evaluation. Three IETF Last Calls where hold. Document Quality FreeDiameter (www.freediameter.net) implements a previous version of the specification. A number of vendors have indicated interest on implementing the specification due it correcting several known flaws. Personnel Jouni Korhonen is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. From iesg-secretary@ietf.org Mon May 7 09:48:10 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F08621F8493; Mon, 7 May 2012 09:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrA1jlla1b2x; Mon, 7 May 2012 09:48:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E830321F85F2; Mon, 7 May 2012 09:48:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507164808.1088.91946.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 09:48:08 -0700 Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Network Address and Port Translation Control Application' to Proposed Standard (draft-ietf-dime-nat-control-17.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 16:48:10 -0000 The IESG has approved the following document: - 'Diameter Network Address and Port Translation Control Application' (draft-ietf-dime-nat-control-17.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-nat-control/ Technical Summary This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4-address space completion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA- servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. Working Group Summary The document spent well over a year in the WG and has had an intensive review in the WG. However, the authors actively kept the document progressing and improving. The document is a result of collaborative WG work. Document Quality There is currently no publicly announced implementations of the protocol. The document itself is solid, well written and in places goes into level of details not often seen in Diameter Application describing documents. Personnel Jouni Korhonen is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. From bclaise@cisco.com Tue May 8 00:00:07 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257AD21F85C5 for ; Tue, 8 May 2012 00:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTwzFxMI6P+3 for ; Tue, 8 May 2012 00:00:06 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 58FAE21F85C4 for ; Tue, 8 May 2012 00:00:06 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q48705fn003890 for ; Tue, 8 May 2012 09:00:05 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q48704Rc021795 for ; Tue, 8 May 2012 09:00:05 +0200 (CEST) Message-ID: <4FA8C475.5030407@cisco.com> Date: Tue, 08 May 2012 09:00:05 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 CC: dime mailing list References: <20120507164808.1088.91946.idtracker@ietfa.amsl.com> In-Reply-To: <20120507164808.1088.91946.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Protocol Action: 'Diameter Network Address and Port Translation Control Application' to Proposed Standard (draft-ietf-dime-nat-control-17.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 07:00:07 -0000 Congratulations to the editors, authors, reviewers, and WG chairs. Basically everybody who helped with this draft. Regards, Benoit. > The IESG has approved the following document: > - 'Diameter Network Address and Port Translation Control Application' > (draft-ietf-dime-nat-control-17.txt) as Proposed Standard > > This document is the product of the Diameter Maintenance and Extensions > Working Group. > > The IESG contact persons are Benoit Claise and Ronald Bonica. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-dime-nat-control/ > > > > > Technical Summary > > This document describes the framework, messages, and procedures for > the Diameter Network address and port translation Control > Application. This Diameter application allows per endpoint control > of Network Address Translators and Network Address and Port > Translators, which are added to networks to cope with IPv4-address > space completion. This Diameter application allows external devices > to configure and manage a Network Address Translator device - > expanding the existing Diameter-based AAA and policy control > capabilities with a Network Address Translators and Network Address > and Port Translators control component. These external devices can > be network elements in the data plane such as a Network Access > Server, or can be more centralized control plane devices such as AAA- > servers. This Diameter application establishes a context to commonly > identify and manage endpoints on a gateway or server, and a Network > Address Translator and Network Address and Port Translator device. > This includes, for example, the control of the total number of > Network Address Translator bindings allowed or the allocation of a > specific Network Address Translator binding for a particular > endpoint. In addition, it allows Network Address Translator devices > to provide information relevant to accounting purposes. > > Working Group Summary > > The document spent well over a year in the WG and has had an intensive > review in the WG. However, the authors > actively kept the document progressing and improving. The document > is a result of collaborative WG work. > > Document Quality > > There is currently no publicly announced implementations of the > protocol. The document itself is solid, well written and in places > goes into level of details not often seen in Diameter Application > describing documents. > > Personnel > > Jouni Korhonen is the Document Shepherd for this document. > Dan Romascanu is the Responsible Area Director. > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From bclaise@cisco.com Tue May 8 00:05:30 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD6721F85DB for ; Tue, 8 May 2012 00:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTN-ovYUrKUA for ; Tue, 8 May 2012 00:05:28 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2A86921F85D8 for ; Tue, 8 May 2012 00:05:28 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q486vIPh003385 for ; Tue, 8 May 2012 08:57:18 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q486vHpw019658 for ; Tue, 8 May 2012 08:57:17 +0200 (CEST) Message-ID: <4FA8C3CE.2040101@cisco.com> Date: Tue, 08 May 2012 08:57:18 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 CC: dime mailing list References: <20120507162034.26611.11975.idtracker@ietfa.amsl.com> In-Reply-To: <20120507162034.26611.11975.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070509050507010700070900" Subject: Re: [Dime] Protocol Action: 'Diameter Base Protocol' to Proposed Standard (draft-ietf-dime-rfc3588bis-33.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 07:05:30 -0000 This is a multi-part message in MIME format. --------------070509050507010700070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, The draft version 00 started in 2006! Publishing this RFC will actually result in 4 new RFCs , all part of the cluster C133 Congratulations on this milestone, and thanks to all who helped. Regards, Benoit. > The IESG has approved the following document: > - 'Diameter Base Protocol' > (draft-ietf-dime-rfc3588bis-33.txt) as Proposed Standard > > This document is the product of the Diameter Maintenance and Extensions > Working Group. > > The IESG contact persons are Benoit Claise and Ronald Bonica. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ > > > > > Technical Summary > > The Diameter base protocol is intended to provide an Authentication, > Authorization and Accounting (AAA) framework for applications such as > network access or IP mobility in both local and roaming situations. > This document specifies the message format, transport, error > reporting, accounting and security services used by all Diameter > applications. The Diameter base protocol as defined in this document > obsoletes RFC 3588 and must be supported by all new Diameter > implementations. > > Working Group Summary > > The document spent almost four years in the WG, which is > unreasonably long time. This was not a result of large > controversy, but rather ensuring nothing important breaks > in backwards compatibility. At IETF-79 the WG decided to include > in this version of Diameter support for Diameter over SCTP and > asked for the document to be updated and brought up again to the > WG and IETF consensus before it is submitted to IESG evaluation. > Three IETF Last Calls where hold. > > Document Quality > > FreeDiameter (www.freediameter.net) implements a previous > version of the specification. > > A number of vendors have indicated interest on implementing > the specification due it correcting several known flaws. > > Personnel > > Jouni Korhonen is the Document Shepherd for this document. > Dan Romascanu is the Responsible Area Director. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > --------------070509050507010700070900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

The draft version 00 started in 2006!
Publishing this RFC will actually result in 4 new RFCs, all part of the cluster C133
Congratulations on this milestone, and thanks to all who helped.

Regards, Benoit.
The IESG has approved the following document:
- 'Diameter Base Protocol'
  (draft-ietf-dime-rfc3588bis-33.txt) as Proposed Standard

This document is the product of the Diameter Maintenance and Extensions
Working Group.

The IESG contact persons are Benoit Claise and Ronald Bonica.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/




Technical Summary

   The Diameter base protocol is intended to provide an Authentication,
   Authorization and Accounting (AAA) framework for applications such as
   network access or IP mobility in both local and roaming situations.
   This document specifies the message format, transport, error
   reporting, accounting and security services used by all Diameter
   applications.  The Diameter base protocol as defined in this document
   obsoletes RFC 3588 and must be supported by all new Diameter
   implementations.

Working Group Summary

  The document spent almost four years in the WG, which is
  unreasonably long time. This was not a result of large 
  controversy, but rather ensuring nothing important breaks
  in backwards compatibility. At IETF-79 the WG decided to include 
  in this version of Diameter support for Diameter over SCTP and 
  asked for the document to be updated and brought up again to the 
  WG and IETF consensus before it is submitted to IESG evaluation. 
  Three IETF Last Calls where hold. 

Document Quality

  FreeDiameter (www.freediameter.net) implements a previous
  version of the specification.

  A number of vendors have indicated interest on implementing
  the specification due it correcting several known flaws.

Personnel

 Jouni Korhonen is the Document Shepherd for this document.
 Dan Romascanu is the Responsible Area Director.


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------070509050507010700070900-- From dromasca@avaya.com Tue May 8 01:31:23 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145D221F84EE for ; Tue, 8 May 2012 01:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.347 X-Spam-Level: X-Spam-Status: No, score=-103.347 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8U+RsjSuZeo for ; Tue, 8 May 2012 01:31:21 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2B60D21F84E6 for ; Tue, 8 May 2012 01:31:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAGbZqE+HCzI1/2dsb2JhbAAqGoJGnnKIKgGJP4EHggwBAQEBAwEBAQ8KEQM+CxACAQgNAQMEAQELBgwHBAEGASYfCQgBAQQTCBqHbAsqnSydOYsAhSZjBJcPhQeKKoJrbQ X-IronPort-AV: E=Sophos;i="4.75,549,1330923600"; d="scan'208,217";a="305359674" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 May 2012 04:30:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 May 2012 04:14:02 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2CF4.EF095347" Date: Tue, 8 May 2012 10:31:14 +0200 Message-ID: In-Reply-To: <4FA8C3CE.2040101@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Protocol Action: 'Diameter Base Protocol' to Proposed Standard (draft-ietf-dime-rfc3588bis-33.txt) Thread-Index: Ac0s6PkrQE+OIglQRUy9HqfsdAmEgQAC4TNQ References: <20120507162034.26611.11975.idtracker@ietfa.amsl.com> <4FA8C3CE.2040101@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: dime mailing list Subject: Re: [Dime] Protocol Action: 'Diameter Base Protocol' to Proposed Standard (draft-ietf-dime-rfc3588bis-33.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 08:31:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2CF4.EF095347 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to join my congratulations to Benoit's and thank everybody who worked on this document. This work started shortly after I became an AD and was completed now, soon after Benoit became an AD. BTW, the announcement should be corrected to mention 'Benoit Claise is the Responsible Area Director.' =20 Regards, =20 Dan =20 =20 From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Tuesday, May 08, 2012 9:57 AM Cc: dime mailing list Subject: Re: [Dime] Protocol Action: 'Diameter Base Protocol' to Proposed Standard (draft-ietf-dime-rfc3588bis-33.txt) =20 Dear all, The draft version 00 started in 2006! Publishing this RFC will actually result in 4 new RFCs , all part of = the cluster C133 Congratulations on this milestone, and thanks to all who helped. Regards, Benoit. The IESG has approved the following document: - 'Diameter Base Protocol' (draft-ietf-dime-rfc3588bis-33.txt) as Proposed Standard =20 This document is the product of the Diameter Maintenance and Extensions Working Group. =20 The IESG contact persons are Benoit Claise and Ronald Bonica. =20 A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ =20 =20 =20 =20 Technical Summary =20 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and must be supported by all new Diameter implementations. =20 Working Group Summary =20 The document spent almost four years in the WG, which is unreasonably long time. This was not a result of large=20 controversy, but rather ensuring nothing important breaks in backwards compatibility. At IETF-79 the WG decided to include=20 in this version of Diameter support for Diameter over SCTP and=20 asked for the document to be updated and brought up again to the=20 WG and IETF consensus before it is submitted to IESG evaluation.=20 Three IETF Last Calls where hold.=20 =20 Document Quality =20 FreeDiameter (www.freediameter.net) implements a previous version of the specification. =20 A number of vendors have indicated interest on implementing the specification due it correcting several known flaws. =20 Personnel =20 Jouni Korhonen is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. =20 =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 =20 =20 ------_=_NextPart_001_01CD2CF4.EF095347 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to join my congratulations to Benoit’s and thank = everybody who worked on this document. This work started shortly after I = became an AD and was completed now, soon after Benoit became an AD. BTW, = the announcement should be corrected to mention ‘Benoit = Claise is the Responsible Area Director.’

 

Regards,

 

Dan

 

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Benoit Claise
Sent: Tuesday, May 08, 2012 9:57 = AM
Cc: dime mailing list
Subject: Re: [Dime] = Protocol Action: 'Diameter Base Protocol' to Proposed Standard = (draft-ietf-dime-rfc3588bis-33.txt)

 

Dear = all,

The draft = version 00 started in 2006!
Publishing this RFC will actually = result in 4 new = RFCs, all part of the cluster C133
Congratulations on this = milestone, and thanks to all who helped.

Regards, = Benoit.

The IESG has approved the following =
document:
- 'Diameter Base =
Protocol'
  =
(draft-ietf-dime-rfc3588bis-33.txt) as Proposed =
Standard
 
This document =
is the product of the Diameter Maintenance and =
Extensions
Working =
Group.
 
The IESG contact =
persons are Benoit Claise and Ronald =
Bonica.
 
A URL of this =
Internet Draft is:
http=
://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/
 
 
&nbs=
p;
 
Technical =
Summary
 
   =
The Diameter base protocol is intended to provide an =
Authentication,
   Authorization and =
Accounting (AAA) framework for applications such =
as
   network access or IP mobility in =
both local and roaming situations.
   =
This document specifies the message format, transport, =
error
   reporting, accounting and =
security services used by all Diameter
   =
applications.  The Diameter base protocol as defined in this =
document
   obsoletes RFC 3588 and must =
be supported by all new Diameter
   =
implementations.
 
Working=
 Group Summary
 
  =
The document spent almost four years in the WG, which =
is
  unreasonably long time. This was not a =
result of large 
  controversy, but =
rather ensuring nothing important breaks
  in =
backwards compatibility. At IETF-79 the WG decided to include =

  in this version of Diameter support =
for Diameter over SCTP and 
  asked for =
the document to be updated and brought up again to the =

  WG and IETF consensus before it is =
submitted to IESG evaluation. 
  Three =
IETF Last Calls where hold. =

 
Document =
Quality
 
  =
FreeDiameter (www.freediameter.net) =
implements a previous
  version of the =
specification.
 
  A =
number of vendors have indicated interest on =
implementing
  the specification due it =
correcting several known =
flaws.
 
Personnel
 
 Jouni Korhonen is the =
Document Shepherd for this document.
 Dan Romascanu =
is the Responsible Area =
Director.
 
 
_______________________________________________<=
/pre>
DiME mailing list
DiME@ietf.org
https://www.ietf.org/=
mailman/listinfo/dime
 
 
 
------_=_NextPart_001_01CD2CF4.EF095347-- From lionel.morand@orange.com Tue May 8 01:58:39 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF3421F854F for ; Tue, 8 May 2012 01:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.915 X-Spam-Level: X-Spam-Status: No, score=-6.915 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7rGIHw4dazO for ; Tue, 8 May 2012 01:58:35 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id B1E9D21F8564 for ; Tue, 8 May 2012 01:58:34 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 25C801074001; Tue, 8 May 2012 10:58:46 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 117E0E301D1; Tue, 8 May 2012 10:58:46 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 May 2012 10:58:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2CF8.BE7CD972" Date: Tue, 8 May 2012 10:58:31 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Protocol Action: 'Diameter Base Protocol' to ProposedStandard (draft-ietf-dime-rfc3588bis-33.txt) Thread-Index: Ac0s6PkrQE+OIglQRUy9HqfsdAmEgQAC4TNQAACxWpA= References: <20120507162034.26611.11975.idtracker@ietfa.amsl.com><4FA8C3CE.2040101@cisco.com> From: To: , X-OriginalArrivalTime: 08 May 2012 08:58:33.0032 (UTC) FILETIME=[BEECE480:01CD2CF8] Cc: dime@ietf.org Subject: Re: [Dime] Protocol Action: 'Diameter Base Protocol' to ProposedStandard (draft-ietf-dime-rfc3588bis-33.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 08:58:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2CF8.BE7CD972 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank to all the contributors to this huge work that allowed the = publication of this document, which was expected for a long time! Dan, I cannot think of a more appropriate retirement gift from the Dime = WG! J Thank you for all your support during these 6 years! =20 Regards, =20 Lionel=20 =20 De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de = Romascanu, Dan (Dan) Envoy=E9 : mardi 8 mai 2012 10:31 =C0 : Benoit Claise Cc : dime mailing list Objet : Re: [Dime] Protocol Action: 'Diameter Base Protocol' to = ProposedStandard (draft-ietf-dime-rfc3588bis-33.txt) =20 I would like to join my congratulations to Benoit's and thank everybody = who worked on this document. This work started shortly after I became an = AD and was completed now, soon after Benoit became an AD. BTW, the = announcement should be corrected to mention 'Benoit Claise is the = Responsible Area Director.' =20 Regards, =20 Dan =20 =20 From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = Benoit Claise Sent: Tuesday, May 08, 2012 9:57 AM Cc: dime mailing list Subject: Re: [Dime] Protocol Action: 'Diameter Base Protocol' to = Proposed Standard (draft-ietf-dime-rfc3588bis-33.txt) =20 Dear all, The draft version 00 = started in = 2006! Publishing this RFC will actually result in 4 new RFCs = , all part of = the cluster C133 Congratulations on this milestone, and thanks to all who helped. Regards, Benoit. The IESG has approved the following document: - 'Diameter Base Protocol' (draft-ietf-dime-rfc3588bis-33.txt) as Proposed Standard =20 This document is the product of the Diameter Maintenance and Extensions Working Group. =20 The IESG contact persons are Benoit Claise and Ronald Bonica. =20 A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ =20 =20 =20 =20 Technical Summary =20 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and must be supported by all new Diameter implementations. =20 Working Group Summary =20 The document spent almost four years in the WG, which is unreasonably long time. This was not a result of large=20 controversy, but rather ensuring nothing important breaks in backwards compatibility. At IETF-79 the WG decided to include=20 in this version of Diameter support for Diameter over SCTP and=20 asked for the document to be updated and brought up again to the=20 WG and IETF consensus before it is submitted to IESG evaluation.=20 Three IETF Last Calls where hold.=20 =20 Document Quality =20 FreeDiameter (www.freediameter.net) implements a previous version of the specification. =20 A number of vendors have indicated interest on implementing the specification due it correcting several known flaws. =20 Personnel =20 Jouni Korhonen is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. =20 =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 =20 =20 ------_=_NextPart_001_01CD2CF8.BE7CD972 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thank to all the contributors to this huge work that allowed the = publication of this document, which was expected for a long = time!

Dan, I cannot think of a more appropriate retirement gift from the = Dime WG! J Thank you for all your support during these 6 = years!

 

Regards,

 

Lionel

 

De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Romascanu, Dan (Dan)
Envoy=E9 : mardi 8 mai 2012 = 10:31
=C0 : Benoit Claise
Cc : dime = mailing list
Objet : Re: [Dime] Protocol Action: = 'Diameter Base Protocol' to ProposedStandard = (draft-ietf-dime-rfc3588bis-33.txt)

 

I would like to join my congratulations to Benoit’s and thank = everybody who worked on this document. This work started shortly after I = became an AD and was completed now, soon after Benoit became an AD. BTW, = the announcement should be corrected to mention ‘Benoit Claise is the Responsible Area Director.’

 

Regards,

 

Dan

 

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Benoit Claise
Sent: Tuesday, May 08, 2012 9:57 = AM
Cc: dime mailing list
Subject: Re: [Dime] = Protocol Action: 'Diameter Base Protocol' to Proposed Standard = (draft-ietf-dime-rfc3588bis-33.txt)

 

Dear = all,

The draft = version 00 started in 2006!
Publishing this RFC will actually = result in 4 new = RFCs, all part of the cluster C133
Congratulations on this = milestone, and thanks to all who helped.

Regards, = Benoit.

The IESG has =
approved the following document:
- 'Diameter Base =
Protocol'
  =
(draft-ietf-dime-rfc3588bis-33.txt) as Proposed =
Standard
 
This =
document is the product of the Diameter Maintenance and =
Extensions
Working =
Group.
 
The =
IESG contact persons are Benoit Claise and Ronald =
Bonica.
 
A URL =
of this Internet Draft is:
http=
://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/
 
 
 
 
Technical Summary
 
   The Diameter base protocol is intended to =
provide an Authentication,
   Authorization and Accounting (AAA) framework =
for applications such as
   network access or IP mobility in both local =
and roaming situations.
   This document specifies the message format, =
transport, error
   reporting, accounting and security services =
used by all Diameter
   applications.  The Diameter base protocol =
as defined in this document
   obsoletes RFC 3588 and must be supported by =
all new Diameter
   =
implementations.
 
Working Group Summary
 
  The document spent almost four years in the WG, =
which is
  =
unreasonably long time. This was not a result of large =

  controversy, =
but rather ensuring nothing important =
breaks
  in =
backwards compatibility. At IETF-79 the WG decided to include =

  in this =
version of Diameter support for Diameter over SCTP and =

  asked for =
the document to be updated and brought up again to the =

  WG and IETF =
consensus before it is submitted to IESG evaluation. =

  Three IETF =
Last Calls where hold. 
 
Document Quality
 
  FreeDiameter (www.freediameter.net) =
implements a previous
  version of the =
specification.
 
  A number of vendors have indicated interest on =
implementing
  the =
specification due it correcting several known =
flaws.
 
Personnel
 
 =
Jouni Korhonen is the Document Shepherd for this =
document.
 Dan Romascanu =
is the Responsible Area Director.
 
 
_______________________________________________
DiME mailing =
list
DiME@ietf.org
https://www.ietf.org/= mailman/listinfo/dime
 
 

 

------_=_NextPart_001_01CD2CF8.BE7CD972-- From lionel.morand@orange.com Tue May 8 02:01:31 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A123121F84B5 for ; Tue, 8 May 2012 02:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.82 X-Spam-Level: X-Spam-Status: No, score=-6.82 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTO11al8J6Nk for ; Tue, 8 May 2012 02:01:25 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD0121F84AF for ; Tue, 8 May 2012 02:01:25 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 63DF8E301DC; Tue, 8 May 2012 11:01:37 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5A597E301D1; Tue, 8 May 2012 11:01:37 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 May 2012 11:01:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 May 2012 11:01:23 +0200 Message-ID: In-Reply-To: <4FA8C475.5030407@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Protocol Action: 'Diameter Network Address and Port Translation Control Application' to Proposed Standard (draft-ietf-dime-nat-control-17.txt) Thread-Index: Ac0s6EbuByWvmEJjSdaYA4rEULyXNgAEIJ/Q References: <20120507164808.1088.91946.idtracker@ietfa.amsl.com> <4FA8C475.5030407@cisco.com> From: To: X-OriginalArrivalTime: 08 May 2012 09:01:24.0426 (UTC) FILETIME=[25158AA0:01CD2CF9] Cc: dime@ietf.org Subject: Re: [Dime] Protocol Action: 'Diameter Network Address and Port Translation Control Application' to Proposed Standard (draft-ietf-dime-nat-control-17.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 09:01:31 -0000 Thank to the authors, reviewers and IESG members that have contributed = to the completion and publication of this new proposed standard. Regards, Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Benoit Claise Envoy=E9=A0: mardi 8 mai 2012 09:00 Cc=A0: dime mailing list Objet=A0: Re: [Dime] Protocol Action: 'Diameter Network Address and Port = Translation Control Application' to Proposed Standard = (draft-ietf-dime-nat-control-17.txt) Congratulations to the editors, authors, reviewers, and WG chairs. Basically everybody who helped with this draft. Regards, Benoit. > The IESG has approved the following document: > - 'Diameter Network Address and Port Translation Control Application' > (draft-ietf-dime-nat-control-17.txt) as Proposed Standard > > This document is the product of the Diameter Maintenance and = Extensions > Working Group. > > The IESG contact persons are Benoit Claise and Ronald Bonica. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-dime-nat-control/ > > > > > Technical Summary > > This document describes the framework, messages, and procedures = for > the Diameter Network address and port translation Control > Application. This Diameter application allows per endpoint = control > of Network Address Translators and Network Address and Port > Translators, which are added to networks to cope with IPv4-address > space completion. This Diameter application allows external = devices > to configure and manage a Network Address Translator device - > expanding the existing Diameter-based AAA and policy control > capabilities with a Network Address Translators and Network = Address > and Port Translators control component. These external devices = can > be network elements in the data plane such as a Network Access > Server, or can be more centralized control plane devices such as = AAA- > servers. This Diameter application establishes a context to = commonly > identify and manage endpoints on a gateway or server, and a = Network > Address Translator and Network Address and Port Translator device. > This includes, for example, the control of the total number of > Network Address Translator bindings allowed or the allocation of a > specific Network Address Translator binding for a particular > endpoint. In addition, it allows Network Address Translator = devices > to provide information relevant to accounting purposes. > > Working Group Summary > > The document spent well over a year in the WG and has had an = intensive > review in the WG. However, the authors > actively kept the document progressing and improving. The document > is a result of collaborative WG work. > > Document Quality > > There is currently no publicly announced implementations of the > protocol. The document itself is solid, well written and in places > goes into level of details not often seen in Diameter Application > describing documents. > > Personnel > > Jouni Korhonen is the Document Shepherd for this document. > Dan Romascanu is the Responsible Area Director. > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From mauricio.sanchez@hp.com Wed May 9 10:57:12 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C06721F8573; Wed, 9 May 2012 10:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpBH-MgbvgKG; Wed, 9 May 2012 10:57:11 -0700 (PDT) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1C621F856F; Wed, 9 May 2012 10:57:11 -0700 (PDT) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 4BFE3243AB; Wed, 9 May 2012 17:57:11 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 9 May 2012 17:56:15 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Wed, 9 May 2012 18:56:15 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" , "dime@ietf.org" Date: Wed, 9 May 2012 18:56:13 +0100 Thread-Topic: RADEXT WG Last Call: "RADIUS Protocol Extensions" Thread-Index: Ac0uDQatZHc5yeLqQZmcgfGJYhN4Ag== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 09 May 2012 22:34:00 -0700 Subject: [Dime] RADEXT WG Last Call: "RADIUS Protocol Extensions" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 17:57:12 -0000 This is an announcement of RADEXT WG last call on "RADIUS Protocol Extensio= ns", prior to sending the document to the IESG for publication as a propos= ed standard RFC. We are asking review from both RADEXT and DIME WGs as a ma= tter completeness. The document is available for inspection here: http://tools.ietf.org/id/draft-ietf-radext-radius-extensions The RADEXT WG last call will last until Wednesday May 23, 2012. If you ha= ve comments on the document, please file using TRAC system. See below for = summary of instructions. Thanks, Mauricio and Jouni 1. To submit an issue in TRAC, you first need to login to the RADEXT = WG site on the tools server: http://tools.ietf.org/wg/radext/trac/login 2. If you don=92t already have a login ID, you can obtain one by navi= gating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can fil= e an issue by navigating to the ticket entry form:http://trac.tools.ietf.o= rg/wg/radext/trac/newticket 4. When opening an issue: a. The Type: field should be set to =93defect=94 for an issue with th= e current document text, or =93enhancement=94 for a proposed addition of fu= nctionality (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. Fo= r example, editorial issues are typically =93minor=94 or =93trivial=94. c. The Milestone: field should be set to milestone1 (useless, I know)= . d. The Component: field should be set to the document you are filing t= he issue on. e. The Version: field should be set to =931.0=94. f. The Severity: field should be set to based on the status of the d= ocument (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you. h. The Assign To: field is generally filled in with the email address = of the editor. 5. Typically it won=92t be necessary to enclose a file with the ticke= t, but if you need to, select =93I have files to attach to this ticket=94. 6. If you want to preview your Issue, click on the =93Preview=94 butt= on. When you=92re ready to submit the issue, click on the =93Create Ticket= =94 button. 7. If you want to update an issue, go to the "View Tickets" page: htt= p://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # you = want to update, and then modify the ticket fields as required From internet-drafts@ietf.org Fri May 11 00:38:06 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512C021F860E; Fri, 11 May 2012 00:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLb+Xm++vVAG; Fri, 11 May 2012 00:38:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C3921F846F; Fri, 11 May 2012 00:38:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120511073805.24838.45685.idtracker@ietfa.amsl.com> Date: Fri, 11 May 2012 00:38:05 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-pmip6-lr-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 07:38:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Support for Proxy Mobile IPv6 Localized Routing Author(s) : Glen Zorn Qin Wu Marco Liebsch Jouni Korhonen Filename : draft-ietf-dime-pmip6-lr-12.txt Pages : 12 Date : 2012-05-11 In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, the usage of localized routing may be authorized for both MAGs. This document specifies how to accomplish this using the Diameter protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-pmip6-lr/ From iesg-secretary@ietf.org Tue May 15 10:21:39 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B80821F88CD; Tue, 15 May 2012 10:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHuhbfNFKT0w; Tue, 15 May 2012 10:21:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BEF21F8933; Tue, 15 May 2012 10:21:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120515172135.27468.86369.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 10:21:35 -0700 Cc: jouni.korhonen@nsn.com, dime@ietf.org Subject: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 17:21:40 -0000 The Diameter Maintenance and Extensions (dime) working group in the Operati= ons and Management Area of the IETF has been rechartered. For additional i= nformation, please contact the Area Directors or the working group Chairs. Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Current Status: Active Chairs: Jouni Korhonen Lionel Morand Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/ Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the = IESG for consideration as a Proposed Standards:* 'Diameter = Mobile IPv6: Support for Home Agent to Diameter Server = Interaction' * 'Diameter Mobile IPv6: Support for Network = Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an = Informational RFC Done - Submit 'Quality of Service Parameters for Usage with = Diameter' to the IESG for consideration as a Proposed = Standard. Done - Submit 'Diameter QoS Application' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' = as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing = Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group = item Done - Submit 'Quality of Service Attributes for Diameter' to the = IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing = Clarifications' to the IESG for consideration as a Proposed = Standard Done - Submit 'Diameter NAT Control Application' as DIME working = group item Done - Submit 'Diameter Capabilities Update' as DIME working group = item Done - Submit 'Diameter Credit Control Application MIB' to the IESG = for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for = consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME working = group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized = Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key = Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME = working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key = Transport' to the IESG for consideration as a Proposed = Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG = for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server = Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as = a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized = Routing' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for = consideration as a Proposed Standard Mar 2012 - Submit Revision of 'Diameter Network Access Server = Application - RFC 4005bis' to the IESG for consideration as a = Proposed Standard May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG = for consideration as a BCP document Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' = to the IESG for consideration as a Proposed Standard Aug 2012 - Submit 'problem statement and requirements for Diameter end- to-end security framework' as Dime working group item Aug 2012 - Submit a document on 'Protocol extension for bulk and group = signaling' as a working group item Dec 2012 - Submit 'problem statement and requirements for Diameter end- to-end security framework' to the IESG for consideration as = an Informational RFC Aug 2013 - Submit a document on 'Protocol extension for bulk and group = signaling' to the IESG for consideration as a Proposed = Standard From internet-drafts@ietf.org Tue May 15 22:47:29 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABAC21F877D; Tue, 15 May 2012 22:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pEe1q147k3x; Tue, 15 May 2012 22:47:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E5C21F876A; Tue, 15 May 2012 22:47:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120516054729.20953.62620.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 22:47:29 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-pmip6-lr-13.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 05:47:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Support for Proxy Mobile IPv6 Localized Routing Author(s) : Glen Zorn Qin Wu Marco Liebsch Jouni Korhonen Filename : draft-ietf-dime-pmip6-lr-13.txt Pages : 12 Date : 2012-05-15 In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, the usage of localized routing may be authorized for both MAGs. This document specifies how to accomplish this using the Diameter protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-pmip6-lr/ From bclaise@cisco.com Wed May 16 02:55:38 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF89321F8743 for ; Wed, 16 May 2012 02:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.54 X-Spam-Level: X-Spam-Status: No, score=-8.54 tagged_above=-999 required=5 tests=[AWL=2.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cJ7i9hH8XS6 for ; Wed, 16 May 2012 02:55:34 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3316721F8742 for ; Wed, 16 May 2012 02:55:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4G9tXq5012343; Wed, 16 May 2012 11:55:33 +0200 (CEST) Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4G9tWnN020085; Wed, 16 May 2012 11:55:32 +0200 (CEST) Message-ID: <4FB37994.3080802@cisco.com> Date: Wed, 16 May 2012 11:55:32 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dime@ietf.org References: <20120515172135.27468.86369.idtracker@ietfa.amsl.com> In-Reply-To: <20120515172135.27468.86369.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------040802060403050509090606" Cc: jouni.korhonen@nsn.com Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 09:55:39 -0000 This is a multi-part message in MIME format. --------------040802060403050509090606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, The only change in the charter is the removal of the following paragraph: - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. Reason: as agreed, the "Diameter Base Protocol MIB" and "Diameter Credit Control Application MIB" were declared dead. Regards, Benoit. > The Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. > > > Diameter Maintenance and Extensions (dime) > ------------------------------------------ > > Charter > > Current Status: Active > > Chairs: > Jouni Korhonen > Lionel Morand > > Operations and Management Area Directors: > Ronald Bonica > Benoit Claise > > Operations and Management Area Advisor: > Benoit Claise > > Mailing Lists: > General Discussion: dime@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dime > Archive: http://www.ietf.org/mail-archive/web/dime/ > > Description of Working Group: > > The Diameter Maintenance and Extensions WG will focus on maintenance and > extensions to the Diameter protocol required to enable its use for > authentication, authorization, accounting, charging in network access, > provisioning of configuration information within the network, and for > new AAA session management uses within the extensibility rules of the > Diameter base protocol. > > The DIME working group plans to address the following items: > > - Maintaining and/or progressing, along the standards track, the > Diameter Base protocol and Diameter Applications. This includes > extensions to Diameter Base protocol that can be considered as enhanced > features or bug fixes. > > - Diameter application design guideline. This document will provide > guidelines for design of Diameter extensions. It will detail when to > consider reusing an existing application and when to develop a new > application. > > - Protocol extensions for bulk and grouped AAA session management. The > aim of this work is to study and standardize a solution for handling > groups of AAA sessions within the Diameter base protocol context. The > solution would define how to identify and handle grouped AAA sessions in > commands and operations. > > Additionally, Diameter-based systems require interoperability in order > to work. The working group, along with the AD, will need to evaluate any > potential extensions and require verification that the proposed > extension is needed, and is within the extensibility rules of Diameter > and AAA scope. Coordination with other IETF working groups and other > SDOs (e.g. 3GPP) will be used to ensure this. > > Goals and Milestones: > > Done - Submit the following two Diameter Mobility documents to the > IESG for consideration as a Proposed Standards:* 'Diameter > Mobile IPv6: Support for Home Agent to Diameter Server > Interaction' * 'Diameter Mobile IPv6: Support for Network > Access Server to Diameter Server Interaction' > Done - Submit 'Diameter API' to the IESG for consideration as an > Informational RFC > Done - Submit 'Quality of Service Parameters for Usage with > Diameter' to the IESG for consideration as a Proposed > Standard. > Done - Submit 'Diameter QoS Application' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Support for EAP Re-authentication Protocol' > as DIME working group item > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' as DIME working group item > Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group > item > Done - Submit 'Quality of Service Attributes for Diameter' to the > IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' to the IESG for consideration as a Proposed > Standard > Done - Submit 'Diameter NAT Control Application' as DIME working > group item > Done - Submit 'Diameter Capabilities Update' as DIME working group > item > Done - Submit 'Diameter Credit Control Application MIB' to the IESG > for consideration as an Informational RFC > Done - Submit 'Diameter Base Protocol MIB' to the IESG for > consideration as an Informational RFC > Done - Submit 'Diameter Capabilities Update' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' as DIME working group item > Done - Submit 'Realm-Based Redirection In Diameter' as DIME working > group item > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' as DIME working group item > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key > Transport' as DIME working group item > Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME > working group item > Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > Done - Submit Revision of 'Diameter Base Protocol' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key > Transport' to the IESG for consideration as a Proposed > Standard > Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG > for consideration as a Proposed Standard > Done - Submit Revision of 'Diameter Network Access Server > Application - RFC 4005bis' as DIME working group item > Done - Submit 'Diameter NAT Control Application' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as > a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' to the IESG for consideration as a Proposed Standard > Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for > consideration as a Proposed Standard > Mar 2012 - Submit Revision of 'Diameter Network Access Server > Application - RFC 4005bis' to the IESG for consideration as a > Proposed Standard > May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG > for consideration as a BCP document > Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' > to the IESG for consideration as a Proposed Standard > Aug 2012 - Submit 'problem statement and requirements for Diameter end- > to-end security framework' as Dime working group item > Aug 2012 - Submit a document on 'Protocol extension for bulk and group > signaling' as a working group item > Dec 2012 - Submit 'problem statement and requirements for Diameter end- > to-end security framework' to the IESG for consideration as > an Informational RFC > Aug 2013 - Submit a document on 'Protocol extension for bulk and group > signaling' to the IESG for consideration as a Proposed > Standard > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > --------------040802060403050509090606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

The only change in the charter is the removal of the following paragraph:
 - Protocol extensions for the management of Diameter entities. This work
  focuses on the standardization of Management Information Bases (MIBs) to
  configure Diameter entities (such as the Diameter Base protocol or
  Diameter Credit Control nodes). The usage of other management protocols
  for configuring Diameter entities may be future work within the group.
Reason: as agreed, the "Diameter Base Protocol MIB" and "Diameter Credit Control Application MIB" were declared dead.

Regards, Benoit.

The Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF has been rechartered.  For additional information, please contact the Area Directors or the working group Chairs.


Diameter Maintenance and Extensions (dime)
------------------------------------------

 Charter

 Current Status: Active

 Chairs:
     Jouni Korhonen <jouni.korhonen@nsn.com>
     Lionel Morand <lionel.morand@orange.com>

 Operations and Management Area Directors:
     Ronald Bonica <rbonica@juniper.net>
     Benoit Claise <bclaise@cisco.com>

 Operations and Management Area Advisor:
     Benoit Claise <bclaise@cisco.com>

 Mailing Lists:
     General Discussion: dime@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/dime
     Archive:            http://www.ietf.org/mail-archive/web/dime/

Description of Working Group:

The Diameter Maintenance and Extensions WG will focus on maintenance and
extensions to the Diameter protocol required to enable its use for
authentication, authorization, accounting, charging in network access,
provisioning of configuration information within the network, and for
new AAA session management uses within the extensibility rules of the
Diameter base protocol.

The DIME working group plans to address the following items:

- Maintaining and/or progressing, along the standards track, the
Diameter Base protocol and Diameter Applications. This includes
extensions to Diameter Base protocol that can be considered as enhanced
features or bug fixes.

- Diameter application design guideline. This document will provide
guidelines for design of Diameter extensions. It will detail when to
consider reusing an existing application and when to develop a new
application.

- Protocol extensions for bulk and grouped AAA session management. The
aim of this work is to study and standardize a solution for handling
groups of AAA sessions within the Diameter base protocol context. The
solution would define how to identify and handle grouped AAA sessions in
commands and operations.

Additionally, Diameter-based systems require interoperability in order
to work. The working group, along with the AD, will need to evaluate any
potential extensions and require verification that the proposed
extension is needed, and is within the extensibility rules of Diameter
and AAA scope. Coordination with other IETF working groups and other
SDOs (e.g. 3GPP) will be used to ensure this.

Goals and Milestones:

Done     - Submit the following two Diameter Mobility documents to the 
           IESG for consideration as a Proposed Standards:* 'Diameter 
           Mobile IPv6: Support for Home Agent to Diameter Server 
           Interaction' * 'Diameter Mobile IPv6: Support for Network 
           Access Server to Diameter Server Interaction'
Done     - Submit 'Diameter API' to the IESG for consideration as an 
           Informational RFC
Done     - Submit 'Quality of Service Parameters for Usage with 
           Diameter' to the IESG for consideration as a Proposed 
           Standard.
Done     - Submit 'Diameter QoS Application' to the IESG for 
           consideration as a Proposed Standard
Done     - Submit 'Diameter Support for EAP Re-authentication Protocol' 
           as DIME working group item
Done     - Submit 'Diameter User-Name and Realm Based Request Routing 
           Clarifications' as DIME working group item
Done     - Submit 'Diameter Proxy Mobile IPv6' as DIME working group 
           item
Done     - Submit 'Quality of Service Attributes for Diameter' to the 
           IESG for consideration as a Proposed Standard
Done     - Submit 'Diameter Proxy Mobile IPv6' to the IESG for 
           consideration as a Proposed Standard
Done     - Submit 'Diameter User-Name and Realm Based Request Routing 
           Clarifications' to the IESG for consideration as a Proposed 
           Standard
Done     - Submit 'Diameter NAT Control Application' as DIME working 
           group item
Done     - Submit 'Diameter Capabilities Update' as DIME working group 
           item
Done     - Submit 'Diameter Credit Control Application MIB' to the IESG 
           for consideration as an Informational RFC
Done     - Submit 'Diameter Base Protocol MIB' to the IESG for 
           consideration as an Informational RFC
Done     - Submit 'Diameter Capabilities Update' to the IESG for 
           consideration as a Proposed Standard
Done     - Submit 'Diameter Extended NAPTR' as DIME working group item
Done     - Submit 'Realm-Based Redirection In Diameter' as DIME working 
           group item
Done     - Submit 'Diameter Support for Proxy Mobile IPv6 Localized 
           Routing' as DIME working group item
Done     - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key 
           Transport' as DIME working group item
Done     - Submit 'Diameter Priority Attribute Value Pairs' as DIME 
           working group item
Done     - Submit 'Diameter IKEv2 PSK' as DIME working group item
Done     - Submit Revision of 'Diameter Base Protocol' to the IESG for 
           consideration as a Proposed Standard
Done     - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key 
           Transport' to the IESG for consideration as a Proposed 
           Standard
Done     - Submit 'Diameter Priority Attribute Value Pairs' to the IESG 
           for consideration as a Proposed Standard
Done     - Submit Revision of 'Diameter Network Access Server 
           Application - RFC 4005bis' as DIME working group item
Done     - Submit 'Diameter NAT Control Application' to the IESG for 
           consideration as a Proposed Standard
Done     - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as 
           a Proposed Standard
Done     - Submit 'Diameter Extended NAPTR' to the IESG for 
           consideration as a Proposed Standard
Done     - Submit 'Diameter Support for Proxy Mobile IPv6 Localized 
           Routing' to the IESG for consideration as a Proposed Standard
Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for 
           consideration as a Proposed Standard
Mar 2012 - Submit Revision of 'Diameter Network Access Server 
           Application - RFC 4005bis' to the IESG for consideration as a 
           Proposed Standard
May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG 
           for consideration as a BCP document
Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' 
           to the IESG for consideration as a Proposed Standard
Aug 2012 - Submit 'problem statement and requirements for Diameter end-
           to-end security framework' as Dime working group item
Aug 2012 - Submit a document on 'Protocol extension for bulk and group 
           signaling' as a working group item
Dec 2012 - Submit 'problem statement and requirements for Diameter end-
           to-end security framework' to the IESG for consideration as 
           an Informational RFC
Aug 2013 - Submit a document on 'Protocol extension for bulk and group 
           signaling' to the IESG for consideration as a Proposed 
           Standard
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------040802060403050509090606-- From emcmurry@estacado.net Thu May 17 10:43:27 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25A21F8659 for ; Thu, 17 May 2012 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDAbfPZwprC8 for ; Thu, 17 May 2012 10:43:26 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADC121F870E for ; Thu, 17 May 2012 10:43:26 -0700 (PDT) Received: from embp.mcmurry.home (cpe-76-184-161-215.tx.res.rr.com [76.184.161.215]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q4HHhKGx035114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 17 May 2012 12:43:24 -0500 (CDT) (envelope-from emcmurry@estacado.net) From: Eric McMurry Content-Type: multipart/alternative; boundary="Apple-Mail=_76DF94BB-4F5E-4055-9E69-DA3B4D7E4935" Date: Thu, 17 May 2012 12:43:14 -0500 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Dime] Diameter Overload Control Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 17:43:27 -0000 --Apple-Mail=_76DF94BB-4F5E-4055-9E69-DA3B4D7E4935 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A new draft has been submitted intended to address requirements for = overload control in Diameter. =20 http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt Diameter deployments are growing in size and this is becoming more of an = issue. We have seen significant interest in providing a mechanism to = address it. Hopefully this document is useful as a base for discussion = on what is needed and we welcome comments. Abstract: When a Diameter server or agent becomes overloaded, it needs to = be able to gracefully reduce its load, typically by informing clients to = reduce sending traffic for some period of time. Otherwise, it must = continue to expend resources parsing and responding to Diameter messages, = possibly resulting in congestion collapse. The existing mechanisms = provided by Diameter are not sufficient for this purpose. This document = describes the limitations of the existing mechanisms, and provides = requirements for new overload management mechanisms. The dime charter has an item, - Maintaining and/or progressing, along the standards track, the=20 Diameter Base protocol and Diameter Applications. This includes=20 extensions to Diameter Base protocol that can be considered as enhanced=20= features or bug fixes. that this seems suited to go under and we welcome comment on that as = well. --Apple-Mail=_76DF94BB-4F5E-4055-9E69-DA3B4D7E4935 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ht= tp://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt

Diameter deployments are growing in size = and this is becoming more of an issue.  We have seen significant = interest in providing a mechanism to address it.  Hopefully this = document is useful as a base for discussion on what is needed and we = welcome = comments.

Abstract:
  =      When a Diameter server or agent becomes overloaded, = it needs to be able
       to gracefully = reduce its load, typically by informing clients to = reduce
       sending traffic for some = period of time. Otherwise, it must continue to
    =    expend resources parsing and responding to Diameter = messages, possibly
       resulting in = congestion collapse. The existing mechanisms provided = by
       Diameter are not sufficient for = this purpose. This document describes
      =  the limitations of the existing mechanisms, and provides = requirements
       for new overload = management mechanisms.

The dime charter = has an item,

- Maintaining and/or = progressing, along the standards track, = the 
Diameter Base protocol and = Diameter Applications. This = includes 
extensions to Diameter Base protocol that can be considered as = enhanced 
features or bug = fixes.

that this = seems suited to go under and we welcome comment on that as = well.


= --Apple-Mail=_76DF94BB-4F5E-4055-9E69-DA3B4D7E4935-- From internet-drafts@ietf.org Fri May 18 00:43:24 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685D721F8622; Fri, 18 May 2012 00:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L954wMzyqT-u; Fri, 18 May 2012 00:43:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EE921F8636; Fri, 18 May 2012 00:43:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120518074323.27300.23234.idtracker@ietfa.amsl.com> Date: Fri, 18 May 2012 00:43:23 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc4005bis-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 07:43:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Network Access Server Application Author(s) : Glen Zorn Filename : draft-ietf-dime-rfc4005bis-09.txt Pages : 67 Date : 2012-05-18 This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/ From lionel.morand@orange.com Sun May 20 10:41:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7365F21F85F7; Sun, 20 May 2012 10:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dr9XPlPLve6; Sun, 20 May 2012 10:41:14 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2983321F85C3; Sun, 20 May 2012 10:41:12 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5E7CEE301DC; Sun, 20 May 2012 19:41:37 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 4EE31E301DB; Sun, 20 May 2012 19:41:37 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 May 2012 19:41:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD36AF.BDE5FBE1" Date: Sun, 20 May 2012 19:41:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for RFC4005bis -draft-ietf-dime-rfc4005bis-09 Thread-Index: Ac02r7z3CifaAbXRSx6w82HR5D9ovA== From: To: X-OriginalArrivalTime: 20 May 2012 17:41:10.0385 (UTC) FILETIME=[BE523E10:01CD36AF] Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: [Dime] Publication request for RFC4005bis -draft-ietf-dime-rfc4005bis-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 17:41:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD36AF.BDE5FBE1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Secretary, =20 This is a request for publication of draft-ietf-dime-rfc4005bis-09 as a standards track RFC (http://tools.ietf.org/html/draft-ietf-dime-rfc4005bis-09).=20 Hereafter is the document shepherd proto write-up, using current version of the document shepherd writeup template. =20 Regards, =20 Lionel =20 *************************** =20 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? =20 This type of RFC request is Proposed Standard in the Standards track. Standards Track is indicated in the title page header. This document is a bis version an existing Standards Track RFC (RFC 4005) and this new version will obsolete the old one if approved.=20 =20 (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: =20 Technical Summary =20 This document obsoletes RFC 4005 and is not backward compatible with that document. The main change compared to the RFC 4005 is the removal of all of the material related to RADIUS/Diameter protocol interactions,=20 which was underspecified and misleading. Moreover, the Command Code Format (CCF) for the Accounting-Request and Accounting-Answer messages has been=20 changed to explicitly require the inclusion of the Acct-Application-Id AVP and=20 exclude the Vendor-Specific-Application-Id AVP. The accounting model to be used with this application is also specified. =20 =20 Working Group Summary =20 ----- =20 The document spent almost two years as WG document and the=20 proposed changes from RFC 4005 were straightforward and roughly=20 endorsed by the Working Group. There was no controversy on its=20 final content.=20 =20 Document Quality =20 ----- =20 A number of vendors have indicated interest on implementing the specification due it correcting several known flaws. =20 There has been no MIB Doctor or Media Type reviews as those were not seen relevant for the bis version of the specification. There has not been explicitly requested expert reviews outside the WG as we believe most if not all important technical experts are already represented in the WG and its mailing list. The document has received multiple reviews while in WGLC. =20 Personnel =20 Who is the Document Shepherd? Who is the Responsible Area Director? =20 Lionel Morand (lionel.morand@orange.com) is the Document Shepherd,=20 As Dime WG co-chair. Benoit Claise Benoit Claise (bclaise@cisco.com) is the Responsible Area Director. =20 (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. =20 I have personally reviewed the draft, exchanged with authors to=20 clarify some points and concluded that this document was ready for publication =20 (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?=20 =20 The document shepherd has no concern about quality of the reviews,=20 which were performed by key WG members. =20 (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. =20 No. =20 (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. =20 No concern. =20 (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. =20 This document does not introduce any material subject to IPR disclosure, as the main changes were to remove material or clarify existing part of=20 the existing RFC (RFC 4005) that IPR free. =20 (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. =20 No IPR =20 (9) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?=20 =20 The main objective of this document, i.e. removal of material related to RADIUS/Diameter protocol interactions in the RFC 4005, was discussed and agreed in the Dime WG, as well as in the AAA-Doctors directorate.=20 The resulting document was quite straightforward without controversial updates. This document has beneficiated of reviews from key members. =20 (10) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)=20 =20 No. =20 (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. =20 Idnits was run. No action is required. =20 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. =20 (13) Have all references within this document been identified as either normative or informative? =20 Yes. =20 (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? =20 I-D.ietf-dime-rfc3588bis has just been approved by IESG and is in=20 the RFC Ed Queue. =20 =20 (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.=20 =20 No downward normative references. =20 (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. =20 Any existing document making reference to the RFC 4005 will be=20 automatically updated with the reference of this new RFC, as it will obsolete the previous one. =20 (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). =20 This document does not introduce protocol extensions or new registries. Existing namespaces used in this document are already managed by the IANA. =20 (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registry. =20 No new registry. =20 (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. =20 No check has been performed on this document as ABNF description found in this document is from the existing RFC already checked. =20 ------_=_NextPart_001_01CD36AF.BDE5FBE1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = Secretary,

 

This = is a request for publication of draft-ietf-dime-rfc4005bis-09 as a = standards track RFC (http://= tools.ietf.org/html/draft-ietf-dime-rfc4005bis-09). =

Hereafter is the = document shepherd proto write-up, using current version of the document = shepherd writeup template.

 

Regards,

 

Lionel

 

***************************

 

(1) = What type of RFC is being requested (BCP, Proposed = Standard,

Internet Standard, = Informational, Experimental, or Historic)?  = Why

is this the proper = type of RFC?  Is this type of RFC indicated in = the

title page = header?

 

   This type of RFC request is Proposed Standard in the = Standards track.

   Standards Track is indicated in the title page = header.

   This = document is a bis version an existing Standards Track RFC (RFC = 4005)

   and = this new version will obsolete the old one if approved. =

 

(2) = The IESG approval announcement includes a Document = Announcement

Write-Up. Please provide such a Document Announcement Write-Up. = Recent

examples can be = found in the "Action" announcements for = approved

documents. The = approval announcement contains the following = sections:

 

Technical Summary

 

   This document obsoletes RFC 4005 and is not backward = compatible with

   that document. The main change compared to the =
RFC 4005 is the removal
   of all of the material related to =
RADIUS/Diameter protocol interactions, =

   which =
was underspecified and misleading. Moreover, the Command Code =
Format
   (CCF) =
for the Accounting-Request and Accounting-Answer messages has been =

   changed to explicitly require the =
inclusion of the Acct-Application-Id AVP and =

   exclude the =
Vendor-Specific-Application-Id AVP. The accounting model to =
be
   used with =
this application is also specified.

 

 

Working Group Summary

 

  = -----

 

  = The document spent almost two years as WG document and the =

  proposed changes from RFC 4005 were straightforward = and roughly

  endorsed by the Working Group. There was no = controversy on its

  final content.

 

Document Quality

 

  = -----

 

  = A number of vendors have indicated interest on = implementing

=  the specification due it correcting several known = flaws.

 

=  There has been no MIB Doctor or Media Type reviews as = those

 were not = seen relevant for the bis version of the = specification.

=  There has not been explicitly requested expert reviews = outside

 the WG as we = believe most if not all important technical = experts

 are already = represented in the WG and its mailing list. The

 document has = received multiple reviews while in WGLC.

 

Personnel

 

  = Who is the Document Shepherd? Who is the Responsible = Area

  = Director?

 

  = Lionel Morand (lionel.morand@orange.com) = is the Document Shepherd,

  As Dime = WG co-chair. Benoit Claise

  Benoit = Claise (bclaise@cisco.com) is = the Responsible Area Director.

 

(3) = Briefly describe the review of this document that was performed = by

the Document = Shepherd.  If this version of the document is not = ready

for publication, = please explain why the document is being forwarded = to

the = IESG.

 

   I have personally reviewed the draft, exchanged with = authors to

   clarify some points and concluded that this = document was ready for

  =  publication

 

(4) = Does the document Shepherd have any concerns about the depth = or

breadth of the = reviews that have been performed?

 

  = The document shepherd has no concern about quality of the reviews, =

  which = were performed by key WG members.

 

(5) Do = portions of the document need review from a particular or = from

broader = perspective, e.g., security, operational complexity, AAA, = DNS,

DHCP, XML, or = internationalization? If so, describe the review = that

took = place.

 

  = No.

 

(6) = Describe any specific concerns or issues that the Document = Shepherd

has with this = document that the Responsible Area Director and/or = the

IESG should be = aware of? For example, perhaps he or she is = uncomfortable

with = certain parts of the document, or has concerns whether there = really

is a need for it. = In any event, if the WG has discussed those issues = and

has indicated that = it still wishes to advance the document, detail = those

concerns = here.

 

  = No concern.

 

(7) = Has each author confirmed that any and all appropriate = IPR

disclosures = required for full conformance with the provisions of BCP = 78

and BCP 79 have = already been filed. If not, explain why.

 

  = This document does not introduce any material subject to IPR = disclosure,

  as the main = changes were to remove material or clarify existing part of =

  the = existing RFC (RFC 4005) that IPR free.

 

(8) = Has an IPR disclosure been filed that references this = document?

If so, summarize = any WG discussion and conclusion regarding the = IPR

disclosures.

 

   No IPR

 

(9) = How solid is the WG consensus behind this document? Does it =

represent the = strong concurrence of a few individuals, with = others

being silent, or = does the WG as a whole understand and agree with it? =

 

  = The main objective of this document, i.e. removal of material = related

 to = RADIUS/Diameter protocol interactions in the RFC 4005, was = discussed

 and agreed = in the Dime WG, as well as in the AAA-Doctors directorate. =

  The = resulting document was quite straightforward without = controversial

=  updates. This document has beneficiated of reviews from key = members.

 

(10) = Has anyone threatened an appeal or otherwise indicated extreme =

discontent? If so, = please summarise the areas of conflict in = separate

email messages to = the Responsible Area Director. (It should be in = a

separate email = because this questionnaire is publicly available.) =

 

  = No.

 

(11) = Identify any ID nits the Document Shepherd has found in = this

document. (See = http://www.ietf.org/tools/idnits/ and the = Internet-Drafts

Checklist). Boilerplate checks are not enough; this check needs to = be

thorough.

 

  = Idnits was run. No action is required.

 

(12) = Describe how the document meets any required formal = review

criteria, such as = the MIB Doctor, media type, and URI type = reviews.

 

(13) = Have all references within this document been identified = as

either normative or = informative?

 

  = Yes.

 

(14) = Are there normative references to documents that are not ready = for

advancement or are = otherwise in an unclear state? If such normative

references exist, = what is the plan for their completion?

 

  I-D.ietf-dime-rfc3588bis =
has just been approved by IESG and is in =

  the RFC Ed =
Queue.

 

 

(15) = Are there downward normative references references (see RFC = 3967)?

If so, list these = downward references to support the Area Director in = the

Last Call = procedure.

 

  = No downward normative references.

 

(16) = Will publication of this document change the status of = any

existing RFCs? Are = those RFCs listed on the title page header, = listed

in the abstract, = and discussed in the introduction? If the RFCs are = not

listed in the = Abstract and Introduction, explain why, and point to = the

part of the = document where the relationship of this document to = the

other RFCs is = discussed. If this information is not in the = document,

explain why the WG = considers it unnecessary.

 

  = Any existing document making reference to the RFC 4005 will be =

  automatically updated with the reference of this new = RFC, as it will

  = obsolete the previous one.

 

(17) = Describe the Document Shepherd's review of the IANA = considerations

section, especially with regard to its consistency with the body = of the

document. Confirm = that all protocol extensions that the document = makes

are associated with = the appropriate reservations in IANA registries.

Confirm that any = referenced IANA registries have been clearly

identified. Confirm = that newly created IANA registries include a

detailed = specification of the initial contents for the registry, = that

allocations = procedures for future registrations are defined, and = a

reasonable name for = the new registry has been suggested (see RFC = 5226).

 

  = This document does not introduce protocol extensions or new = registries.

  Existing =
namespaces used in this document are already managed by the =
IANA.

  =

(18) List any new = IANA registries that require Expert Review for = future

allocations. = Provide any public guidance that the IESG would = find

useful in selecting = the IANA Experts for these new registry.

 

  = No new registry.

 

(19) = Describe reviews and automated checks performed by the = Document

Shepherd to = validate sections of the document written in a = formal

language, such as = XML code, BNF rules, MIB definitions, etc.

 

  = No check has been performed on this document as ABNF description = found

 in this = document is from the existing RFC already = checked.

 

------_=_NextPart_001_01CD36AF.BDE5FBE1-- From jan.van.geel@belgacom.be Tue May 29 05:50:05 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD2021F85C2 for ; Tue, 29 May 2012 05:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJqqKLlh0CHX for ; Tue, 29 May 2012 05:50:05 -0700 (PDT) Received: from mx13.belgacom.be (mx13.belgacom.be [195.13.15.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7F421F85BE for ; Tue, 29 May 2012 05:50:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,677,1330902000"; d="scan'208,217";a="13452150" Received: from a03007.bgc.net ([10.120.129.162]) by mx13.belgacom.be with ESMTP; 29 May 2012 14:50:01 +0200 X-TM-IMSS-Message-ID: <03e01dfe0000daef@belgacom.be> Received: from A04027.BGC.NET ([10.121.135.24]) by belgacom.be ([10.120.129.162]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 03e01dfe0000daef ; Tue, 29 May 2012 14:50:02 +0200 Received: from A04067.BGC.NET ([10.121.135.38]) by A04027.BGC.NET ([10.121.135.24]) with mapi id 14.01.0355.002; Tue, 29 May 2012 14:50:01 +0200 From: "VAN GEEL Jan (SDV/PSE)" To: "dime@ietf.org" Thread-Topic: [Dime] Diameter Overload Control Requirements Thread-Index: AQHNNFSXvZMQDf0LpUmFPbEbcScN7ZbguwqwgAAPUlA= Date: Tue, 29 May 2012 12:50:01 +0000 Message-ID: <1E97FFD1485F1142BC075FF145A53A1E0D9C47@A04067.BGC.NET> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.224.45] Content-Type: multipart/alternative; boundary="_000_1E97FFD1485F1142BC075FF145A53A1E0D9C47A04067BGCNET_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 29 May 2012 08:49:06 -0700 Subject: Re: [Dime] Diameter Overload Control Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 12:50:06 -0000 --_000_1E97FFD1485F1142BC075FF145A53A1E0D9C47A04067BGCNET_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this work Jan Van Geel IT and Network Specialist Belgacom SDE/SDV/PSE/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be From: dime-bounces@ietf.org [mailto:dime-boun= ces@ietf.org] On Behalf Of Eric McMu= rry Sent: Thursday, May 17, 2012 1:43 PM To: dime@ietf.org Subject: [Dime] Diameter Overload Control Requirements A new draft has been submitted intended to address requirements for overloa= d control in Diameter. http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt Diameter deployments are growing in size and this is becoming more of an is= sue. We have seen significant interest in providing a mechanism to address= it. Hopefully this document is useful as a base for discussion on what is= needed and we welcome comments. Abstract: When a Diameter server or agent becomes overloaded, it needs to be a= ble to gracefully reduce its load, typically by informing clients to red= uce sending traffic for some period of time. Otherwise, it must continue= to expend resources parsing and responding to Diameter messages, possib= ly resulting in congestion collapse. The existing mechanisms provided b= y Diameter are not sufficient for this purpose. This document describe= s the limitations of the existing mechanisms, and provides requirement= s for new overload management mechanisms. The dime charter has an item, - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. that this seems suited to go under and we welcome comment on that as well. ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer --_000_1E97FFD1485F1142BC075FF145A53A1E0D9C47A04067BGCNET_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support this work<= /p>

 

Jan Van Geel
IT and Network Specialist
Belgacom SDE/SDV/PSE/FVC
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : jan.van.geel@belgacom.be

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eric McMurry
Sent: Thursday, May 17, 2012 1:43 PM
To: dime@ietf.org
Subject: [Dime] Diameter Overload Control Requirements

 

A new draft has been submitted = intended to address requirements for overload control in Diameter.  

 

 

 

Diameter deployments are growin= g in size and this is becoming more of an issue.  We have seen signifi= cant interest in providing a mechanism to address it.  Hopefully this = document is useful as a base for discussion on what is needed and we welcome comments.

 

Abstract:

       When= a Diameter server or agent becomes overloaded, it needs to be able<= /p>

       to g= racefully reduce its load, typically by informing clients to reduce<= /p>

       send= ing traffic for some period of time. Otherwise, it must continue to<= /p>

       expe= nd resources parsing and responding to Diameter messages, possibly

       resu= lting in congestion collapse. The existing mechanisms provided by

       Diam= eter are not sufficient for this purpose. This document describes

       the = limitations of the existing mechanisms, and provides requirements

       for = new overload management mechanisms.

 

The dime charter has an item,

 

- Maintaining and/or progressing, along the standards track, the&nbs= p;

Diameter Base protocol and Diameter Applications. This includes = ;

extensions to Diameter Base protocol that can be considered as enhan= ced 

features or bug fixes.

 

that this seems suited to go un= der and we welcome comment on that as well.

 

 



***** Disclaimer *****
http://www.belgacom.be/maildisclaimer
 --_000_1E97FFD1485F1142BC075FF145A53A1E0D9C47A04067BGCNET_-- From ruibing_hao@cable.comcast.com Tue May 29 12:12:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D0721F8559 for ; Tue, 29 May 2012 12:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.23 X-Spam-Level: X-Spam-Status: No, score=-105.23 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4pwWNKmdmow for ; Tue, 29 May 2012 12:12:15 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2E821F84DE for ; Tue, 29 May 2012 12:12:15 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.19145882; Tue, 29 May 2012 12:56:25 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.45]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Tue, 29 May 2012 15:12:10 -0400 From: "Hao, Ruibing" To: "dime@ietf.org" Thread-Topic: Subject: Re: [Dime] Diameter Overload Control Requirements Thread-Index: AQHNPc7xzAxYtie4RUyRnzZLtO3xbA== Date: Tue, 29 May 2012 19:12:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [24.40.55.73] Content-Type: multipart/alternative; boundary="_000_CBEA97D318ED1RuibingHaocablecomcastcom_" MIME-Version: 1.0 Subject: [Dime] Subject: Re: Diameter Overload Control Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 19:12:16 -0000 --_000_CBEA97D318ED1RuibingHaocablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this work. Ruibing Hao Principal Engineer Comcast Cable One Comcast Center Philadelphia, PA 19103 Tel: 215-286-3991(O) --_000_CBEA97D318ED1RuibingHaocablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3E63509D97642D4E86C33AC76EA2FD60@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
I support this work.

Ruibing Hao
Principal= Engineer
Comcast C= able
One Comcast Center
Philadelphia, PA 19103
Tel: 215-286-3991(O)


--_000_CBEA97D318ED1RuibingHaocablecomcastcom_-- From tasveren@sonusnet.com Tue May 29 19:01:09 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0176021F85B6 for ; Tue, 29 May 2012 19:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzpY2nH6g0pT for ; Tue, 29 May 2012 19:01:06 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8D721F85B1 for ; Tue, 29 May 2012 19:01:05 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT8V/YAzgMk5Am0q4sWmt2JH4MHwLT+vP@postini.com; Tue, 29 May 2012 19:01:05 PDT Received: from USMA-EX-MB1.sonusnet.com ([fe80::b9d9:948e:3e0a:3eb0]) by usma-ex-hub1.sonusnet.com ([2002:42cb:5a10::42cb:5a10]) with mapi id 14.02.0247.003; Tue, 29 May 2012 22:01:28 -0400 From: "Asveren, Tolga" To: Eric McMurry , "dime@ietf.org" Thread-Topic: [Dime] Diameter Overload Control Requirements Thread-Index: AQHNNFSc+cM+APcWJ0qRTgCrq7IVYZbhkvgA Date: Wed, 30 May 2012 02:01:27 +0000 Message-ID: <750381A9C4CFD449928BD2CAC1E734E001C46A@usma-ex-mb1.sonusnet.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.176.22] Content-Type: multipart/alternative; boundary="_000_750381A9C4CFD449928BD2CAC1E734E001C46Ausmaexmb1sonusnet_" MIME-Version: 1.0 Subject: Re: [Dime] Diameter Overload Control Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 02:01:09 -0000 --_000_750381A9C4CFD449928BD2CAC1E734E001C46Ausmaexmb1sonusnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was an attempt around 2007 to start this work but at that time there = wasn't much interest. I don't recall any strong technical objections but Di= ameter traffic volumes were not as high as now so there wasn't an immediate= need. I hope this time it goes through. A few comments after a quick read: i- 4.2. Problems with Explicit Mechanisms The Diameter specification is ambiguous on how a client should handle receipt of a DIAMETER_TOO_BUSY response. The base specification [I-D.ietf-dime-rfc3588bis] indicates that the sending client should attempt to send the request to a different peer. It makes no suggestion that a the receipt of a DIAMETER_TOO_BUSY response should affect future Diameter messages in any way. I think this is reading the RFC3588 in a too literal way. One could argue t= hat similarly there is nothing preventing an implementation to use DIAMETER= _TOO_BUSY as input to an adaptive overload control mechanism. OTOH, I would= agree that it would be better if this is explicitly mentioned in 3588-bis. ii- 3. Existing Mechanisms Diameter requires the use of a congestion-managed transport layer, currently TCP or SCTP, to mitigate network congestion. But even with a congestion-managed transport, a Diameter node can become overloaded at the protocol layer due to the causes described in Section 1.1. It could be good to mention issues with TCP/SCTP congestion propagation and= about using receiver window sizes. iii- 4.2 A DIAMETER_TOO_BUSY error can only indicate overload at a "whole se= rver" scope. I thought that it would indicate overload for the application as indicated = in Application-Id. Is there any text in RFC3588 supporting either view? iv- REQ 15: The mechanism MUST NOT interfere with the congestion control m= echanisms of underlying transport protocols. Does this mean that there shouldn't be any reliance on indications from und= erlying transport protocol? v- REQ 26: The specification for the overload mechanism SHOULD offer guidance on which message types might be desirable to process over others during times of overload, based on Diameter-specific considerations. For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. I think the guidance should be for which messages should be sent rather tha= n which ones should be processed. vi- 2.2 On the other hand, there are cases where the client needs to be able to select a particular server from behind an agent. For example, if a Diameter request is part of a multiple-round-trip authentication, or is otherwise part of a Diameter "session", it may have a DestinationHost AVP that requires the request to be served by server 1. Therefore the agent may need to inform a client that a particular upstream server is overloaded or otherwise unavailable. Is this always a feasible approach considering that client may not always k= now the redundant pair for an overloaded server? Probably a mechanism is ne= eded which allows the server to communicate the identity of a redundant pai= r. That was also work proposed back in 2007 and which did not move forward = due to lack of interest. Maybe it is time to pick it up again. Actually it = could be preferable if Redundant Server info can be used directly by Relay = Agent (did not analyze in depth whether there are any issues with this appr= oach though) Thanks, Tolga From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eri= c McMurry Sent: Thursday, May 17, 2012 1:43 PM To: dime@ietf.org Subject: [Dime] Diameter Overload Control Requirements A new draft has been submitted intended to address requirements for overloa= d control in Diameter. http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt Diameter deployments are growing in size and this is becoming more of an is= sue. We have seen significant interest in providing a mechanism to address= it. Hopefully this document is useful as a base for discussion on what is= needed and we welcome comments. Abstract: When a Diameter server or agent becomes overloaded, it needs to be a= ble to gracefully reduce its load, typically by informing clients to red= uce sending traffic for some period of time. Otherwise, it must continue= to expend resources parsing and responding to Diameter messages, possib= ly resulting in congestion collapse. The existing mechanisms provided b= y Diameter are not sufficient for this purpose. This document describe= s the limitations of the existing mechanisms, and provides requirement= s for new overload management mechanisms. The dime charter has an item, - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. that this seems suited to go under and we welcome comment on that as well. --_000_750381A9C4CFD449928BD2CAC1E734E001C46Ausmaexmb1sonusnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There was an attempt around 2007 to start this= work but at that time there wasn’t much interest. I don’t reca= ll any strong technical objections but Diameter traffic volumes were not as high as now so there wasn’t an immediate need. I hope th= is time it goes through.

 

A few comments after a quick read:<= /span>

 <= /p> 

i- 4.2.  Problems with Explicit=
 Mechanisms

 

   The Diameter specification is ambiguous on ho= w a client should handle

   receipt of a DIAMETER_TOO_BUSY response. = ; The base specification

   [I-D.ietf-dime-rfc3588bis] indicates that the= sending client should

   attempt to send the request to a different pe= er.  It makes no

   suggestion that a the receipt of a DIAMETER_T= OO_BUSY response should

   affect future Diameter messages in any way.

 

I think this is reading the RFC3588 in a too literal way. = One could argue that similarly there is nothing preventing an implementatio= n to use DIAMETER_TOO_BUSY as input to an adaptive overload control mechanism. OTOH, I would agree that it would be better if= this is explicitly mentioned in 3588-bis.

 

ii- 3.  Existing Mechanisms
 
   Diameter requires the use of a congestion-managed transpo=
rt layer,
   currently TCP or SCTP, to mitigate network congestion.&nb=
sp; But even with
   a congestion-managed transport, a Diameter node can becom=
e overloaded
   at the protocol layer due to the causes described in Sect=
ion 1.1.

 

It could be good to mention issues with TCP/SCTP congestio= n propagation and about using receiver window sizes.

 

 

iii- 4.2

        A DIAMETER_TOO_BUSY error c=
an only indicate overload at a "whole server" scope.

I thought that it would indicate overload for the application as indic=
ated in Application-Id. Is there any text in RFC3588 supporting either view=
?


 


iv- REQ 15:  The mechanism MUST NOT interfere with the congestion=
 control mechanisms of underlying transport protocols.


Does this mean that there shouldn’t be any reliance on indicatio=
ns from underlying transport protocol?


 


v- REQ 26:  The specification for the overload mechanism SHOULD o=
ffer


            gui=
dance on which message types might be desirable to


            pro=
cess over others during times of overload, based on


            Dia=
meter-specific considerations.  For example, it may be

            mor=
e beneficial to process messages for existing sessions


            ahe=
ad of new sessions.


I think the guidance should be for which messages should be sent rathe=
r than which ones should be processed.


 


vi- 2.2


   On the other hand, there are cases where the client needs=
 to be able


   to select a particular server from behind an agent. =
 For example, if


   a Diameter request is part of a multiple-round-trip authe=
ntication,


   or is otherwise part of a Diameter "session", i=
t may have a


   DestinationHost AVP that requires the request to be serve=
d by server


 


   1.  Therefore the agent may need to inform a client =
that a particular


   upstream server is overloaded or otherwise unavailable.


 


Is this always a feasible approach considering that client may not alw=
ays know the redundant pair for an overloaded server? Probably a mechanism =
is needed which allows the server to communicate the identity of a redundan=
t pair. That was also work proposed back in 2007 and which did not move for=
ward due to lack of interest. Maybe it is time to pick it up again. Actuall=
y it could be preferable if Redundant Server info can be used directly by R=
elay Agent (did not analyze in depth whether there are any issues with this=
 approach though)


 


 


Thanks,


Tolga


 


 <=
/p>







From: dime-bou=
nces@ietf.org [mailto:dime-bounces@ietf.org]
On Behalf Of Eric McMurry

Sent: Thursday, May 17, 2012 1:43 PM

To: dime@ietf.org

Subject: [Dime] Diameter Overload Control Requirements






 




A new draft has been submitted intended to address r=
equirements for overload control in Diameter.  






 







 






 






Diameter deployments are growing in size and this is=
 becoming more of an issue.  We have seen significant interest in prov=
iding a mechanism to address it.  Hopefully this document is useful as=
 a base for discussion on what is needed and
 we welcome comments.






 






Abstract:








       When a Diameter server or=
 agent becomes overloaded, it needs to be able






       to gracefully reduce its =
load, typically by informing clients to reduce






       sending traffic for some =
period of time. Otherwise, it must continue to






       expend resources parsing =
and responding to Diameter messages, possibly






       resulting in congestion c=
ollapse. The existing mechanisms provided by






       Diameter are not sufficie=
nt for this purpose. This document describes






       the limitations of the ex=
isting mechanisms, and provides requirements






       for new overload manageme=
nt mechanisms.








 






The dime charter has an item,






 










- Mainta=
ining and/or progressing, along the standards track, the 










Diameter=
 Base protocol and Diameter Applications. This includes =











extensio=
ns to Diameter Base protocol that can be considered as enhanced 










features=
 or bug fixes.










 






that this seems suited to go under and we welcome co=
mment on that as well.






 






 
--_000_750381A9C4CFD449928BD2CAC1E734E001C46Ausmaexmb1sonusnet_-- From lionel.morand@orange.com Wed May 30 01:50:35 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4485521F86D7 for ; Wed, 30 May 2012 01:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uquNlKrh0O99 for ; Wed, 30 May 2012 01:50:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DE75C21F86B5 for ; Wed, 30 May 2012 01:50:33 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id A352F2DC305; Wed, 30 May 2012 10:50:32 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7D58F23804B; Wed, 30 May 2012 10:50:32 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 30 May 2012 10:50:32 +0200 From: To: Eric McMurry , "dime@ietf.org" Thread-Topic: [Dime] Diameter Overload Control Requirements Thread-Index: Ac00VKSaFVbksAlyTg2BMhcMY66kqwJ7ISnQ Date: Wed, 30 May 2012 08:50:31 +0000 Message-ID: <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.24.112414 Subject: Re: [Dime] Diameter Overload Control Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 08:50:35 -0000 (as individual) Hi Eric, Ben, I think that it is clear that it is required to further detail how to provi= de overload control in Diameter based networks, especially in large network= s such as mobile networks. However, in order to see exactly what to do, I think that we should first a= gree on what are missing pieces in the current specifications. So the secti= on 4 should be further detailed to differentiate what should be clarified (= if required) from what should be defined. After a quick review, here is a set of comments as input for further discus= sion. The idea is that the set of requirements should be derived from a cle= ar problem statement. ********************* 4.1. Problems with Implicit Mechanism The implicit mechanism doesn't allow an agent or server to inform the client of a problem until it is effectively too late to do anything about it. The client does not know to take action until the upstream node has effectively failed. A Diameter node has no opportunity to shed load early to avoid collapse in the first place. Additionally, the implicit mechanism cannot distinguish between overload of a Diameter node and network congestion. Diameter treats the failure to receive an answer as a transport failure. [Lionel] IMHO, the first priority would be to clarify the relationship betw= een Overload and Network congestion. Another one would be to clarify/verify= some assumptions taken as baselines all along the document such as "inform= the client of a problem until it is effectively too late to do anything ab= out it". As explained below. =20 4.2. Problems with Explicit Mechanisms The Diameter specification is ambiguous on how a client should handle receipt of a DIAMETER_TOO_BUSY response. The base specification [I-D.ietf-dime-rfc3588bis] indicates that the sending client should attempt to send the request to a different peer. It makes no suggestion that a the receipt of a DIAMETER_TOO_BUSY response should affect future Diameter messages in any way. [Lionel] in RFC3588-bis, the SHOULD is meant as a strong recommendation for= application designers. So for me, the expected behavior of the receiver of= this result code is quite clear IMHO. If something needs to be further cla= rified, it may be the conditions for sending the DIAMETER_TOO_BUSY response= . It is assumed that the server will wait for being overloaded but there is= nothing preventing the server to apply a specific policy/algorithm allowin= g the server to modulate the traffic load.=20 There's a strong likelihood that at least some implementations will continue to send Diameter requests to an upstream peer even after receiving a DIAMETER_TOO_BUSY error. [Lionel] this would mean that these implementations would not follow the re= commendations put in the RFC. BCP 41 [RFC2914] describes, among other things, how end-to-end application behavior can help avoid congestion collapse. In particular, an application should avoid sending messages that will never be delivered or processed. The DIAMETER_TOO_BUSY behavior as described in the Diameter base specification fails at this, since if an upstream node becomes overloaded, a client attempts each request, and does not discover the need to failover the request until the initial attempt fails. [Lionel] As described above, it depends on the time the first DIAMETER_TOO_= BUSY response. But it is clear that this point needs to be further investig= ated.=20 The situation is improved if implementations follow the [RFC3539] recommendation and keep state about upstream peer overload. But even then, the Diameter specification offers no guidance on how long a client should wait before retrying the overloaded destination. If an agent or server supports multiple realms and/or applications, DIAMETER_TOO_BUSY only offers no way to indicate that it is overloaded for one application but not another. A DIAMETER_TOO_BUSY error can only indicate overload at a "whole server" scope. [Lionel] the DIAMETER_TOO_BUSY response is per application as it is in resp= onse to given command request using a specific application-id. But this poi= nt is maybe not so clear in the RFC3588bis. Agent processing of a DIAMETER_TOO_BUSY response is also problematic as described in the base specification. DIAMETER_TOO_BUSY is defined as a protocol error. If an agent receives a protocol error, it may either handle it locally or it may forward the response back towards the downstream peer. (The Diameter specification is inconsistent about whether a protocol error MAY or SHOULD be handled by an agent, rather than forwarded downstream.) If a downstream peer receives the DIAMETER_TOO_BUSY response, it may stop sending all requests to the agent for some period of time, even though the agent may still be able to deliver requests to other upstream peers. [Lionel] the DIAMETER_TOO_BUSY response is sent by the overloaded server. S= o if the Proxy/Relay forwards the response to a downstream client, the clie= nt can determine if the "busy" node is the agent or the server based on ori= gin-host of the response. About the behavior of the agent receiving the DIA= METER_TOO_BUSY response, it cannot be found in the base protocol but should= be defined par application, even if generic guidelines could be provided. [Lionel] Some texts on DIAMETER_UNABLE_TO_DELIVER may be useful also to exp= lain that there is also some gray area around its use, especially in a over= load control context. For instance, a client receiving this response does n= ot know the reason for which the request has not been delivered (e.g. IP fa= ilure, network congestion, etc.) and so it is not possible to provide a fin= er granularity of the client behavior, depending of different criteria can'= t be further detailed Regards, Lionel Morand ****************** De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de E= ric McMurry Envoy=E9=A0: jeudi 17 mai 2012 19:43 =C0=A0: dime@ietf.org Objet=A0: [Dime] Diameter Overload Control Requirements A new draft has been submitted intended to address requirements for overloa= d control in Diameter. =A0 http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt Diameter deployments are growing in size and this is becoming more of an is= sue. =A0We have seen significant interest in providing a mechanism to addre= ss it. =A0Hopefully this document is useful as a base for discussion on wha= t is needed and we welcome comments. Abstract: =A0 =A0 =A0 =A0When a Diameter server or agent becomes overloaded, it needs= to be able =A0 =A0 =A0 =A0to gracefully reduce its load, typically by informing client= s to reduce =A0 =A0 =A0 =A0sending traffic for some period of time. Otherwise, it must = continue to =A0 =A0 =A0 =A0expend resources parsing and responding to Diameter messages= , possibly =A0 =A0 =A0 =A0resulting in congestion collapse. The existing mechanisms pr= ovided by =A0 =A0 =A0 =A0Diameter are not sufficient for this purpose. This document = describes =A0 =A0 =A0 =A0the limitations of the existing mechanisms, and provides req= uirements =A0 =A0 =A0 =A0for new overload management mechanisms. The dime charter has an item, - Maintaining and/or progressing, along the standards track, the=A0 Diameter Base protocol and Diameter Applications. This includes=A0 extensions to Diameter Base protocol that can be considered as enhanced=A0 features or bug fixes. that this seems suited to go under and we welcome comment on that as well. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From dromasca@avaya.com Wed May 30 02:24:38 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C8621F86D0 for ; Wed, 30 May 2012 02:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRFN4AyCmHDb for ; Wed, 30 May 2012 02:24:37 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D7AF321F86C9 for ; Wed, 30 May 2012 02:24:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGPmxU+HCzI1/2dsb2JhbABEtASBB4IXAQEBAQMBAQEPHhcnBBMEAgEIDQQEAQELBgwLAQYBJh8JCAEBBAESCAEZh2kLnCSOEY8NiwWEYmADiA2SfIoBgmKBXQ X-IronPort-AV: E=Sophos;i="4.75,684,1330923600"; d="scan'208";a="308564684" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 May 2012 05:22:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 30 May 2012 05:06:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 May 2012 11:24:31 +0200 Message-ID: In-Reply-To: <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Overload Control Requirements Thread-Index: Ac00VKSaFVbksAlyTg2BMhcMY66kqwJ7ISnQAAEC0AA= References: <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup> From: "Romascanu, Dan (Dan)" To: , "Eric McMurry" , Subject: Re: [Dime] Diameter Overload Control Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 09:24:38 -0000 The I-D and Lionel's comments make a good case about the need for such a = piece of work. I would however suggest that we clarify better how we = estimate overload and congestion and how we differentiate between = overload and congestion caused by Diameter vs. other protocols run by = the same hosts and networks. I am somehow unconvinced by the language = used by the I-D which talks about 'Diameter networks', there is no such = things, we have networks and hosts that run Diameter together with many = other protocols, and congestion and overload is caused by their = combination. The 3GPP study that is referred does not either focus on = Diameter only. We need to understand what are the operational realities = and concerns to make sure that we do not develop sophisticated protocol = extensions in Diameter, which contribute only to alleviate a fraction of = the real problems that operator face.=20 Regards, Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of > lionel.morand@orange.com > Sent: Wednesday, May 30, 2012 11:51 AM > To: Eric McMurry; dime@ietf.org > Subject: Re: [Dime] Diameter Overload Control Requirements >=20 > (as individual) >=20 > Hi Eric, Ben, >=20 > I think that it is clear that it is required to further detail how to > provide overload control in Diameter based networks, especially in > large networks such as mobile networks. >=20 > However, in order to see exactly what to do, I think that we should > first agree on what are missing pieces in the current specifications. > So the section 4 should be further detailed to differentiate what > should be clarified (if required) from what should be defined. >=20 > After a quick review, here is a set of comments as input for further > discussion. The idea is that the set of requirements should be derived > from a clear problem statement. >=20 > ********************* > 4.1. Problems with Implicit Mechanism >=20 > The implicit mechanism doesn't allow an agent or server to inform > the > client of a problem until it is effectively too late to do anything > about it. The client does not know to take action until the > upstream > node has effectively failed. A Diameter node has no opportunity to > shed load early to avoid collapse in the first place. >=20 > Additionally, the implicit mechanism cannot distinguish between > overload of a Diameter node and network congestion. Diameter = treats > the failure to receive an answer as a transport failure. >=20 > [Lionel] IMHO, the first priority would be to clarify the relationship > between Overload and Network congestion. Another one would be to > clarify/verify some assumptions taken as baselines all along the > document such as "inform the client of a problem until it is > effectively too late to do anything about it". As explained below. >=20 >=20 > 4.2. Problems with Explicit Mechanisms >=20 > The Diameter specification is ambiguous on how a client should > handle > receipt of a DIAMETER_TOO_BUSY response. The base specification > [I-D.ietf-dime-rfc3588bis] indicates that the sending client should > attempt to send the request to a different peer. It makes no > suggestion that a the receipt of a DIAMETER_TOO_BUSY response = should > affect future Diameter messages in any way. >=20 > [Lionel] in RFC3588-bis, the SHOULD is meant as a strong = recommendation > for application designers. So for me, the expected behavior of the > receiver of this result code is quite clear IMHO. If something needs = to > be further clarified, it may be the conditions for sending the > DIAMETER_TOO_BUSY response. It is assumed that the server will wait = for > being overloaded but there is nothing preventing the server to apply a > specific policy/algorithm allowing the server to modulate the traffic > load. >=20 > There's a strong likelihood that at least some implementations will > continue to send Diameter requests to an upstream peer even after > receiving a DIAMETER_TOO_BUSY error. >=20 > [Lionel] this would mean that these implementations would not follow > the recommendations put in the RFC. >=20 > BCP 41 [RFC2914] describes, among other things, how end-to-end > application behavior can help avoid congestion collapse. In > particular, an application should avoid sending messages that will > never be delivered or processed. The DIAMETER_TOO_BUSY behavior as > described in the Diameter base specification fails at this, since = if > an upstream node becomes overloaded, a client attempts each = request, > and does not discover the need to failover the request until the > initial attempt fails. >=20 > [Lionel] As described above, it depends on the time the first > DIAMETER_TOO_BUSY response. But it is clear that this point needs to = be > further investigated. >=20 > The situation is improved if implementations follow the [RFC3539] > recommendation and keep state about upstream peer overload. But > even > then, the Diameter specification offers no guidance on how long a > client should wait before retrying the overloaded destination. If > an > agent or server supports multiple realms and/or applications, > DIAMETER_TOO_BUSY only offers no way to indicate that it is > overloaded for one application but not another. A = DIAMETER_TOO_BUSY > error can only indicate overload at a "whole server" scope. >=20 > [Lionel] the DIAMETER_TOO_BUSY response is per application as it is in > response to given command request using a specific application-id. But > this point is maybe not so clear in the RFC3588bis. >=20 > Agent processing of a DIAMETER_TOO_BUSY response is also = problematic > as described in the base specification. DIAMETER_TOO_BUSY is > defined > as a protocol error. If an agent receives a protocol error, it may > either handle it locally or it may forward the response back = towards > the downstream peer. (The Diameter specification is inconsistent > about whether a protocol error MAY or SHOULD be handled by an = agent, > rather than forwarded downstream.) If a downstream peer receives > the > DIAMETER_TOO_BUSY response, it may stop sending all requests to the > agent for some period of time, even though the agent may still be > able to deliver requests to other upstream peers. >=20 > [Lionel] the DIAMETER_TOO_BUSY response is sent by the overloaded > server. So if the Proxy/Relay forwards the response to a downstream > client, the client can determine if the "busy" node is the agent or = the > server based on origin-host of the response. About the behavior of the > agent receiving the DIAMETER_TOO_BUSY response, it cannot be found in > the base protocol but should be defined par application, even if > generic guidelines could be provided. >=20 > [Lionel] Some texts on DIAMETER_UNABLE_TO_DELIVER may be useful also = to > explain that there is also some gray area around its use, especially = in > a overload control context. For instance, a client receiving this > response does not know the reason for which the request has not been > delivered (e.g. IP failure, network congestion, etc.) and so it is not > possible to provide a finer granularity of the client behavior, > depending of different criteria can't be further detailed >=20 > Regards, >=20 > Lionel Morand >=20 > ****************** >=20 > De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de > Eric McMurry > Envoy=E9=A0: jeudi 17 mai 2012 19:43 > =C0=A0: dime@ietf.org > Objet=A0: [Dime] Diameter Overload Control Requirements >=20 > A new draft has been submitted intended to address requirements for > overload control in Diameter. >=20 > http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt >=20 >=20 > Diameter deployments are growing in size and this is becoming more of > an issue. =A0We have seen significant interest in providing a = mechanism > to address it. =A0Hopefully this document is useful as a base for > discussion on what is needed and we welcome comments. >=20 > Abstract: > =A0 =A0 =A0 =A0When a Diameter server or agent becomes overloaded, it = needs to > be able > =A0 =A0 =A0 =A0to gracefully reduce its load, typically by informing = clients to > reduce > =A0 =A0 =A0 =A0sending traffic for some period of time. Otherwise, it = must > continue to > =A0 =A0 =A0 =A0expend resources parsing and responding to Diameter = messages, > possibly > =A0 =A0 =A0 =A0resulting in congestion collapse. The existing = mechanisms > provided by > =A0 =A0 =A0 =A0Diameter are not sufficient for this purpose. This = document > describes > =A0 =A0 =A0 =A0the limitations of the existing mechanisms, and = provides > requirements > =A0 =A0 =A0 =A0for new overload management mechanisms. >=20 > The dime charter has an item, >=20 > - Maintaining and/or progressing, along the standards track, the > Diameter Base protocol and Diameter Applications. This includes > extensions to Diameter Base protocol that can be considered as > enhanced > features or bug fixes. >=20 > that this seems suited to go under and we welcome comment on that as > well. >=20 >=20 >=20 > = _______________________________________________________________________ > __________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a > ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From emcmurry@estacado.net Wed May 30 05:54:47 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63F621F849B for ; Wed, 30 May 2012 05:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU87m4n066qa for ; Wed, 30 May 2012 05:54:46 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61221F8685 for ; Wed, 30 May 2012 05:54:45 -0700 (PDT) Received: from embp.mcmurry.home (cpe-76-184-161-215.tx.res.rr.com [76.184.161.215]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q4UCsbIP026512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 May 2012 07:54:42 -0500 (CDT) (envelope-from emcmurry@estacado.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_2A4A8A07-BC1B-4CAA-BC7B-87F354825593" From: Eric McMurry In-Reply-To: <750381A9C4CFD449928BD2CAC1E734E001C46A@usma-ex-mb1.sonusnet.com> Date: Wed, 30 May 2012 07:54:32 -0500 Message-Id: <4648B7C6-8C23-405C-9232-9B7BD2FA4BEF@estacado.net> References: <750381A9C4CFD449928BD2CAC1E734E001C46A@usma-ex-mb1.sonusnet.com> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.1278) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Overload Control Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 12:54:47 -0000 --Apple-Mail=_2A4A8A07-BC1B-4CAA-BC7B-87F354825593 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the comments Tolga. Responses are inline. On May 29, 2012, at 21:01 , Asveren, Tolga wrote: > There was an attempt around 2007 to start this work but at that time = there wasn=92t much interest. I don=92t recall any strong technical = objections but Diameter traffic volumes were not as high as now so there = wasn=92t an immediate need. I hope this time it goes through. > =20 > A few comments after a quick read: > =20 > i- 4.2. Problems with Explicit Mechanisms > =20 > The Diameter specification is ambiguous on how a client should = handle > receipt of a DIAMETER_TOO_BUSY response. The base specification > [I-D.ietf-dime-rfc3588bis] indicates that the sending client should > attempt to send the request to a different peer. It makes no > suggestion that a the receipt of a DIAMETER_TOO_BUSY response = should > affect future Diameter messages in any way. > =20 > I think this is reading the RFC3588 in a too literal way. One could = argue that similarly there is nothing preventing an implementation to = use DIAMETER_TOO_BUSY as input to an adaptive overload control = mechanism. OTOH, I would agree that it would be better if this is = explicitly mentioned in 3588-bis. > =20 The behavior for DIAMETER_TOO_BUSY is generally underspecified and not = using it for this purpose avoids tying that confusion into overload = control. I agree with you that fixing it in 3588-bis would be nice, but = that draft is done (approved for RFC). > ii- 3. Existing Mechanisms > =20 > Diameter requires the use of a congestion-managed transport layer, > currently TCP or SCTP, to mitigate network congestion. But even = with > a congestion-managed transport, a Diameter node can become = overloaded > at the protocol layer due to the causes described in Section 1.1. > =20 > It could be good to mention issues with TCP/SCTP congestion = propagation and about using receiver window sizes. We can do that. I think the point here was that there is an issue at = the Diameter layer regardless of what happens at the transport layer. = For example, transports do not address multi hop or multi destination = scenarios. > =20 > =20 > iii- 4.2 > A DIAMETER_TOO_BUSY error can only indicate overload at a = "whole server" scope. > I thought that it would indicate overload for the application as = indicated in Application-Id. Is there any text in RFC3588 supporting = either view? not explicitly. However, DIAMETER_TOO_BUSY can only be used when a = specific server is requested, implying that it has a server scope. from Ben: This drives home the underspecified nature if too_busy. You = have to read between the lines to figure out what you can do with it. = I've talked to people who ignore the "specific server" rule because it = really doesn't make sense. We interpreted as "server", and you = interpreted it as server+application. This makes interop problematic. > =20 > iv- REQ 15: The mechanism MUST NOT interfere with the congestion = control mechanisms of underlying transport protocols. > Does this mean that there shouldn=92t be any reliance on indications = from underlying transport protocol? This was intended to keep the Diameter overload control mechanism from = preventing the proper operation of whatever transport it is using. = =46rom Adam: For example, a mechanism that opened additional TCP = connections when the network is congested would reduce the effectiveness = of the underlying congestion control mechanisms. I recall that at some point we had a requirement for transport = independence that would have covered what you are asking about. I'm not = sure when it fell out. Do you think it makes sense for that to be = there? > =20 > v- REQ 26: The specification for the overload mechanism SHOULD offer > guidance on which message types might be desirable to > process over others during times of overload, based on > Diameter-specific considerations. For example, it may be > more beneficial to process messages for existing sessions > ahead of new sessions. > I think the guidance should be for which messages should be sent = rather than which ones should be processed. I was thinking in terms of what was going on at an overloaded element = for this one. You have a good point though and it should cover both = ends. > =20 > vi- 2.2 > On the other hand, there are cases where the client needs to be = able > to select a particular server from behind an agent. For example, = if > a Diameter request is part of a multiple-round-trip authentication, > or is otherwise part of a Diameter "session", it may have a > DestinationHost AVP that requires the request to be served by = server > =20 > 1. Therefore the agent may need to inform a client that a = particular > upstream server is overloaded or otherwise unavailable. > =20 > Is this always a feasible approach considering that client may not = always know the redundant pair for an overloaded server? Probably a = mechanism is needed which allows the server to communicate the identity = of a redundant pair. That was also work proposed back in 2007 and which = did not move forward due to lack of interest. Maybe it is time to pick = it up again. Actually it could be preferable if Redundant Server info = can be used directly by Relay Agent (did not analyze in depth whether = there are any issues with this approach though) For a redundant pair that are functionally identical for the purposes of = serving the request in the example (and which may use a shared IP, DNS, = or some other mechanism outside of Diameter for routing to the pair) the = client wouldn't necessarily be able to distinguish the pair mates. In = this case, overload should only be reported if both of the servers are = overloaded. This applies any scenario where multiple servers can = transparently serve the same request. The servers in these cases will = have to coordinate reporting of overload.=20 A mechanism that allows multiple ways of specifying the scope of the = overload would be helpful here. --Apple-Mail=_2A4A8A07-BC1B-4CAA-BC7B-87F354825593 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
There was an attempt = around 2007 to start this work but at that time there wasn=92t much = interest. I don=92t recall any strong technical objections but Diameter = traffic volumes were not as high as now so there wasn=92t an immediate = need. I hope this time it goes through.
 
A few comments after a quick = read:
i- = 4.2.  Problems with Explicit Mechanisms
 
   The Diameter = specification is ambiguous on how a client should = handle
   receipt of a = DIAMETER_TOO_BUSY response.  The base = specification
   = [I-D.ietf-dime-rfc3588bis] indicates that the sending client = should
   attempt to send the = request to a different peer.  It makes = no
   suggestion that a the receipt = of a DIAMETER_TOO_BUSY response should
   affect future Diameter messages in any = way.
 
I think this is reading the RFC3588 in a too literal way. One = could argue that similarly there is nothing preventing an implementation = to use DIAMETER_TOO_BUSY as input to an adaptive overload control = mechanism. OTOH, I would agree that it would be better if this is = explicitly mentioned in 3588-bis.
 

<= /div>
The behavior for DIAMETER_TOO_BUSY is generally underspecified = and not using it for this purpose avoids tying that confusion into = overload control.  I agree with you that fixing it in 3588-bis = would be nice, but that draft is done (approved for = RFC).

ii- 3.  Existing =
Mechanisms
 
   currently TCP or SCTP, =
to mitigate network congestion.  But even with
   at the protocol layer =
due to the causes described in Section 1.1.
 
It could be good to mention issues = with TCP/SCTP congestion propagation and about using receiver window = sizes.

We = can do that.  I think the point here was that there is an issue at = the Diameter layer regardless of what happens at the transport layer. =  For example, transports do not address multi hop or multi = destination scenarios.

 
 
iii- 4.2
I thought that it would indicate overload for the =
application as indicated in Application-Id. Is there any text in RFC3588 =
supporting either =
view?

not =
explicitly.  However, DIAMETER_TOO_BUSY can only be used when a =
specific server is requested, implying that it has a server =
scope.

from Ben: This drives home the =
underspecified nature if too_busy. You have to read between the lines to =
figure out what you can do with it. I've talked to people who ignore the =
"specific server" rule because it really doesn't make sense. We =
interpreted as "server", and you interpreted it as =
server+application.

This makes interop =
problematic.

iv- REQ 15:  The mechanism MUST NOT =
interfere with the congestion control mechanisms of underlying transport =
protocols.
Does this mean that there shouldn=92t be =
any reliance on indications from underlying transport =
protocol?

This =
was intended to keep the Diameter overload control mechanism from =
preventing the proper operation of whatever transport  it is using. =
 =46rom Adam: For example, a mechanism that opened additional TCP =
connections when the network is congested would reduce the effectiveness =
of the underlying congestion control =
mechanisms.

I recall that at some point we had =
a requirement for transport independence that would have covered what =
you are asking about.  I'm not sure when it fell out.  Do you =
think it makes sense for that to be there?

v- REQ 26:  The specification for the =
overload mechanism SHOULD offer
     =
       guidance on which message =
types might be desirable to
I think the guidance should be for =
which messages should be sent rather than which ones should be =
processed.

I =
was thinking in terms of what was going on at an overloaded element for =
this one.  You have a good point though and it should cover both =
ends.

vi- 2.2
   to select a particular server =
from behind an agent.  For example, if
   or is otherwise part of =
a Diameter "session", it may have a
 
   upstream server is =
overloaded or otherwise unavailable.
Is this always a feasible approach =
considering that client may not always know the redundant pair for an =
overloaded server? Probably a mechanism is needed which allows the =
server to communicate the identity of a redundant pair. That was also =
work proposed back in 2007 and which did not move forward due to lack of =
interest. Maybe it is time to pick it up again. Actually it could be =
preferable if Redundant Server info can be used directly by Relay Agent =
(did not analyze in depth whether there are any issues with this =
approach though)

For =
a redundant pair that are functionally identical for the purposes of =
serving the request in the example (and which may use a shared IP, DNS, =
or some other mechanism outside of Diameter for routing to the pair) the =
client wouldn't necessarily be able to distinguish the pair mates. =
 In this case, overload should only be reported if both of the =
servers are overloaded.  This applies any scenario where multiple =
servers can transparently serve the same request.  The servers in =
these cases will have to coordinate reporting of =
overload. 

A mechanism that allows =
multiple ways of specifying the scope of the overload would be helpful =
here.

=

--Apple-Mail=_2A4A8A07-BC1B-4CAA-BC7B-87F354825593--

From emcmurry@estacado.net  Wed May 30 06:36:38 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA73121F8702 for ; Wed, 30 May 2012 06:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Uzihg5vjb0j for ; Wed, 30 May 2012 06:36:38 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id C85FF21F86FD for ; Wed, 30 May 2012 06:36:37 -0700 (PDT)
Received: from embp.mcmurry.home (cpe-76-184-161-215.tx.res.rr.com [76.184.161.215]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q4UDaQjf038454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 May 2012 08:36:30 -0500 (CDT) (envelope-from emcmurry@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=iso-8859-1
From: Eric McMurry 
In-Reply-To: <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Wed, 30 May 2012 08:36:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <544B99F3-1AD3-4600-A2D0-A28EFCF8BC0D@estacado.net>
References:  <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: 
X-Mailer: Apple Mail (2.1278)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 13:36:39 -0000

Hi Lionel,

Thank you for the comments.  Based on your, and Dan's comments, adding =
more detail to the problem statement and front matter makes sense.  I've =
responded to your points below.


On May 30, 2012, at 3:50 ,  wrote:

> (as individual)
>=20
> Hi Eric, Ben,
>=20
> I think that it is clear that it is required to further detail how to =
provide overload control in Diameter based networks, especially in large =
networks such as mobile networks.
>=20
> However, in order to see exactly what to do, I think that we should =
first agree on what are missing pieces in the current specifications. So =
the section 4 should be further detailed to differentiate what should be =
clarified (if required) from what should be defined.
>=20
> After a quick review, here is a set of comments as input for further =
discussion. The idea is that the set of requirements should be derived =
from a clear problem statement.
>=20
> *********************
> 4.1.  Problems with Implicit Mechanism
>=20
>   The implicit mechanism doesn't allow an agent or server to inform =
the
>   client of a problem until it is effectively too late to do anything
>   about it.  The client does not know to take action until the =
upstream
>   node has effectively failed.  A Diameter node has no opportunity to
>   shed load early to avoid collapse in the first place.
>=20
>   Additionally, the implicit mechanism cannot distinguish between
>   overload of a Diameter node and network congestion.  Diameter treats
>   the failure to receive an answer as a transport failure.
>=20
> [Lionel] IMHO, the first priority would be to clarify the relationship =
between Overload and Network congestion. Another one would be to =
clarify/verify some assumptions taken as baselines all along the =
document such as "inform the client of a problem until it is effectively =
too late to do anything about it". As explained below.
>=20

agree.   Overload vs. network congestion could use more clarification.  =
These are different and network congestion is not what we are trying to =
solve (transports do this).

>=20
> 4.2.  Problems with Explicit Mechanisms
>=20
>   The Diameter specification is ambiguous on how a client should =
handle
>   receipt of a DIAMETER_TOO_BUSY response.  The base specification
>   [I-D.ietf-dime-rfc3588bis] indicates that the sending client should
>   attempt to send the request to a different peer.  It makes no
>   suggestion that a the receipt of a DIAMETER_TOO_BUSY response should
>   affect future Diameter messages in any way.
>=20
> [Lionel] in RFC3588-bis, the SHOULD is meant as a strong =
recommendation for application designers. So for me, the expected =
behavior of the receiver of this result code is quite clear IMHO. If =
something needs to be further clarified, it may be the conditions for =
sending the DIAMETER_TOO_BUSY response. It is assumed that the server =
will wait for being overloaded but there is nothing preventing the =
server to apply a specific policy/algorithm allowing the server to =
modulate the traffic load.=20

There is mention of this being a transient error, but nothing specific.  =
I have seen multiple interpretations of the scope the error applies to.  =
In practice, implementations are using this in different ways.

>=20
>   There's a strong likelihood that at least some implementations will
>   continue to send Diameter requests to an upstream peer even after
>   receiving a DIAMETER_TOO_BUSY error.
>=20
> [Lionel] this would mean that these implementations would not follow =
the recommendations put in the RFC.

With no bounds on what transient means, implementations are open to =
start sending to the server reporting DIAMETER_TOO_BUSY as soon as the =
next request, although I would think that would not work particularly =
well.

>=20
>   BCP 41 [RFC2914] describes, among other things, how end-to-end
>   application behavior can help avoid congestion collapse.  In
>   particular, an application should avoid sending messages that will
>   never be delivered or processed.  The DIAMETER_TOO_BUSY behavior as
>   described in the Diameter base specification fails at this, since if
>   an upstream node becomes overloaded, a client attempts each request,
>   and does not discover the need to failover the request until the
>   initial attempt fails.
>=20
> [Lionel] As described above, it depends on the time the first =
DIAMETER_TOO_BUSY response. But it is clear that this point needs to be =
further investigated.=20
>=20
>   The situation is improved if implementations follow the [RFC3539]
>   recommendation and keep state about upstream peer overload.  But =
even
>   then, the Diameter specification offers no guidance on how long a
>   client should wait before retrying the overloaded destination.  If =
an
>   agent or server supports multiple realms and/or applications,
>   DIAMETER_TOO_BUSY only offers no way to indicate that it is
>   overloaded for one application but not another.  A DIAMETER_TOO_BUSY
>   error can only indicate overload at a "whole server" scope.
>=20
> [Lionel] the DIAMETER_TOO_BUSY response is per application as it is in =
response to given command request using a specific application-id. But =
this point is maybe not so clear in the RFC3588bis.
>=20
>   Agent processing of a DIAMETER_TOO_BUSY response is also problematic
>   as described in the base specification.  DIAMETER_TOO_BUSY is =
defined
>   as a protocol error.  If an agent receives a protocol error, it may
>   either handle it locally or it may forward the response back towards
>   the downstream peer.  (The Diameter specification is inconsistent
>   about whether a protocol error MAY or SHOULD be handled by an agent,
>   rather than forwarded downstream.)  If a downstream peer receives =
the
>   DIAMETER_TOO_BUSY response, it may stop sending all requests to the
>   agent for some period of time, even though the agent may still be
>   able to deliver requests to other upstream peers.
>=20
> [Lionel] the DIAMETER_TOO_BUSY response is sent by the overloaded =
server. So if the Proxy/Relay forwards the response to a downstream =
client, the client can determine if the "busy" node is the agent or the =
server based on origin-host of the response. About the behavior of the =
agent receiving the DIAMETER_TOO_BUSY response, it cannot be found in =
the base protocol but should be defined par application, even if generic =
guidelines could be provided.
>=20
> [Lionel] Some texts on DIAMETER_UNABLE_TO_DELIVER may be useful also =
to explain that there is also some gray area around its use, especially =
in a overload control context. For instance, a client receiving this =
response does not know the reason for which the request has not been =
delivered (e.g. IP failure, network congestion, etc.) and so it is not =
possible to provide a finer granularity of the client behavior, =
depending of different criteria can't be further detailed
>=20

Good point.  We can add something on this.



From ecnoel@research.att.com  Wed May 30 06:24:02 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357A321F86D0 for ; Wed, 30 May 2012 06:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level: 
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b07AYehgMzIq for ; Wed, 30 May 2012 06:24:00 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 898BE21F865C for ; Wed, 30 May 2012 06:23:59 -0700 (PDT)
Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id CBFF9120251 for ; Wed, 30 May 2012 09:23:58 -0400 (EDT)
Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id C0E61BFA2; Wed, 30 May 2012 09:23:58 -0400 (EDT)
Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%15]) with mapi; Wed, 30 May 2012 09:22:57 -0400
From: "NOEL, ERIC C (ERIC C)" 
To: "DOLLY, MARTIN C" , "'dime@ietf.org'" 
Date: Wed, 30 May 2012 09:22:56 -0400
Thread-Topic: [Dime] Diameter Overload Control Requirements
Thread-Index: AQHNNFSXvZMQDf0LpUmFPbEbcScN7ZbguwqwgAGqYsA=
Message-ID: <5EBD159DE88147488A3B1590E090018403163F490136@njfpsrvexg2.research.att.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5EBD159DE88147488A3B1590E090018403163F490136njfpsrvexg2_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 30 May 2012 08:02:06 -0700
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 13:24:02 -0000

--_000_5EBD159DE88147488A3B1590E090018403163F490136njfpsrvexg2_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I support this work.

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
ecnoel@att.com

From: DOLLY, MARTIN C
Sent: Tuesday, May 29, 2012 8:01 AM
To: 3GPP_TSG_CT_IETF-COORD@list.etsi.org; 3GPP_TSG_CT_WG4@list.etsi.org; 3G=
PP_TSG_CT_WG3@list.etsi.org
Cc: CHASTAIN, COOPER; FREEMAN, BRIAN D; NOEL, ERIC C (ERIC C); YUAN, CHIN; =
QIU, CHAOXIN C; Campbell, Ben; SHAW, VENSON M; JOHNSON, CAROLYN R; 'Henders=
on, Scott'; Eric McMurry; WANG, JIANRONG; FIGURELLE, TERRY F; Roach, Adam
Subject: FW: [Dime] Diameter Overload Control Requirements
Importance: High

Hello,

Hope you all had safe travels back home.

AT&T has been working with Tekelec on Diameter Overload Requirements, analo=
gous to the SIP Overload work.

We request your support on the DIME list in order to get this work started =
in the IETF. (e.g., a simple, "I support this work").

Better, would be review and comments to the list.

Thank you,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Services, Inc.
md3135@att.com
+1-609-903-3360



From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eri=
c McMurry
Sent: Thursday, May 17, 2012 1:43 PM
To: dime@ietf.org
Subject: [Dime] Diameter Overload Control Requirements

A new draft has been submitted intended to address requirements for overloa=
d control in Diameter.

http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt


Diameter deployments are growing in size and this is becoming more of an is=
sue.  We have seen significant interest in providing a mechanism to address=
 it.  Hopefully this document is useful as a base for discussion on what is=
 needed and we welcome comments.

Abstract:
       When a Diameter server or agent becomes overloaded, it needs to be a=
ble
       to gracefully reduce its load, typically by informing clients to red=
uce
       sending traffic for some period of time. Otherwise, it must continue=
 to
       expend resources parsing and responding to Diameter messages, possib=
ly
       resulting in congestion collapse. The existing mechanisms provided b=
y
       Diameter are not sufficient for this purpose. This document describe=
s
       the limitations of the existing mechanisms, and provides requirement=
s
       for new overload management mechanisms.

The dime charter has an item,

- Maintaining and/or progressing, along the standards track, the
Diameter Base protocol and Diameter Applications. This includes
extensions to Diameter Base protocol that can be considered as enhanced
features or bug fixes.

that this seems suited to go under and we welcome comment on that as well.



--_000_5EBD159DE88147488A3B1590E090018403163F490136njfpsrvexg2_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I support=
 this work.
 
Thanks,<=
/span>
 
Eric Noel 
AT&T Labs, Inc. 
<=
span style=3D'font-size:9.0pt;font-family:"Verdana","sans-serif";color:#00B=
0E0'>Rethink Possible
 
Network Design=
 and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown=
, NJ 07748
P: 732.420.4174
ecnoel@att.com
 
From: DOLLY, MARTIN C 
Sent: Tuesday, May 29, 2012 8:01 AM
To: 3GPP_TSG_CT_IETF-COORD@list.e=
tsi.org; 3GPP_TSG_CT_WG4@list.etsi.org; 3GPP_TSG_CT_WG3@list.etsi.org
Cc: CHASTAIN, COOPER; FREEMAN, BRIAN D; NOEL, ERIC C (ERIC C); YUAN, C=
HIN; QIU, CHAOXIN C; Campbell, Ben; SHAW, VENSON M; JOHNSON, CAROLYN R; 'He=
nderson, Scott'; Eric McMurry; WANG, JIANRONG; FIGURELLE, TERRY F; Roach, A=
dam
Subject: FW: [Dime] Diameter Overload Control RequirementsImportance: High
 
Hello,
 
Hope you all had safe travels back home.
 
AT&T has been working with Tekelec on Diameter Overload Requ=
irements, analogous to the SIP Overload work.
 
We request your support on the DIME list in order to get this work started=
 in the IETF. (e.g., a simple, “I support this work”).
 
Better, would be review and comments to the list.
 
<=
p class=3DMsoNormal>Thank you,
 
Martin =
Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&=
;T Services, Inc.
md3135@att.com
+1-609-903-3360<=
/span>
 
 
 
From:=
 dime-bo=
unces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eric McMu=
rry
Sent: Thursday, May 17, 2012 1:43 PM
To: dime@ietf.=
org
Subject: [Dime] Diameter Overload Control Requirements
 
<=
p class=3DMsoNormal>A new draft has been submitted intended to address requ=
irements for overload control in Diameter.  
=

 
<=
a href=3D"http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt">h=
ttp://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt
 
 
Diamete=
r deployments are growing in size and this is becoming more of an issue. &n=
bsp;We have seen significant interest in providing a mechanism to address i=
t.  Hopefully this document is useful as a base for discussion on what=
 is needed and we welcome comments.
 
Abstract:<=
/o:p>
       Wh=
en a Diameter server or agent becomes overloaded, it needs to be able<=
/o:p>
       to grac=
efully reduce its load, typically by informing clients to reduce=

       sending traf=
fic for some period of time. Otherwise, it must continue to
<=
/div>
       expend resources =
parsing and responding to Diameter messages, possibly
<=
div>
       resulting in congestion=
 collapse. The existing mechanisms provided by
       Diameter are not sufficient fo=
r this purpose. This document describes
       the limitations of the existing mec=
hanisms, and provides requirements
       for new overload management mechanisms.
 
The dime charter has an item,
 
- Maintaining and/or progressing, along the standards=
 track, the 
Diameter Base protocol and Diameter Appl=
ications. This includes 
=

extensions to Diameter Base =
protocol that can be considered as enhanced <=
/p>
features=
 or bug fixes.
 
tha=
t this seems suited to go under and we welcome comment on that as well.
 
=

 
=

--_000_5EBD159DE88147488A3B1590E090018403163F490136njfpsrvexg2_--

From jouni.nospam@gmail.com  Wed May 30 08:22:59 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2509311E8083 for ; Wed, 30 May 2012 08:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.832
X-Spam-Level: 
X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kV6xGRsLVCq for ; Wed, 30 May 2012 08:22:58 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F333A11E8080 for ; Wed, 30 May 2012 08:22:57 -0700 (PDT)
Received: by yenq13 with SMTP id q13so3654259yen.31 for ; Wed, 30 May 2012 08:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=gLXmjc3pe2S4dAMdf4ER//k/D007I4QuPDnpGSMV0hA=; b=suGAVimLSATbrr44UeZ2o5QN9BhyZvXPLLUusw2g/KHKz2F8povjmZ/qiGxwDoBGan is1qB9+0gr9PcT0fPNCiv0Z0RaJE/o+lgtSH1vpVNjuvevHUfIAvfAebQLtqb22E3hqm zf0CjgOMRgzjbe7aLoGcss6jMrknCnpUMTvj9zdD7Mona7DP70Z2Y90DfCdNYeLDQB+v o9TjIisdODg/PktDYGPDZ/FPO+UKdJFcBwXYe3ElbytGSuo79G6Vj7ZGvEnWlYfLaypY 5SbUwL9FGfs+jvsOdsmpcRBawzDlX77NytbRNwLb/A07DhpJtfy7aqUl8mbGFNh8jMCh rIYg==
Received: by 10.60.3.40 with SMTP id 8mr15693207oez.31.1338391377442; Wed, 30 May 2012 08:22:57 -0700 (PDT)
Received: from a88-114-71-183.elisa-laajakaista.fi (a88-114-71-183.elisa-laajakaista.fi. [88.114.71.183]) by mx.google.com with ESMTPS id aj16sm6615oec.0.2012.05.30.08.22.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 May 2012 08:22:57 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Wed, 30 May 2012 18:21:36 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CD8EEAD-FD51-405F-AFE5-CC8CB372BEE9@gmail.com>
References: 
To: Eric McMurry 
X-Mailer: Apple Mail (2.1084)
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 15:22:59 -0000

Hi,

I skimmed through the document writeup. Thanks for writing it!  I have a =
couple of
observations. On the reasons for the overload situation, maybe one =
should also list
architectural issues and lack of "check points" i.e. if you are in a =
middle of a
multistep procedure and one of those fail you revert back to zero & =
restart. There
having a nice Diameter overload control does not help too much if then =
some earlier
non-Diameter part gets impatient and determines everything failed, even =
if the
delay/failure is temporary on some Diameter exchange.

Too bad we cannot really have system level solution requirements. In =
many cases the
overload "signal" needs to be propagated also to non-Diameter functions =
and elements.
But I guess that is an unsaid assumption here in the solution =
requirements, right? Is
this what the Req-23 tries to say?

My reading of the solution requirements is that it is already decided =
that extending
base protocol is the way to go. Basically req-2 states this. I don't =
think this is
particularly good for a requirements document.

Req-6 mentions a capability advertisement between peers but the later =
requirements
are more geared towards end-to-end capability advertisement (like =
req-29..). So
which one is more desired? end-to-end or hop-by-hop or both?

Either req-11 or req-13 should say that the overload indication must not =
cause even
more signaling into the network. Or is this what the req-14 actually =
tries to say?

Could you expand the req-15 a bit and give an example of possible cases =
that lead
to this requirement?

- Jouni





On May 17, 2012, at 8:43 PM, Eric McMurry wrote:

> A new draft has been submitted intended to address requirements for =
overload control in Diameter. =20
>=20
> http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt
>=20
>=20
> Diameter deployments are growing in size and this is becoming more of =
an issue.  We have seen significant interest in providing a mechanism to =
address it.  Hopefully this document is useful as a base for discussion =
on what is needed and we welcome comments.
>=20
> Abstract:
>        When a Diameter server or agent becomes overloaded, it needs to =
be able
>        to gracefully reduce its load, typically by informing clients =
to reduce
>        sending traffic for some period of time. Otherwise, it must =
continue to
>        expend resources parsing and responding to Diameter messages, =
possibly
>        resulting in congestion collapse. The existing mechanisms =
provided by
>        Diameter are not sufficient for this purpose. This document =
describes
>        the limitations of the existing mechanisms, and provides =
requirements
>        for new overload management mechanisms.
>=20
> The dime charter has an item,
>=20
> - Maintaining and/or progressing, along the standards track, the=20
> Diameter Base protocol and Diameter Applications. This includes=20
> extensions to Diameter Base protocol that can be considered as =
enhanced=20
> features or bug fixes.
>=20
> that this seems suited to go under and we welcome comment on that as =
well.
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From adam@nostrum.com  Wed May 30 09:02:21 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E5911E808E for ; Wed, 30 May 2012 09:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLBEPy60BUOP for ; Wed, 30 May 2012 09:02:19 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C58711E8083 for ; Wed, 30 May 2012 09:02:19 -0700 (PDT)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4UG2Fs7099459 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 May 2012 11:02:16 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4FC64487.7090102@nostrum.com>
Date: Wed, 30 May 2012 11:02:15 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Asveren, Tolga" 
References:  <750381A9C4CFD449928BD2CAC1E734E001C46A@usma-ex-mb1.sonusnet.com>
In-Reply-To: <750381A9C4CFD449928BD2CAC1E734E001C46A@usma-ex-mb1.sonusnet.com>
Content-Type: multipart/alternative; boundary="------------060105090101070505040704"
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 16:02:21 -0000

This is a multi-part message in MIME format.
--------------060105090101070505040704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 5/29/12 9:01 PM, Asveren, Tolga wrote:
> iv- REQ 15:  The mechanism MUST NOT interfere with the congestion control mechanisms of underlying transport protocols.
> Does this mean that there shouldn't be any reliance on indications from underlying transport protocol?

I think something that's been conflated in this some of the comments so 
far is that network congestion is a different problem than server 
overload. The first problem -- network congestion -- is addressed by TCP 
and SCTP, and I don't think that we could do much to improve upon those 
mechanisms. (This would, in any case, be the wrong place to do so). What 
we're trying to solve is the second problem: server overload.

Even though these are different problems, there is clearly an 
interaction between them. It is possible to do things at the application 
layer that defeats or damages TCP and SCTP's ability to manage 
congestion. One example would be opening multiple TCP connections under 
high load conditions. The point of REQ 15 is that the server overload 
management solution cannot take this or any similar actions that would 
harm network congestion management.

/a

--------------060105090101070505040704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 5/29/12 9:01 PM, Asveren, Tolga wrote:
    

      
iv- REQ 15:  The mechanism MUST NOT interfere with the congestion control mechanisms of underlying transport protocols.

      
Does this mean that there shouldn’t be any reliance on indications from underlying transport protocol?

    

    

    I think something that's been conflated in this some of the comments
    so far is that network congestion is a different problem than server
    overload. The first problem -- network congestion -- is addressed by
    TCP and SCTP, and I don't think that we could do much to improve
    upon those mechanisms. (This would, in any case, be the wrong place
    to do so). What we're trying to solve is the second problem: server
    overload.

    

    Even though these are different problems, there is clearly an
    interaction between them. It is possible to do things at the
    application layer that defeats or damages TCP and SCTP's ability to
    manage congestion. One example would be opening multiple TCP
    connections under high load conditions. The point of REQ 15 is that
    the server overload management solution cannot take this or any
    similar actions that would harm network congestion management.

    

    /a

  


--------------060105090101070505040704--

From jgunn6@csc.com  Wed May 30 09:44:16 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE69F11E80A1; Wed, 30 May 2012 09:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecXnd7f5NDjP; Wed, 30 May 2012 09:44:15 -0700 (PDT)
Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by ietfa.amsl.com (Postfix) with ESMTP id E9D4321F859F; Wed, 30 May 2012 09:44:14 -0700 (PDT)
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-9.tower-170.messagelabs.com!1338396252!21498231!1
X-Originating-IP: [20.137.2.87]
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8242 invoked from network); 30 May 2012 16:44:13 -0000
Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-9.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 May 2012 16:44:13 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q4UGi1C8025530; Wed, 30 May 2012 12:44:11 -0400
In-Reply-To: 
References: 
To: Eric McMurry 
MIME-Version: 1.0
X-KeepSent: C775270D:24833142-85257A0E:005B537C; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2FP3 July 11, 2011
From: Janet P Gunn 
Message-ID: 
Date: Wed, 30 May 2012 12:44:06 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 05/30/2012 12:40:39 PM, Serialize complete at 05/30/2012 12:40:39 PM
Content-Type: multipart/alternative; boundary="=_alternative 005B5D8685257A0E_="
Cc: dime-bounces@ietf.org, dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 16:44:16 -0000

This is a multipart message in MIME format.
--=_alternative 005B5D8685257A0E_=
Content-Type: text/plain; charset="US-ASCII"

I support this work, and will have comments later.

Janet Gunn

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.



From:   Eric McMurry 
To:     dime@ietf.org
Date:   05/17/2012 01:43 PM
Subject:        [Dime] Diameter Overload Control Requirements
Sent by:        dime-bounces@ietf.org



A new draft has been submitted intended to address requirements for 
overload control in Diameter. 

http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt


Diameter deployments are growing in size and this is becoming more of an 
issue.  We have seen significant interest in providing a mechanism to 
address it.  Hopefully this document is useful as a base for discussion on 
what is needed and we welcome comments.

Abstract:
       When a Diameter server or agent becomes overloaded, it needs to be 
able
       to gracefully reduce its load, typically by informing clients to 
reduce
       sending traffic for some period of time. Otherwise, it must 
continue to
       expend resources parsing and responding to Diameter messages, 
possibly
       resulting in congestion collapse. The existing mechanisms provided 
by
       Diameter are not sufficient for this purpose. This document 
describes
       the limitations of the existing mechanisms, and provides 
requirements
       for new overload management mechanisms.

The dime charter has an item,

- Maintaining and/or progressing, along the standards track, the 
Diameter Base protocol and Diameter Applications. This includes 
extensions to Diameter Base protocol that can be considered as enhanced 
features or bug fixes.

that this seems suited to go under and we welcome comment on that as well.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


--=_alternative 005B5D8685257A0E_=
Content-Type: text/html; charset="US-ASCII"

I support this work, and will have comments
later.



Janet Gunn



This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.







From:      
 Eric McMurry <emcmurry@estacado.net>

To:      
 dime@ietf.org

Date:      
 05/17/2012 01:43 PM

Subject:    
   [Dime] Diameter
Overload Control Requirements

Sent by:    
   dime-bounces@ietf.org









A new draft has been submitted intended to address requirements
for overload control in Diameter.  



http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt





Diameter deployments are growing in size and this is becoming
more of an issue.  We have seen significant interest in providing
a mechanism to address it.  Hopefully this document is useful as a
base for discussion on what is needed and we welcome comments.



Abstract:

       When a Diameter server or agent
becomes overloaded, it needs to be able

       to gracefully reduce its load,
typically by informing clients to reduce

       sending traffic for some period
of time. Otherwise, it must continue to

       expend resources parsing and
responding to Diameter messages, possibly

       resulting in congestion collapse.
The existing mechanisms provided by

       Diameter are not sufficient
for this purpose. This document describes

       the limitations of the existing
mechanisms, and provides requirements

       for new overload management
mechanisms.



The dime charter has an item,



- Maintaining and/or progressing, along the
standards track, the 

Diameter Base protocol and Diameter Applications.
This includes 

extensions to Diameter Base protocol that
can be considered as enhanced 

features or bug fixes.



that this seems suited to go under and we welcome comment
on that as well.



_______________________________________________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime




--=_alternative 005B5D8685257A0E_=--

From Tina.Tsou.Zouting@huawei.com  Wed May 30 09:54:53 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D72E11E8086; Wed, 30 May 2012 09:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.42
X-Spam-Level: 
X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.178,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDiti83-tHPh; Wed, 30 May 2012 09:54:52 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 42F8B11E8099; Wed, 30 May 2012 09:54:52 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGR27566; Wed, 30 May 2012 12:54:52 -0400 (EDT)
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 May 2012 09:51:56 -0700
Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Wed, 30 May 2012 09:51:59 -0700
From: Tina TSOU 
To: Janet P Gunn , Eric McMurry 
Thread-Topic: [Dime] Diameter Overload Control Requirements
Thread-Index: AQHNNFSc/JEStGQEwEa02FC6ISqRvZbjE4oA//+M11A=
Date: Wed, 30 May 2012 16:51:59 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.135.5]
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A80D3B52EDdfweml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dime-bounces@ietf.org" , "dime@ietf.org" 
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 16:54:53 -0000

--_000_C0E0A32284495243BDE0AC8A066631A80D3B52EDdfweml513mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Support too.

Tina

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jan=
et P Gunn
Sent: Wednesday, May 30, 2012 9:44 AM
To: Eric McMurry
Cc: dime-bounces@ietf.org; dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements

I support this work, and will have comments later.

Janet Gunn

This is a PRIVATE message. If you are not the intended recipient, please de=
lete without copying and kindly advise us by e-mail of the mistake in deliv=
ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC=
 to any order or other contract unless pursuant to explicit written agreeme=
nt or government initiative expressly permitting the use of e-mail for such=
 purpose.



From:        Eric McMurry 
To:        dime@ietf.org
Date:        05/17/2012 01:43 PM
Subject:        [Dime] Diameter Overload Control Requirements
Sent by:        dime-bounces@ietf.org
________________________________



A new draft has been submitted intended to address requirements for overloa=
d control in Diameter.

http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt


Diameter deployments are growing in size and this is becoming more of an is=
sue.  We have seen significant interest in providing a mechanism to address=
 it.  Hopefully this document is useful as a base for discussion on what is=
 needed and we welcome comments.

Abstract:
       When a Diameter server or agent becomes overloaded, it needs to be a=
ble
       to gracefully reduce its load, typically by informing clients to red=
uce
       sending traffic for some period of time. Otherwise, it must continue=
 to
       expend resources parsing and responding to Diameter messages, possib=
ly
       resulting in congestion collapse. The existing mechanisms provided b=
y
       Diameter are not sufficient for this purpose. This document describe=
s
       the limitations of the existing mechanisms, and provides requirement=
s
       for new overload management mechanisms.

The dime charter has an item,

- Maintaining and/or progressing, along the standards track, the
Diameter Base protocol and Diameter Applications. This includes
extensions to Diameter Base protocol that can be considered as enhanced
features or bug fixes.

that this seems suited to go under and we welcome comment on that as well.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--_000_C0E0A32284495243BDE0AC8A066631A80D3B52EDdfweml513mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Support too.


 <=
/p>

Tina

 <=
/p>







From: dime-bou=
nces@ietf.org [mailto:dime-bounces@ietf.org]
On Behalf Of Janet P Gunn

Sent: Wednesday, May 30, 2012 9:44 AM

To: Eric McMurry

Cc: dime-bounces@ietf.org; dime@ietf.org

Subject: Re: [Dime] Diameter Overload Control Requirements






 


I support this work, and will have commen=
ts later.




Janet Gunn



This is a PRIVATE message. If you are not the intended recipient, please de=
lete without copying and kindly advise us by e-mail of the mistake in deliv=
ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC=
 to any order or other contract
 unless pursuant to explicit written agreement or government initiative exp=
ressly permitting the use of e-mail for such purpose.








From:        E=
ric McMurry <emcmurry@estacado.net>


To:        d=
ime@ietf.org


Date:        0=
5/17/2012 01:43 PM


Subject:        [Dime] Diameter Overload Control Requirements


Sent by:        dime-bounces@ietf.org















A new draft has been submitted intended to address requirements for overloa=
d control in Diameter.  




=
http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt






Diameter deployments are growing in size and this is becoming more of an is=
sue.  We have seen significant interest in providing a mechanism to ad=
dress it.  Hopefully this document is useful as a base for discussion =
on what is needed and we welcome comments.




Abstract: 

       When a Diameter server or agent becomes overload=
ed, it needs to be able 

       to gracefully reduce its load, typically by info=
rming clients to reduce 

       sending traffic for some period of time. Otherwi=
se, it must continue to 

       expend resources parsing and responding to Diame=
ter messages, possibly 

       resulting in congestion collapse. The existing m=
echanisms provided by 

       Diameter are not sufficient for this purpose. Th=
is document describes 

       the limitations of the existing mechanisms, and =
provides requirements 

       for new overload management mechanisms. 



The dime charter has an item, 



- Maintaining and/or progressing, along the standards track, the


Diameter Base protocol and Diameter Applications. This includes


extensions to Diameter Base protocol that can be considered as e=
nhanced


features or bug fixes.




that this seems suited to go under and we welcome comment on that as well. =




______________________________________=
_________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime








--_000_C0E0A32284495243BDE0AC8A066631A80D3B52EDdfweml513mbxchi_--

From emcmurry@estacado.net  Wed May 30 11:06:20 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC09C21F85AC for ; Wed, 30 May 2012 11:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h42YmG28rX2 for ; Wed, 30 May 2012 11:06:20 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id D1B5321F85AA for ; Wed, 30 May 2012 11:06:19 -0700 (PDT)
Received: from dn3-227.estacado.net (dn3-227.estacado.net [172.16.3.227]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q4UI6C8L086082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 May 2012 13:06:13 -0500 (CDT) (envelope-from emcmurry@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Eric McMurry 
In-Reply-To: <5CD8EEAD-FD51-405F-AFE5-CC8CB372BEE9@gmail.com>
Date: Wed, 30 May 2012 13:06:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CC419BA-6822-48E6-B1F8-D2DF7FA712D1@estacado.net>
References:  <5CD8EEAD-FD51-405F-AFE5-CC8CB372BEE9@gmail.com>
To: jouni korhonen 
X-Mailer: Apple Mail (2.1278)
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 18:06:21 -0000

Thanks for the comments Jouni.  responses inline.

On May 30, 2012, at 10:21 , jouni korhonen wrote:

> Hi,
>=20
> I skimmed through the document writeup. Thanks for writing it!  I have =
a couple of
> observations. On the reasons for the overload situation, maybe one =
should also list
> architectural issues and lack of "check points" i.e. if you are in a =
middle of a
> multistep procedure and one of those fail you revert back to zero & =
restart. There
> having a nice Diameter overload control does not help too much if then =
some earlier
> non-Diameter part gets impatient and determines everything failed, =
even if the
> delay/failure is temporary on some Diameter exchange.
>=20
> Too bad we cannot really have system level solution requirements. In =
many cases the
> overload "signal" needs to be propagated also to non-Diameter =
functions and elements.
> But I guess that is an unsaid assumption here in the solution =
requirements, right? Is
> this what the Req-23 tries to say?

Even without network wide/solution level requirements, we can talk more =
about how this fits and what is going on  at a higher level.  Solving it =
across protocols is more of an application level issue though, and best =
addressed in application level specifications (in 3GPP for example).

>=20
> My reading of the solution requirements is that it is already decided =
that extending
> base protocol is the way to go. Basically req-2 states this. I don't =
think this is
> particularly good for a requirements document.

That part of req 2 was intended as an example and does not use =
requirement language, so I agree with you that it should not be a direct =
requirement.  That said, addressing this in the base makes sense to me =
and helps address several of the requirements.

>=20
> Req-6 mentions a capability advertisement between peers but the later =
requirements
> are more geared towards end-to-end capability advertisement (like =
req-29..). So
> which one is more desired? end-to-end or hop-by-hop or both?

The requirements were not intended to specify hop-by-hop or end-to-end.  =
SIP overload control, which informed this, landed on hop-by-hop, but =
Diameter has some characteristics that are different than SIP.  We were =
intending to leave this for the mechanism.

>=20
> Either req-11 or req-13 should say that the overload indication must =
not cause even
> more signaling into the network. Or is this what the req-14 actually =
tries to say?
>=20

14 was intended to cover this when load is high, and it can be implied =
from 13 also (hopefully).

> Could you expand the req-15 a bit and give an example of possible =
cases that lead
> to this requirement?
>=20

Adam covered this in his earlier response to Tolga.


From ben@nostrum.com  Wed May 30 12:27:57 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB4011E8124 for ; Wed, 30 May 2012 12:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.045
X-Spam-Level: 
X-Spam-Status: No, score=-102.045 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSSjmqWhtBF4 for ; Wed, 30 May 2012 12:27:56 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 44DB211E8113 for ; Wed, 30 May 2012 12:27:55 -0700 (PDT)
Received: from dn3-123.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4UJRhlV011963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 May 2012 14:27:44 -0500 (CDT) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=iso-8859-1
From: Ben Campbell 
In-Reply-To: 
Date: Wed, 30 May 2012 14:27:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1101A0B4-070C-4E62-96DF-3A0C95B614C9@nostrum.com>
References:  <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
To: "Romascanu, Dan (Dan)" 
X-Mailer: Apple Mail (2.1278)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 19:27:58 -0000

Hi Dan, thanks for the feedback. See comments inline:

On May 30, 2012, at 4:24 AM, Romascanu, Dan (Dan) wrote:

> The I-D and Lionel's comments make a good case about the need for such =
a piece of work. I would however suggest that we clarify better how we =
estimate overload and congestion and how we differentiate between =
overload and congestion caused by Diameter vs. other protocols run by =
the same hosts and networks. I am somehow unconvinced by the language =
used by the I-D which talks about 'Diameter networks', there is no such =
things, we have networks and hosts that run Diameter together with many =
other protocols, and congestion and overload is caused by their =
combination. The 3GPP study that is referred does not either focus on =
Diameter only. We need to understand what are the operational realities =
and concerns to make sure that we do not develop sophisticated protocol =
extensions in Diameter, which contribute only to alleviate a fraction of =
the real problems that operator face.=20
>=20

There's probably room to clarify this, but our expectation was that =
network congestion would not be in scope for this effort. As Adam =
mentioned in a separate email, network congestion is probably more a =
transport protocol issue, not a Diameter issue per se.  We are really =
talking about Diameter node overload. We also don't expect that we can =
standardize how a particular Diameter implementation determines it needs =
to shed load, or how that would interact with other applications. That =
seems to me to be very implementation and application dependent.

OTOH, once a Diameter implementation determines that it needs to reduce =
its load, it needs a mechanism to tell Diameter peers to reduce the =
amount of work they are sending it. That's the part that seems to =
benefit from standardization.

We recognize that Diameter does not run in a vacuum, and put words to =
that effect in Section 1. (Third paragraph). We also talked about how =
Diameter overload can be impacted by non-Diameter dependencies (Section =
1.1, Dependency Failures). We of course welcome suggestions on how to =
further clarify this.

Thanks!

Ben.

[...]

>=20
>=20
>> -----Original Message-----
>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf =
Of
>> lionel.morand@orange.com
>> Sent: Wednesday, May 30, 2012 11:51 AM
>> To: Eric McMurry; dime@ietf.org
>> Subject: Re: [Dime] Diameter Overload Control Requirements
>>=20
>> (as individual)
>>=20
>> Hi Eric, Ben,
>>=20
>> I think that it is clear that it is required to further detail how to
>> provide overload control in Diameter based networks, especially in
>> large networks such as mobile networks.
>>=20
>> However, in order to see exactly what to do, I think that we should
>> first agree on what are missing pieces in the current specifications.
>> So the section 4 should be further detailed to differentiate what
>> should be clarified (if required) from what should be defined.
>>=20
>> After a quick review, here is a set of comments as input for further
>> discussion. The idea is that the set of requirements should be =
derived
>> from a clear problem statement.
>>=20
>> *********************
>> 4.1.  Problems with Implicit Mechanism
>>=20
>>   The implicit mechanism doesn't allow an agent or server to inform
>> the
>>   client of a problem until it is effectively too late to do anything
>>   about it.  The client does not know to take action until the
>> upstream
>>   node has effectively failed.  A Diameter node has no opportunity to
>>   shed load early to avoid collapse in the first place.
>>=20
>>   Additionally, the implicit mechanism cannot distinguish between
>>   overload of a Diameter node and network congestion.  Diameter =
treats
>>   the failure to receive an answer as a transport failure.
>>=20
>> [Lionel] IMHO, the first priority would be to clarify the =
relationship
>> between Overload and Network congestion. Another one would be to
>> clarify/verify some assumptions taken as baselines all along the
>> document such as "inform the client of a problem until it is
>> effectively too late to do anything about it". As explained below.
>>=20
>>=20
>> 4.2.  Problems with Explicit Mechanisms
>>=20
>>   The Diameter specification is ambiguous on how a client should
>> handle
>>   receipt of a DIAMETER_TOO_BUSY response.  The base specification
>>   [I-D.ietf-dime-rfc3588bis] indicates that the sending client should
>>   attempt to send the request to a different peer.  It makes no
>>   suggestion that a the receipt of a DIAMETER_TOO_BUSY response =
should
>>   affect future Diameter messages in any way.
>>=20
>> [Lionel] in RFC3588-bis, the SHOULD is meant as a strong =
recommendation
>> for application designers. So for me, the expected behavior of the
>> receiver of this result code is quite clear IMHO. If something needs =
to
>> be further clarified, it may be the conditions for sending the
>> DIAMETER_TOO_BUSY response. It is assumed that the server will wait =
for
>> being overloaded but there is nothing preventing the server to apply =
a
>> specific policy/algorithm allowing the server to modulate the traffic
>> load.
>>=20
>>   There's a strong likelihood that at least some implementations will
>>   continue to send Diameter requests to an upstream peer even after
>>   receiving a DIAMETER_TOO_BUSY error.
>>=20
>> [Lionel] this would mean that these implementations would not follow
>> the recommendations put in the RFC.
>>=20
>>   BCP 41 [RFC2914] describes, among other things, how end-to-end
>>   application behavior can help avoid congestion collapse.  In
>>   particular, an application should avoid sending messages that will
>>   never be delivered or processed.  The DIAMETER_TOO_BUSY behavior as
>>   described in the Diameter base specification fails at this, since =
if
>>   an upstream node becomes overloaded, a client attempts each =
request,
>>   and does not discover the need to failover the request until the
>>   initial attempt fails.
>>=20
>> [Lionel] As described above, it depends on the time the first
>> DIAMETER_TOO_BUSY response. But it is clear that this point needs to =
be
>> further investigated.
>>=20
>>   The situation is improved if implementations follow the [RFC3539]
>>   recommendation and keep state about upstream peer overload.  But
>> even
>>   then, the Diameter specification offers no guidance on how long a
>>   client should wait before retrying the overloaded destination.  If
>> an
>>   agent or server supports multiple realms and/or applications,
>>   DIAMETER_TOO_BUSY only offers no way to indicate that it is
>>   overloaded for one application but not another.  A =
DIAMETER_TOO_BUSY
>>   error can only indicate overload at a "whole server" scope.
>>=20
>> [Lionel] the DIAMETER_TOO_BUSY response is per application as it is =
in
>> response to given command request using a specific application-id. =
But
>> this point is maybe not so clear in the RFC3588bis.
>>=20
>>   Agent processing of a DIAMETER_TOO_BUSY response is also =
problematic
>>   as described in the base specification.  DIAMETER_TOO_BUSY is
>> defined
>>   as a protocol error.  If an agent receives a protocol error, it may
>>   either handle it locally or it may forward the response back =
towards
>>   the downstream peer.  (The Diameter specification is inconsistent
>>   about whether a protocol error MAY or SHOULD be handled by an =
agent,
>>   rather than forwarded downstream.)  If a downstream peer receives
>> the
>>   DIAMETER_TOO_BUSY response, it may stop sending all requests to the
>>   agent for some period of time, even though the agent may still be
>>   able to deliver requests to other upstream peers.
>>=20
>> [Lionel] the DIAMETER_TOO_BUSY response is sent by the overloaded
>> server. So if the Proxy/Relay forwards the response to a downstream
>> client, the client can determine if the "busy" node is the agent or =
the
>> server based on origin-host of the response. About the behavior of =
the
>> agent receiving the DIAMETER_TOO_BUSY response, it cannot be found in
>> the base protocol but should be defined par application, even if
>> generic guidelines could be provided.
>>=20
>> [Lionel] Some texts on DIAMETER_UNABLE_TO_DELIVER may be useful also =
to
>> explain that there is also some gray area around its use, especially =
in
>> a overload control context. For instance, a client receiving this
>> response does not know the reason for which the request has not been
>> delivered (e.g. IP failure, network congestion, etc.) and so it is =
not
>> possible to provide a finer granularity of the client behavior,
>> depending of different criteria can't be further detailed
>>=20
>> Regards,
>>=20
>> Lionel Morand
>>=20
>> ******************
>>=20
>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part =
de
>> Eric McMurry
>> Envoy=E9 : jeudi 17 mai 2012 19:43
>> =C0 : dime@ietf.org
>> Objet : [Dime] Diameter Overload Control Requirements
>>=20
>> A new draft has been submitted intended to address requirements for
>> overload control in Diameter.
>>=20
>> http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt
>>=20
>>=20
>> Diameter deployments are growing in size and this is becoming more of
>> an issue.  We have seen significant interest in providing a mechanism
>> to address it.  Hopefully this document is useful as a base for
>> discussion on what is needed and we welcome comments.
>>=20
>> Abstract:
>>        When a Diameter server or agent becomes overloaded, it needs =
to
>> be able
>>        to gracefully reduce its load, typically by informing clients =
to
>> reduce
>>        sending traffic for some period of time. Otherwise, it must
>> continue to
>>        expend resources parsing and responding to Diameter messages,
>> possibly
>>        resulting in congestion collapse. The existing mechanisms
>> provided by
>>        Diameter are not sufficient for this purpose. This document
>> describes
>>        the limitations of the existing mechanisms, and provides
>> requirements
>>        for new overload management mechanisms.
>>=20
>> The dime charter has an item,
>>=20
>> - Maintaining and/or progressing, along the standards track, the
>> Diameter Base protocol and Diameter Applications. This includes
>> extensions to Diameter Base protocol that can be considered as
>> enhanced
>> features or bug fixes.
>>=20
>> that this seems suited to go under and we welcome comment on that as
>> well.
>>=20
>>=20
>>=20
>> =
_______________________________________________________________________
>> __________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez
>> recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration,
>> France Telecom - Orange decline toute responsabilite si ce message a
>> ete altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and
>> delete this message and its attachments.
>> As emails may be altered, France Telecom - Orange is not liable for
>> messages that have been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Wed May 30 14:01:22 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EFC11E8117 for ; Wed, 30 May 2012 14:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level: 
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8vCaXIiIMaz for ; Wed, 30 May 2012 14:01:21 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 35B3811E809C for ; Wed, 30 May 2012 14:01:21 -0700 (PDT)
Received: by werb13 with SMTP id b13so191663wer.31 for ; Wed, 30 May 2012 14:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Qe6DPK8MZmEJlv1YS/bs7//SORbAJzqMe+rGbEHH1Jw=; b=Ky+TjeRBEZTCBq/LK0Xk5qouDvZ42eBjJT7R5yV0VMVPTrvNeXtKk0aX6aDuMftEQw ncjWqvhA+jfZK/cxNBsmMPzLEr9Ek+QPgI5svKr1h0ZbGTPfEzAtCuJrPviTACGcdNYT VE+MV/VYoxO2C7HTDb4riKmGA8fRUqOTGtbMa175Ugp4GQe1FYTTtmTytUayYU5DiMDS kgV1Apr9/FH0VpLhJISzR7zz1PS2tPvdBJg2PMYT3G1z8aRAVL/8bZEOBS54e3UZgnXC yNY8Ye4TQVKM3eYruTmcZyqW+MJ5WlHHhqrLwZuZWnlpy7OTy/ZTgtNE+duZhzPosPi/ 6I5w==
Received: by 10.216.218.219 with SMTP id k69mr10728708wep.123.1338411680285; Wed, 30 May 2012 14:01:20 -0700 (PDT)
Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id d10sm2738448wiy.3.2012.05.30.14.01.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 May 2012 14:01:18 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Jouni 
In-Reply-To: <0CC419BA-6822-48E6-B1F8-D2DF7FA712D1@estacado.net>
Date: Thu, 31 May 2012 00:01:13 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <8800ADBA-666A-45C5-9CC4-6B1A819C6E79@gmail.com>
References:  <5CD8EEAD-FD51-405F-AFE5-CC8CB372BEE9@gmail.com> <0CC419BA-6822-48E6-B1F8-D2DF7FA712D1@estacado.net>
To: Eric McMurry 
X-Mailer: Apple Mail (2.1257)
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 21:01:22 -0000

Hi,

On May 30, 2012, at 9:06 PM, Eric McMurry wrote:

> Thanks for the comments Jouni.  responses inline.
>=20
> On May 30, 2012, at 10:21 , jouni korhonen wrote:

>> My reading of the solution requirements is that it is already decided =
that extending
>> base protocol is the way to go. Basically req-2 states this. I don't =
think this is
>> particularly good for a requirements document.
>=20
> That part of req 2 was intended as an example and does not use =
requirement language, so I agree with you that it should not be a direct =
requirement.  That said, addressing this in the base makes sense to me =
and helps address several of the requirements.

Well, "MUST be useable with any existing or future.." and
"MUST NOT require specification changes for existing.." basically
rule out anything that you can stuff into CCF or existing commands
in specs world. So I am left only with base protocol level options.
Just language tweaking..

- Jouni


From emcmurry@estacado.net  Wed May 30 14:11:34 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9891121F86A4 for ; Wed, 30 May 2012 14:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mj2-Zm-409S for ; Wed, 30 May 2012 14:11:34 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id BD2E121F8679 for ; Wed, 30 May 2012 14:11:33 -0700 (PDT)
Received: from dn3-227.estacado.net (dn3-227.estacado.net [172.16.3.227]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q4ULBPe3018809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 May 2012 16:11:25 -0500 (CDT) (envelope-from emcmurry@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Eric McMurry 
In-Reply-To: <8800ADBA-666A-45C5-9CC4-6B1A819C6E79@gmail.com>
Date: Wed, 30 May 2012 16:11:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <37B40FC0-20FB-47D6-BBB4-D3B2BBB82F34@estacado.net>
References:  <5CD8EEAD-FD51-405F-AFE5-CC8CB372BEE9@gmail.com> <0CC419BA-6822-48E6-B1F8-D2DF7FA712D1@estacado.net> <8800ADBA-666A-45C5-9CC4-6B1A819C6E79@gmail.com>
To: Jouni 
X-Mailer: Apple Mail (2.1278)
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 21:11:34 -0000

On May 30, 2012, at 16:01 , Jouni wrote:

> Hi,
>=20
> On May 30, 2012, at 9:06 PM, Eric McMurry wrote:
>=20
>> Thanks for the comments Jouni.  responses inline.
>>=20
>> On May 30, 2012, at 10:21 , jouni korhonen wrote:
>=20
>>> My reading of the solution requirements is that it is already =
decided that extending
>>> base protocol is the way to go. Basically req-2 states this. I don't =
think this is
>>> particularly good for a requirements document.
>>=20
>> That part of req 2 was intended as an example and does not use =
requirement language, so I agree with you that it should not be a direct =
requirement.  That said, addressing this in the base makes sense to me =
and helps address several of the requirements.
>=20
> Well, "MUST be useable with any existing or future.." and
> "MUST NOT require specification changes for existing.." basically
> rule out anything that you can stuff into CCF or existing commands
> in specs world. So I am left only with base protocol level options.
> Just language tweaking..
>=20

I think those requirements could be met without base level changes.  =
Perhaps I am misunderstanding your point though.  Do you think that =
working with existing and future applications and not requiring changes =
to existing applications are unreasonable requirements?




From Kalyani.Bogineni@VerizonWireless.com  Wed May 30 12:34:59 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40EC11E80D0 for ; Wed, 30 May 2012 12:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hzd8v6w39iW2 for ; Wed, 30 May 2012 12:34:57 -0700 (PDT)
Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id 29E6511E80D6 for ; Wed, 30 May 2012 12:34:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizonwireless.com; i=Kalyani.Bogineni@verizonwireless.com; l=0; q=dns/txt; s=prodmail; t=1338405996; x=1369941996; h=from:to:cc:date:subject:references:in-reply-to: content-transfer-encoding:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=ReOuRZPK7/mu2a8A2DVrk51KLf2xwCcEUF2ZE4RFMpByhDmcrTjAlXN/ oYOzx/jDZPwgNvII6uZtK9u9+JVb/oFda1noGVmVwgu6SDmX3VseikJXR BVRcrwWbUWkIssl;
Received: from ohdub02exhub01.uswin.ad.vzwcorp.com ([10.97.42.201]) by vanguard.verizonwireless.com with ESMTP; 30 May 2012 12:26:34 -0700
Received: from OHDUB02EXCV33.uswin.ad.vzwcorp.com ([10.97.42.179]) by OHDUB02EXHUB01.uswin.ad.vzwcorp.com ([10.97.42.201]) with mapi; Wed, 30 May 2012 15:34:54 -0400
From: "Bogineni, Kalyani" 
To: Ben Campbell 
Date: Wed, 30 May 2012 15:34:54 -0400
Thread-Topic: [Dime] Diameter Overload Control Requirements
Thread-Index: Ac0+mlxW13WxnFP6Tk6hrfOSrztY1QAALa1g
References:  <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <1101A0B4-070C-4E62-96DF-3A0C95B614C9@nostrum.com>
In-Reply-To: <1101A0B4-070C-4E62-96DF-3A0C95B614C9@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-Id: <20120530193457.29E6511E80D6@ietfa.amsl.com>
X-Mailman-Approved-At: Wed, 30 May 2012 15:36:41 -0700
Cc: "Bogineni, Kalyani" , "dime@ietf.org" 
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 19:34:59 -0000

We support this work.

Regards,
Kalyani Bogineni
Verizon

>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part=20
>> de Eric McMurry Envoy=E9 : jeudi 17 mai 2012 19:43 =C0 : dime@ietf.org=20
>> Objet : [Dime] Diameter Overload Control Requirements
>>=20
>> A new draft has been submitted intended to address requirements for=20
>> overload control in Diameter.
>>=20
>> http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt
>>=20
>>=20
>> Diameter deployments are growing in size and this is becoming more of=20
>> an issue.  We have seen significant interest in providing a mechanism=20
>> to address it.  Hopefully this document is useful as a base for=20
>> discussion on what is needed and we welcome comments.
>>=20
>> Abstract:
>>        When a Diameter server or agent becomes overloaded, it needs=20
>> to be able
>>        to gracefully reduce its load, typically by informing clients=20
>> to reduce
>>        sending traffic for some period of time. Otherwise, it must=20
>> continue to
>>        expend resources parsing and responding to Diameter messages,=20
>> possibly
>>        resulting in congestion collapse. The existing mechanisms=20
>> provided by
>>        Diameter are not sufficient for this purpose. This document=20
>> describes
>>        the limitations of the existing mechanisms, and provides=20
>> requirements
>>        for new overload management mechanisms.
>>=20
>> The dime charter has an item,
>>=20
>> - Maintaining and/or progressing, along the standards track, the=20
>> Diameter Base protocol and Diameter Applications. This includes=20
>> extensions to Diameter Base protocol that can be considered as=20
>> enhanced features or bug fixes.
>>=20
>> that this seems suited to go under and we welcome comment on that as=20
>> well.
>>=20
>>=20


From vshaikh@appcomsci.com  Wed May 30 09:59:55 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430D221F8554; Wed, 30 May 2012 09:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WV1daU12ilm; Wed, 30 May 2012 09:59:54 -0700 (PDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5648C21F854A; Wed, 30 May 2012 09:59:54 -0700 (PDT)
Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q4UGxfQu004588; Wed, 30 May 2012 12:59:41 -0400 (EDT)
Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.research.telcordia.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q4UGxftB028174; Wed, 30 May 2012 12:59:41 -0400
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.97.3 at bambi
Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Wed, 30 May 2012 12:58:33 -0400
From: "Shaikh, Viqar A" 
To: MARTIN C DOLLY , Eric McMurry 
Thread-Topic: [Dime] Diameter Overload Control Requirements
Thread-Index: AQHNNFSaaS/ceEsaL0+8Vbm9CaF6dZbi4T8AgAACNID//74yiw==
Date: Wed, 30 May 2012 16:58:32 +0000
Message-ID: <341B32B15901F94185C9E67CAAE13303FBA59D@rrc-ats-exmb1>
References:  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [205.132.0.199]
Content-Type: multipart/alternative; boundary="_000_341B32B15901F94185C9E67CAAE13303FBA59Drrcatsexmb1_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 30 May 2012 15:37:11 -0700
Cc: "dime-bounces@ietf.org" , "dime@ietf.org" 
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 17:01:24 -0000

--_000_341B32B15901F94185C9E67CAAE13303FBA59Drrcatsexmb1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I support this work.

Viqar







From:        Eric McMurry 
To:        dime@ietf.org
Date:        05/17/2012 01:43 PM
Subject:        [Dime] Diameter Overload Control Requirements
Sent by:        dime-bounces@ietf.org

________________________________



A new draft has been submitted intended to address requirements for overloa=
d control in Diameter.

http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt


Diameter deployments are growing in size and this is becoming more of an is=
sue.  We have seen significant interest in providing a mechanism to address=
 it.  Hopefully this document is useful as a base for discussion on what is=
 needed and we welcome comments.

Abstract:
       When a Diameter server or agent becomes overloaded, it needs to be a=
ble
       to gracefully reduce its load, typically by informing clients to red=
uce
       sending traffic for some period of time. Otherwise, it must continue=
 to
       expend resources parsing and responding to Diameter messages, possib=
ly
       resulting in congestion collapse. The existing mechanisms provided b=
y
       Diameter are not sufficient for this purpose. This document describe=
s
       the limitations of the existing mechanisms, and provides requirement=
s
       for new overload management mechanisms.

The dime charter has an item,

- Maintaining and/or progressing, along the standards track, the
Diameter Base protocol and Diameter Applications. This includes
extensions to Diameter Base protocol that can be considered as enhanced
features or bug fixes.

that this seems suited to go under and we welcome comment on that as well.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--_000_341B32B15901F94185C9E67CAAE13303FBA59Drrcatsexmb1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










I sup=
port this work.




Viqar


 


 


 




From:        Eric McMurry <emcm=
urry@estacado.net>


To:        dime@ietf.org


Date:        05/17/2012 01:43 PM


Subject:        [Dime] Diameter Overload Contr=
ol Requirements


Sent by:        dime-bounces@ietf.org



















A new draft has been submitted intended to address requirements for overloa=
d control in Diameter.  




http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-0=
0.txt






Diameter deployments are growing in size and this is becoming more of an is=
sue.  We have seen significant interest in providing a mechanism to ad=
dress it.  Hopefully this document is useful as a base for discussion =
on what is needed and we welcome comments.




Abstract: 

       When a Diameter server or agent becomes overload=
ed, it needs to be able 

       to gracefully reduce its load, typically by info=
rming clients to reduce 

       sending traffic for some period of time. Otherwi=
se, it must continue to 

       expend resources parsing and responding to Diame=
ter messages, possibly 

       resulting in congestion collapse. The existing m=
echanisms provided by 

       Diameter are not sufficient for this purpose. Th=
is document describes 

       the limitations of the existing mechanisms, and =
provides requirements 

       for new overload management mechanisms. 



The dime charter has an item, 



- Mainta=
ining and/or progressing, along the standards track, the


Diameter=
 Base protocol and Diameter Applications. This includes


extensio=
ns to Diameter Base protocol that can be considered as enhanced


features=
 or bug fixes.




that this seems suited to go under and we welcome comment on that as well. =




_______________________________________=
________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listi=
nfo/dime














--_000_341B32B15901F94185C9E67CAAE13303FBA59Drrcatsexmb1_--

From lionel.morand@orange.com  Wed May 30 16:34:34 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0257821F86B5 for ; Wed, 30 May 2012 16:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwyNJ98vB2mK for ; Wed, 30 May 2012 16:34:33 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE6A21F866A for ; Wed, 30 May 2012 16:34:32 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 4F9742DC46D; Thu, 31 May 2012 01:34:31 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 35998238084; Thu, 31 May 2012 01:34:31 +0200 (CEST)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 31 May 2012 01:34:30 +0200
From: 
To: Eric McMurry 
Thread-Topic: [Dime] Diameter Overload Control Requirements
Thread-Index: AQHNPmkyFVbksAlyTg2BMhcMY66kq5bi9waA
Date: Wed, 30 May 2012 23:34:29 +0000
Message-ID: <32525_1338420871_4FC6AE87_32525_2028_1_6B7134B31289DC4FAF731D844122B36E012A8A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References:  <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup> <544B99F3-1AD3-4600-A2D0-A28EFCF8BC0D@estacado.net>
In-Reply-To: <544B99F3-1AD3-4600-A2D0-A28EFCF8BC0D@estacado.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.24.112414
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 23:34:34 -0000

Hi Eric, Thank you for your feedback. Please see additional comments below.

Regards,

Lionel

-----Message d'origine-----
De=A0: Eric McMurry [mailto:emcmurry@estacado.net]=20
Envoy=E9=A0: mercredi 30 mai 2012 15:36
=C0=A0: MORAND Lionel RD-CORE
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] Diameter Overload Control Requirements

Hi Lionel,

Thank you for the comments.  Based on your, and Dan's comments, adding more=
 detail to the problem statement and front matter makes sense.  I've respon=
ded to your points below.


On May 30, 2012, at 3:50 ,  wrote:

> (as individual)
>=20
> Hi Eric, Ben,
>=20
> I think that it is clear that it is required to further detail how to pro=
vide overload control in Diameter based networks, especially in large netwo=
rks such as mobile networks.
>=20
> However, in order to see exactly what to do, I think that we should first=
 agree on what are missing pieces in the current specifications. So the sec=
tion 4 should be further detailed to differentiate what should be clarified=
 (if required) from what should be defined.
>=20
> After a quick review, here is a set of comments as input for further disc=
ussion. The idea is that the set of requirements should be derived from a c=
lear problem statement.
>=20
> *********************
> 4.1.  Problems with Implicit Mechanism
>=20
>   The implicit mechanism doesn't allow an agent or server to inform the
>   client of a problem until it is effectively too late to do anything
>   about it.  The client does not know to take action until the upstream
>   node has effectively failed.  A Diameter node has no opportunity to
>   shed load early to avoid collapse in the first place.
>=20
>   Additionally, the implicit mechanism cannot distinguish between
>   overload of a Diameter node and network congestion.  Diameter treats
>   the failure to receive an answer as a transport failure.
>=20
> [Lionel] IMHO, the first priority would be to clarify the relationship be=
tween Overload and Network congestion. Another one would be to clarify/veri=
fy some assumptions taken as baselines all along the document such as "info=
rm the client of a problem until it is effectively too late to do anything =
about it". As explained below.
>=20

agree.   Overload vs. network congestion could use more clarification.  The=
se are different and network congestion is not what we are trying to solve =
(transports do this).

[Lionel] indeed it is different aspects. And it will be suitable to clarify=
 the difference but also the possible interaction between both.

>=20
> 4.2.  Problems with Explicit Mechanisms
>=20
>   The Diameter specification is ambiguous on how a client should handle
>   receipt of a DIAMETER_TOO_BUSY response.  The base specification
>   [I-D.ietf-dime-rfc3588bis] indicates that the sending client should
>   attempt to send the request to a different peer.  It makes no
>   suggestion that a the receipt of a DIAMETER_TOO_BUSY response should
>   affect future Diameter messages in any way.
>=20
> [Lionel] in RFC3588-bis, the SHOULD is meant as a strong recommendation f=
or application designers. So for me, the expected behavior of the receiver =
of this result code is quite clear IMHO. If something needs to be further c=
larified, it may be the conditions for sending the DIAMETER_TOO_BUSY respon=
se. It is assumed that the server will wait for being overloaded but there =
is nothing preventing the server to apply a specific policy/algorithm allow=
ing the server to modulate the traffic load.=20

There is mention of this being a transient error, but nothing specific.  I =
have seen multiple interpretations of the scope the error applies to.  In p=
ractice, implementations are using this in different ways.

[Lionel] the landscape of Diameter implementations is wide and time-to-time=
 surprising :)

>=20
>   There's a strong likelihood that at least some implementations will
>   continue to send Diameter requests to an upstream peer even after
>   receiving a DIAMETER_TOO_BUSY error.
>=20
> [Lionel] this would mean that these implementations would not follow the =
recommendations put in the RFC.

With no bounds on what transient means, implementations are open to start s=
ending to the server reporting DIAMETER_TOO_BUSY as soon as the next reques=
t, although I would think that would not work particularly well.

[Lionel] I might have missed something in your response but DIAMETER_TOO_BU=
SY is not defined as a transient failure cause but as a permanent error. An=
d the definition of the error is:

   DIAMETER_TOO_BUSY                  3004
      When returned, a Diameter node SHOULD attempt to send the message
      to an alternate peer.  This error MUST only be used when a
      specific server is requested, and it cannot provide the requested
      service.

And the "SHOULD" in the text has to be understood as defined in RFC2119:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

This is why I was saying that the given implementations were not following =
the recommendation of the RFC (or RFCbis). Nevertheless, I have admitted th=
at it may be required to clarify the use of this error (triggering mechanis=
m, detailed behavior of the client, possible action of agent, etc.)

>=20
>   BCP 41 [RFC2914] describes, among other things, how end-to-end
>   application behavior can help avoid congestion collapse.  In
>   particular, an application should avoid sending messages that will
>   never be delivered or processed.  The DIAMETER_TOO_BUSY behavior as
>   described in the Diameter base specification fails at this, since if
>   an upstream node becomes overloaded, a client attempts each request,
>   and does not discover the need to failover the request until the
>   initial attempt fails.
>=20
> [Lionel] As described above, it depends on the time the first DIAMETER_TO=
O_BUSY response. But it is clear that this point needs to be further invest=
igated.=20
>=20
>   The situation is improved if implementations follow the [RFC3539]
>   recommendation and keep state about upstream peer overload.  But even
>   then, the Diameter specification offers no guidance on how long a
>   client should wait before retrying the overloaded destination.  If an
>   agent or server supports multiple realms and/or applications,
>   DIAMETER_TOO_BUSY only offers no way to indicate that it is
>   overloaded for one application but not another.  A DIAMETER_TOO_BUSY
>   error can only indicate overload at a "whole server" scope.
>=20
> [Lionel] the DIAMETER_TOO_BUSY response is per application as it is in re=
sponse to given command request using a specific application-id. But this p=
oint is maybe not so clear in the RFC3588bis.
>=20
>   Agent processing of a DIAMETER_TOO_BUSY response is also problematic
>   as described in the base specification.  DIAMETER_TOO_BUSY is defined
>   as a protocol error.  If an agent receives a protocol error, it may
>   either handle it locally or it may forward the response back towards
>   the downstream peer.  (The Diameter specification is inconsistent
>   about whether a protocol error MAY or SHOULD be handled by an agent,
>   rather than forwarded downstream.)  If a downstream peer receives the
>   DIAMETER_TOO_BUSY response, it may stop sending all requests to the
>   agent for some period of time, even though the agent may still be
>   able to deliver requests to other upstream peers.
>=20
> [Lionel] the DIAMETER_TOO_BUSY response is sent by the overloaded server.=
 So if the Proxy/Relay forwards the response to a downstream client, the cl=
ient can determine if the "busy" node is the agent or the server based on o=
rigin-host of the response. About the behavior of the agent receiving the D=
IAMETER_TOO_BUSY response, it cannot be found in the base protocol but shou=
ld be defined par application, even if generic guidelines could be provided.
>=20
> [Lionel] Some texts on DIAMETER_UNABLE_TO_DELIVER may be useful also to e=
xplain that there is also some gray area around its use, especially in a ov=
erload control context. For instance, a client receiving this response does=
 not know the reason for which the request has not been delivered (e.g. IP =
failure, network congestion, etc.) and so it is not possible to provide a f=
iner granularity of the client behavior, depending of different criteria ca=
n't be further detailed
>=20

Good point.  We can add something on this.



___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From adam@nostrum.com  Wed May 30 20:35:36 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D8011E80A6 for ; Wed, 30 May 2012 20:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT6+pS0yJbEW for ; Wed, 30 May 2012 20:35:36 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CDF1011E8093 for ; Wed, 30 May 2012 20:35:35 -0700 (PDT)
Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4V3ZPT3038279 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 May 2012 22:35:26 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4FC6E6FD.70405@nostrum.com>
Date: Wed, 30 May 2012 22:35:25 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: lionel.morand@orange.com
References:  <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup> <544B99F3-1AD3-4600-A2D0-A28EFCF8BC0D@estacado.net> <32525_1338420871_4FC6AE87_32525_2028_1_6B7134B31289DC4FAF731D844122B36E012A8A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <32525_1338420871_4FC6AE87_32525_2028_1_6B7134B31289DC4FAF731D844122B36E012A8A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 03:35:36 -0000

On 5/30/12 18:34, May 30, lionel.morand@orange.com wrote:
>
>>    There's a strong likelihood that at least some implementations will
>>    continue to send Diameter requests to an upstream peer even after
>>    receiving a DIAMETER_TOO_BUSY error.
>>
>> [Lionel] this would mean that these implementations would not follow the recommendations put in the RFC.
> With no bounds on what transient means, implementations are open to start sending to the server reporting DIAMETER_TOO_BUSY as soon as the next request, although I would think that would not work particularly well.
>
> [Lionel] I might have missed something in your response but DIAMETER_TOO_BUSY is not defined as a transient failure cause but as a permanent error.

Yes, it is. And permanent failures are described: "Errors that fall 
within the permanent failures category are used to inform the peer that 
the request failed, and should not be attempted again."

I would put heavy emphasis on the the two words "the request," 
particularly on the non-plural nature of that phrase. Permanent failures 
are permanent for the specific request they are sent in response to. 
There is no statement, or even implication, anywhere in 3588 or its 
revision that permanent errors have any bearing on future requests.


>   And the definition of the error is:
>
>     DIAMETER_TOO_BUSY                  3004
>        When returned, a Diameter node SHOULD attempt to send the message
>        to an alternate peer.  This error MUST only be used when a
>        specific server is requested, and it cannot provide the requested
>        service.
>
> And the "SHOULD" in the text has to be understood as defined in RFC2119:
>
> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
>     may exist valid reasons in particular circumstances to ignore a
>     particular item, but the full implications must be understood and
>     carefully weighed before choosing a different course.
>
> This is why I was saying that the given implementations were not following the recommendation of the RFC (or RFCbis).

Yes, it is true that the client "SHOULD attempt to sent THE MESSAGE to 
an alternate peer." Not "messages." "Message."

Let's tease this out a bit. Consider a client. It knows that the 
requests it can send are serviced preferentially by server A. It also 
knows that the same requests can be handled by a backup server B. (This 
arrangement could be detailed through SRV record priorities, 
provisioning, etc.). The client sends request 1 to server A. It gets a 
"DIAMETER_TOO_BUSY" error. Following the normative SHOULD-level 
requirement above, it then sends this same request 1 to server B. Server 
B processes the request, and everyone is happy.

Thirty milliseconds later, the same client wants to send a request 2, 
unrelated to request 1, to the server. Is it in violation of any portion 
of 3588 or 3588bis' normative language if it sends this request 2 to 
server A? If so, could you point out the normative statement it violates?

Thirty seconds later, the client wants to send a request 3. Does that 
change your answer?

How about thirty minutes? Thirty days?

/a

From dromasca@avaya.com  Thu May 31 01:06:22 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B1D21F866C for ; Thu, 31 May 2012 01:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.509
X-Spam-Level: 
X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOewO8kroHfr for ; Thu, 31 May 2012 01:06:21 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDAD21F866B for ; Thu, 31 May 2012 01:06:20 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAN0kx0+HCzI1/2dsb2JhbABEtBSBB4IXAQEBAQMBAQEPHhcnBAcMBAIBCA0EBAEBAQoGDAsBBgEmHwkIAQEEEwgBGYdpC5wJjhGOa4sIhGZgA4gNknyKAoJigV0
X-IronPort-AV: E=Sophos;i="4.75,691,1330923600"; d="scan'208";a="308721246"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 May 2012 04:04:06 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 May 2012 03:48:15 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 31 May 2012 10:06:15 +0200
Message-ID: 
In-Reply-To: <1101A0B4-070C-4E62-96DF-3A0C95B614C9@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Diameter Overload Control Requirements
Thread-Index: Ac0+mlhXbAX3BGeVQ9KA0pNJtRnZkAAaV6dQ
References:  <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <1101A0B4-070C-4E62-96DF-3A0C95B614C9@nostrum.com>
From: "Romascanu, Dan (Dan)" 
To: "Ben Campbell" 
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 08:06:23 -0000

Hi Ben,

Thank you (and also Adam) for the clarification. If the work focuses on =
server overload rather than on network overload I suggest this to be =
explicitly articulated, also the use of language like 'Diameter network' =
and 'Overload in the Diameter network' is confusing on this respect, as =
well as the fact that the 'other mechanisms' list in section 3 begins =
with the transport layer network congestion avoidance mechanisms.=20

Regards,

Dan


> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: Wednesday, May 30, 2012 10:28 PM
> To: Romascanu, Dan (Dan)
> Cc: lionel.morand@orange.com; Eric McMurry; dime@ietf.org
> Subject: Re: [Dime] Diameter Overload Control Requirements
>=20
> Hi Dan, thanks for the feedback. See comments inline:
>=20
> On May 30, 2012, at 4:24 AM, Romascanu, Dan (Dan) wrote:
>=20
> > The I-D and Lionel's comments make a good case about the need for
> such a piece of work. I would however suggest that we clarify better
> how we estimate overload and congestion and how we differentiate
> between overload and congestion caused by Diameter vs. other protocols
> run by the same hosts and networks. I am somehow unconvinced by the
> language used by the I-D which talks about 'Diameter networks', there
> is no such things, we have networks and hosts that run Diameter
> together with many other protocols, and congestion and overload is
> caused by their combination. The 3GPP study that is referred does not
> either focus on Diameter only. We need to understand what are the
> operational realities and concerns to make sure that we do not develop
> sophisticated protocol extensions in Diameter, which contribute only =
to
> alleviate a fraction of the real problems that operator face.
> >
>=20
> There's probably room to clarify this, but our expectation was that
> network congestion would not be in scope for this effort. As Adam
> mentioned in a separate email, network congestion is probably more a
> transport protocol issue, not a Diameter issue per se.  We are really
> talking about Diameter node overload. We also don't expect that we can
> standardize how a particular Diameter implementation determines it
> needs to shed load, or how that would interact with other =
applications.
> That seems to me to be very implementation and application dependent.
>=20
> OTOH, once a Diameter implementation determines that it needs to =
reduce
> its load, it needs a mechanism to tell Diameter peers to reduce the
> amount of work they are sending it. That's the part that seems to
> benefit from standardization.
>=20
> We recognize that Diameter does not run in a vacuum, and put words to
> that effect in Section 1. (Third paragraph). We also talked about how
> Diameter overload can be impacted by non-Diameter dependencies =
(Section
> 1.1, Dependency Failures). We of course welcome suggestions on how to
> further clarify this.
>=20
> Thanks!
>=20
> Ben.
>=20
> [...]
>=20
> >
> >
> >> -----Original Message-----
> >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On =
Behalf
> Of
> >> lionel.morand@orange.com
> >> Sent: Wednesday, May 30, 2012 11:51 AM
> >> To: Eric McMurry; dime@ietf.org
> >> Subject: Re: [Dime] Diameter Overload Control Requirements
> >>
> >> (as individual)
> >>
> >> Hi Eric, Ben,
> >>
> >> I think that it is clear that it is required to further detail how
> to
> >> provide overload control in Diameter based networks, especially in
> >> large networks such as mobile networks.
> >>
> >> However, in order to see exactly what to do, I think that we should
> >> first agree on what are missing pieces in the current
> specifications.
> >> So the section 4 should be further detailed to differentiate what
> >> should be clarified (if required) from what should be defined.
> >>
> >> After a quick review, here is a set of comments as input for =
further
> >> discussion. The idea is that the set of requirements should be
> derived
> >> from a clear problem statement.
> >>
> >> *********************
> >> 4.1.  Problems with Implicit Mechanism
> >>
> >>   The implicit mechanism doesn't allow an agent or server to inform
> >> the
> >>   client of a problem until it is effectively too late to do
> anything
> >>   about it.  The client does not know to take action until the
> >> upstream
> >>   node has effectively failed.  A Diameter node has no opportunity
> to
> >>   shed load early to avoid collapse in the first place.
> >>
> >>   Additionally, the implicit mechanism cannot distinguish between
> >>   overload of a Diameter node and network congestion.  Diameter
> treats
> >>   the failure to receive an answer as a transport failure.
> >>
> >> [Lionel] IMHO, the first priority would be to clarify the
> relationship
> >> between Overload and Network congestion. Another one would be to
> >> clarify/verify some assumptions taken as baselines all along the
> >> document such as "inform the client of a problem until it is
> >> effectively too late to do anything about it". As explained below.
> >>
> >>
> >> 4.2.  Problems with Explicit Mechanisms
> >>
> >>   The Diameter specification is ambiguous on how a client should
> >> handle
> >>   receipt of a DIAMETER_TOO_BUSY response.  The base specification
> >>   [I-D.ietf-dime-rfc3588bis] indicates that the sending client
> should
> >>   attempt to send the request to a different peer.  It makes no
> >>   suggestion that a the receipt of a DIAMETER_TOO_BUSY response
> should
> >>   affect future Diameter messages in any way.
> >>
> >> [Lionel] in RFC3588-bis, the SHOULD is meant as a strong
> recommendation
> >> for application designers. So for me, the expected behavior of the
> >> receiver of this result code is quite clear IMHO. If something =
needs
> to
> >> be further clarified, it may be the conditions for sending the
> >> DIAMETER_TOO_BUSY response. It is assumed that the server will wait
> for
> >> being overloaded but there is nothing preventing the server to =
apply
> a
> >> specific policy/algorithm allowing the server to modulate the
> traffic
> >> load.
> >>
> >>   There's a strong likelihood that at least some implementations
> will
> >>   continue to send Diameter requests to an upstream peer even after
> >>   receiving a DIAMETER_TOO_BUSY error.
> >>
> >> [Lionel] this would mean that these implementations would not =
follow
> >> the recommendations put in the RFC.
> >>
> >>   BCP 41 [RFC2914] describes, among other things, how end-to-end
> >>   application behavior can help avoid congestion collapse.  In
> >>   particular, an application should avoid sending messages that =
will
> >>   never be delivered or processed.  The DIAMETER_TOO_BUSY behavior
> as
> >>   described in the Diameter base specification fails at this, since
> if
> >>   an upstream node becomes overloaded, a client attempts each
> request,
> >>   and does not discover the need to failover the request until the
> >>   initial attempt fails.
> >>
> >> [Lionel] As described above, it depends on the time the first
> >> DIAMETER_TOO_BUSY response. But it is clear that this point needs =
to
> be
> >> further investigated.
> >>
> >>   The situation is improved if implementations follow the [RFC3539]
> >>   recommendation and keep state about upstream peer overload.  But
> >> even
> >>   then, the Diameter specification offers no guidance on how long a
> >>   client should wait before retrying the overloaded destination.  =
If
> >> an
> >>   agent or server supports multiple realms and/or applications,
> >>   DIAMETER_TOO_BUSY only offers no way to indicate that it is
> >>   overloaded for one application but not another.  A
> DIAMETER_TOO_BUSY
> >>   error can only indicate overload at a "whole server" scope.
> >>
> >> [Lionel] the DIAMETER_TOO_BUSY response is per application as it is
> in
> >> response to given command request using a specific application-id.
> But
> >> this point is maybe not so clear in the RFC3588bis.
> >>
> >>   Agent processing of a DIAMETER_TOO_BUSY response is also
> problematic
> >>   as described in the base specification.  DIAMETER_TOO_BUSY is
> >> defined
> >>   as a protocol error.  If an agent receives a protocol error, it
> may
> >>   either handle it locally or it may forward the response back
> towards
> >>   the downstream peer.  (The Diameter specification is inconsistent
> >>   about whether a protocol error MAY or SHOULD be handled by an
> agent,
> >>   rather than forwarded downstream.)  If a downstream peer receives
> >> the
> >>   DIAMETER_TOO_BUSY response, it may stop sending all requests to
> the
> >>   agent for some period of time, even though the agent may still be
> >>   able to deliver requests to other upstream peers.
> >>
> >> [Lionel] the DIAMETER_TOO_BUSY response is sent by the overloaded
> >> server. So if the Proxy/Relay forwards the response to a downstream
> >> client, the client can determine if the "busy" node is the agent or
> the
> >> server based on origin-host of the response. About the behavior of
> the
> >> agent receiving the DIAMETER_TOO_BUSY response, it cannot be found
> in
> >> the base protocol but should be defined par application, even if
> >> generic guidelines could be provided.
> >>
> >> [Lionel] Some texts on DIAMETER_UNABLE_TO_DELIVER may be useful =
also
> to
> >> explain that there is also some gray area around its use, =
especially
> in
> >> a overload control context. For instance, a client receiving this
> >> response does not know the reason for which the request has not =
been
> >> delivered (e.g. IP failure, network congestion, etc.) and so it is
> not
> >> possible to provide a finer granularity of the client behavior,
> >> depending of different criteria can't be further detailed
> >>
> >> Regards,
> >>
> >> Lionel Morand
> >>
> >> ******************
> >>
> >> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la =
part
> de
> >> Eric McMurry
> >> Envoy=E9 : jeudi 17 mai 2012 19:43
> >> =C0 : dime@ietf.org
> >> Objet : [Dime] Diameter Overload Control Requirements
> >>
> >> A new draft has been submitted intended to address requirements for
> >> overload control in Diameter.
> >>
> >> http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt
> >>
> >>
> >> Diameter deployments are growing in size and this is becoming more
> of
> >> an issue.  We have seen significant interest in providing a
> mechanism
> >> to address it.  Hopefully this document is useful as a base for
> >> discussion on what is needed and we welcome comments.
> >>
> >> Abstract:
> >>        When a Diameter server or agent becomes overloaded, it needs
> to
> >> be able
> >>        to gracefully reduce its load, typically by informing =
clients
> to
> >> reduce
> >>        sending traffic for some period of time. Otherwise, it must
> >> continue to
> >>        expend resources parsing and responding to Diameter =
messages,
> >> possibly
> >>        resulting in congestion collapse. The existing mechanisms
> >> provided by
> >>        Diameter are not sufficient for this purpose. This document
> >> describes
> >>        the limitations of the existing mechanisms, and provides
> >> requirements
> >>        for new overload management mechanisms.
> >>
> >> The dime charter has an item,
> >>
> >> - Maintaining and/or progressing, along the standards track, the
> >> Diameter Base protocol and Diameter Applications. This includes
> >> extensions to Diameter Base protocol that can be considered as
> >> enhanced
> >> features or bug fixes.
> >>
> >> that this seems suited to go under and we welcome comment on that =
as
> >> well.
> >>
> >>
> >>
> >>
> =
_______________________________________________________________________
> >> __________________________________________________
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations
> >> confidentielles ou privilegiees et ne doivent donc
> >> pas etre diffuses, exploites ou copies sans autorisation. Si vous
> avez
> >> recu ce message par erreur, veuillez le signaler
> >> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> >> messages electroniques etant susceptibles d'alteration,
> >> France Telecom - Orange decline toute responsabilite si ce message =
a
> >> ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or
> privileged
> >> information that may be protected by law;
> >> they should not be distributed, used or copied without
> authorisation.
> >> If you have received this email in error, please notify the sender
> and
> >> delete this message and its attachments.
> >> As emails may be altered, France Telecom - Orange is not liable for
> >> messages that have been modified, changed or falsified.
> >> Thank you.
> >>
> >> _______________________________________________
> >> DiME mailing list
> >> DiME@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dime
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Thu May 31 01:33:11 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB0121F86AB for ; Thu, 31 May 2012 01:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.513
X-Spam-Level: 
X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3ZQqCm+-kg3 for ; Thu, 31 May 2012 01:33:09 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B911521F869D for ; Thu, 31 May 2012 01:33:08 -0700 (PDT)
Received: by bkty8 with SMTP id y8so655379bkt.31 for ; Thu, 31 May 2012 01:33:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5qkwZkK+vBetNa+syk+AICs9yAKhurYGMhGGC0G26hE=; b=mkNs1zem/w+EoAi4UMPrYsFH+YI8f1RUjl+OcOeBiHb6PDz/ehdrcYO3PJDfq3ACNI WozvPcRD3tYpdxtG3/MTxFKw0MXqUFffH63iwh9hZVm+sa66FRONrsAwj0ApkhqQ3sfi kPh4HlNTN9oykFUrCHrRJ1hPiDYAG6D8u58HFbX8BcQNziaIjCBaop4PVjHW27XIqTCP DpjeDnfRIj+Vdn0cNgxZpQstNKy+wnsUcmzUR7wOmg67XqhYKomKzTAMOg/78TM89yX+ az5NcvVcBbZm6IWpf0cGZMlumUsO80c5/JUIZBoEuyoa7LHcWFBFS5vp1BshSzU8Z7Ul 6Qgg==
Received: by 10.205.128.8 with SMTP id hc8mr596518bkc.17.1338453183263; Thu, 31 May 2012 01:33:03 -0700 (PDT)
Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id e20sm2200967bkv.10.2012.05.31.01.32.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 May 2012 01:32:45 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <37B40FC0-20FB-47D6-BBB4-D3B2BBB82F34@estacado.net>
Date: Thu, 31 May 2012 11:32:26 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <0866D5BC-8CC9-46E7-BEF1-9AD4CA1207B1@gmail.com>
References:  <5CD8EEAD-FD51-405F-AFE5-CC8CB372BEE9@gmail.com> <0CC419BA-6822-48E6-B1F8-D2DF7FA712D1@estacado.net> <8800ADBA-666A-45C5-9CC4-6B1A819C6E79@gmail.com> <37B40FC0-20FB-47D6-BBB4-D3B2BBB82F34@estacado.net>
To: Eric McMurry 
X-Mailer: Apple Mail (2.1084)
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 08:33:12 -0000

Hi Eric,

On May 31, 2012, at 12:11 AM, Eric McMurry wrote:

>=20
> On May 30, 2012, at 16:01 , Jouni wrote:
>=20
>> Hi,
>>=20
>> On May 30, 2012, at 9:06 PM, Eric McMurry wrote:
>>=20
>>> Thanks for the comments Jouni.  responses inline.
>>>=20
>>> On May 30, 2012, at 10:21 , jouni korhonen wrote:
>>=20
>>>> My reading of the solution requirements is that it is already =
decided that extending
>>>> base protocol is the way to go. Basically req-2 states this. I =
don't think this is
>>>> particularly good for a requirements document.
>>>=20
>>> That part of req 2 was intended as an example and does not use =
requirement language, so I agree with you that it should not be a direct =
requirement.  That said, addressing this in the base makes sense to me =
and helps address several of the requirements.
>>=20
>> Well, "MUST be useable with any existing or future.." and
>> "MUST NOT require specification changes for existing.." basically
>> rule out anything that you can stuff into CCF or existing commands
>> in specs world. So I am left only with base protocol level options.
>> Just language tweaking..
>>=20
>=20
> I think those requirements could be met without base level changes.  =
Perhaps I am misunderstanding your point though.  Do you think that =
working with existing and future
>  applications and not requiring changes to existing applications are =
unreasonable requirements?

No. Definitely not. I was just saying, the req-2 does not, as written
now, give you any other choice than extend or leverage the base
protocol. I am not comfortable with that -- as a requirement to be
documented.

- Jouni

>=20
>=20
>=20


From emcmurry@estacado.net  Thu May 31 06:42:57 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D3921F86A1 for ; Thu, 31 May 2012 06:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0EvDoN6ke9w for ; Thu, 31 May 2012 06:42:57 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9CB21F869D for ; Thu, 31 May 2012 06:42:56 -0700 (PDT)
Received: from embp.mcmurry.home (cpe-76-184-161-215.tx.res.rr.com [76.184.161.215]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q4VDgnGw099152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 08:42:53 -0500 (CDT) (envelope-from emcmurry@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Eric McMurry 
In-Reply-To: <0866D5BC-8CC9-46E7-BEF1-9AD4CA1207B1@gmail.com>
Date: Thu, 31 May 2012 08:42:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <857EB77C-46F2-4001-9319-E2D7EFDB0A65@estacado.net>
References:  <5CD8EEAD-FD51-405F-AFE5-CC8CB372BEE9@gmail.com> <0CC419BA-6822-48E6-B1F8-D2DF7FA712D1@estacado.net> <8800ADBA-666A-45C5-9CC4-6B1A819C6E79@gmail.com> <37B40FC0-20FB-47D6-BBB4-D3B2BBB82F34@estacado.net> <0866D5BC-8CC9-46E7-BEF1-9AD4CA1207B1@gmail.com>
To: jouni korhonen 
X-Mailer: Apple Mail (2.1278)
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 13:42:57 -0000

Hey Jouni,

On May 31, 2012, at 3:32 , jouni korhonen wrote:

> Hi Eric,
>=20
> On May 31, 2012, at 12:11 AM, Eric McMurry wrote:
>=20
>>=20
>> On May 30, 2012, at 16:01 , Jouni wrote:
>>=20
>>> Hi,
>>>=20
>>> On May 30, 2012, at 9:06 PM, Eric McMurry wrote:
>>>=20
>>>> Thanks for the comments Jouni.  responses inline.
>>>>=20
>>>> On May 30, 2012, at 10:21 , jouni korhonen wrote:
>>>=20
>>>>> My reading of the solution requirements is that it is already =
decided that extending
>>>>> base protocol is the way to go. Basically req-2 states this. I =
don't think this is
>>>>> particularly good for a requirements document.
>>>>=20
>>>> That part of req 2 was intended as an example and does not use =
requirement language, so I agree with you that it should not be a direct =
requirement.  That said, addressing this in the base makes sense to me =
and helps address several of the requirements.
>>>=20
>>> Well, "MUST be useable with any existing or future.." and
>>> "MUST NOT require specification changes for existing.." basically
>>> rule out anything that you can stuff into CCF or existing commands
>>> in specs world. So I am left only with base protocol level options.
>>> Just language tweaking..
>>>=20
>>=20
>> I think those requirements could be met without base level changes.  =
Perhaps I am misunderstanding your point though.  Do you think that =
working with existing and future
>> applications and not requiring changes to existing applications are =
unreasonable requirements?
>=20
> No. Definitely not. I was just saying, the req-2 does not, as written
> now, give you any other choice than extend or leverage the base
> protocol. I am not comfortable with that -- as a requirement to be
> documented.

So if we take off the last sentence (the one that refers to the base =
protocol) would that allay your concern?

Thanks,

Eric


From emcmurry@estacado.net  Thu May 31 06:48:31 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F3C21F864B for ; Thu, 31 May 2012 06:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEDL+lp+kC+i for ; Thu, 31 May 2012 06:48:31 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id B76BC21F8644 for ; Thu, 31 May 2012 06:48:30 -0700 (PDT)
Received: from embp.mcmurry.home (cpe-76-184-161-215.tx.res.rr.com [76.184.161.215]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q4VDmOuA000241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 08:48:30 -0500 (CDT) (envelope-from emcmurry@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=iso-8859-1
From: Eric McMurry 
In-Reply-To: <4FC6E6FD.70405@nostrum.com>
Date: Thu, 31 May 2012 08:48:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <82E3BCF9-440D-4DC5-BE14-417C7BBCAD0B@estacado.net>
References:  <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup> <544B99F3-1AD3-4600-A2D0-A28EFCF8BC0D@estacado.net> <32525_1338420871_4FC6AE87_32525_2028_1_6B7134B31289DC4FAF731D844122B36E012A8A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <4FC6E6FD.70405@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.1278)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 13:48:31 -0000

On May 30, 2012, at 22:35 , Adam Roach wrote:

> On 5/30/12 18:34, May 30, lionel.morand@orange.com wrote:
>>=20
>>>   There's a strong likelihood that at least some implementations =
will
>>>   continue to send Diameter requests to an upstream peer even after
>>>   receiving a DIAMETER_TOO_BUSY error.
>>>=20
>>> [Lionel] this would mean that these implementations would not follow =
the recommendations put in the RFC.
>> With no bounds on what transient means, implementations are open to =
start sending to the server reporting DIAMETER_TOO_BUSY as soon as the =
next request, although I would think that would not work particularly =
well.
>>=20
>> [Lionel] I might have missed something in your response but =
DIAMETER_TOO_BUSY is not defined as a transient failure cause but as a =
permanent error.
>=20
> Yes, it is. And permanent failures are described: "Errors that fall =
within the permanent failures category are used to inform the peer that =
the request failed, and should not be attempted again."
>=20
> I would put heavy emphasis on the the two words "the request," =
particularly on the non-plural nature of that phrase. Permanent failures =
are permanent for the specific request they are sent in response to. =
There is no statement, or even implication, anywhere in 3588 or its =
revision that permanent errors have any bearing on future requests.


The only permanent errors I see are the 5xxx class errors =
(DIAMETER_TOO_BUSY is 3004).  Additionally, sections 8.1 and 8.2 refer =
to DIAMETER_TOO_BUSY as a transient or temporary error.

[...]


From ben@nostrum.com  Thu May 31 07:13:19 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3C221F867A for ; Thu, 31 May 2012 07:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPw6Oq4dVp08 for ; Thu, 31 May 2012 07:13:18 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E041321F8673 for ; Thu, 31 May 2012 07:13:17 -0700 (PDT)
Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4VEDBZp078166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 09:13:11 -0500 (CDT) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=iso-8859-1
From: Ben Campbell 
In-Reply-To: 
Date: Thu, 31 May 2012 09:13:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <80B56270-B590-4C4A-9F51-A5B9FFB48BF2@nostrum.com>
References:  <6198_1338367832_4FC5DF58_6198_841_2_6B7134B31289DC4FAF731D844122B36E0126B2@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <1101A0B4-070C-4E62-96DF-3A0C95B614C9@nostrum.com> 
To: "Romascanu, Dan (Dan)" 
X-Mailer: Apple Mail (2.1278)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Overload Control Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 14:13:20 -0000

Thanks Dan. We definitely want to be clear on that point, and will try =
to clarify it in the next revision.

Thanks!

Ben.

On May 31, 2012, at 3:06 AM, Romascanu, Dan (Dan) wrote:

> Hi Ben,
>=20
> Thank you (and also Adam) for the clarification. If the work focuses =
on server overload rather than on network overload I suggest this to be =
explicitly articulated, also the use of language like 'Diameter network' =
and 'Overload in the Diameter network' is confusing on this respect, as =
well as the fact that the 'other mechanisms' list in section 3 begins =
with the transport layer network congestion avoidance mechanisms.=20
>=20
> Regards,
>=20
> Dan
>=20
>=20
>> -----Original Message-----
>> From: Ben Campbell [mailto:ben@nostrum.com]
>> Sent: Wednesday, May 30, 2012 10:28 PM
>> To: Romascanu, Dan (Dan)
>> Cc: lionel.morand@orange.com; Eric McMurry; dime@ietf.org
>> Subject: Re: [Dime] Diameter Overload Control Requirements
>>=20
>> Hi Dan, thanks for the feedback. See comments inline:
>>=20
>> On May 30, 2012, at 4:24 AM, Romascanu, Dan (Dan) wrote:
>>=20
>>> The I-D and Lionel's comments make a good case about the need for
>> such a piece of work. I would however suggest that we clarify better
>> how we estimate overload and congestion and how we differentiate
>> between overload and congestion caused by Diameter vs. other =
protocols
>> run by the same hosts and networks. I am somehow unconvinced by the
>> language used by the I-D which talks about 'Diameter networks', there
>> is no such things, we have networks and hosts that run Diameter
>> together with many other protocols, and congestion and overload is
>> caused by their combination. The 3GPP study that is referred does not
>> either focus on Diameter only. We need to understand what are the
>> operational realities and concerns to make sure that we do not =
develop
>> sophisticated protocol extensions in Diameter, which contribute only =
to
>> alleviate a fraction of the real problems that operator face.
>>>=20
>>=20
>> There's probably room to clarify this, but our expectation was that
>> network congestion would not be in scope for this effort. As Adam
>> mentioned in a separate email, network congestion is probably more a
>> transport protocol issue, not a Diameter issue per se.  We are really
>> talking about Diameter node overload. We also don't expect that we =
can
>> standardize how a particular Diameter implementation determines it
>> needs to shed load, or how that would interact with other =
applications.
>> That seems to me to be very implementation and application dependent.
>>=20
>> OTOH, once a Diameter implementation determines that it needs to =
reduce
>> its load, it needs a mechanism to tell Diameter peers to reduce the
>> amount of work they are sending it. That's the part that seems to
>> benefit from standardization.
>>=20
>> We recognize that Diameter does not run in a vacuum, and put words to
>> that effect in Section 1. (Third paragraph). We also talked about how
>> Diameter overload can be impacted by non-Diameter dependencies =
(Section
>> 1.1, Dependency Failures). We of course welcome suggestions on how to
>> further clarify this.
>>=20
>> Thanks!
>>=20
>> Ben.
>>=20
>> [...]
>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On =
Behalf
>> Of
>>>> lionel.morand@orange.com
>>>> Sent: Wednesday, May 30, 2012 11:51 AM
>>>> To: Eric McMurry; dime@ietf.org
>>>> Subject: Re: [Dime] Diameter Overload Control Requirements
>>>>=20
>>>> (as individual)
>>>>=20
>>>> Hi Eric, Ben,
>>>>=20
>>>> I think that it is clear that it is required to further detail how
>> to
>>>> provide overload control in Diameter based networks, especially in
>>>> large networks such as mobile networks.
>>>>=20
>>>> However, in order to see exactly what to do, I think that we should
>>>> first agree on what are missing pieces in the current
>> specifications.
>>>> So the section 4 should be further detailed to differentiate what
>>>> should be clarified (if required) from what should be defined.
>>>>=20
>>>> After a quick review, here is a set of comments as input for =
further
>>>> discussion. The idea is that the set of requirements should be
>> derived
>>>> from a clear problem statement.
>>>>=20
>>>> *********************
>>>> 4.1.  Problems with Implicit Mechanism
>>>>=20
>>>>  The implicit mechanism doesn't allow an agent or server to inform
>>>> the
>>>>  client of a problem until it is effectively too late to do
>> anything
>>>>  about it.  The client does not know to take action until the
>>>> upstream
>>>>  node has effectively failed.  A Diameter node has no opportunity
>> to
>>>>  shed load early to avoid collapse in the first place.
>>>>=20
>>>>  Additionally, the implicit mechanism cannot distinguish between
>>>>  overload of a Diameter node and network congestion.  Diameter
>> treats
>>>>  the failure to receive an answer as a transport failure.
>>>>=20
>>>> [Lionel] IMHO, the first priority would be to clarify the
>> relationship
>>>> between Overload and Network congestion. Another one would be to
>>>> clarify/verify some assumptions taken as baselines all along the
>>>> document such as "inform the client of a problem until it is
>>>> effectively too late to do anything about it". As explained below.
>>>>=20
>>>>=20
>>>> 4.2.  Problems with Explicit Mechanisms
>>>>=20
>>>>  The Diameter specification is ambiguous on how a client should
>>>> handle
>>>>  receipt of a DIAMETER_TOO_BUSY response.  The base specification
>>>>  [I-D.ietf-dime-rfc3588bis] indicates that the sending client
>> should
>>>>  attempt to send the request to a different peer.  It makes no
>>>>  suggestion that a the receipt of a DIAMETER_TOO_BUSY response
>> should
>>>>  affect future Diameter messages in any way.
>>>>=20
>>>> [Lionel] in RFC3588-bis, the SHOULD is meant as a strong
>> recommendation
>>>> for application designers. So for me, the expected behavior of the
>>>> receiver of this result code is quite clear IMHO. If something =
needs
>> to
>>>> be further clarified, it may be the conditions for sending the
>>>> DIAMETER_TOO_BUSY response. It is assumed that the server will wait
>> for
>>>> being overloaded but there is nothing preventing the server to =
apply
>> a
>>>> specific policy/algorithm allowing the server to modulate the
>> traffic
>>>> load.
>>>>=20
>>>>  There's a strong likelihood that at least some implementations
>> will
>>>>  continue to send Diameter requests to an upstream peer even after
>>>>  receiving a DIAMETER_TOO_BUSY error.
>>>>=20
>>>> [Lionel] this would mean that these implementations would not =
follow
>>>> the recommendations put in the RFC.
>>>>=20
>>>>  BCP 41 [RFC2914] describes, among other things, how end-to-end
>>>>  application behavior can help avoid congestion collapse.  In
>>>>  particular, an application should avoid sending messages that will
>>>>  never be delivered or processed.  The DIAMETER_TOO_BUSY behavior
>> as
>>>>  described in the Diameter base specification fails at this, since
>> if
>>>>  an upstream node becomes overloaded, a client attempts each
>> request,
>>>>  and does not discover the need to failover the request until the
>>>>  initial attempt fails.
>>>>=20
>>>> [Lionel] As described above, it depends on the time the first
>>>> DIAMETER_TOO_BUSY response. But it is clear that this point needs =
to
>> be
>>>> further investigated.
>>>>=20
>>>>  The situation is improved if implementations follow the [RFC3539]
>>>>  recommendation and keep state about upstream peer overload.  But
>>>> even
>>>>  then, the Diameter specification offers no guidance on how long a
>>>>  client should wait before retrying the overloaded destination.  If
>>>> an
>>>>  agent or server supports multiple realms and/or applications,
>>>>  DIAMETER_TOO_BUSY only offers no way to indicate that it is
>>>>  overloaded for one application but not another.  A
>> DIAMETER_TOO_BUSY
>>>>  error can only indicate overload at a "whole server" scope.
>>>>=20
>>>> [Lionel] the DIAMETER_TOO_BUSY response is per application as it is
>> in
>>>> response to given command request using a specific application-id.
>> But
>>>> this point is maybe not so clear in the RFC3588bis.
>>>>=20
>>>>  Agent processing of a DIAMETER_TOO_BUSY response is also
>> problematic
>>>>  as described in the base specification.  DIAMETER_TOO_BUSY is
>>>> defined
>>>>  as a protocol error.  If an agent receives a protocol error, it
>> may
>>>>  either handle it locally or it may forward the response back
>> towards
>>>>  the downstream peer.  (The Diameter specification is inconsistent
>>>>  about whether a protocol error MAY or SHOULD be handled by an
>> agent,
>>>>  rather than forwarded downstream.)  If a downstream peer receives
>>>> the
>>>>  DIAMETER_TOO_BUSY response, it may stop sending all requests to
>> the
>>>>  agent for some period of time, even though the agent may still be
>>>>  able to deliver requests to other upstream peers.
>>>>=20
>>>> [Lionel] the DIAMETER_TOO_BUSY response is sent by the overloaded
>>>> server. So if the Proxy/Relay forwards the response to a downstream
>>>> client, the client can determine if the "busy" node is the agent or
>> the
>>>> server based on origin-host of the response. About the behavior of
>> the
>>>> agent receiving the DIAMETER_TOO_BUSY response, it cannot be found
>> in
>>>> the base protocol but should be defined par application, even if
>>>> generic guidelines could be provided.
>>>>=20
>>>> [Lionel] Some texts on DIAMETER_UNABLE_TO_DELIVER may be useful =
also
>> to
>>>> explain that there is also some gray area around its use, =
especially
>> in
>>>> a overload control context. For instance, a client receiving this
>>>> response does not know the reason for which the request has not =
been
>>>> delivered (e.g. IP failure, network congestion, etc.) and so it is
>> not
>>>> possible to provide a finer granularity of the client behavior,
>>>> depending of different criteria can't be further detailed
>>>>=20
>>>> Regards,
>>>>=20
>>>> Lionel Morand
>>>>=20
>>>> ******************
>>>>=20
>>>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la =
part
>> de
>>>> Eric McMurry
>>>> Envoy=E9 : jeudi 17 mai 2012 19:43
>>>> =C0 : dime@ietf.org
>>>> Objet : [Dime] Diameter Overload Control Requirements
>>>>=20
>>>> A new draft has been submitted intended to address requirements for
>>>> overload control in Diameter.
>>>>=20
>>>> http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-00.txt
>>>>=20
>>>>=20
>>>> Diameter deployments are growing in size and this is becoming more
>> of
>>>> an issue.  We have seen significant interest in providing a
>> mechanism
>>>> to address it.  Hopefully this document is useful as a base for
>>>> discussion on what is needed and we welcome comments.
>>>>=20
>>>> Abstract:
>>>>       When a Diameter server or agent becomes overloaded, it needs
>> to
>>>> be able
>>>>       to gracefully reduce its load, typically by informing clients
>> to
>>>> reduce
>>>>       sending traffic for some period of time. Otherwise, it must
>>>> continue to
>>>>       expend resources parsing and responding to Diameter messages,
>>>> possibly
>>>>       resulting in congestion collapse. The existing mechanisms
>>>> provided by
>>>>       Diameter are not sufficient for this purpose. This document
>>>> describes
>>>>       the limitations of the existing mechanisms, and provides
>>>> requirements
>>>>       for new overload management mechanisms.
>>>>=20
>>>> The dime charter has an item,
>>>>=20
>>>> - Maintaining and/or progressing, along the standards track, the
>>>> Diameter Base protocol and Diameter Applications. This includes
>>>> extensions to Diameter Base protocol that can be considered as
>>>> enhanced
>>>> features or bug fixes.
>>>>=20
>>>> that this seems suited to go under and we welcome comment on that =
as
>>>> well.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>> =
_______________________________________________________________________
>>>> __________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>> avez
>>>> recu ce message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>>>> messages electroniques etant susceptibles d'alteration,
>>>> France Telecom - Orange decline toute responsabilite si ce message =
a
>>>> ete altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or
>> privileged
>>>> information that may be protected by law;
>>>> they should not be distributed, used or copied without
>> authorisation.
>>>> If you have received this email in error, please notify the sender
>> and
>>>> delete this message and its attachments.
>>>> As emails may be altered, France Telecom - Orange is not liable for
>>>> messages that have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>=20