From internet-drafts@ietf.org Thu Jan 3 00:53:55 2013 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 D22DC21F8A3F; Thu, 3 Jan 2013 00:53:55 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gptQ36lZM3GK; Thu, 3 Jan 2013 00:53:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B35421F8A69; Thu, 3 Jan 2013 00:53:55 -0800 (PST) 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.37 Message-ID: <20130103085355.3332.35391.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2013 00:53:55 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc4005bis-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: Thu, 03 Jan 2013 08:53:56 -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 Worki= ng Group of the IETF. Title : Diameter Network Access Server Application Author(s) : Glen Zorn Filename : draft-ietf-dime-rfc4005bis-12.txt Pages : 67 Date : 2013-01-03 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-rfc4005bis-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-rfc4005bis-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tushar.panda@ruckuswireless.com Thu Jan 3 01:30:07 2013 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 6F50E21F8648 for ; Thu, 3 Jan 2013 01:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxVE+tfH7rGR for ; Thu, 3 Jan 2013 01:30:06 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD8B21F863C for ; Thu, 3 Jan 2013 01:30:06 -0800 (PST) Received: from mail28-co1-R.bigfish.com (10.243.78.206) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Thu, 3 Jan 2013 09:30:05 +0000 Received: from mail28-co1 (localhost [127.0.0.1]) by mail28-co1-R.bigfish.com (Postfix) with ESMTP id B18114C0117 for ; Thu, 3 Jan 2013 09:30:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.237.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0811HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zzc85fh1443Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh18c673h17326ahz32i2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail28-co1 (localhost.localdomain [127.0.0.1]) by mail28-co1 (MessageSwitch) id 1357205403116947_25205; Thu, 3 Jan 2013 09:30:03 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.199]) by mail28-co1.bigfish.com (Postfix) with ESMTP id 0FE8FB4005E for ; Thu, 3 Jan 2013 09:30:03 +0000 (UTC) Received: from BY2PRD0811HT005.namprd08.prod.outlook.com (157.56.237.5) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 3 Jan 2013 09:30:02 +0000 Received: from BY2PRD0811MB405.namprd08.prod.outlook.com ([169.254.3.206]) by BY2PRD0811HT005.namprd08.prod.outlook.com ([10.255.91.168]) with mapi id 14.16.0245.002; Thu, 3 Jan 2013 09:30:01 +0000 From: "Tushar Kanti. Panda" To: "dime@ietf.org" Thread-Topic: Clarification on Few Use Cases Thread-Index: Ac3pkma25e4EhzDlQqeDlO0nXkN5FA== Date: Thu, 3 Jan 2013 09:30:01 +0000 Message-ID: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [202.56.248.46] Content-Type: multipart/alternative; boundary="_000_CAA7E123BE3C0242B256F243B976385D24E994B9BY2PRD0811MB405_" MIME-Version: 1.0 X-OriginatorOrg: ruckuswireless.com Subject: [Dime] Clarification on Few Use Cases 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, 03 Jan 2013 09:31:30 -0000 --_000_CAA7E123BE3C0242B256F243B976385D24E994B9BY2PRD0811MB405_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Diameter Team, It is quite some time when I work= ed on Diameter related application. Recently for my project requirement, I = again need to work on Diameter stuff. I got some doubts for few use cases a= nd I need team's help to validate my understanding. 1st Use Case : It is regarding server initiated message such as RAR or ASR.= These requests are sent from server to client and will always have destina= tion host. My understanding says that server initiated message will also pa= ss through request routing principle as discussed in Sec 6.1 of RFC 6733. = Having said above, it is possible that if the given destination host is not= available from the server prospective, then server may route the server in= itiated request to some other server based on request routing. Is my unders= tanding correct over here ? I am not sure if there are any diameter applications which sends server ini= tiated message without destination host and requests are routed. Whatever a= pplications I have seen, all are having destination host mandatory AVP in t= he server initiated request. 2nd Use Case : Is it possible that Server accepts subsequent messages related to a given s= essions from multiple origin host. In simple terms, let's say Host 1 initia= ted the diameter session X1 with OCS server. Will OCS server give any error= if it receives 2nd request on the same session from Host 2. Is this allowe= d ? Thanks in advance for any help in this regard. Regards Tushar --_000_CAA7E123BE3C0242B256F243B976385D24E994B9BY2PRD0811MB405_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Diameter Team,

        &nbs= p;            &= nbsp;           &nbs= p;        It is quite some time when I w= orked on Diameter related application. Recently for my project requirement,= I again need to work on Diameter stuff. I got some doubts for few use case= s and I need team’s help to validate my understanding.

 

1st Use Case : It is regarding server ini= tiated message such as RAR or ASR. These requests are sent from server to c= lient and will always have destination host. My understanding says that ser= ver initiated message will also pass through  request routing principle as discussed in Sec 6.1 of RFC 673= 3. Having said above, it is possible that if the given destination host is = not available from the server prospective, then server may route the server= initiated request to some other server based on request routing. Is my understanding correct over here ?

 

I am not sure if there are any diameter applications= which sends server initiated message without destination host and requests= are routed. Whatever applications I have seen, all are having destination = host mandatory AVP in the server initiated request.

 

 

2nd Use Case :

 

Is it possible that Server accepts subsequent messag= es related to a given sessions from multiple origin host. In simple terms, = let’s say Host 1 initiated the diameter session X1 with OCS server. W= ill OCS server give any error if it receives 2nd request on the same session from Host 2. Is this allowed ?<= o:p>

 

Thanks in advance for any help in this regard.<= /o:p>

 

 

Regards

Tushar

--_000_CAA7E123BE3C0242B256F243B976385D24E994B9BY2PRD0811MB405_-- From ben@nostrum.com Mon Jan 7 14:29:57 2013 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 58EEB11E809A for ; Mon, 7 Jan 2013 14:29:57 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l51mX7dreAp for ; Mon, 7 Jan 2013 14:29:56 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A592211E8099 for ; Mon, 7 Jan 2013 14:29:56 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r07MTjmv043567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Jan 2013 16:29:46 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_B3D14098-7652-49BB-8683-D5B3C5D64BA8" Date: Mon, 7 Jan 2013 16:29:48 -0600 Message-Id: <70D78ADF-5D0B-4C12-8E5B-E27A61F1AB46@nostrum.com> To: "" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Subject: [Dime] Overload Req 2 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 Jan 2013 22:29:57 -0000 --Apple-Mail=_B3D14098-7652-49BB-8683-D5B3C5D64BA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, We had a thread on Req 2 from the overload requirements draft that sort = of trailed off over the weekend. I'd like to bring that to a conclusion = soon so we can submit a version with no known open issues. Here's proposed language (A complete replacement for Req 2) based on = that thread: Old: [Open Issue: The following requirement has generated list discussion = that is unresolved at the time of this writing. The discussion concerns = whether this requirement is needed at all, whether it should include the = "MUST NOT require specification changes" language vs saying that it = should not force changes large enough to require new application IDs, = and whether we should include additional language to forbid assumptions = about the behavior of specific implementations.] The overload control = mechanism MUST be useable with any existing or future Diameter = application. It MUST NOT require specification changes for existing = Diameter applications. New: The mechanism MUST allow Diameter nodes to support overload control = regardless of which Diameter applications they support.=20 The basic mechanism is intended to be application-independent, that is, = a Diameter node can use it across any existing and future Diameter = applications and expect reasonable results. Certain Diameter = applications might, however, benefit from application-specific behavior = over and above the mechanism's defaults. For example, an application = specification might specify relative priorities of messages or selection = of a specific overload control algorithm. Thanks! Ben. --Apple-Mail=_B3D14098-7652-49BB-8683-D5B3C5D64BA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
[Open Issue: =
The following requirement has generated list discussion that is =
unresolved at the time of this writing. The discussion concerns whether =
this requirement is needed at all, whether it should include the "MUST =
NOT require specification changes" language vs saying that it should not =
force changes large enough to require new application IDs, and whether =
we should include additional language to forbid assumptions about the =
behavior of specific implementations.] The overload control mechanism =
MUST be useable with any existing or future Diameter application. It =
MUST NOT require specification changes for existing Diameter =
applications.


<= br>
New:

The basic mechanism is intended to be application-independent, = that is, a Diameter node can use it across any existing and future = Diameter applications and expect reasonable results. Certain Diameter = applications might, however, benefit from application-specific behavior = over and above the mechanism's defaults. For example, an application = specification might specify relative priorities of messages or selection = of a specific overload control algorithm.

Dear All:

By reading the draft-ietf-dime-overload-reqs-02, I have few comments on REQ 18.

REQ 18:=A0=A0=A0=A0=A0 In a mixed environment of nodes that support the overload

=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 control mechanism and that do not, users and operators of

=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 nodes that do not support the mechanism MUST NOT unfairly

=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 benefit from the mechanism.

=A0

It may be necessary to further clarify the meaning of the =93unfairly benefit=94 in t= he context of Diameter overload control. The =93unfairly benefit=94 may indica= te achieving higher effective throughput, obtaining a higher share of the serv= ice of upstream node, or others. Thus, a more thorough explanation of =93unfair= ly benefit=94 is needed.

=A0

In addition, si= nce the fairness is an important performance metric of overload control mechani= sm (as in SIP overload control, RFC6357 section 7), should we need to define t= he fairness in Diameter overload control and propose the requirements on fairn= ess of overload control mechanism? For example, the nodes that support the over= load control mechanism MUST fairly share the service of upstream node.

=A0=A0


Best Regards

Jinzhu Wang

China Mobile

--20cf300fafc1a1fc9e04d2ad1243-- From ben@nostrum.com Mon Jan 7 18:31:20 2013 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 1812721F87F9 for ; Mon, 7 Jan 2013 18:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UrAewYZPm6k for ; Mon, 7 Jan 2013 18:31:19 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 882D121F87F5 for ; Mon, 7 Jan 2013 18:31:19 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r082VEmh067728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Jan 2013 20:31:15 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Mon, 7 Jan 2013 20:31:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3A058F67-1929-4AE0-8567-65A8FE62801D@nostrum.com> References: To: jinzhu wang X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] comments on REQ 18 in draft-ietf-dime-overload-reqs-02 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 Jan 2013 02:31:20 -0000 Hi, Please see inline: Thanks! Ben. On Jan 7, 2013, at 12:38 AM, jinzhu wang = wrote: > Dear All: >=20 > By reading the draft-ietf-dime-overload-reqs-02, I have few comments = on REQ 18. >=20 > REQ 18: In a mixed environment of nodes that support the overload >=20 > control mechanism and that do not, users and operators of >=20 > nodes that do not support the mechanism MUST NOT unfairly >=20 > benefit from the mechanism. >=20 > =20 > It may be necessary to further clarify the meaning of the =93unfairly = benefit=94 in the context of Diameter overload control. The =93unfairly = benefit=94 may indicate achieving higher effective throughput, obtaining = a higher share of the service of upstream node, or others. Thus, a more = thorough explanation of =93unfairly benefit=94 is needed. >=20 I don't think we intended to introduce the idea of fairness as a = measurable quantity in this draft, and certainly not with the degree of = precision in RFC 6357. It was a deliberately imprecise term to describe = a deliberately imprecise concept. In fact, the word "unfair" was = introduced in this most recent version to try to better explain the = previous wording. If it can't stand without a definition, then I think = we should revert back, and add some more explanation. In particular, we are trying to avoid the scenario where a = non-supporting node gains an advantage over a supporting node merely = from the fact that it doesn't support the mechanism. For example, = consider if an overloaded server asks clients to reduce the traffic. A = supporting node does so. A non-supporting node continues to send the = original traffic level, and gets more transaction completions than the = supporting server. That particular example suggests that the server = can't simply assume that all clients will honor the request, and still = needs to implement whatever internal load-shedding mechanism it would = have used without the overload control mechanism. That's one example, and there may be others. Maybe it would help to = restate this as a design consideration rather than a requirement? > In addition, since the fairness is an important performance metric of = overload control mechanism (as in SIP overload control, RFC6357 section = 7), should we need to define the fairness in Diameter overload control = and propose the requirements on fairness of overload control mechanism? = For example, the nodes that support the overload control mechanism MUST = fairly share the service of upstream node. >=20 I don't think we set out to define performance metrics in this draft. It = might be good to have them, but I'm not sure they belong here. What do = others think? From isj-dime@i1.dk Tue Jan 8 00:49:55 2013 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 E4CA721F8830 for ; Tue, 8 Jan 2013 00:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.961 X-Spam-Level: * X-Spam-Status: No, score=1.961 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DK=1.009, HELO_MISMATCH_DK=1.7, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IfjehO186yu for ; Tue, 8 Jan 2013 00:49:55 -0800 (PST) Received: from i1.dk (unknown [188.176.48.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4587D21F882D for ; Tue, 8 Jan 2013 00:49:55 -0800 (PST) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id B18265C0095 for ; Tue, 8 Jan 2013 09:49:50 +0100 (CET) Received: from isjsys.int.i1.dk (isjsys-i0.int.i1.dk [IPv6:2001:16d8:dd31:1:219:d1ff:fe90:2bfa]) by i1.dk (Postfix) with ESMTP for ; Tue, 8 Jan 2013 09:49:50 +0100 (CET) Received: from isjsys.localnet (localhost [IPv6:::1]) by isjsys.int.i1.dk (Postfix) with ESMTP id 82BAEE9F41 for ; Tue, 8 Jan 2013 09:49:47 +0100 (CET) From: Ivan Skytte =?iso-8859-1?q?J=F8rgensen?= To: "dime@ietf.org" Date: Tue, 8 Jan 2013 09:49:47 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301080949.47194.isj-dime@i1.dk> Subject: [Dime] CER from already connected peer 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 Jan 2013 08:49:56 -0000 If a peer receives a CER with an Origin-Host for which the peer already have a transport connection what should happen? I initially thought that the election process should take place but then I realised that if it is due to a misconfiguration and it is actually two different peers that has errournously been configured with the same Host- Identity then doing an election would cause the first transport connection to be closed, and cause a flip-flp effect: Peer A connects, transport connection 1 is established. Peer B connections, presents the same Origin-Host in CER, causes transport connection 1 to be closed. Transport connection 2 established. Peer A connections, presents the same Origin-Host in CER, causes transport connection 2 to be closed. Transport connection 3 established. Peer B connections, presents the same Origin-Host in CER, causes transport connection 3 to be closed. Transport connection 4 established. ... ad nauseam Neither RFC3588 nor RFC6733 is clear about this error configuration; they are most concerned when two peers simultaneously connect to eachother. Currently I keep the existing transport connection. If it is in fact the same peer and not two misconfigured peers then the old transport connection will presumably be closed eventually due to DW failures, and a new transport connection will be accepted. Does anyone see a flow in this? Regards, Ivan From wangjinzhu1004@gmail.com Tue Jan 8 19:31:50 2013 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 DF42411E80D2 for ; Tue, 8 Jan 2013 19:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P62riLxKLpxf for ; Tue, 8 Jan 2013 19:31:50 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id EC3D111E80AE for ; Tue, 8 Jan 2013 19:31:49 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id eg20so1298812lab.30 for ; Tue, 08 Jan 2013 19:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=E4WsuZMlzOQMqnCKdAkudg3+YwBZyFpIYyuP5Pfnbkk=; b=A8usq/Aw4EURNl35NskNlryD7nXyl3cZl7MOhxhpg3DN/etrCTONRUm8cpiluWpksK jVvc66nwVZJOChMWLH2dYLrdZOJKt8ze6uyQAFV6FEpd20qf5lJGPgYoUtffGsbKaVYm QaXWeMq76PxXReEBmaDQhYCBwq0QS/4tebzBrxIE2rtk2RcCQy0kuLnTmZ5Cdx6ol6jl rciOIXNkvVX4E5ftg4HpnSaJYw+Ic7H2r+6vM3wgNhjPgYn0RVmXuUzN6TgWS4G55ogu pfjd/cnh6f3DJzImr0zkeR8ExoxxUyE1otJUYvzht6eotYUAS5j7YhiK1Ul8VPqoD55z XKYw== MIME-Version: 1.0 Received: by 10.152.46.161 with SMTP id w1mr63927681lam.27.1357702306480; Tue, 08 Jan 2013 19:31:46 -0800 (PST) Received: by 10.112.23.8 with HTTP; Tue, 8 Jan 2013 19:31:46 -0800 (PST) In-Reply-To: <3A058F67-1929-4AE0-8567-65A8FE62801D@nostrum.com> References: <3A058F67-1929-4AE0-8567-65A8FE62801D@nostrum.com> Date: Wed, 9 Jan 2013 11:31:46 +0800 Message-ID: From: jinzhu wang To: Ben Campbell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] comments on REQ 18 in draft-ietf-dime-overload-reqs-02 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 Jan 2013 03:31:51 -0000 Hi Ben, Please see inline: Best Regards Jinzhu Wang China Mobile 2013/1/8 Ben Campbell : > Hi, > > Please see inline: > > Thanks! > > Ben. > > On Jan 7, 2013, at 12:38 AM, jinzhu wang wrote= : > >> Dear All: >> >> By reading the draft-ietf-dime-overload-reqs-02, I have few comments on = REQ 18. >> >> REQ 18: In a mixed environment of nodes that support the overload >> >> control mechanism and that do not, users and operators of >> >> nodes that do not support the mechanism MUST NOT unfairly >> >> benefit from the mechanism. >> >> >> It may be necessary to further clarify the meaning of the =93unfairly be= nefit=94 in the context of Diameter overload control. The =93unfairly benef= it=94 may indicate achieving higher effective throughput, obtaining a highe= r share of the service of upstream node, or others. Thus, a more thorough e= xplanation of =93unfairly benefit=94 is needed. >> > > I don't think we intended to introduce the idea of fairness as a measurab= le quantity in this draft, and certainly not with the degree of precision i= n RFC 6357. It was a deliberately imprecise term to describe a deliberately= imprecise concept. In fact, the word "unfair" was introduced in this most = recent version to try to better explain the previous wording. If it can't s= tand without a definition, then I think we should revert back, and add some= more explanation. > > In particular, we are trying to avoid the scenario where a non-supporting= node gains an advantage over a supporting node merely from the fact that i= t doesn't support the mechanism. For example, consider if an overloaded ser= ver asks clients to reduce the traffic. A supporting node does so. A non-su= pporting node continues to send the original traffic level, and gets more t= ransaction completions than the supporting server. That particular example = suggests that the server can't simply assume that all clients will honor th= e request, and still needs to implement whatever internal load-shedding mec= hanism it would have used without the overload control mechanism. > > That's one example, and there may be others. Maybe it would help to resta= te this as a design consideration rather than a requirement? > Thanks for the thorough explanation. I agree with the requirement of preventing the non-supporting node gaining an advantage over a supporting node and I think it is better to give a more explanation to this requirement instead of using the word =93unfair=94. >> In addition, since the fairness is an important performance metric of ov= erload control mechanism (as in SIP overload control, RFC6357 section 7), s= hould we need to define the fairness in Diameter overload control and propo= se the requirements on fairness of overload control mechanism? For example,= the nodes that support the overload control mechanism MUST fairly share th= e service of upstream node. >> > > I don't think we set out to define performance metrics in this draft. It = might be good to have them, but I'm not sure they belong here. What do othe= rs think? > The main performance metrics of the overload control mechanism consist of throughput, responsiveness, fairness, etc. I notice that the requirements of high throughput and high responsiveness have already been proposed. (REQ 3 requires high throughput and REQ 14 requires high responsiveness). In this regard, the requirement of good fairness may be needed? From hannes.tschofenig@gmx.net Fri Jan 11 00:11:34 2013 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 E24D721F8ABA for ; Fri, 11 Jan 2013 00:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.885 X-Spam-Level: X-Spam-Status: No, score=-101.885 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl-Qnqe-ZxlZ for ; Fri, 11 Jan 2013 00:11:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7721F8AB8 for ; Fri, 11 Jan 2013 00:11:32 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M2rpw-1T0vgr3TpG-00scyo for ; Fri, 11 Jan 2013 09:11:31 +0100 Received: (qmail invoked by alias); 11 Jan 2013 08:11:31 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp028) with SMTP; 11 Jan 2013 09:11:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181EoZd7tw1tkjoIVxZ2UadUV5nuc1ay4LiZUyCxv dUHGG5GSnkOKk9 From: Hannes Tschofenig Content-Type: multipart/alternative; boundary=Apple-Mail-123--519915560 Date: Fri, 11 Jan 2013 10:11:29 +0200 Message-Id: <2C652EE2-3EC4-4CBB-AE90-20CDA94D6563@gmx.net> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [Dime] Review of draft-ietf-dime-overload-reqs-02 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 Jan 2013 08:11:35 -0000 --Apple-Mail-123--519915560 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Eric, Hi Ben,=20 I went through the document and here are a few minor comments.=20 You write: " 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. " I suggest to change it to: " The existing Diameter mechanisms, listed in Section 4, are not sufficient for this purpose. Section 5 describes the limitations of the existing mechanisms, and provides requirements for new overload management mechanisms in Section 7. " =20 You write:=20 This document draws on [RFC5390] and the work done on SIP overload control as well as on overload practices in SS7 networks and studies done by 3GPP. =20 My suggestion would be to re-word this sentence to: This document draws on the work done on SIP overload control [RFC5390, RFC6357, draft-ietf-soc-overload-control], = experience gained with overload handling in SS7 networks, and studies = done by 3GPP (see Section 6). =20 You write: " Diameter is not typically an end-user protocol; rather it is =20 generally used as one component in support of some end-user activity. For example, a WiFi access point might use Diameter to authenticate and authorize user access via 802.11. Overload in a network that uses Diameter applications will likely spill over into the end-user application network. The impact of Diameter overload on the client application (a client application may use the Diameter protocol and other protocols to do its job) is beyond the scope of this document. "=20 I would change this paragraph to: "=20 Diameter is not an end-user protocol; rather it is =20 generally used as a backend protocol in support of some application. =20 For example, a SIP server might use Diameter to authenticate and authorize user access. Overload in the Diameter backend = infrastructure will likely impact the experience observed by the end user in the SIP=20= application.=20 =20 The impact of Diameter overload on the application using the Diameter = protocol=20 is beyond the scope of this document. " You write: "=20 Diameter depends heavily on The "Authentication, Authorization, and Accounting (AAA) Transport Profile" [RFC3539], which states assumptions about the scale of AAA services which may be incorrect for current uses of Diameter. In particular, the document suggests that AAA services will typically be low volume and that traffic will typically be application-driven. Section 2.1 of that document uses an example of a 48 port NAS. However, Diameter is commonly used in large-scale mobile data environments, where a typical client could be a packet gateway that serves millions of users, and generates Diameter messages at network-driven rates. " I am not sure why the text is indented. I also do not believe that RFC = 3539 states incorrect assumption. You reference the same of a 48 port NAS but = in the=20 same section 10,000 48-ports NASes as well as 2048-port NASes are = mentioned as well.=20 Even though the examples may not necessarily map to the current = deployment the=20 point the referenced section makes is a different one, namely "the rate = at which=20 messages are sent is typically limited by how quickly they are generated = by the application,=20 rather than by the size of the congestion window." This statement is = also applicable=20 to the discussion in draft-ietf-dime-overload-reqs. =20 Section 2.3: s/diameter/Diameter Section 3: s/diameter/Diameter Regarding extensibility I am wondering whether you are trying to say = that the algorithm itself should not be standardized (or should at least = be extensible) or that the mechanism to convey overload information = should be extensible.=20 If it is the former then I would suggest to rename the section to = something like "Overload Algorithm Independence" I would have actually expected the text from Section 4 to appear much = earlier in the document, for example, in the introduction RFC 5390 = actually does a pretty good job in explaining why the currently = specified overload mechanisms in SIP are insufficient and further work = is needed.=20 Section 5:=20 I would shorten the introduction to the sub-sections because the same = text is repeated twice.=20 Change from: " The currently available Diameter mechanisms for indicating an overload condition are not adequate to avoid service outages due to overload. This inadequacy may, in turn, contribute to broader congestion collapse due to unresponsive Diameter nodes causing application or transport layer retransmissions. In particular, they do not allow a Diameter agent or server to shed load as it approaches overload. At best, a node can only indicate that it needs to entirely stop receiving requests, i.e. that it has effectively failed. Even that is problematic due to the inability to indicate durational validity on the transient errors available in the base Diameter protocol. Diameter offers no mechanism to allow a node to indicate different overload states for different categories of messages, for example, if it is overloaded for one Diameter application but not another. " To: " The currently available Diameter mechanisms for indicating an overload condition are not adequate, as described in the sub-sections=20= below.=20 " s/It makes no suggestion that a the receipt of a DIAMETER_TOO_BUSY response should affect future Diameter messages in any way./It makes no suggestion that the receipt of a DIAMETER_TOO_BUSY response should affect future Diameter messages in any way. =20 =20 You should probably expand acronyms on first use. Examples: IMS, GSM, = SS7, 3GPP, UMTS, CDMA You write:=20 " Smartphones contribute much more heavily, relative to non- smartphones, to the continuation of a registration surge due to their very aggressive registration algorithms. The aggressive smartphone logic is designed to: a. always have voice and data registration, and b. constantly try to be on 3G or LTE data (and thus on 3G voice or VoLTE) for their added benefits. Non-smartphones typically have logic to wait for a time period after registering successfully on voice and data. The smartphone aggressive registration is problematic in two ways: o first by generating excessive signaling load towards the HLR that is ten times that from a non-smartphone, o and second by causing continual registration attempts when a network failure affects registrations through the 3G data network. = =20 " I have to guess what point you are trying to make in the second part of = Section 6.1.=20 I believe the the issue you want to point out is that applications on = smart phones send keep-alive messages peridically to ensure that the = applications are always reachable. The Diameter overload handling does = not offer a solution in this case since newer phones work (with their = applications) work differently than legacy phones and therefore more = state is required. It might help to cite a document that provides further information and = to supports the statements you have made.=20 Requirements:=20 You write: " REQ 11: The overload control mechanism MUST be scalable. That is, it MUST be able to operate in different sized networks. "=20 I would simplify this statement into: " REQ 11: The overload control mechanism MUST be able to operate = networks of different=20 size.=20 "=20 =09 Just saying it "scales" is not really useful. REQ 18: In a mixed environment of nodes that support the overload control mechanism and that do not, users and operators of nodes that do not support the mechanism MUST NOT unfairly benefit from the mechanism. =09 As mentioned on the mailing list this is hard to accomplish. Consider = the following case: +------------------+ +------------------+ | | | | | | | | | Client 1 | | Client 2 | | | | | +--------+-`.------+ +------.'+---------+ `. .' `. .' `. .' `. .' +-------`.'--------+ | | | | | Agent | | | +--------+---------+ | | | +--------+---------+ | | | | | Server | | | +------------------+ Imagine that the server is under heavy load and reports this situation. = There are two clients who contribute to the overload: client 1 = understands the overload feedback signal and client 2 doesn't. So, = what's going to happen? client 1 will reduce the sending rate while = client 2 will not react.=20 =09 I am not sure what you are trying to express with REQ 30. Lacking e2e = security in Diameter all you can do is to trust your neighboring nodes = (which you hopefully have authenticated).=20 Replay Attacks Are you concerned about replay attacks by Diameter nodes, by on-path = attackers (who are not Diameter nodes), or by off-path attackers?=20 Reading through the entire document there is one aspect unclear to me: = How do you want to support the exchange of overload information between = non-neighboring nodes (particularly when some intermediate nodes do not = support the indicated mechanism)? Or, you could phrase it in a different = way: If you are able to exchange overload information how do you expect = the approach to work when an unknown number of intermediaries do not = understand how to behave differently in case of new requests. Since you = scope the document in such a way that the actual initiator of the = interactions does not necessarily get informed you leave the decision = making pending somewhere but you do not say where. Let me give you an = example: Imagine a SIP client that triggers some transactions that = require AAA interworking. The AAA client (for example a proxy server) = could decide to reject some end user requests when it receives = notifications about overload. It could, however, also assume that = somewhere further in the AAA network the signaling load will be = "re-directed" to some other servers. Lacking any information about what = the real reason for the overload is it is hard to make some assumptions. = A load balancing node, for example, may not be updated to support the = overload features and could therefore not take those into account, the = may only be a single server, there may be multiple servers but they are = all connected to the same database and the problem is actually with the = database, etc.=20 Ciao Hannes --Apple-Mail-123--519915560 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Eric, Hi = Ben, 

I went through the document and here are a few = minor comments. 

You = write:

"
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.
"

I suggest to change it to:

"
The = existing Diameter mechanisms, listed in Section 4, are not
  =  sufficient for this purpose. Section 5 describes the = limitations
   of the existing mechanisms, and provides = requirements for new
   overload management mechanisms in = Section 7.
   "
   

You = write: 

   This document draws on [RFC5390] and = the work done on SIP overload
   control as well as on = overload practices in SS7 networks and studies
   done by = 3GPP.
 
My suggestion would be to re-word this sentence = to:

   This document draws on the work done on SIP = overload
   control [RFC5390, RFC6357, = draft-ietf-soc-overload-control], experience gained with overload = handling in SS7 networks, and studies done by 3GPP (see Section = 6).
   

You write:
"
   Diameter is = not typically an end-user protocol; rather it is   
  =  generally used as one component in support of some end-user = activity.
   For example, a WiFi access point might use = Diameter to authenticate
   and authorize user access via = 802.11.  Overload in a network that
   uses Diameter = applications will likely spill over into the end-user
  =  application network.  The impact of Diameter overload on the = client
   application (a client application may use the = Diameter protocol and
   other protocols to do its job) is = beyond the scope of this document.
" 

I would change this = paragraph to:
" 
   Diameter is not an end-user = protocol; rather it is   
   generally used as a = backend protocol in support of some application.
  =  
   For example, a SIP server might use Diameter to = authenticate
   and authorize user access.  Overload = in the Diameter backend infrastructure
   will likely = impact the experience observed by the end user in the = SIP 
   application. 
   
  =  The impact of Diameter overload on the application using the = Diameter protocol 
   is beyond the scope of this = document.
"

You write:

" 
      = Diameter depends heavily on The "Authentication, = Authorization,
      and Accounting (AAA) Transport = Profile" [RFC3539], which states
      assumptions = about the scale of AAA services which may be incorrect
    =   for current uses of Diameter.  In particular, the = document
      suggests that AAA services will = typically be low volume and that
      traffic will = typically be application-driven.  Section 2.1 of that
  =     document uses an example of a 48 port NAS.  However, = Diameter is
      commonly used in large-scale mobile = data environments, where a
      typical client could = be a packet gateway that serves millions of
      = users, and generates Diameter messages at network-driven = rates.
"

I am not sure why the text is indented. I also do not = believe that RFC 3539
states incorrect assumption. You reference the = same of a 48 port NAS but in the 
same section 10,000 48-ports = NASes as well as 2048-port NASes are mentioned as well. 
Even = though the examples may not necessarily map to the current deployment = the 
point the referenced section makes is a different one, = namely "the rate at which 
messages are sent is typically = limited by how quickly they are generated by the = application, 
rather than by the size of the congestion window." = This statement is also applicable 
to the discussion in = draft-ietf-dime-overload-reqs.
   
Section 2.3: = s/diameter/Diameter
Section 3: s/diameter/Diameter

Regarding = extensibility I am wondering whether you are trying to say that the = algorithm itself should not be standardized (or should at least be = extensible) or that the mechanism to convey overload information = should be extensible. 

If it is the former then I would = suggest to rename the section to something like "Overload Algorithm = Independence"

I would have actually expected the text from = Section 4 to appear much earlier in the document, for example, in the = introduction RFC 5390 actually does a pretty good job in = explaining why the currently specified overload mechanisms in SIP = are insufficient and further work is needed. 


Section = 5: 

I would shorten the introduction to the sub-sections = because the same text is repeated twice. 

Change = from:

"
   The currently available Diameter = mechanisms for indicating an
   overload condition are not = adequate to avoid service outages due to
   overload. =  This inadequacy may, in turn, contribute to broader
  =  congestion collapse due to unresponsive Diameter nodes = causing
   application or transport layer retransmissions. =  In particular, they
   do not allow a Diameter agent = or server to shed load as it approaches
   overload. =  At best, a node can only indicate that it needs to
  =  entirely stop receiving requests, i.e. that it has = effectively
   failed.  Even that is problematic due = to the inability to indicate
   durational validity on the = transient errors available in the base
   Diameter = protocol.  Diameter offers no mechanism to allow a node = to
   indicate different overload states for different = categories of
   messages, for example, if it is overloaded = for one Diameter
   application but not = another.
"

To:

"
   The currently = available Diameter mechanisms for indicating an
   overload = condition are not adequate, as described in the = sub-sections 
   below. 
"


s/It = makes no suggestion that a the
   receipt of a = DIAMETER_TOO_BUSY response should affect future Diameter
  =  messages in any way./It makes no suggestion that the
  =  receipt of a DIAMETER_TOO_BUSY response should affect future = Diameter
   messages in any way.
   
  =  
You should probably expand acronyms on first use. Examples: = IMS, GSM, SS7, 3GPP, UMTS, CDMA


You = write: 

"
Smartphones contribute much more heavily, = relative to non-
   smartphones, to the continuation of a = registration surge due to their
   very aggressive = registration algorithms.  The aggressive smartphone
  =  logic is designed to:

   a.  always have = voice and data registration, and

   b.  constantly = try to be on 3G or LTE data (and thus on 3G voice or
    =    VoLTE) for their added benefits.

  =  Non-smartphones typically have logic to wait for a time period = after
   registering successfully on voice and = data.

   The smartphone aggressive registration is = problematic in two ways:

   o  first by generating = excessive signaling load towards the HLR that
      is = ten times that from a non-smartphone,

   o  and = second by causing continual registration attempts when a
  =     network failure affects registrations through the 3G data = network. =    
"

I have to guess what point you are = trying to make in the second part of Section 6.1. 

I believe = the the issue you want to point out is that applications on smart phones = send keep-alive messages peridically to ensure that the applications are = always reachable. The Diameter overload handling does not offer a = solution in this case since newer phones work (with their applications) = work differently than legacy phones and therefore more state = is required.

It might help to cite a document that provides = further information and to supports the statements you have = made. 

Requirements: 

You write:
"
  =  REQ 11:  The overload control mechanism MUST be scalable. =  That is,
            it MUST be = able to operate in different sized networks.
" 

I would = simplify this statement into:

"
   REQ 11:  The = overload control mechanism MUST be able to operate networks of = different 
   size. 
" 
=
Just saying it "scales" is not really useful.

REQ 18: =  In a mixed environment of nodes that support the = overload
            control mechanism = and that do not, users and operators of
        =     nodes that do not support the mechanism MUST NOT = unfairly
            benefit from the = mechanism.
=
As mentioned on the mailing list this is hard to = accomplish. Consider the following case:


      =      +------------------+     = +------------------+
           | =                  |   =   |                 =  |
           |     =              |     |   =                |
  =          |     Client 1     = |     |     Client 2     |
  =          |           =        |     |         =          |
        =    +--------+-`.------+     = +------.'+---------+
              =           `.           =     .'
              =            `.         =   .'
                =             `.       = .'
                  =             `.   .'
    =                     = +-------`.'--------+
              =           |           =        |
          =               |       =            |
      =                   |   =   Agent        |
        =                 |     =              |
    =                     = +--------+---------+
              =                   =  |
                =                 =  |
                =                 =  |
                =         +--------+---------+
      =                   |   =                |
  =                     =   |                 =  |
                =         |     Server       = |
                  =       |               =    |
              =           +------------------+

Imagine = that the server is under heavy load and reports this situation. There = are two clients who contribute to the overload: client 1 understands the = overload feedback signal and client 2 doesn't. So, what's going to = happen? client 1 will reduce the sending rate while client 2 will not = react. 
=
I am not sure what = you are trying to express with REQ 30. Lacking e2e security in Diameter = all you can do is to trust your neighboring nodes (which you hopefully = have authenticated). 

Replay Attacks

Are you = concerned about replay attacks by Diameter nodes, by on-path attackers = (who are not Diameter nodes), or by off-path = attackers? 

Reading through the entire document there is one = aspect unclear to me: How do you want to support the exchange of = overload information between non-neighboring nodes (particularly = when some intermediate nodes do not support the indicated = mechanism)? Or, you could phrase it in a different way: If you are able = to exchange overload information how do you expect the approach to work = when an unknown number of intermediaries do not understand how to behave = differently in case of new requests. Since you scope the document in = such a way that the actual initiator of the interactions does not = necessarily get informed you leave the decision making pending somewhere = but you do not say where. Let me give you an example: Imagine a SIP = client that triggers some transactions that require AAA interworking. = The AAA client (for example a proxy server) could decide to reject some = end user requests when it receives notifications about overload. It = could, however, also assume that somewhere further in the AAA network = the signaling load will be "re-directed" to some other servers. Lacking = any information about what the real reason for the overload is it is = hard to make some assumptions. A load balancing node, for example, may = not be updated to support the overload features and could therefore not = take those into account, the may only be a single server, there may be = multiple servers but they are all connected to the same database and the = problem is actually with the database, etc. 

Ciao
Hannes

= --Apple-Mail-123--519915560-- From emcmurry@computer.org Fri Jan 11 07:56:02 2013 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 0F13621F872C for ; Fri, 11 Jan 2013 07:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEtdGWkYWCpl for ; Fri, 11 Jan 2013 07:55:59 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 782D321F884A for ; Fri, 11 Jan 2013 07:55:59 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Ttgxa-000Fut-B3; Fri, 11 Jan 2013 15:55:58 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 641E41388BC5; Fri, 11 Jan 2013 09:55:57 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19GalnGuHKdP1CRCIDI/fkRhV1gOTo2bas= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDlq30xm2q5J; Fri, 11 Jan 2013 09:55:57 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 18C571388BB1; Fri, 11 Jan 2013 09:55:57 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_34D46423-53A0-48D2-A323-3B73C7425EA9" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <2C652EE2-3EC4-4CBB-AE90-20CDA94D6563@gmx.net> Date: Fri, 11 Jan 2013 09:55:55 -0600 Message-Id: <548AFADB-5519-4C0F-83E4-0DBD3781649C@computer.org> References: <2C652EE2-3EC4-4CBB-AE90-20CDA94D6563@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-overload-reqs-02 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 Jan 2013 15:56:02 -0000 --Apple-Mail=_34D46423-53A0-48D2-A323-3B73C7425EA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Hannes, thanks for the comments! responses inline. Eric On Jan 11, 2013, at 2:11 , Hannes Tschofenig = wrote: > Hi Eric, Hi Ben,=20 >=20 > I went through the document and here are a few minor comments.=20 >=20 > You write: >=20 > " > 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 > I suggest to change it to: >=20 > " > The existing Diameter mechanisms, listed in Section 4, are not > sufficient for this purpose. Section 5 describes the limitations > of the existing mechanisms, and provides requirements for new > overload management mechanisms in Section 7. > " > =20 okay >=20 > You write:=20 >=20 > This document draws on [RFC5390] and the work done on SIP overload > control as well as on overload practices in SS7 networks and = studies > done by 3GPP. > =20 > My suggestion would be to re-word this sentence to: >=20 > This document draws on the work done on SIP overload > control [RFC5390, RFC6357, draft-ietf-soc-overload-control], = experience gained with overload handling in SS7 networks, and studies = done by 3GPP (see Section 6). okay in general. I'd rather not reference a draft if it can be avoided. > =20 >=20 > You write: > " > Diameter is not typically an end-user protocol; rather it is =20 > generally used as one component in support of some end-user = activity. > For example, a WiFi access point might use Diameter to authenticate > and authorize user access via 802.11. Overload in a network that > uses Diameter applications will likely spill over into the end-user > application network. The impact of Diameter overload on the client > application (a client application may use the Diameter protocol and > other protocols to do its job) is beyond the scope of this = document. > "=20 >=20 > I would change this paragraph to: > "=20 > Diameter is not an end-user protocol; rather it is =20 > generally used as a backend protocol in support of some = application. > =20 > For example, a SIP server might use Diameter to authenticate > and authorize user access. Overload in the Diameter backend = infrastructure > will likely impact the experience observed by the end user in the = SIP=20 > application.=20 > =20 > The impact of Diameter overload on the application using the = Diameter protocol=20 > is beyond the scope of this document. > " >=20 I see two comments here; break up the paragraph, and use a SIP example = instead of the 802.11 example. right? > You write: >=20 > "=20 > Diameter depends heavily on The "Authentication, Authorization, > and Accounting (AAA) Transport Profile" [RFC3539], which states > assumptions about the scale of AAA services which may be = incorrect > for current uses of Diameter. In particular, the document > suggests that AAA services will typically be low volume and that > traffic will typically be application-driven. Section 2.1 of = that > document uses an example of a 48 port NAS. However, Diameter is > commonly used in large-scale mobile data environments, where a > typical client could be a packet gateway that serves millions of > users, and generates Diameter messages at network-driven rates. > " >=20 > I am not sure why the text is indented. I also do not believe that RFC = 3539 > states incorrect assumption. You reference the same of a 48 port NAS = but in the=20 > same section 10,000 48-ports NASes as well as 2048-port NASes are = mentioned as well.=20 > Even though the examples may not necessarily map to the current = deployment the=20 > point the referenced section makes is a different one, namely "the = rate at which=20 > messages are sent is typically limited by how quickly they are = generated by the application,=20 > rather than by the size of the congestion window." This statement is = also applicable=20 > to the discussion in draft-ietf-dime-overload-reqs. I think it was indented because no one noticed that :-). If there was a = reason, I don't remember it. I will fix that. I agree with you on the intent of that session in RFC 3539, and I = believe that was where the last statement in the paragraph in this draft = came from. Even using the RFC 3539 example of 10,000 NASs, the = characteristics and scale are quite different than with current and = future Diameter usage. It is entirely possible for networks, as well as = applications, to become congested with Diameter traffic now. That said, this was in the document to show some history and how the = original thinking and planned usages have not matched where things ended = up, and is not integral to the document. If it is causing confusion it = should be changed or removed. > =20 > Section 2.3: s/diameter/Diameter > Section 3: s/diameter/Diameter thanks, I'll fix those >=20 > Regarding extensibility I am wondering whether you are trying to say = that the algorithm itself should not be standardized (or should at least = be extensible) or that the mechanism to convey overload information = should be extensible.=20 >=20 > If it is the former then I would suggest to rename the section to = something like "Overload Algorithm Independence" The intended extensibility was broader. I recall that this was added to = address a question on one of the requirements at some point. It looks = like we should have put a bit more in it. I'll broaden the language in = this section. >=20 > I would have actually expected the text from Section 4 to appear much = earlier in the document, for example, in the introduction RFC 5390 = actually does a pretty good job in explaining why the currently = specified overload mechanisms in SIP are insufficient and further work = is needed.=20 I think swapping that with section 3 would be reasonable. It was after = section 2 so that there was some context to talk about why the existing = mechanisms were not sufficient. Putting it before that might be a bit = confusing. Thoughts? >=20 >=20 > Section 5:=20 >=20 > I would shorten the introduction to the sub-sections because the same = text is repeated twice.=20 >=20 > Change from: >=20 > " > The currently available Diameter mechanisms for indicating an > overload condition are not adequate to avoid service outages due to > overload. This inadequacy may, in turn, contribute to broader > congestion collapse due to unresponsive Diameter nodes causing > application or transport layer retransmissions. In particular, = they > do not allow a Diameter agent or server to shed load as it = approaches > overload. At best, a node can only indicate that it needs to > entirely stop receiving requests, i.e. that it has effectively > failed. Even that is problematic due to the inability to indicate > durational validity on the transient errors available in the base > Diameter protocol. Diameter offers no mechanism to allow a node to > indicate different overload states for different categories of > messages, for example, if it is overloaded for one Diameter > application but not another. > " >=20 > To: >=20 > " > The currently available Diameter mechanisms for indicating an > overload condition are not adequate, as described in the = sub-sections=20 > below.=20 > " >=20 I'm not sure I agree with this. If I were reading it on a first pass I = think I would appreciate the summary. The same concepts are repeated = and expanded in the subsections, but I don't think the text is copied. >=20 > s/It makes no suggestion that a the > receipt of a DIAMETER_TOO_BUSY response should affect future = Diameter > messages in any way./It makes no suggestion that the > receipt of a DIAMETER_TOO_BUSY response should affect future = Diameter > messages in any way. > =20 got it. thanks. > =20 > You should probably expand acronyms on first use. Examples: IMS, GSM, = SS7, 3GPP, UMTS, CDMA I will scrub for that. These particular terms though are usually not = expanded in documents that I recall. >=20 >=20 > You write:=20 >=20 > " > Smartphones contribute much more heavily, relative to non- > smartphones, to the continuation of a registration surge due to = their > very aggressive registration algorithms. The aggressive smartphone > logic is designed to: >=20 > a. always have voice and data registration, and >=20 > b. constantly try to be on 3G or LTE data (and thus on 3G voice or > VoLTE) for their added benefits. >=20 > Non-smartphones typically have logic to wait for a time period = after > registering successfully on voice and data. >=20 > The smartphone aggressive registration is problematic in two ways: >=20 > o first by generating excessive signaling load towards the HLR = that > is ten times that from a non-smartphone, >=20 > o and second by causing continual registration attempts when a > network failure affects registrations through the 3G data = network. =20 > " >=20 > I have to guess what point you are trying to make in the second part = of Section 6.1.=20 >=20 > I believe the the issue you want to point out is that applications on = smart phones send keep-alive messages peridically to ensure that the = applications are always reachable. The Diameter overload handling does = not offer a solution in this case since newer phones work (with their = applications) work differently than legacy phones and therefore more = state is required. >=20 > It might help to cite a document that provides further information and = to supports the statements you have made.=20 I'll see what I can find for references. At a minimum, I agree that some context should be placed there around = the growing proportion of smartphones and their impact. This is = expository and is just intended to convey an example cause of overload = that is getting worse over time. >=20 > Requirements:=20 >=20 > You write: > " > REQ 11: The overload control mechanism MUST be scalable. That is, > it MUST be able to operate in different sized networks. > "=20 >=20 > I would simplify this statement into: >=20 > " > REQ 11: The overload control mechanism MUST be able to operate = networks of different=20 > size.=20 > "=20 > =09 > Just saying it "scales" is not really useful. okay >=20 > REQ 18: In a mixed environment of nodes that support the overload > control mechanism and that do not, users and operators of > nodes that do not support the mechanism MUST NOT unfairly > benefit from the mechanism. > =09 > As mentioned on the mailing list this is hard to accomplish. Consider = the following case: >=20 >=20 > +------------------+ +------------------+ > | | | | > | | | | > | Client 1 | | Client 2 | > | | | | > +--------+-`.------+ +------.'+---------+ > `. .' > `. .' > `. .' > `. .' > +-------`.'--------+ > | | > | | > | Agent | > | | > +--------+---------+ > | > | > | > +--------+---------+ > | | > | | > | Server | > | | > +------------------+ >=20 > Imagine that the server is under heavy load and reports this = situation. There are two clients who contribute to the overload: client = 1 understands the overload feedback signal and client 2 doesn't. So, = what's going to happen? client 1 will reduce the sending rate while = client 2 will not react.=20 Perhaps saying that the mechanism must allow elements to ensure fair = behavior or provide means to do so would be better. The mechanism must = not preclude fair behavior. In this case, the server (or the agent) = could throttle traffic from client 2. > =09 > I am not sure what you are trying to express with REQ 30. Lacking e2e = security in Diameter all you can do is to trust your neighboring nodes = (which you hopefully have authenticated).=20 yes, lack of e2e security is an issue. Hop-by-hop authentication helps, = but would not protect from a middle box relaying malicious information. = You could also, for example, control what scope of overload is = acceptable from any given source, to minimize impacts. The point of = this was to ensure that this was considered for any mechanism. >=20 > Replay Attacks >=20 > Are you concerned about replay attacks by Diameter nodes, by on-path = attackers (who are not Diameter nodes), or by off-path attackers?=20 is there a reason to be specific here? >=20 > Reading through the entire document there is one aspect unclear to me: = How do you want to support the exchange of overload information between = non-neighboring nodes (particularly when some intermediate nodes do not = support the indicated mechanism)? Or, you could phrase it in a different = way: If you are able to exchange overload information how do you expect = the approach to work when an unknown number of intermediaries do not = understand how to behave differently in case of new requests. Since you = scope the document in such a way that the actual initiator of the = interactions does not necessarily get informed you leave the decision = making pending somewhere but you do not say where. Let me give you an = example: Imagine a SIP client that triggers some transactions that = require AAA interworking. The AAA client (for example a proxy server) = could decide to reject some end user requests when it receives = notifications about overload. It could, however, also assume that = somewhere further in the AAA network the signaling load will be = "re-directed" to some other servers. Lacking any information about what = the real reason for the overload is it is hard to make some assumptions. = A load balancing node, for example, may not be updated to support the = overload features and could therefore not take those into account, the = may only be a single server, there may be multiple servers but they are = all connected to the same database and the problem is actually with the = database, etc.=20 I'm not sure I fully understand your question, but I'll take a stab. I = think the general point is around middle boxes that do no support the = mechanism. This is tricky, because clients may not be aware of any = specifics behind middle boxes. In the case of a load balancer, for = example, a client may be unaware that there are multiple servers. If it = exchanged overload information with one server behind the load balancer, = would that information be valid for all of the other servers? I think = the requirement here is that it would be, or that the middle box would = be responsible for it. In general, anything reporting overload = information for a particular scope needs to be authoritative for that = scope. We were trying to capture that in the requirements in a way that = did not force a particular mechanism. --Apple-Mail=_34D46423-53A0-48D2-A323-3B73C7425EA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Hannes,

thanks for the = comments!

responses = inline.

Eric


On Jan 11, 2013, at 2:11 , Hannes Tschofenig <hannes.tschofenig@gmx.net>= ; wrote:

Hi Eric, Hi = Ben, 

I went through the document and here are a few = minor comments. 

You = write:

"
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.
"

I suggest to change it to:

"
The = existing Diameter mechanisms, listed in Section 4, are not
  =  sufficient for this purpose. Section 5 describes the = limitations
   of the existing mechanisms, and provides = requirements for new
   overload management mechanisms in = Section 7.
   "
  =  

okay

You = write: 

   This document draws on [RFC5390] and = the work done on SIP overload
   control as well as on = overload practices in SS7 networks and studies
   done by = 3GPP.
 
My suggestion would be to re-word this sentence = to:

   This document draws on the work done on SIP = overload
   control [RFC5390, RFC6357, = draft-ietf-soc-overload-control], experience gained with overload = handling in SS7 networks, and studies done by 3GPP (see Section = 6).

okay in = general.  I'd rather not reference a draft if it can be = avoided.


  =  

You write:
"
   Diameter is not typically = an end-user protocol; rather it is   
  =  generally used as one component in support of some end-user = activity.
   For example, a WiFi access point might use = Diameter to authenticate
   and authorize user access via = 802.11.  Overload in a network that
   uses Diameter = applications will likely spill over into the end-user
  =  application network.  The impact of Diameter overload on the = client
   application (a client application may use the = Diameter protocol and
   other protocols to do its job) is = beyond the scope of this document.
" 

I would change this = paragraph to:
" 
   Diameter is not an end-user = protocol; rather it is   
   generally used as a = backend protocol in support of some application.
  =  
   For example, a SIP server might use Diameter to = authenticate
   and authorize user access.  Overload = in the Diameter backend infrastructure
   will likely = impact the experience observed by the end user in the = SIP 
   application. 
   
  =  The impact of Diameter overload on the application using the = Diameter protocol 
   is beyond the scope of this = document.
"


= I see two comments here; break up the paragraph, and use a SIP example = instead of the 802.11 example.  right?

You = write:

" 
      Diameter depends heavily = on The "Authentication, Authorization,
      and = Accounting (AAA) Transport Profile" [RFC3539], which states
  =     assumptions about the scale of AAA services which may be = incorrect
      for current uses of Diameter.  In = particular, the document
      suggests that AAA = services will typically be low volume and that
      = traffic will typically be application-driven.  Section 2.1 of = that
      document uses an example of a 48 port NAS. =  However, Diameter is
      commonly used in = large-scale mobile data environments, where a
      = typical client could be a packet gateway that serves millions = of
      users, and generates Diameter messages at = network-driven rates.
"

I am not sure why the text is = indented. I also do not believe that RFC 3539
states incorrect = assumption. You reference the same of a 48 port NAS but in = the 
same section 10,000 48-ports NASes as well as 2048-port = NASes are mentioned as well. 
Even though the examples may not = necessarily map to the current deployment the 
point the = referenced section makes is a different one, namely "the rate at = which 
messages are sent is typically limited by how quickly = they are generated by the application, 
rather than by the size = of the congestion window." This statement is also applicable 
to = the discussion in = draft-ietf-dime-overload-reqs.
I think it was indented because no one noticed that :-). =  If there was a reason, I don't remember it.  I will fix = that.

I agree with you on the intent of that = session in RFC 3539, and I believe that was where the last statement in = the paragraph in this draft came from.  Even using the RFC 3539 = example of 10,000 NASs, the characteristics and scale are quite = different than with current and future Diameter usage.  It is = entirely possible for networks, as well as applications, to become = congested with Diameter traffic now.

That said, = this was in the document to show some history and how the original = thinking and planned usages have not matched where things ended up, and = is not integral to the document.  If it is causing confusion it = should be changed or removed.


  =  
Section 2.3: s/diameter/Diameter
Section 3: = s/diameter/Diameter

thanks, I'll fix those


Regarding = extensibility I am wondering whether you are trying to say that the = algorithm itself should not be standardized (or should at least be = extensible) or that the mechanism to convey overload information = should be extensible. 

If it is the former then I would = suggest to rename the section to something like "Overload Algorithm = Independence"

The = intended extensibility was broader.  I recall that this was added = to address a question on one of the requirements at some point.  It = looks like we should have put a bit more in it.  I'll broaden the = language in this section.


I would have = actually expected the text from Section 4 to appear much earlier in the = document, for example, in the introduction RFC 5390 actually does a = pretty good job in explaining why the currently specified overload = mechanisms in SIP are insufficient and further work is = needed. 

I = think swapping that with section 3 would be reasonable.  It was = after section 2 so that there was some context to talk about why the = existing mechanisms were not sufficient.  Putting it before that = might be a bit confusing.  Thoughts?



Section = 5: 

I would shorten the introduction to the sub-sections = because the same text is repeated twice. 

Change = from:

"
   The currently available Diameter = mechanisms for indicating an
   overload condition are not = adequate to avoid service outages due to
   overload. =  This inadequacy may, in turn, contribute to broader
  =  congestion collapse due to unresponsive Diameter nodes = causing
   application or transport layer retransmissions. =  In particular, they
   do not allow a Diameter agent = or server to shed load as it approaches
   overload. =  At best, a node can only indicate that it needs to
  =  entirely stop receiving requests, i.e. that it has = effectively
   failed.  Even that is problematic due = to the inability to indicate
   durational validity on the = transient errors available in the base
   Diameter = protocol.  Diameter offers no mechanism to allow a node = to
   indicate different overload states for different = categories of
   messages, for example, if it is overloaded = for one Diameter
   application but not = another.
"

To:

"
  =  The currently available Diameter mechanisms for indicating = an
   overload condition are not adequate, as described in = the sub-sections 
  =  below. 
"


I'm not sure I agree with this.  If I were reading it on a = first pass I think I would appreciate the summary.  The same = concepts are repeated and expanded in the subsections, but I don't think = the text is copied.


s/It makes no = suggestion that a the
   receipt of a DIAMETER_TOO_BUSY = response should affect future Diameter
   messages in any = way./It makes no suggestion that the
   receipt of a = DIAMETER_TOO_BUSY response should affect future Diameter
  =  messages in any way.
  =  

got it. =  thanks.

   
You should probably expand = acronyms on first use. Examples: IMS, GSM, SS7, 3GPP, UMTS, = CDMA

I will scrub = for that.  These particular terms though are usually not expanded = in documents that I recall.



You = write: 

"
Smartphones contribute much more heavily, = relative to non-
   smartphones, to the continuation of a = registration surge due to their
   very aggressive = registration algorithms.  The aggressive smartphone
  =  logic is designed to:

   a.  always have = voice and data registration, and

   b.  constantly = try to be on 3G or LTE data (and thus on 3G voice or
    =    VoLTE) for their added benefits.

  =  Non-smartphones typically have logic to wait for a time period = after
   registering successfully on voice and = data.

   The smartphone aggressive registration is = problematic in two ways:

   o  first by generating = excessive signaling load towards the HLR that
      is = ten times that from a non-smartphone,

   o  and = second by causing continual registration attempts when a
  =     network failure affects registrations through the 3G data = network. =    
"

I have to guess what point you are = trying to make in the second part of Section 6.1. 

I believe = the the issue you want to point out is that applications on smart phones = send keep-alive messages peridically to ensure that the applications are = always reachable. The Diameter overload handling does not offer a = solution in this case since newer phones work (with their applications) = work differently than legacy phones and therefore more state = is required.

It might help to cite a document that provides = further information and to supports the statements you have = made. 

I'll = see what I can find for references.

At a = minimum, I agree that some context should be placed there around the = growing proportion of smartphones and their impact.  This is = expository and is just intended to convey an example cause of overload = that is getting worse over time.


Requirements: 

You write:
"
   REQ = 11:  The overload control mechanism MUST be scalable.  That = is,
            it MUST be able to = operate in different sized networks.
" 

I would simplify = this statement into:

"
   REQ 11:  The overload = control mechanism MUST be able to operate networks of = different 
   size. 
" 
=
Just saying it "scales" is not really = useful.

okay
<= br>

REQ = 18:  In a mixed environment of nodes that support the = overload
            control mechanism = and that do not, users and operators of
        =     nodes that do not support the mechanism MUST NOT = unfairly
            benefit from the = mechanism.
=
As mentioned on the mailing list this is hard to = accomplish. Consider the following case:


      =      +------------------+     = +------------------+
           | =                  |   =   |                 =  |
           |     =              |     |   =                |
  =          |     Client 1     = |     |     Client 2     |
  =          |           =        |     |         =          |
        =    +--------+-`.------+     = +------.'+---------+
              =           `.           =     .'
              =            `.         =   .'
                =             `.       = .'
                  =             `.   .'
    =                     = +-------`.'--------+
              =           |           =        |
          =               |       =            |
      =                   |   =   Agent        |
        =                 |     =              |
    =                     = +--------+---------+
              =                   =  |
                =                 =  |
                =                 =  |
                =         +--------+---------+
      =                   |   =                |
  =                     =   |                 =  |
                =         |     Server       = |
                  =       |               =    |
              =           +------------------+

Imagine = that the server is under heavy load and reports this situation. There = are two clients who contribute to the overload: client 1 understands the = overload feedback signal and client 2 doesn't. So, what's going to = happen? client 1 will reduce the sending rate while client 2 will not = react. 

Perhap= s saying that the mechanism must allow elements to ensure fair behavior = or provide means to do so would be better.  The mechanism must not = preclude fair behavior.  In this case, the server (or the agent) = could throttle traffic from client 2.

=
I am not sure what you are trying to express = with REQ 30. Lacking e2e security in Diameter all you can do is to trust = your neighboring nodes (which you hopefully have = authenticated). 

yes, lack of e2e security is an issue.  Hop-by-hop = authentication helps, but would not protect from a middle box relaying = malicious information.  You could also, for example, control what = scope of overload is acceptable from any given source, to minimize = impacts.  The point of this was to ensure that this was considered = for any mechanism.



Replay = Attacks

Are you concerned about replay attacks by Diameter nodes, = by on-path attackers (who are not Diameter nodes), or by off-path = attackers? 

is= there a reason to be specific here?


Reading through = the entire document there is one aspect unclear to me: How do you want = to support the exchange of overload information between non-neighboring = nodes (particularly when some intermediate nodes do not support the = indicated mechanism)? Or, you could phrase it in a different way: If you = are able to exchange overload information how do you expect the approach = to work when an unknown number of intermediaries do not understand how = to behave differently in case of new requests. Since you scope the = document in such a way that the actual initiator of the interactions = does not necessarily get informed you leave the decision making pending = somewhere but you do not say where. Let me give you an example: Imagine = a SIP client that triggers some transactions that require AAA = interworking. The AAA client (for example a proxy server) could decide = to reject some end user requests when it receives notifications about = overload. It could, however, also assume that somewhere further in the = AAA network the signaling load will be "re-directed" to some other = servers. Lacking any information about what the real reason for the = overload is it is hard to make some assumptions. A load balancing node, = for example, may not be updated to support the overload features and = could therefore not take those into account, the may only be a single = server, there may be multiple servers but they are all connected to the = same database and the problem is actually with the database, = etc. 

I'm not = sure I fully understand your question, but I'll take a stab.  I = think the general point is around middle boxes that do no support the = mechanism.  This is tricky, because clients may not be aware of any = specifics behind middle boxes.  In the case of a load balancer, for = example, a client may be unaware that there are multiple servers. =  If it exchanged overload information with one server behind the = load balancer, would that information be valid for all of the other = servers?  I think the requirement here is that it would be, or that = the middle box would be responsible for it.  In general, anything = reporting overload information for a particular scope needs to be = authoritative for that scope.  We were trying to capture that in = the requirements in a way that did not force a particular = mechanism.




= --Apple-Mail=_34D46423-53A0-48D2-A323-3B73C7425EA9-- From hannes.tschofenig@gmx.net Tue Jan 15 00:46:53 2013 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 C0CD721F87D5 for ; Tue, 15 Jan 2013 00:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.048 X-Spam-Level: X-Spam-Status: No, score=-102.048 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96vWTSyr5Rti for ; Tue, 15 Jan 2013 00:46:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id A938121F87C8 for ; Tue, 15 Jan 2013 00:46:51 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LiZpS-1TN4vW3Q56-00cjmt for ; Tue, 15 Jan 2013 09:46:50 +0100 Received: (qmail invoked by alias); 15 Jan 2013 08:46:50 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp002) with SMTP; 15 Jan 2013 09:46:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18d2O59IVkdWCpvcAPyDVvc4+aZz+GchDCFtlqEiJ byoB0bLwKtgmqz Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <548AFADB-5519-4C0F-83E4-0DBD3781649C@computer.org> Date: Tue, 15 Jan 2013 10:46:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B8DAABB-DE1A-44E6-B115-CF388EFB76A5@gmx.net> References: <2C652EE2-3EC4-4CBB-AE90-20CDA94D6563@gmx.net> <548AFADB-5519-4C0F-83E4-0DBD3781649C@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-overload-reqs-02 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 Jan 2013 08:46:53 -0000 Hi Eric,=20 thanks for your quick response.=20 On Jan 11, 2013, at 5:55 PM, Eric McMurry wrote: > Hi Hannes, >=20 > thanks for the comments! >=20 > responses inline. >=20 > Eric >=20 >=20 > On Jan 11, 2013, at 2:11 , Hannes Tschofenig = wrote: >=20 >> Hi Eric, Hi Ben,=20 >>=20 >> I went through the document and here are a few minor comments.=20 >>=20 >> You write: >>=20 >> " >> 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 >> I suggest to change it to: >>=20 >> " >> The existing Diameter mechanisms, listed in Section 4, are not >> sufficient for this purpose. Section 5 describes the limitations >> of the existing mechanisms, and provides requirements for new >> overload management mechanisms in Section 7. >> " >> =20 >=20 > okay >=20 >>=20 >> You write:=20 >>=20 >> This document draws on [RFC5390] and the work done on SIP overload >> control as well as on overload practices in SS7 networks and = studies >> done by 3GPP. >> =20 >> My suggestion would be to re-word this sentence to: >>=20 >> This document draws on the work done on SIP overload >> control [RFC5390, RFC6357, draft-ietf-soc-overload-control], = experience gained with overload handling in SS7 networks, and studies = done by 3GPP (see Section 6). >=20 > okay in general. I'd rather not reference a draft if it can be = avoided. >=20 >=20 As informative references drafts are unproblematic.=20 >> =20 >>=20 >> You write: >> " >> Diameter is not typically an end-user protocol; rather it is =20 >> generally used as one component in support of some end-user = activity. >> For example, a WiFi access point might use Diameter to = authenticate >> and authorize user access via 802.11. Overload in a network that >> uses Diameter applications will likely spill over into the = end-user >> application network. The impact of Diameter overload on the = client >> application (a client application may use the Diameter protocol = and >> other protocols to do its job) is beyond the scope of this = document. >> "=20 >>=20 >> I would change this paragraph to: >> "=20 >> Diameter is not an end-user protocol; rather it is =20 >> generally used as a backend protocol in support of some = application. >> =20 >> For example, a SIP server might use Diameter to authenticate >> and authorize user access. Overload in the Diameter backend = infrastructure >> will likely impact the experience observed by the end user in the = SIP=20 >> application.=20 >> =20 >> The impact of Diameter overload on the application using the = Diameter protocol=20 >> is beyond the scope of this document. >> " >>=20 >=20 > I see two comments here; break up the paragraph, and use a SIP example = instead of the 802.11 example. right? Particularly the reference to 802.11 does not seem too realistic since = WLAN deployments mostly use RADIUS.=20 >=20 >> You write: >>=20 >> "=20 >> Diameter depends heavily on The "Authentication, Authorization, >> and Accounting (AAA) Transport Profile" [RFC3539], which states >> assumptions about the scale of AAA services which may be = incorrect >> for current uses of Diameter. In particular, the document >> suggests that AAA services will typically be low volume and = that >> traffic will typically be application-driven. Section 2.1 of = that >> document uses an example of a 48 port NAS. However, Diameter = is >> commonly used in large-scale mobile data environments, where a >> typical client could be a packet gateway that serves millions = of >> users, and generates Diameter messages at network-driven rates. >> " >>=20 >> I am not sure why the text is indented. I also do not believe that = RFC 3539 >> states incorrect assumption. You reference the same of a 48 port NAS = but in the=20 >> same section 10,000 48-ports NASes as well as 2048-port NASes are = mentioned as well.=20 >> Even though the examples may not necessarily map to the current = deployment the=20 >> point the referenced section makes is a different one, namely "the = rate at which=20 >> messages are sent is typically limited by how quickly they are = generated by the application,=20 >> rather than by the size of the congestion window." This statement is = also applicable=20 >> to the discussion in draft-ietf-dime-overload-reqs. >=20 > I think it was indented because no one noticed that :-). If there was = a reason, I don't remember it. I will fix that. >=20 > I agree with you on the intent of that session in RFC 3539, and I = believe that was where the last statement in the paragraph in this draft = came from. Even using the RFC 3539 example of 10,000 NASs, the = characteristics and scale are quite different than with current and = future Diameter usage. It is entirely possible for networks, as well as = applications, to become congested with Diameter traffic now. >=20 > That said, this was in the document to show some history and how the = original thinking and planned usages have not matched where things ended = up, and is not integral to the document. If it is causing confusion it = should be changed or removed. >=20 To focus on the specific sentences: "=20 Diameter depends heavily on the "Authentication, Authorization, and Accounting (AAA) Transport Profile" [RFC3539], " I would write: "The Transport Profile document [RFC3539] discusses = transport layer issues that arise with AAA protocols and recommendations on how to overcome these issues. " " which states assumptions about the scale of AAA services which may be incorrect for current uses of Diameter. " I don't see those assumptions. The entire document is only focused on = discussing different issues.=20 " In particular, the document suggests that AAA services will typically be low volume and that traffic will typically be application-driven. " I don't see this assumption of low volume.=20 " Section 2.1 of that document uses an example of a 48 port NAS. However, Diameter is commonly used in large-scale mobile data environments, where a typical client could be a packet gateway that serves millions of users, and generates Diameter messages at network-driven rates. " I would write:=20 "Diameter is commonly used in large-scale mobile data environments, where a typical client could be a packet gateway that serves millions of users." >=20 >> =20 >> Section 2.3: s/diameter/Diameter >> Section 3: s/diameter/Diameter >=20 > thanks, I'll fix those >=20 >>=20 >> Regarding extensibility I am wondering whether you are trying to say = that the algorithm itself should not be standardized (or should at least = be extensible) or that the mechanism to convey overload information = should be extensible.=20 >>=20 >> If it is the former then I would suggest to rename the section to = something like "Overload Algorithm Independence" >=20 > The intended extensibility was broader. I recall that this was added = to address a question on one of the requirements at some point. It = looks like we should have put a bit more in it. I'll broaden the = language in this section. Thanks.=20 >=20 >>=20 >> I would have actually expected the text from Section 4 to appear much = earlier in the document, for example, in the introduction RFC 5390 = actually does a pretty good job in explaining why the currently = specified overload mechanisms in SIP are insufficient and further work = is needed.=20 >=20 > I think swapping that with section 3 would be reasonable. It was = after section 2 so that there was some context to talk about why the = existing mechanisms were not sufficient. Putting it before that might = be a bit confusing. Thoughts? I personally think that Section 4 could come after Section 2 since the = scenarios just try to illustrate new features that should be supported.=20= >=20 >>=20 >>=20 >> Section 5:=20 >>=20 >> I would shorten the introduction to the sub-sections because the same = text is repeated twice.=20 >>=20 >> Change from: >>=20 >> " >> The currently available Diameter mechanisms for indicating an >> overload condition are not adequate to avoid service outages due = to >> overload. This inadequacy may, in turn, contribute to broader >> congestion collapse due to unresponsive Diameter nodes causing >> application or transport layer retransmissions. In particular, = they >> do not allow a Diameter agent or server to shed load as it = approaches >> overload. At best, a node can only indicate that it needs to >> entirely stop receiving requests, i.e. that it has effectively >> failed. Even that is problematic due to the inability to indicate >> durational validity on the transient errors available in the base >> Diameter protocol. Diameter offers no mechanism to allow a node = to >> indicate different overload states for different categories of >> messages, for example, if it is overloaded for one Diameter >> application but not another. >> " >>=20 >> To: >>=20 >> " >> The currently available Diameter mechanisms for indicating an >> overload condition are not adequate, as described in the = sub-sections=20 >> below.=20 >> " >>=20 >=20 > I'm not sure I agree with this. If I were reading it on a first pass = I think I would appreciate the summary. The same concepts are repeated = and expanded in the subsections, but I don't think the text is copied. For long and complex text it makes sense to summarize but in this case = neither is true.=20 >=20 >>=20 >> s/It makes no suggestion that a the >> receipt of a DIAMETER_TOO_BUSY response should affect future = Diameter >> messages in any way./It makes no suggestion that the >> receipt of a DIAMETER_TOO_BUSY response should affect future = Diameter >> messages in any way. >> =20 >=20 > got it. thanks. >=20 >> =20 >> You should probably expand acronyms on first use. Examples: IMS, GSM, = SS7, 3GPP, UMTS, CDMA >=20 > I will scrub for that. These particular terms though are usually not = expanded in documents that I recall. >=20 Here is a list of abbreviations the RFC editor has collected: http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt >>=20 >>=20 >> You write:=20 >>=20 >> " >> Smartphones contribute much more heavily, relative to non- >> smartphones, to the continuation of a registration surge due to = their >> very aggressive registration algorithms. The aggressive = smartphone >> logic is designed to: >>=20 >> a. always have voice and data registration, and >>=20 >> b. constantly try to be on 3G or LTE data (and thus on 3G voice = or >> VoLTE) for their added benefits. >>=20 >> Non-smartphones typically have logic to wait for a time period = after >> registering successfully on voice and data. >>=20 >> The smartphone aggressive registration is problematic in two ways: >>=20 >> o first by generating excessive signaling load towards the HLR = that >> is ten times that from a non-smartphone, >>=20 >> o and second by causing continual registration attempts when a >> network failure affects registrations through the 3G data = network. =20 >> " >>=20 >> I have to guess what point you are trying to make in the second part = of Section 6.1.=20 >>=20 >> I believe the the issue you want to point out is that applications on = smart phones send keep-alive messages peridically to ensure that the = applications are always reachable. The Diameter overload handling does = not offer a solution in this case since newer phones work (with their = applications) work differently than legacy phones and therefore more = state is required. >>=20 >> It might help to cite a document that provides further information = and to supports the statements you have made.=20 >=20 > I'll see what I can find for references. >=20 > At a minimum, I agree that some context should be placed there around = the growing proportion of smartphones and their impact. This is = expository and is just intended to convey an example cause of overload = that is getting worse over time. >=20 >>=20 >> Requirements:=20 >>=20 >> You write: >> " >> REQ 11: The overload control mechanism MUST be scalable. That = is, >> it MUST be able to operate in different sized networks. >> "=20 >>=20 >> I would simplify this statement into: >>=20 >> " >> REQ 11: The overload control mechanism MUST be able to operate = networks of different=20 >> size.=20 >> "=20 >> =09 >> Just saying it "scales" is not really useful. >=20 > okay >=20 >>=20 >> REQ 18: In a mixed environment of nodes that support the overload >> control mechanism and that do not, users and operators of >> nodes that do not support the mechanism MUST NOT unfairly >> benefit from the mechanism. >> =09 >> As mentioned on the mailing list this is hard to accomplish. Consider = the following case: >>=20 >>=20 >> +------------------+ +------------------+ >> | | | | >> | | | | >> | Client 1 | | Client 2 | >> | | | | >> +--------+-`.------+ +------.'+---------+ >> `. .' >> `. .' >> `. .' >> `. .' >> +-------`.'--------+ >> | | >> | | >> | Agent | >> | | >> +--------+---------+ >> | >> | >> | >> +--------+---------+ >> | | >> | | >> | Server | >> | | >> +------------------+ >>=20 >> Imagine that the server is under heavy load and reports this = situation. There are two clients who contribute to the overload: client = 1 understands the overload feedback signal and client 2 doesn't. So, = what's going to happen? client 1 will reduce the sending rate while = client 2 will not react.=20 >=20 > Perhaps saying that the mechanism must allow elements to ensure fair = behavior or provide means to do so would be better. The mechanism must = not preclude fair behavior. In this case, the server (or the agent) = could throttle traffic from client 2. >=20 >> =09 >> I am not sure what you are trying to express with REQ 30. Lacking e2e = security in Diameter all you can do is to trust your neighboring nodes = (which you hopefully have authenticated).=20 >=20 > yes, lack of e2e security is an issue. Hop-by-hop authentication = helps, but would not protect from a middle box relaying malicious = information. You could also, for example, control what scope of = overload is acceptable from any given source, to minimize impacts. The = point of this was to ensure that this was considered for any mechanism. >=20 >=20 >>=20 >> Replay Attacks >>=20 >> Are you concerned about replay attacks by Diameter nodes, by on-path = attackers (who are not Diameter nodes), or by off-path attackers?=20 >=20 > is there a reason to be specific here? It depends what your concerns are and how they impact the solution. If = there is just some text to say that the authors have addressed security = in the document then it does not matter.=20 For cases where non-Diameter nodes act as adversaries there is a = solution in Diameter. That's good. For those cases where Diameter nodes = act maliciously there is a problem (which you will not be able to fix).=20= >=20 >>=20 >> Reading through the entire document there is one aspect unclear to = me: How do you want to support the exchange of overload information = between non-neighboring nodes (particularly when some intermediate nodes = do not support the indicated mechanism)? Or, you could phrase it in a = different way: If you are able to exchange overload information how do = you expect the approach to work when an unknown number of intermediaries = do not understand how to behave differently in case of new requests. = Since you scope the document in such a way that the actual initiator of = the interactions does not necessarily get informed you leave the = decision making pending somewhere but you do not say where. Let me give = you an example: Imagine a SIP client that triggers some transactions = that require AAA interworking. The AAA client (for example a proxy = server) could decide to reject some end user requests when it receives = notifications about overload. It could, however, also assume that = somewhere further in the AAA network the signaling load will be = "re-directed" to some other servers. Lacking any information about what = the real reason for the overload is it is hard to make some assumptions. = A load balancing node, for example, may not be updated to support the = overload features and could therefore not take those into account, the = may only be a single server, there may be multiple servers but they are = all connected to the same database and the problem is actually with the = database, etc.=20 >=20 > I'm not sure I fully understand your question, but I'll take a stab. = I think the general point is around middle boxes that do no support the = mechanism. This is tricky, because clients may not be aware of any = specifics behind middle boxes. In the case of a load balancer, for = example, a client may be unaware that there are multiple servers. If it = exchanged overload information with one server behind the load balancer, = would that information be valid for all of the other servers? I think = the requirement here is that it would be, or that the middle box would = be responsible for it. In general, anything reporting overload = information for a particular scope needs to be authoritative for that = scope. We were trying to capture that in the requirements in a way that = did not force a particular mechanism. I was hoping to read from the requirement whether a hop-by-hop approach = or an end-to-end approach is better.=20 Ciao Hannes From emcmurry@computer.org Tue Jan 15 13:00:29 2013 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 B60761F0C5F for ; Tue, 15 Jan 2013 13:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJLTLT0BAVTE for ; Tue, 15 Jan 2013 13:00:27 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id A1DAD21F84D0 for ; Tue, 15 Jan 2013 13:00:27 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TvDcQ-000DVf-OM; Tue, 15 Jan 2013 21:00:27 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 1079B14BEA6F; Tue, 15 Jan 2013 15:00:25 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18/xXT18akE6xpfs5c03XlDlncWdteKbjI= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhYFb-Bw_AwV; Tue, 15 Jan 2013 15:00:24 -0600 (CST) Received: from [10.12.30.154] (unknown [4.30.77.1]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 654C714BEA67; Tue, 15 Jan 2013 15:00:24 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <1B8DAABB-DE1A-44E6-B115-CF388EFB76A5@gmx.net> Date: Tue, 15 Jan 2013 15:00:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <29007788-BEA5-430F-B672-51C4B7C7041A@computer.org> References: <2C652EE2-3EC4-4CBB-AE90-20CDA94D6563@gmx.net> <548AFADB-5519-4C0F-83E4-0DBD3781649C@computer.org> <1B8DAABB-DE1A-44E6-B115-CF388EFB76A5@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-overload-reqs-02 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 Jan 2013 21:00:29 -0000 Hi Hannes, Thanks for the additional clarification. Responses inline. Eric On Jan 15, 2013, at 2:46 , Hannes Tschofenig = wrote: > Hi Eric,=20 >=20 > thanks for your quick response.=20 >=20 > On Jan 11, 2013, at 5:55 PM, Eric McMurry wrote: >=20 >> Hi Hannes, >>=20 >> thanks for the comments! >>=20 >> responses inline. >>=20 >> Eric >>=20 >>=20 >> On Jan 11, 2013, at 2:11 , Hannes Tschofenig = wrote: >>=20 >>> Hi Eric, Hi Ben,=20 >>>=20 >>> I went through the document and here are a few minor comments.=20 >>>=20 >>> You write: >>>=20 >>> " >>> 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 >>> I suggest to change it to: >>>=20 >>> " >>> The existing Diameter mechanisms, listed in Section 4, are not >>> sufficient for this purpose. Section 5 describes the limitations >>> of the existing mechanisms, and provides requirements for new >>> overload management mechanisms in Section 7. >>> " >>>=20 >>=20 >> okay >>=20 >>>=20 >>> You write:=20 >>>=20 >>> This document draws on [RFC5390] and the work done on SIP overload >>> control as well as on overload practices in SS7 networks and = studies >>> done by 3GPP. >>>=20 >>> My suggestion would be to re-word this sentence to: >>>=20 >>> This document draws on the work done on SIP overload >>> control [RFC5390, RFC6357, draft-ietf-soc-overload-control], = experience gained with overload handling in SS7 networks, and studies = done by 3GPP (see Section 6). >>=20 >> okay in general. I'd rather not reference a draft if it can be = avoided. >>=20 >>=20 >=20 > As informative references drafts are unproblematic.=20 okay. In this case though, I don't think we referenced that for the = requirements. That one is more useful for drawing from for mechanism. >=20 >=20 >>>=20 >>>=20 >>> You write: >>> " >>> Diameter is not typically an end-user protocol; rather it is =20 >>> generally used as one component in support of some end-user = activity. >>> For example, a WiFi access point might use Diameter to = authenticate >>> and authorize user access via 802.11. Overload in a network that >>> uses Diameter applications will likely spill over into the = end-user >>> application network. The impact of Diameter overload on the = client >>> application (a client application may use the Diameter protocol = and >>> other protocols to do its job) is beyond the scope of this = document. >>> "=20 >>>=20 >>> I would change this paragraph to: >>> "=20 >>> Diameter is not an end-user protocol; rather it is =20 >>> generally used as a backend protocol in support of some = application. >>>=20 >>> For example, a SIP server might use Diameter to authenticate >>> and authorize user access. Overload in the Diameter backend = infrastructure >>> will likely impact the experience observed by the end user in the = SIP=20 >>> application.=20 >>>=20 >>> The impact of Diameter overload on the application using the = Diameter protocol=20 >>> is beyond the scope of this document. >>> " >>>=20 >>=20 >> I see two comments here; break up the paragraph, and use a SIP = example instead of the 802.11 example. right? >=20 > Particularly the reference to 802.11 does not seem too realistic since = WLAN deployments mostly use RADIUS.=20 okay >=20 >=20 >>=20 >>> You write: >>>=20 >>> "=20 >>> Diameter depends heavily on The "Authentication, Authorization, >>> and Accounting (AAA) Transport Profile" [RFC3539], which states >>> assumptions about the scale of AAA services which may be = incorrect >>> for current uses of Diameter. In particular, the document >>> suggests that AAA services will typically be low volume and = that >>> traffic will typically be application-driven. Section 2.1 of = that >>> document uses an example of a 48 port NAS. However, Diameter = is >>> commonly used in large-scale mobile data environments, where a >>> typical client could be a packet gateway that serves millions = of >>> users, and generates Diameter messages at network-driven rates. >>> " >>>=20 >>> I am not sure why the text is indented. I also do not believe that = RFC 3539 >>> states incorrect assumption. You reference the same of a 48 port NAS = but in the=20 >>> same section 10,000 48-ports NASes as well as 2048-port NASes are = mentioned as well.=20 >>> Even though the examples may not necessarily map to the current = deployment the=20 >>> point the referenced section makes is a different one, namely "the = rate at which=20 >>> messages are sent is typically limited by how quickly they are = generated by the application,=20 >>> rather than by the size of the congestion window." This statement is = also applicable=20 >>> to the discussion in draft-ietf-dime-overload-reqs. >>=20 >> I think it was indented because no one noticed that :-). If there = was a reason, I don't remember it. I will fix that. >>=20 >> I agree with you on the intent of that session in RFC 3539, and I = believe that was where the last statement in the paragraph in this draft = came from. Even using the RFC 3539 example of 10,000 NASs, the = characteristics and scale are quite different than with current and = future Diameter usage. It is entirely possible for networks, as well as = applications, to become congested with Diameter traffic now. >>=20 >> That said, this was in the document to show some history and how the = original thinking and planned usages have not matched where things ended = up, and is not integral to the document. If it is causing confusion it = should be changed or removed. >>=20 > To focus on the specific sentences: >=20 > "=20 > Diameter depends heavily on the "Authentication, Authorization, > and Accounting (AAA) Transport Profile" [RFC3539], > " >=20 > I would write: "The Transport Profile document [RFC3539] discusses = transport layer > issues that arise with AAA protocols and recommendations on how to > overcome these issues. " > " > which states > assumptions about the scale of AAA services which may be = incorrect > for current uses of Diameter. > " >=20 > I don't see those assumptions. The entire document is only focused on = discussing different issues.=20 >=20 > " > In particular, the document > suggests that AAA services will typically be low volume and that > traffic will typically be application-driven. > " >=20 > I don't see this assumption of low volume.=20 >=20 > " > Section 2.1 of that > document uses an example of a 48 port NAS. However, Diameter is > commonly used in large-scale mobile data environments, where a > typical client could be a packet gateway that serves millions of > users, and generates Diameter messages at network-driven rates. > " >=20 > I would write:=20 >=20 > "Diameter is > commonly used in large-scale mobile data environments, where a > typical client could be a packet gateway that serves millions of > users." The need for this paragraph has probably passed. I'm thinking deleting = it would be the best course. I'll remove this from the submission I'm = about to make, but I can add it back if folks disagree. [...] >>=20 >>>=20 >>> You should probably expand acronyms on first use. Examples: IMS, = GSM, SS7, 3GPP, UMTS, CDMA >>=20 >> I will scrub for that. These particular terms though are usually not = expanded in documents that I recall. >>=20 > Here is a list of abbreviations the RFC editor has collected: > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt saw that. I expanded the acronyms. thanks for catching. [...] >=20 >=20 >>=20 >>>=20 >>> Replay Attacks >>>=20 >>> Are you concerned about replay attacks by Diameter nodes, by on-path = attackers (who are not Diameter nodes), or by off-path attackers?=20 >>=20 >> is there a reason to be specific here? >=20 > It depends what your concerns are and how they impact the solution. If = there is just some text to say that the authors have addressed security = in the document then it does not matter.=20 >=20 > For cases where non-Diameter nodes act as adversaries there is a = solution in Diameter. That's good. For those cases where Diameter nodes = act maliciously there is a problem (which you will not be able to fix).=20= I think for the requirements, we're just saying that it should be = considered. I agree that a Diameter node can cause issues that are not = fixable, but the scope of potential damage can still be controlled. >=20 >>=20 >>>=20 >>> Reading through the entire document there is one aspect unclear to = me: How do you want to support the exchange of overload information = between non-neighboring nodes (particularly when some intermediate nodes = do not support the indicated mechanism)? Or, you could phrase it in a = different way: If you are able to exchange overload information how do = you expect the approach to work when an unknown number of intermediaries = do not understand how to behave differently in case of new requests. = Since you scope the document in such a way that the actual initiator of = the interactions does not necessarily get informed you leave the = decision making pending somewhere but you do not say where. Let me give = you an example: Imagine a SIP client that triggers some transactions = that require AAA interworking. The AAA client (for example a proxy = server) could decide to reject some end user requests when it receives = notifications about overload. It could, however, also assume that = somewhere further in the AAA network the signaling load will be = "re-directed" to some other servers. Lacking any information about what = the real reason for the overload is it is hard to make some assumptions. = A load balancing node, for example, may not be updated to support the = overload features and could therefore not take those into account, the = may only be a single server, there may be multiple servers but they are = all connected to the same database and the problem is actually with the = database, etc.=20 >>=20 >> I'm not sure I fully understand your question, but I'll take a stab. = I think the general point is around middle boxes that do no support the = mechanism. This is tricky, because clients may not be aware of any = specifics behind middle boxes. In the case of a load balancer, for = example, a client may be unaware that there are multiple servers. If it = exchanged overload information with one server behind the load balancer, = would that information be valid for all of the other servers? I think = the requirement here is that it would be, or that the middle box would = be responsible for it. In general, anything reporting overload = information for a particular scope needs to be authoritative for that = scope. We were trying to capture that in the requirements in a way that = did not force a particular mechanism. >=20 > I was hoping to read from the requirement whether a hop-by-hop = approach or an end-to-end approach is better.=20 We didn't think the requirements should specify that. Mechanisms could = be done either way. From internet-drafts@ietf.org Tue Jan 15 13:01:29 2013 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 8CA4F21F84E6; Tue, 15 Jan 2013 13:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js1mPEWizLsv; Tue, 15 Jan 2013 13:01:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD4021F84D0; Tue, 15 Jan 2013 13:01:29 -0800 (PST) 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.37 Message-ID: <20130115210127.21498.12048.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 13:01:27 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-overload-reqs-03.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, 15 Jan 2013 21:01: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 Worki= ng Group of the IETF. Title : Diameter Overload Control Requirements Author(s) : Eric McMurry Ben Campbell Filename : draft-ietf-dime-overload-reqs-03.txt Pages : 27 Date : 2013-01-15 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 Diameter mechanisms, listed in Section 3 are not sufficient for this purpose. This document describes the limitations of the existing mechanisms in Section 4. Requirements for new overload management mechanisms are provided in Section 7. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From emcmurry@computer.org Tue Jan 15 13:03:54 2013 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 9FBB911E8099 for ; Tue, 15 Jan 2013 13:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCLP7bpTnOWh for ; Tue, 15 Jan 2013 13:03:54 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 09D2C1F0C5F for ; Tue, 15 Jan 2013 13:03:54 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TvDfl-000I4A-DI for dime@ietf.org; Tue, 15 Jan 2013 21:03:53 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 403FF14BEDB8 for ; Tue, 15 Jan 2013 15:03:51 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18CbW4032DUStB3iulgFneY7LSyQ4fehAA= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNt3HJJ72Sb0 for ; Tue, 15 Jan 2013 15:03:51 -0600 (CST) Received: from [10.12.30.154] (unknown [4.30.77.1]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id A829214BEDA3 for ; Tue, 15 Jan 2013 15:03:50 -0600 (CST) From: Eric McMurry Content-Type: multipart/alternative; boundary="Apple-Mail=_07BEB45F-027A-4099-A18B-7289A1B7349F" Message-Id: <409D34FB-17DE-41CF-85D4-637CC9A3D9A5@computer.org> Date: Tue, 15 Jan 2013 15:03:47 -0600 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [Dime] overload control requirements update 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 Jan 2013 21:03:54 -0000 --Apple-Mail=_07BEB45F-027A-4099-A18B-7289A1B7349F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There is a new version of the overload control requirements that = addresses all of the list comments that I am aware of: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-03 Eric= --Apple-Mail=_07BEB45F-027A-4099-A18B-7289A1B7349F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii There = is a new version of the overload control requirements that addresses all = of the list comments that I am aware = of:


The IETF datatracker status page for this draft = is:

There's also a htmlized = version available at:

A diff from the previous = version is available at:
 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: dime-chairs@ietf.org Subject: [Dime] WGLC for draft-ietf-dime-overload-reqs-03 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, 22 Jan 2013 12:29:59 -0000 Folks, The authors of draft-ietf-dime-overload-reqs have requested for a WGLC and I think the document is stable enough for it. This email starts a two week WGLC for draft-ietf-dime-overload-reqs-03. The WGLC ends Tuesday 5th February 2013. Post your comments to the mailing list and if you think something needs to be changed, put that also into the Issue Tracker. - Jouni & Lionel From bclaise@cisco.com Tue Jan 22 06:21:18 2013 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 AA63521F8807; Tue, 22 Jan 2013 06:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Efon6UZsBFKp; Tue, 22 Jan 2013 06:21:18 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A68DA21F87FB; Tue, 22 Jan 2013 06:21:17 -0800 (PST) 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 r0MELF3t002815; Tue, 22 Jan 2013 15:21:15 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0MEKFel013712; Tue, 22 Jan 2013 15:20:25 +0100 (CET) Message-ID: <50FEA01E.4030809@cisco.com> Date: Tue, 22 Jan 2013 15:20:14 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: draft-ietf-dime-erp@tools.ietf.org References: <50FC23D1.2080400@dial.pipex.com> In-Reply-To: <50FC23D1.2080400@dial.pipex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: General Area Review Team , dime mailing list , draft-ietf-dime-erp.all@tools.ietf.org Subject: Re: [Dime] Telechat review of draft-ietf-dime-erp-16.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, 22 Jan 2013 14:21:18 -0000 draft-ietf-dime-erp authors, Please address this feedback, ideally before the IESG telechat this Thursday. Regards, Benoit > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: I am the assigned Gen-ART reviewer for this draft. For > background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: I am the assigned Gen-ART reviewer for this draft. For > background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-dime-erp-16.txt > Reviewer: Elwyn Davies > Review Date: 20 Jan 2013 > IETF LC End Date: > IESG Telechat date: 24 jan 2013 > > Summary: Not ready assuming I have correctly identified that the > requirements specified in RFC 5295 below are not met by this usage of > the DSRK. Generally the use of the term 'domain' in this draft is > rather cavalier, as it fails to explicitly tie it back to the > restricted meaning of RFC 5295 and does not clarify how nodes find out > what domain name they should be using. > > Major issues: > s5, para 1: > Para 1 states: > > To > achieve this, it must learn the domain name of the ER server. How > this information is acquired is outside the scope of this > specification, but the authenticator might be configured to advertize > this domain name, especially in the case of re-authentication after a > handover. > > It appears that declaring learning the domain name out of scope for > this specification is in conflict with RFC 5295, para 4 (top of page 12): > Usages that make use of the DSRK must define how the peer learns the > domain label to use in a particular derivation. > > This matter escaped me on the previous pass, when I just asked whether > there was any suggestions of how the advertisement might be done. > > Minor issues: > s3: In my Last call review of this document (version 12) I queried > the use of the phrase 'the existence of at most one (logical) ER > server entity' in two places in s3. I received an answer from one of > the the authors that suggested that the phrase was self-explanatory. > At the time I did not push back on this and no change has been made. > On re-reading the latest version of the draft and the author's reply, > I (still) feel that it would help to explain: > (1) Why having more than one ER server in a domain is a mistake - > apparently because this will result in EAP 'failing inappropriately' > in some cases which would seem to be a reason to specifically > deprecate having more then one, and explaining just what the > inappropriate consequences would be. > (2) The consequences of having zero ER servers in a domain. The reply > to my comments seem to imply that this would just result in the > 'protocol failing gracefully'. However, reading RFC 6695, para 2 of > s5.1 seems to imply that having zero ER servers in the local (visited) > domain may not be fatal if there is an ER server in the home domain > (see also s4 of this draft). If I have interpreted this correctly, > then there is a distinction between the cases (home vs arbitrary > visited domain) that could usefully be brought out here rather than > leaving the reader to work it out from later reading. > > s3, last sentence of para 1: ''we assume only one ER server that is > *near* the peer involved in ERP": How are we to interpret 'near' here? > Topologically or physically? How would the peer know a server was > 'near' it or nearer than some other server? > > Nits/editorial comments: > s2/s3: I assume that the term 'domain' is intended to be interpreted > as in RFC 5295, i.e. as a shorthand for Key Management Domain. This > needs to be spelt out here. Similarly 'home domain', 'local domain' > and 'visited domain' should be explicitly mentioned as (presumably) > having the same meanings as in RFC 6696. > > From bclaise@cisco.com Tue Jan 22 06:22:36 2013 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 29A8121F8621; Tue, 22 Jan 2013 06:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.58 X-Spam-Level: X-Spam-Status: No, score=-10.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8UN-BpACm39; Tue, 22 Jan 2013 06:22:33 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7E121F8461; Tue, 22 Jan 2013 06:22:33 -0800 (PST) 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 r0MEMC51002986; Tue, 22 Jan 2013 15:22:12 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0MELj22014931; Tue, 22 Jan 2013 15:21:57 +0100 (CET) Message-ID: <50FEA079.7000109@cisco.com> Date: Tue, 22 Jan 2013 15:21:45 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Stephen Farrell References: <20130121172802.13568.6518.idtracker@ietfa.amsl.com> In-Reply-To: <20130121172802.13568.6518.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-dime-erp@tools.ietf.org, dime mailing list , The IESG , dime-chairs@tools.ietf.org Subject: Re: [Dime] Stephen Farrell's Discuss on draft-ietf-dime-erp-16: (with DISCUSS and COMMENT) 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, 22 Jan 2013 14:22:36 -0000 draft-ietf-dime-erp authors, Please address this feedback, ideally before the IESG telechat this Thursday. Regards, Benoit > Stephen Farrell has entered the following ballot position for > draft-ietf-dime-erp-16: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > This might be a no-brainer, but I wanted to check. RFC 6734 > says that messages containing keys MUST be protected either > via some Diameter-specific scheme (an e2e scheme is being > developed, but is not yet done, right?) or else via > mutually-authenticated TLS or IPsec. This draft says that the > security considerations of 6734 apply, which means that the > response messages MUST be protected like that if they contain > keys. So far so good. However, that leaves open the > possibility that the request or error messages defined here > could be sent unprotected, or am I mis-reading things? If not, > then any attack that could be mounted based on a cleartext > request would arguably be new here. Are there such attacks? > I'm not sure. Would it help in any case to re-state the MUST > from 6734 here but to also include the request messages that > (all going well) cause keys to be sent in responses (and error > messages) and say that all that has to use the same e.g. TLS > session or involve the same entities? (If e.g. TLS was only > turned on for responses, then I'd start to be worried about > the kind of problem that caused us to do the TLS > re-negotiation fix, RFC 5746, but I've not tried to figure out > if there's a real new attack yet, maybe the authors thought > that through already?) > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - I think it'd be clearer to say TBD1 everywhere you mean that > rather than sometimes say . Also, are those > angle brackets missing in the 1st para of section 7? > > - Ought there be a space in the name of the TBD4 value in 9.1? > (I guess not since its not in 10.3) > > > > From hannes.tschofenig@gmx.net Thu Jan 24 00:06:27 2013 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 9DDC621F89BA for ; Thu, 24 Jan 2013 00:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.867 X-Spam-Level: X-Spam-Status: No, score=-101.867 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73BKsSUvJUOg for ; Thu, 24 Jan 2013 00:06:27 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E08D421F8476 for ; Thu, 24 Jan 2013 00:06:26 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M68YO-1Uw25j3dHu-00y7Lz for ; Thu, 24 Jan 2013 09:06:25 +0100 Received: (qmail invoked by alias); 24 Jan 2013 08:06:25 -0000 Received: from unknown (EHLO [10.255.135.110]) [194.251.119.201] by mail.gmx.net (mp032) with SMTP; 24 Jan 2013 09:06:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+aK7I+FGaaF7SiT4EFXaT9BnNpMF9gPA648hTbrx HcyXqVPdB03imY From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Jan 2013 10:06:23 +0200 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 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, 24 Jan 2013 08:06:27 -0000 Hi all,=20 I have a remark regarding requirement 2: " REQ 2: The mechanism MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. " While this sounds completely right there is also a question about what do to in case of overload. The current requirements document focuses largely on the task of conveying overload information to other Diameter nodes and does not really say what should happen in case of overload. One can imagine that load is moved from one server to the other one but that only works in a limited extend. So, what happens if there is a real overload situation?=20 In this case the AAA client needs to start take some actions that are application specific. For example, for certain Diameter applications it may be OK to suppress certain messages and thereby to gracefully reduce functionality or to reject some requests from certain end hosts altogether. What the right action is heavily depends on the specific Diameter application. In that case the specification of the Diameter application needs to be extended with information about what to do in overload situations. This is of course in contradiction with the requirement above but certainly appears useful to think about what to do in those cases. Just dropping Diameter messages by a Diameter intermediary is not particularly useful since this may lead to timeouts and retransmissions (depending on what is specified in a given Diameter application). In order for a Diameter node to do something useful in situations of overload it may need to have some additional information about what the problem is. This may get fairly complicated pretty quickly. Even for a simple load balancing scenario, for example, it does not make sense to forward requests to a new server when a shared backend database is not reachable.=20 So, I am wondering where to draw the line here. The requirements document stops fairly early and is silent about this issue. The solution = documents on the other hand tend to look more sophisticated already and contain functionality that is not mentioned at all in the requirements draft. As an example, take a look at the concept of "scopes" in http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01. A scope is essentially a way to provision the Diameter routing table of a different Diameter node. Ciao Hannes= From jgunn6@csc.com Thu Jan 24 05:15:33 2013 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 40BFF21F8A03; Thu, 24 Jan 2013 05:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEpo-jbuRrmX; Thu, 24 Jan 2013 05:15:32 -0800 (PST) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id F2D3121F8942; Thu, 24 Jan 2013 05:15:31 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-86.messagelabs.com!1359033329!33342590!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31779 invoked from network); 24 Jan 2013 13:15:29 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-7.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Jan 2013 13:15:29 -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 r0ODFSQj025368; Thu, 24 Jan 2013 08:15:29 -0500 In-Reply-To: References: To: Hannes Tschofenig MIME-Version: 1.0 X-KeepSent: CDBCA6AF:130F667F-85257AFD:0048A119; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Thu, 24 Jan 2013 08:15:28 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 01/24/2013 08:10:26 AM, Serialize complete at 01/24/2013 08:10:26 AM Content-Type: multipart/alternative; boundary="=_alternative 0048D3A285257AFD_=" Cc: dime-bounces@ietf.org, dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 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, 24 Jan 2013 13:15:33 -0000 This is a multipart message in MIME format. --=_alternative 0048D3A285257AFD_= Content-Type: text/plain; charset="US-ASCII" I would have thought that was covered by the concept of "local policy", and would be out of scope for THIS draft. Possibly the topic for a different draft or drafts? I agree it needs to be addressed. Janet dime-bounces@ietf.org wrote on 01/24/2013 03:06:23 AM: > From: Hannes Tschofenig > To: dime@ietf.org > Date: 01/24/2013 03:07 AM > Subject: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > Sent by: dime-bounces@ietf.org > > Hi all, > > I have a remark regarding requirement 2: > " > REQ 2: The mechanism MUST allow Diameter nodes to support overload > control regardless of which Diameter applications they > support. > " > > While this sounds completely right there is also a question about what > do to in case of overload. The current requirements document focuses > largely on the task of conveying overload information to other Diameter > nodes and does not really say what should happen in case of overload. > One can imagine that load is moved from one server to the other one but > that only works in a limited extend. So, what happens if there is a real > overload situation? > > In this case the AAA client needs to start take some actions that > are application specific. For example, for certain Diameter applications > it may be OK to suppress certain messages and thereby to gracefully > reduce functionality or to reject some requests from certain end hosts > altogether. What the right action is heavily depends on the specific > Diameter application. In that case the specification of the Diameter > application needs to be extended with information about what to do in > overload situations. This is of course in contradiction with the > requirement above but certainly appears useful to think about what to do > in those cases. Just dropping Diameter messages by a Diameter > intermediary is not particularly useful since this may lead to timeouts > and retransmissions (depending on what is specified in a given Diameter > application). > > In order for a Diameter node to do something useful in situations of > overload it may need to have some additional information about what the > problem is. This may get fairly complicated pretty quickly. Even for a > simple load balancing scenario, for example, it does not make sense to > forward requests to a new server when a shared backend database is not > reachable. > > So, I am wondering where to draw the line here. The requirements > document stops fairly early and is silent about this issue. The > solution documents on > the other hand tend to look more sophisticated already and contain > functionality that is not mentioned at all in the requirements draft. As > an example, take a look at the concept of "scopes" in > http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01. A scope is > essentially a way to provision the Diameter routing table of a different > Diameter node. > > Ciao > Hannes > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=_alternative 0048D3A285257AFD_= Content-Type: text/html; charset="US-ASCII"
I would have thought that was covered by the concept of "local policy", and would be out of scope for THIS draft.  Possibly the topic for a different draft or drafts?  I agree it needs to be addressed.

Janet

dime-bounces@ietf.org wrote on 01/24/2013 03:06:23 AM:

> From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
> To: dime@ietf.org
> Date: 01/24/2013 03:07 AM
> Subject: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
> Sent by: dime-bounces@ietf.org
>
> Hi all,
>
> I have a remark regarding requirement 2:
> "
>  REQ 2:   The mechanism MUST allow Diameter nodes to support overload
>           control regardless of which Diameter applications they
>           support.
> "
>
> While this sounds completely right there is also a question about what
> do to in case of overload. The current requirements document focuses
> largely on the task of conveying overload information to other Diameter
> nodes and does not really say what should happen in case of overload.
> One can imagine that load is moved from one server to the other one but
> that only works in a limited extend. So, what happens if there is a real
> overload situation?
>
> In this case the AAA client needs to start take some actions that
> are application specific. For example, for certain Diameter applications
> it may be OK to suppress certain messages and thereby to gracefully
> reduce functionality or to reject some requests from certain end hosts
> altogether. What the right action is heavily depends on the specific
> Diameter application. In that case the specification of the Diameter
> application needs to be extended with information about what to do in
> overload situations. This is of course in contradiction with the
> requirement above but certainly appears useful to think about what to do
> in those cases. Just dropping Diameter messages by a Diameter
> intermediary is not particularly useful since this may lead to timeouts
> and retransmissions (depending on what is specified in a given Diameter
> application).
>
> In order for a Diameter node to do something useful in situations of
> overload it may need to have some additional information about what the
> problem is. This may get fairly complicated pretty quickly. Even for a
> simple load balancing scenario, for example, it does not make sense to
> forward requests to a new server when a shared backend database is not
> reachable.
>
> So, I am wondering where to draw the line here. The requirements
> document stops fairly early and is silent about this issue. The
> solution documents on
> the other hand tend to look more sophisticated already and contain
> functionality that is not mentioned at all in the requirements draft. As
> an example, take a look at the concept of "scopes" in
> http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01. A scope is
> essentially a way to provision the Diameter routing table of a different
> Diameter node.
>
> Ciao
> Hannes
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
 --=_alternative 0048D3A285257AFD_=-- From laurent.thiebaut@alcatel-lucent.com Thu Jan 24 07:28:26 2013 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 0BC9E21F8994 for ; Thu, 24 Jan 2013 07:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.021 X-Spam-Level: X-Spam-Status: No, score=-10.021 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KtG+Z5mairG for ; Thu, 24 Jan 2013 07:28:22 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB5921F84D9 for ; Thu, 24 Jan 2013 07:28:21 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0OFHexm014178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jan 2013 16:28:15 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 24 Jan 2013 16:27:20 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.182]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 24 Jan 2013 16:27:20 +0100 From: "THIEBAUT, LAURENT (LAURENT)" To: "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm5iW2a6KR6eE2maF55SBpv15hYiT/w Date: Thu, 24 Jan 2013 15:27:20 +0000 Message-ID: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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: [135.239.27.11] Content-Type: multipart/alternative; boundary="_000_669B2D5ED96A8E4E9FD34C91DFD815B00100DCFR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 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, 24 Jan 2013 15:28:26 -0000 --_000_669B2D5ED96A8E4E9FD34C91DFD815B00100DCFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all Please find below our remarks on draft draft-ietf-dime-overload-reqs-03 abo= ut Diameter Overload Control Requirements These remarks address topics we have already addressed over Dime but for wh= ich we think some enhancements to the text is needed. We hope to converge quickly as we believe that based on these small enhance= ments draft-ietf-dime-overload-reqs-03 should be finalized ASAP and moved f= orward into the IETF standardization process. 1. REQ 2: The mechanism MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. The mechanism MUST allow Diameter applications to be aware of an overload situation. We believe that a proper handling of a Diameter server overload is to repor= t it at the level of its Diameter client applications in order for them to = take proper decisions. This may mean to send signalling towards non Diamete= r entities. This may relate with the comment made by Hannes. 2. We recommend to add following requirement: REQ xx: The overload control mechanism MUST allow networks to properly sup= port Diameter signalling related with emergency and/or priority users. This aspect is mentioned in Req 26 but only as a general guidance while thi= s is a strong operational requirement. "For example, it may be more beneficial to process messages for existing sessions ahead of new sessions, or to give priority to requests associated with emergency sessions or with high priority users." 3. REQ 35: The mechanism SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the mechanism. We recommend to replace "The mechanism SHOULD provide a method" by "The mec= hanism MUST provide a method" as it is a key requirement for deployments e= specially via intermediate networks. 4. We recommend to add following requirement REQ yy: The mechanism MUST support a default overload algorithm. This will= facilitate interoperability especially between Networks. 5. REQ 33: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The mechanism MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without forcing available capacity to go unused. The mechanism MUST support specification of overload information with granularities of at least "Diameter node", "realm", "Diameter application", and "Diameter session", and SHOULD allow extensibility for others to be added in the future. a. We recommend to replace "SHOULD allow extensibility" by "MUST allo= w extensibility" . b. We are not sure that the granularity at Diameter session is really= required and suggest to remove it from this Req 33. Best Regards Laurent ALCATEL-LUCENT -----Message d'origine----- De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Han= nes Tschofenig Envoy=E9 : jeudi 24 janvier 2013 09:06 =C0 : dime@ietf.org Objet : [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi all, I have a remark regarding requirement 2: " REQ 2: The mechanism MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. " While this sounds completely right there is also a question about what do to in case of overload. The current requirements document focuses largely on the task of conveying overload information to other Diameter nodes and does not really say what should happen in case of overload. One can imagine that load is moved from one server to the other one but that only works in a limited extend. So, what happens if there is a real overload situation? In this case the AAA client needs to start take some actions that are application specific. For example, for certain Diameter applications it may be OK to suppress certain messages and thereby to gracefully reduce functionality or to reject some requests from certain end hosts altogether. What the right action is heavily depends on the specific Diameter application. In that case the specification of the Diameter application needs to be extended with information about what to do in overload situations. This is of course in contradiction with the requirement above but certainly appears useful to think about what to do in those cases. Just dropping Diameter messages by a Diameter intermediary is not particularly useful since this may lead to timeouts and retransmissions (depending on what is specified in a given Diameter application). In order for a Diameter node to do something useful in situations of overload it may need to have some additional information about what the problem is. This may get fairly complicated pretty quickly. Even for a simple load balancing scenario, for example, it does not make sense to forward requests to a new server when a shared backend database is not reachable. So, I am wondering where to draw the line here. The requirements document stops fairly early and is silent about this issue. The solution do= cuments on the other hand tend to look more sophisticated already and contain functionality that is not mentioned at all in the requirements draft. As an example, take a look at the concept of "scopes" in http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01. A scope is essentially a way to provision the Diameter routing table of a different Diameter node. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_669B2D5ED96A8E4E9FD34C91DFD815B00100DCFR712WXCHMBA11zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

Hello all

Please find below our remarks on draft draft-ietf-dime-o= verload-reqs-03 about Diameter Overload Control Requirements

 

These remarks address topics we have already addressed o= ver Dime but for which we think some enhancements to the text is needed.

We hope to converge quickly as we believe that based on = these small enhancements draft-ietf-dime-overload-reqs-03 should be finalized ASAP and moved forwar= d into the IETF standardization process.

 

1.    REQ 2:&nb= sp;  The mechanism MUST allow Diameter nodes to support overload

            con= trol regardless of which Diameter applications they

            sup= port. The mechanism MUST allow Diameter applica= tions

to be aware of an overload situation.

We believe that a proper handling of a Diameter server o= verload is to report it at the level of its Diameter client applications in order for them to take= proper decisions. This may mean to send signalling towards non Diameter en= tities.

This may relate with the comment made by Hannes.

 

 

 

2.       We recommend to add following requirement:

REQ xx:  The overload control mechanism MUST allow netw= orks to properly support Diameter signalling related with emergency and/or = priority users.

This aspect is mentioned in Req 26 but only as a general guidance whil= e this is a strong operational requirement.

“For example, it may be more beneficial to process mes= sages for

            exi= sting sessions ahead of new sessions, or to give priority

            to = requests associated with emergency sessions or with high

            priority users.”

 

 

 

 

3.    REQ 35:&n= bsp; The mechanism SHOULD provide a method for exchan= ging

            ove= rload and load information between elements that are

            con= nected by intermediaries that do not support the

            mec= hanism.

We recommend to replace “The mechanism SHOULD provide a method” by “The mechanism MUST provide a method”  as it is a key r= equirement for deployments especially via intermediate networks.

 

 

 

 

 

4.       We recommend to add following requirement

REQ yy:  The mechanism MUST support a default overload = algorithm. This will facilitate interoperability especially between Network= s.<= /span>

 

 

 

 

5.    REQ 33:&n= bsp; There are multiple situations where a Diameter node may be

            ove= rloaded for some purposes but not others.  For example,<= font size=3D"2" face=3D"Courier New">

            thi= s can happen to an agent or server that supports multiple

            app= lications, or when a server depends on multiple external

            res= ources, some of which may become overloaded while others

            are= fully available.  The mechanism MUST allow Diameter

            nod= es to indicate overload with sufficient granularity to

            all= ow clients to take action based on the overloaded

            res= ources without forcing available capacity to go unused.

            The= mechanism MUST support specification of overload

            inf= ormation with granularities of at least "Diameter node",

            &qu= ot;realm", "Diameter application", and "Diameter session", and

            SHOULD allow extensibility for oth= ers to be added in the<= span lang=3D"EN-GB" style=3D"font-size:10.0pt;font-family:"Courier New= "">

            fut= ure.

a.       We recommend to replace “SHOULD allow extensibility= ” by “MUST all= ow extensibility&= #8221; .

b.       We are not sure that the granularity at Diameter session is really required and su= ggest to remove it from this Req 33.

 

 

Best Regards

Laurent
ALCATEL-LUCENT

 

 

-----Message d'origine-----
De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part d= e Hannes Tschofenig
Envoy=E9 : jeudi 24 janvier 2013 09:06
=C0 : dime@ietf.org
Objet : [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

 

Hi all,

 

I have a remark regarding requirement= 2:

"

 REQ 2:   The mechanis= m MUST allow Diameter nodes to support overload

      &= nbsp;   control regardless of which Diameter applications they

      &= nbsp;   support.

"

 

While this sounds completely right th= ere is also a question about what

do to in case of overload. The curren= t requirements document focuses

largely on the task of conveying over= load information to other Diameter

nodes and does not really say what sh= ould happen in case of overload.

One can imagine that load is moved fr= om one server to the other one but

that only works in a limited extend. = So, what happens if there is a real

overload situation?

 

In this case the AAA client needs to = start take some actions that

are application specific. For example= , for certain Diameter applications

it may be OK to suppress certain mess= ages and thereby to gracefully

reduce functionality or to reject som= e requests from certain end hosts

altogether. What the right action is = heavily depends on the specific

Diameter application. In that case th= e specification of the Diameter

application needs to be extended with= information about what to do in

overload situations. This is of cours= e in contradiction with the

requirement above but certainly appea= rs useful to think about what to do

in those cases. Just dropping Diamete= r messages by a Diameter

intermediary is not particularly usef= ul since this may lead to timeouts

and retransmissions (depending on wha= t is specified in a given Diameter

application).

 

In order for a Diameter node to do so= mething useful in situations of

overload it may need to have some add= itional information about what the

problem is. This may get fairly compl= icated pretty quickly. Even for a

simple load balancing scenario, for e= xample, it does not make sense to

forward requests to a new server when= a shared backend database is not

reachable.

 

So, I am wondering where to draw the = line here. The requirements

document stops fairly early and is si= lent about this issue. The solution documents on

the other hand tend to look more soph= isticated already and contain

functionality that is not mentioned a= t all in the requirements draft. As

an example, take a look at the concep= t of "scopes" in

http://tools.ietf.org/html/draft-roac= h-dime-overload-ctrl-01. A scope is

essentially a way to provision the Di= ameter routing table of a different

Diameter node.

 

Ciao

Hannes

_____________________________________= __________

DiME mailing list

DiME@ietf.org

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

--_000_669B2D5ED96A8E4E9FD34C91DFD815B00100DCFR712WXCHMBA11zeu_-- From emcmurry@computer.org Thu Jan 24 10:50:39 2013 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 8F6E821F8706 for ; Thu, 24 Jan 2013 10:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwg8t7T4ddLe for ; Thu, 24 Jan 2013 10:50:39 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id E620921F86BA for ; Thu, 24 Jan 2013 10:50:38 -0800 (PST) Received: from [166.137.112.209] (helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TyRsj-000OhQ-UZ; Thu, 24 Jan 2013 18:50:38 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 14215178F576; Thu, 24 Jan 2013 12:50:36 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 166.137.112.209 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+QieyZHq6FE7WMbXbTNLMB23pzwc1Gw6g= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AIwjnxHD_8t; Thu, 24 Jan 2013 12:50:34 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 27D41178F565; Thu, 24 Jan 2013 12:50:32 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: Date: Thu, 24 Jan 2013 12:50:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1A8AF4FA-AB93-42A5-9D42-85554AC2AD55@computer.org> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 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, 24 Jan 2013 18:50:39 -0000 Hi Hannes, These are good observations. I think the answer to your first point = about there being application specific behavior required to deal is = overload is exactly right. As Janet pointed out, what this behavior = should be is up to the specific application and local policies. The = goal of this was just to provide a mechanism for exchanging information. You are also correct about the need to be able to share information with = more granularity to minimize the impacts of overload and overload = mitigation. You are also right that it can get complicated quickly :-). This was a consideration for the requirements and is called out (and = this resulted in what you saw in draft-roach-dime-overload-ctrl). The = shared back-end case you mentioned was one of many that were considered = when looking at scoping for that mechanism draft. For the requirements, = the use of scopes for specifying granularity of overload information was = required in Req 33. There is still a bit of debate over which scopes = should be mandatory though. Thanks, Eric On Jan 24, 2013, at 2:06 , Hannes Tschofenig = wrote: > Hi all,=20 >=20 > I have a remark regarding requirement 2: > " > REQ 2: The mechanism MUST allow Diameter nodes to support overload > control regardless of which Diameter applications they > support. > " >=20 > While this sounds completely right there is also a question about what > do to in case of overload. The current requirements document focuses > largely on the task of conveying overload information to other = Diameter > nodes and does not really say what should happen in case of overload. > One can imagine that load is moved from one server to the other one = but > that only works in a limited extend. So, what happens if there is a = real > overload situation?=20 >=20 > In this case the AAA client needs to start take some actions that > are application specific. For example, for certain Diameter = applications > it may be OK to suppress certain messages and thereby to gracefully > reduce functionality or to reject some requests from certain end hosts > altogether. What the right action is heavily depends on the specific > Diameter application. In that case the specification of the Diameter > application needs to be extended with information about what to do in > overload situations. This is of course in contradiction with the > requirement above but certainly appears useful to think about what to = do > in those cases. Just dropping Diameter messages by a Diameter > intermediary is not particularly useful since this may lead to = timeouts > and retransmissions (depending on what is specified in a given = Diameter > application). >=20 > In order for a Diameter node to do something useful in situations of > overload it may need to have some additional information about what = the > problem is. This may get fairly complicated pretty quickly. Even for a > simple load balancing scenario, for example, it does not make sense to > forward requests to a new server when a shared backend database is not > reachable.=20 >=20 > So, I am wondering where to draw the line here. The requirements > document stops fairly early and is silent about this issue. The = solution documents on > the other hand tend to look more sophisticated already and contain > functionality that is not mentioned at all in the requirements draft. = As > an example, take a look at the concept of "scopes" in > http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01. A scope = is > essentially a way to provision the Diameter routing table of a = different > Diameter node. >=20 > Ciao > Hannes > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From emcmurry@computer.org Thu Jan 24 11:04:46 2013 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 3BAF321F84F3 for ; Thu, 24 Jan 2013 11:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xmPAEE2voPG for ; Thu, 24 Jan 2013 11:04:45 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 919F921F84DE for ; Thu, 24 Jan 2013 11:04:40 -0800 (PST) Received: from [166.137.112.209] (helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TyS6J-000Ihp-If; Thu, 24 Jan 2013 19:04:40 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 725DA17901E8; Thu, 24 Jan 2013 13:04:37 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 166.137.112.209 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19HxfLDqCxo27jw2kmLbWnIeGlGWTfXocE= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJtY-bQc7DXm; Thu, 24 Jan 2013 13:04:37 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 4548B17901D4; Thu, 24 Jan 2013 13:04:37 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5CD368F1-118B-4636-A0D8-83E97203F26D" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 24 Jan 2013 13:04:36 -0600 Message-Id: <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "THIEBAUT, LAURENT (LAURENT)" X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 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, 24 Jan 2013 19:04:46 -0000 --Apple-Mail=_5CD368F1-118B-4636-A0D8-83E97203F26D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Laurent. comments inline. Eric On Jan 24, 2013, at 9:27 , "THIEBAUT, LAURENT (LAURENT)" = wrote: > =20 > =20 > Hello all > Please find below our remarks on draft = draft-ietf-dime-overload-reqs-03 about Diameter Overload Control = Requirements > =20 > These remarks address topics we have already addressed over Dime but = for which we think some enhancements to the text is needed. > We hope to converge quickly as we believe that based on these small = enhancements draft-ietf-dime-overload-reqs-03 should be finalized ASAP = and moved forward into the IETF standardization process. > =20 > 1. REQ 2: The mechanism MUST allow Diameter nodes to support = overload > control regardless of which Diameter applications they > support. The mechanism MUST allow Diameter applications > to be aware of an overload situation. > We believe that a proper handling of a Diameter server overload is to = report it at the level of its Diameter client applications in order for = them to take proper decisions. This may mean to send signalling towards = non Diameter entities. > This may relate with the comment made by Hannes. > =20 As in the current draft, do you think this requirement can be = interpreted to say that a diameter stack should handle overload without = application intervention and that implementations of overload control = mechanisms are required to act in that fashion? I'm struggling a bit with this since I'm reading it as a requirement on = implementations of the overload control mechanism (as opposed to = requirements on the specification of the mechanism). Is it reasonable = to require a stack to not handle overload control by itself? > =20 > =20 > 2. We recommend to add following requirement: > REQ xx: The overload control mechanism MUST allow networks to = properly support Diameter signalling related with emergency and/or = priority users. > This aspect is mentioned in Req 26 but only as a general guidance = while this is a strong operational requirement. > =93For example, it may be more beneficial to process messages for > existing sessions ahead of new sessions, or to give = priority > to requests associated with emergency sessions or with = high > priority users.=94 > =20 > =20 > =20 What does this mean for a mechanism? How would it be done? > =20 > 3. REQ 35: The mechanism SHOULD provide a method for exchanging > overload and load information between elements that are > connected by intermediaries that do not support the > mechanism. > We recommend to replace =93The mechanism SHOULD provide a method=94 by = =93The mechanism MUSTprovide a method=94 as it is a key requirement for = deployments especially via intermediate networks. > =20 > =20 Personally, I'm on the fence here. The main issue I have is that any = end to end, or end to information source method that passes through = intermediaries that don't support the mechanism brings with it an = absolute requirement for end to end security. Given the state of end to = end security, this will cause substantial delay to deployment of = overload control. There is a middle ground where a mechanism that could = support end to end is required to only be used hop by hop without end to = end security in place. That may be compatible with the suggested change = to the requirement but it will have to be considered. There is also the consideration that a mechanism that requires = hop-by-hop action for overload control could be a reasonable or = necessary approach, given the potential complexity of the networks = involved and the implications of that on what the overload information = contains. At any rate, if the change is made, we must also add the additional = security requirement ensuring that the mechanism is not used without end = to end security (this is implied by REQ 28, but it needs to be made = explicit). > =20 > =20 > =20 > 4. We recommend to add following requirement > REQ yy: The mechanism MUST support a default overload algorithm. This = will facilitate interoperability especially between Networks. > =20 I think this would make explicit what is implicit now. I don't see any = issue with adding it. Others should certainly feel free to contradict = me on that. > =20 > =20 > =20 > 5. REQ 33: There are multiple situations where a Diameter node may = be > overloaded for some purposes but not others. For example, > this can happen to an agent or server that supports = multiple > applications, or when a server depends on multiple = external > resources, some of which may become overloaded while = others > are fully available. The mechanism MUST allow Diameter > nodes to indicate overload with sufficient granularity to > allow clients to take action based on the overloaded > resources without forcing available capacity to go unused. > The mechanism MUST support specification of overload > information with granularities of at least "Diameter = node", > "realm", "Diameter application", and "Diameter session", = and > SHOULD allow extensibility for others to be added in the > future. > a. We recommend to replace =93SHOULD allow extensibility=94 by = =93MUST allow extensibility=94 . sounds okay to me. > b. We are not sure that the granularity at Diameter session is = really required and suggest to remove it from this Req 33. Keep in mind that the requirements are on the specification of the = mechanism and not on implementations, so it is reasonable for the = specification to include the definition of a scope that is not required = to implement. That said, I don't have any real issue with this. --Apple-Mail=_5CD368F1-118B-4636-A0D8-83E97203F26D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 laurent.thiebaut@ALCAT= EL-LUCENT.COM> wrote:

Hello = all
Please = find below our remarks on draft draft-ietf-dime-overload-reqs-03 about = Diameter Overload Control = Requirements
These remarks address topics = we have already addressed over Dime but for which we think some = enhancements to the text is needed.
We hope to converge quickly as we believe that based on these = small enhancements draft-ietf-dime-overload-reqs-03 should be finalized = ASAP and moved forward into the IETF standardization = process.
1.    <= /font>REQ 2:   The mechanism MUST allow = Diameter nodes to support overload

 The mechanism MUST allow Diameter = applicationsto be aware of an = overload situation.We believe that a proper = handling of a Diameter server overload is to report it at the level of = its Diameter client applications in order for them to take proper = decisions. This may mean to send signalling towards non Diameter = entities.
This may = relate with the comment made by = Hannes.

= As in the current draft, do you think this requirement can be = interpreted to say that a diameter stack should handle overload without = application intervention and that implementations of overload control = mechanisms are required to act in that = fashion?

I'm struggling a bit with this since = I'm reading it as a requirement on implementations of the overload = control mechanism (as opposed to requirements on the specification of = the mechanism).  Is it reasonable to require a stack to not handle = overload control by itself?

 
2. <= /font>We = recommend to add following requirement:

REQ xx:  The overload control = mechanism MUST allow networks to properly support Diameter signalling = related with emergency and/or priority users.

This aspect is mentioned in = Req 26 but only as a general guidance while this is a strong operational = requirement.

=93For example, = it may be more beneficial to process messages for

 priority = users.=94
 
3.    <= /font>REQ 35:  The mechanism SHOULD provide a method for = exchanging
We recommend to replace = =93The mechanism SHOULD provide a = method=94 by =93The mechanism MUSTprovide a = method=94  as it is a key requirement for deployments especially = via intermediate networks.
 
 

<= div>Personally, I'm on the fence here.  The main issue I have is = that any end to end, or end to information source method that passes = through intermediaries that don't support the mechanism brings with it = an absolute requirement for end to end security.  Given the state = of end to end security, this will cause substantial delay to deployment = of overload control.  There is a middle ground where a mechanism = that could support end to end is required to only be used hop by hop = without end to end security in place.  That may be compatible with = the suggested change to the requirement but it will have to be = considered.

There is also the consideration = that a mechanism that requires hop-by-hop action for overload control = could be a reasonable or necessary approach, given the potential = complexity of the networks involved and the implications of that on what = the overload information contains.

At any rate, = if the change is made, we must also add the additional security = requirement ensuring that the mechanism is not used without end to end = security (this is implied by REQ 28, but it needs to be made = explicit).

 
 

4.       <= /font>We = recommend to add following requirement

REQ yy:  The mechanism MUST support a = default overload algorithm. This will facilitate interoperability = especially between Networks.


= I think this would make explicit what is implicit now.  I don't see = any issue with adding it.  Others should certainly feel free to = contradict me on that.

 
 

5. <= /font>REQ 33:  There are multiple situations = where a Diameter node may be

 and "Diameter session", = and SHOULD allow extensibility for = others to be added in the
a. <= /font>We = recommend to replace =93SHOULD allow = extensibility=94 by =93MUST allow = extensibility=94 = .


sounds okay = to me.

b. <= /font>We are = not sure that the granularity at Diameter session is really = required and suggest to remove it from this Req = 33.


Keep = in mind that the requirements are on the specification of the mechanism = and not on implementations, so it is reasonable for the specification to = include the definition of a scope that is not required to implement. =  That said, I don't have any real issue with = this.

= --Apple-Mail=_5CD368F1-118B-4636-A0D8-83E97203F26D-- From ben@nostrum.com Mon Jan 28 13:00:11 2013 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 8C43121F853E for ; Mon, 28 Jan 2013 13:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKiQUJQrLai3 for ; Mon, 28 Jan 2013 13:00:10 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD2821F850F for ; Mon, 28 Jan 2013 13:00:09 -0800 (PST) Received: from [172.20.10.2] (mobile-166-137-113-101.mycingular.net [166.137.113.101] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0SKxxJt065761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 15:00:00 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <1A8AF4FA-AB93-42A5-9D42-85554AC2AD55@computer.org> Date: Mon, 28 Jan 2013 14:59:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A8AF4FA-AB93-42A5-9D42-85554AC2AD55@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 166.137.113.101 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 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, 28 Jan 2013 21:00:11 -0000 On Jan 24, 2013, at 12:50 PM, Eric McMurry = wrote: > Hi Hannes, >=20 > These are good observations. I think the answer to your first point = about there being application specific behavior required to deal is = overload is exactly right. As Janet pointed out, what this behavior = should be is up to the specific application and local policies. The = goal of this was just to provide a mechanism for exchanging information. Hmm--I think it was a bit more than just communication. We've got some = requirements [7 and 34] and discussion [section 6] that imply that the = mechanism may or should have some default algorithm. I take that to mean = actual behavior, not just communication. We should probably have an = explicit requirement for that, one way or another. >=20 > You are also correct about the need to be able to share information = with more granularity to minimize the impacts of overload and overload = mitigation. You are also right that it can get complicated quickly :-). >=20 > This was a consideration for the requirements and is called out (and = this resulted in what you saw in draft-roach-dime-overload-ctrl). The = shared back-end case you mentioned was one of many that were considered = when looking at scoping for that mechanism draft. For the requirements, = the use of scopes for specifying granularity of overload information was = required in Req 33. There is still a bit of debate over which scopes = should be mandatory though. >=20 > Thanks, >=20 > Eric >=20 >=20 > On Jan 24, 2013, at 2:06 , Hannes Tschofenig = wrote: >=20 >> Hi all,=20 >>=20 >> I have a remark regarding requirement 2: >> " >> REQ 2: The mechanism MUST allow Diameter nodes to support overload >> control regardless of which Diameter applications they >> support. >> " >>=20 >> While this sounds completely right there is also a question about = what >> do to in case of overload. The current requirements document focuses >> largely on the task of conveying overload information to other = Diameter >> nodes and does not really say what should happen in case of overload. >> One can imagine that load is moved from one server to the other one = but >> that only works in a limited extend. So, what happens if there is a = real >> overload situation?=20 >>=20 >> In this case the AAA client needs to start take some actions that >> are application specific. For example, for certain Diameter = applications >> it may be OK to suppress certain messages and thereby to gracefully >> reduce functionality or to reject some requests from certain end = hosts >> altogether. What the right action is heavily depends on the specific >> Diameter application. In that case the specification of the Diameter >> application needs to be extended with information about what to do in >> overload situations. This is of course in contradiction with the >> requirement above but certainly appears useful to think about what to = do >> in those cases. Just dropping Diameter messages by a Diameter >> intermediary is not particularly useful since this may lead to = timeouts >> and retransmissions (depending on what is specified in a given = Diameter >> application). >>=20 >> In order for a Diameter node to do something useful in situations of >> overload it may need to have some additional information about what = the >> problem is. This may get fairly complicated pretty quickly. Even for = a >> simple load balancing scenario, for example, it does not make sense = to >> forward requests to a new server when a shared backend database is = not >> reachable.=20 >>=20 >> So, I am wondering where to draw the line here. The requirements >> document stops fairly early and is silent about this issue. The = solution documents on >> the other hand tend to look more sophisticated already and contain >> functionality that is not mentioned at all in the requirements draft. = As >> an example, take a look at the concept of "scopes" in >> http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01. A scope = is >> essentially a way to provision the Diameter routing table of a = different >> Diameter node. >>=20 >> Ciao >> Hannes >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Mon Jan 28 14:54:47 2013 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 31BFF21E8030 for ; Mon, 28 Jan 2013 14:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kQdToFOqEwB for ; Mon, 28 Jan 2013 14:54:46 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8EE21E8039 for ; Mon, 28 Jan 2013 14:54:46 -0800 (PST) Received: from [10.119.74.98] (69.147.243.203.rdns.ubiquityservers.com [69.147.243.203] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0SMsgq0078322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 16:54:43 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Mon, 28 Jan 2013 16:54:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4084F49C-4E18-4662-91C3-A2D8BC2BA252@nostrum.com> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 69.147.243.203 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 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, 28 Jan 2013 22:54:47 -0000 Hi Hannes, some comments inline: On Jan 24, 2013, at 2:06 AM, Hannes Tschofenig = wrote: > Hi all,=20 >=20 > I have a remark regarding requirement 2: > " > REQ 2: The mechanism MUST allow Diameter nodes to support overload > control regardless of which Diameter applications they > support. > " >=20 > While this sounds completely right there is also a question about what > do to in case of overload. The current requirements document focuses > largely on the task of conveying overload information to other = Diameter > nodes and does not really say what should happen in case of overload. > One can imagine that load is moved from one server to the other one = but > that only works in a limited extend. So, what happens if there is a = real > overload situation? I think there's some implication that the overload control mechanism = should specify at least some default behavior (i.e. algorithm) on the = part of the node that consumed the overload information. I'm pretty sure = both of the mechanism drafts that have been submitted define one or more = such mechanism. As I mentioned separately, we might should consider an = explicit requirement one way or another about that. (We have a = requirement that such an algorithm be extensible, but I'm not sure we = have an expressed requirement that it _exist_ :-) >=20 >=20 > In this case the AAA client needs to start take some actions that > are application specific. For example, for certain Diameter = applications > it may be OK to suppress certain messages and thereby to gracefully > reduce functionality or to reject some requests from certain end hosts > altogether. What the right action is heavily depends on the specific > Diameter application. In that case the specification of the Diameter > application needs to be extended with information about what to do in > overload situations. This is of course in contradiction with the > requirement above but certainly appears useful to think about what to = do > in those cases. Just dropping Diameter messages by a Diameter > intermediary is not particularly useful since this may lead to = timeouts > and retransmissions (depending on what is specified in a given = Diameter > application). We tried to draw a bright line between Diameter and whatever client = application protocol depends on it in section one, with behavior in the = client application beyond the scope of the work. It probably would make = sense for any overload control mechanism draft to elaborate on that to = some degree--but I think the best we can do is to say that if a client = is forced to drop Diameter requests, it has to also do the right thing = in the client protocol (for example, deny network attach request). I = agree that part is application specific. One would hope that any given = application specification says something about what a client does when = it can't complete a given Diameter application. =20 >=20 > In order for a Diameter node to do something useful in situations of > overload it may need to have some additional information about what = the > problem is. This may get fairly complicated pretty quickly. Even for a > simple load balancing scenario, for example, it does not make sense to > forward requests to a new server when a shared backend database is not > reachable.=20 As Eric mentioned, that's one of the intents behind the "scope" concept. = Maybe we could be more explicit about the possibility of a single = overloaded scope impacting more than one client-selectable destination. = (or at least require the mechanism to offer guidance). >=20 > So, I am wondering where to draw the line here. The requirements > document stops fairly early and is silent about this issue. The = solution documents on > the other hand tend to look more sophisticated already and contain > functionality that is not mentioned at all in the requirements draft. = As > an example, take a look at the concept of "scopes" in > http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01. A scope = is > essentially a way to provision the Diameter routing table of a = different > Diameter node. The scope concept in that draft was derived from Req 33. (or maybe = "provoked by" would be a better choice of words :-) ) >=20 > Ciao > Hannes > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Wed Jan 30 15:48:59 2013 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 B0D9C21F86FC for ; Wed, 30 Jan 2013 15:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3AWVs7Gc5yB for ; Wed, 30 Jan 2013 15:48:59 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AFEEA21F86B1 for ; Wed, 30 Jan 2013 15:48:58 -0800 (PST) Received: from [172.20.10.2] (mobile-166-137-113-001.mycingular.net [166.137.113.1] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0UNmikJ005485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jan 2013 17:48:45 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> Date: Wed, 30 Jan 2013 17:48:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> To: Eric McMurry , "THIEBAUT, LAURENT (LAURENT)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 166.137.113.1 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 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 Jan 2013 23:48:59 -0000 Hi, please see comments inline.=20 (Apologies for the late response--I'm catching up on email after = vacation.) On Jan 24, 2013, at 1:04 PM, Eric McMurry wrote: > Thanks Laurent. >=20 > comments inline. >=20 >=20 > Eric >=20 >=20 > On Jan 24, 2013, at 9:27 , "THIEBAUT, LAURENT (LAURENT)" = wrote: >=20 >> =20 >> =20 >> Hello all >> Please find below our remarks on draft = draft-ietf-dime-overload-reqs-03 about Diameter Overload Control = Requirements >> =20 >> These remarks address topics we have already addressed over Dime but = for which we think some enhancements to the text is needed. >> We hope to converge quickly as we believe that based on these small = enhancements draft-ietf-dime-overload-reqs-03 should be finalized ASAP = and moved forward into the IETF standardization process. >> =20 >> 1. REQ 2: The mechanism MUST allow Diameter nodes to support = overload >> control regardless of which Diameter applications they >> support. The mechanism MUST allow Diameter applications >> to be aware of an overload situation. >> We believe that a proper handling of a Diameter server overload is to = report it at the level of its Diameter client applications in order for = them to take proper decisions. This may mean to send signalling towards = non Diameter entities. >> This may relate with the comment made by Hannes. >> =20 >=20 > As in the current draft, do you think this requirement can be = interpreted to say that a diameter stack should handle overload without = application intervention and that implementations of overload control = mechanisms are required to act in that fashion? >=20 > I'm struggling a bit with this since I'm reading it as a requirement = on implementations of the overload control mechanism (as opposed to = requirements on the specification of the mechanism). Is it reasonable = to require a stack to not handle overload control by itself? My personal opinion is that the draft should not talk about software = architecture--just protocol behavior.=20 OTOH, I'm not sure if Laurent meant to refer to the separation between = the Diameter application and stack on a Diameter node, or the client = application that Diameter is supporting. If the second, I agree putting = a few words to that effect could be useful. (For example, if the = Diameter client at a NAS cannot successfully perform an authorization, = it might have to cleanly reject a network attachment attempt. The = details of that rejection would be out of scope for the overload control = mechanism, but the client would still need to Do the Right Thing) >=20 >> =20 >> =20 >> 2. We recommend to add following requirement: >> REQ xx: The overload control mechanism MUST allow networks to = properly support Diameter signalling related with emergency and/or = priority users. >> This aspect is mentioned in Req 26 but only as a general guidance = while this is a strong operational requirement. >> =93For example, it may be more beneficial to process messages for >> existing sessions ahead of new sessions, or to give = priority >> to requests associated with emergency sessions or with = high >> priority users.=94 >> =20 >> =20 >> =20 >=20 >=20 > What does this mean for a mechanism? How would it be done? This seems to me to be more like a more application specific requirement = than a generic Diameter requirement. If so, I think that would be better = specified in whatever document might exist to specify how a particular = application might incorporate the overload control mechanism. (For = example, in a 3GPP document.) >=20 >> =20 >> 3. REQ 35: The mechanism SHOULD provide a method for exchanging >> overload and load information between elements that are >> connected by intermediaries that do not support the >> mechanism. >> We recommend to replace =93The mechanism SHOULD provide a method=94 = by =93The mechanism MUSTprovide a method=94 as it is a key requirement = for deployments especially via intermediate networks. >> =20 >> =20 >=20 > Personally, I'm on the fence here. The main issue I have is that any = end to end, or end to information source method that passes through = intermediaries that don't support the mechanism brings with it an = absolute requirement for end to end security. Given the state of end to = end security, this will cause substantial delay to deployment of = overload control. There is a middle ground where a mechanism that could = support end to end is required to only be used hop by hop without end to = end security in place. That may be compatible with the suggested change = to the requirement but it will have to be considered. >=20 > There is also the consideration that a mechanism that requires = hop-by-hop action for overload control could be a reasonable or = necessary approach, given the potential complexity of the networks = involved and the implications of that on what the overload information = contains. >=20 > At any rate, if the change is made, we must also add the additional = security requirement ensuring that the mechanism is not used without end = to end security (this is implied by REQ 28, but it needs to be made = explicit). I think I concur with Eric here--there's a potential for some surprises = here. I think we need more analysis of the security and architectural = implications of true hop-by-hop vs allowing non-adjacent nodes to = communicate overload information. I wonder if we can delegate that to = the actual mechanism work, or a separate document than this one?=20 >=20 >> =20 >> =20 >> =20 >> 4. We recommend to add following requirement >> REQ yy: The mechanism MUST support a default overload algorithm. = This will facilitate interoperability especially between Networks. >> =20 >=20 > I think this would make explicit what is implicit now. I don't see = any issue with adding it. Others should certainly feel free to = contradict me on that. >=20 I concur. (that we should add the explicit statement, not that people = should contradict you :-) ) [...]= From trac+dime@trac.tools.ietf.org Wed Jan 30 16:23:26 2013 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 57C1E21F87A5 for ; Wed, 30 Jan 2013 16:23:25 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQc1Ku3XxDzm for ; Wed, 30 Jan 2013 16:23:24 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AC9D521F8734 for ; Wed, 30 Jan 2013 16:23:23 -0800 (PST) Received: from localhost ([127.0.0.1]:50474 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U0hvz-00068o-CD; Thu, 31 Jan 2013 01:23:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-overload-reqs@tools.ietf.org, emcmurry@computer.org X-Trac-Project: dime Date: Thu, 31 Jan 2013 00:23:19 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/22 Message-ID: <063.45b1591034a7b3ba091d1456a2c2172a@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-dime-overload-reqs@tools.ietf.org, emcmurry@computer.org, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, emcmurry@computer.org Resent-Message-Id: <20130131002323.AC9D521F8734@ietfa.amsl.com> Resent-Date: Wed, 30 Jan 2013 16:23:23 -0800 (PST) Resent-From: trac+dime@trac.tools.ietf.org Cc: dime@ietf.org Subject: [Dime] [dime] #22: explicit requirement for a default algorithm is needed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 00:23:26 -0000 #22: explicit requirement for a default algorithm is needed There is an implicit requirement that there be a default overload control algorithm. Clarity will be enhanced if this is made explicit. This was pointed out by Laurent Thiebaut. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dime-overload- emcmurry@computer.org | reqs@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: overload- | Version: reqs | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: dime